Articles
Windows FAQ
PHP Installation Problem with php5ts.dll - What is wrong if you ...
Introduction of Windows PowerShell - Where to find introduction ...
What Is Windows PowerShell - What is Windows PowerShell? - Rank:...
Main Features of Windows PowerShell - What are main features of ...
Differences between Windows PowerShell and cmd.exe - What are di...
Who's Online
9 user(s) are online (2 user(s) are browsing Forum)

Members: 0
Guests: 9

more...
   All Posts (luck)


« 1 (2) 3 4 5 ... 33 »


Why Your Bugs are Getting Rejected
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
Why Your Bugs are Getting Rejected

Bug Rejection and Reasons behind it

Rather than revealing the list, I would like to share the outcome bullet points of the list. Here it is –

#1. Misunderstanding the requirements:

For any reason, if you did not understand the requirement properly, you would definitely look out for the misinterpreted requirement in actual implementation and when you would not find it, it would be a bug according to you, which will finally get rejected.

Real life Example: After testing a recipe, you found that it was tasteless as salt was not added but you did not know that salt was supposed to be added at the time of serving otherwise it can affect the look of recipe.

#2. Requirement implementation:

As a part of earlier discussion, you were aware that specific requirement was going to be implemented in XYZ way. But while development, developer found it was not possible to follow XYZ path and so he followed ABC path and that was not communicated to you. Ultimately, you are going to report a bug when you found the requirement was not implemented the way it was discussed.

Real life Example: You asked the tailor to prepare a shirt and when you were asked for trial, you rejected it saying you did not find buttons on it. When the tailor explains that putting on buttons on front would have impacted overall look of the shirt and hence he put it inside the front border, you would definitely dumbfounded.

#3. No clear requirements:

When there are no clear requirements available, everyone is free to assume the requirement in his/her own way and this leads to assumption at personal level. When you see that personal assumption is not satisfied, you mark it as a bug.

Real life Example: You need to draw a cycle, when the teacher announced she had expected the students to draw a bi-cycle. After half an hour, when she checked everyone’s drawing, she did not find anyone matching her expectation. Everyone took the vague statement in their own way and the outcome was a tri-cycle, baby cycle, too many cycles, cycle with wheel chair and so on.

#4. Change in requirement:

Another example of miscommunication, most of the time. When testers are not communicated about requirement changes, more bugs will be reported and ultimately rejected.

Real life Example: You are definitely going to reject the sandwich when you find it used honey bread rather than banana bread you ordered. Least you knew that your partner changed the bread type for order while you were on phone and of course he/she did not find it necessary to share it with you.

#5. Understanding scope:

While testing, you start testing something which should not be considered as testable at specific point or is not at all covered under product criteria; you are going to be a victim of bug rejection.

Real life Example: You are supposed to sweep a room and that is the only focus. Still if you complain about mess in the other areas, you are definitely going to be ignored.

#6. Test environment:

An application / product is a combination of many hardware and software requirements – major and minor both, and when proper test environment is not used or something is missing from test environment, application / product crashes and a critical bug reported….what happens next is – deep investigation because most of the time, we unintentionally do not take care to provide minor details about test environment we used and that increases developer’s work. Ultimately bug gets rejected.

Real life Example: Those yummy muffins you tasted at friend’s house before couple of days were awesome and after following the recipe the muffins were not even nearer to the one you had. Well, you were not supposed to use stale butter as fresh butter was not available, you were not supposed to add pinch of gram flour as you thought it might add the taste, you were not supposed to cook it on pan as the oven was out of order.

#7. Test data used:

Test data used for testing was mismatching with requirement.

Real life Example: Even after knowing that calculator is useful for numeric processing, if you try to add special characters and when calculator responds unexpectedly, you think it was improper. Really?

#8. Duplicate bug:

Someone has already reported the same bug and you did not take care to check for the same before reporting the bug. Again rejection.

Real life Example: The customer support person will not going to be happy when he receives multiple complain calls for same product from each family member. Wasn’t one call enough, he would think.

#9. Improper bug description:

When the developer does not able to understand what you were trying to convey via the bug report, expect it to be rejected because they are also loaded with other tasks and when they do not find proper description and required details in bug report, no matter how critical the bug is, it is expected to be marked as Rejected.

Real life Example: You need to unlock the car, should take a sit and should start by moving the keys in clockwise direction….the car did not start and so you are upset. Weren’t you instructed to check for petrol? Oh, mistake in manual as it assumed that you will surely understand that it should be by default checked.

#10. Non-reproducible bugs:

While reporting bug, you never realized the importance of reproducibility of the bug. Just making sure whether the bug is reproducible always or appears randomly can save hours of work and one more rejected bug.

Real life Example: What would the doctor check for when you complain about rough cold but he does not find any symptoms. Oh, I was just sneezing hard, will not make the situation better.

Conclusion:

Most of the time, our human nature allows us to think negatively when the bug reported is rejected. Genuinely, developers do not see specific reason to reject the bug if it is valid.

So, next time onwards, please do not focus on the bug count. Focus on qualitative bugs with proper details because ultimately what matters is how you helped in improving quality of the product and not how many bugs you reported.

Posted on: 12/4 16:45
Transfer the post to other applications Transfer


ETL Testing Techniques
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
ETL Testing Process:

Similar to any other testing that lies under Independent Verification and Validation, ETL also go through the same phase.

Business and requirement understanding
Validating
Test Estimation
Test planning based on the inputs from test estimation and business requirement
Designing test cases and test scenarios from all the available inputs
Once all the test cases are ready and are approved, testing team proceed to perform pre-execution check and test data preparation for testing
Lastly execution is performed till exit criteria are met
Upon successful completion summary report is prepared and closure process is done.


ETL Testing Techniques:

1) Verify that data is transformed correctly according to various business requirements and rules.
2) Make sure that all projected data is loaded into the data warehouse without any data loss and truncation.
3) Make sure that ETL application appropriately rejects, replaces with default values and reports invalid data.
4) Make sure that data is loaded in data warehouse within prescribed and expected time frames to confirm improved performance and scalability.

Apart from these 4 main ETL testing methods other testing methods like integration testing and user acceptance testing is also carried out to make sure everything is smooth and reliable.

Posted on: 2015/11/16 21:24
Transfer the post to other applications Transfer


What is Fuzz Testing?
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
Fuzz Testing

What is Fuzz Testing?

Fuzz testing is a software testing technique using which a random data is given as the inputs to the system. If the application fails, then those issues/defects are to be addressed by the system. In short, unexpected or random inputs might lead to unexpected results.

Fuzz Testing Phases:

Log defects -> identify Target System -->identify input
-->Generate Fuzz data --> Execute the test using Fuzz data
-->Monitor System behaviour -->Log defects


Attack Types

Number/Character Fuzzing

Application Fuzzing

Protocol Fuzzing

File Format Fuzzing

Posted on: 2015/11/2 20:30
Transfer the post to other applications Transfer


Microsoft Interview Question for Software Engineer in Tests about Algorithm
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
Microsoft Interview Question for Software Engineer in Tests about Algorithm


Find first repeated substring in a given input string.
1. The repeated strings can overlap.
2. The repeated string should not overlap.

char keyMap[10][5] = {"abc","def","ghi","jkl","mno","pqrs","tuv","wxyz"};


void rcsv_KeyPermute(char *keyNum, char *buf, int level, int end)
{
char *keys = keyMap[ *keyNum - '0' ];
char ch;
while( (ch = *keys++) != NULL )
{
*(buf + level) = ch;
if( level != end )
{
rcsv_KeyPermute( keyNum+1, buf, level+1, end );
}
else
{
*(buf + level + 1) = NULL;
cout << buf << " ";
}
}
}


void KeypadPermute(char *numbers)
{
int length = strlen(numbers);
char buf[100];
rcsv_KeyPermute(numbers, buf,0, length-1);
}

Posted on: 2015/10/19 20:35
Transfer the post to other applications Transfer


PERL and C Programs for Validating and Checking - Yawet
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
PERL and C Programs for Validating and Checking - Yawet

Yawet - Visual web test tool from InforMatrix GmbH enables graphical creation of web app tests. Create, run and debug functional and regression tests for web applications. Can verify HTML, XML, and PDF' ability to do report generation, reusable step libraires and parameterization. Freeware; download jar file and start by double-click or with command javaw -jar yawet.jar

Posted on: 2015/10/5 16:41
Transfer the post to other applications Transfer


PERL and C Programs for Validating and Checking - Regression Tester
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
PERL and C Programs for Validating and Checking - Regression Tester



Regression Tester - Web test tool from Info-Pack.com allows testing of functionality of any page or form Reports are fully customizable.

Posted on: 2015/8/24 16:53
Transfer the post to other applications Transfer


PERL and C Programs for Validating and Checking - SOASTA Concerto
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
PERL and C Programs for Validating and Checking - SOASTA Concerto

SOASTA Concerto - A suite of visual tools for automated web functional and load testing from SOASTA, Inc. Available as services on the web. Drag and drop visual interface that also allows access to underlying message complexity. Task-specific visual editors support creation of targets, messages, test cases, and test compositions. Works with Firefox and MSIE, Win and OSX.

Posted on: 2015/8/5 20:38
Transfer the post to other applications Transfer


PERL and C Programs for Validating and Checking - WET
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
PERL and C Programs for Validating and Checking - WET


WET - Open source web testing tool that drives MSIE directly; from Qantom Software Pvt. Ltd. Has many features like multiple parameter based object identification for more reliable object recognition, support for XML Based Object Repository and more. Scripting in Ruby; written in Ruby.

Posted on: 2015/7/16 16:32
Transfer the post to other applications Transfer


PERL and C Programs for Validating and Checking - Imprimatur
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
PERL and C Programs for Validating and Checking -
Imprimatur


Imprimatur - Free web functional testing tool by Tony Locke,
written in Java as a command-line application. Tests are described in a simple XML file; along with standard GET, POST and DELETE methods, handles HTTP authentication and file uploads. Responses can be validated using regular expressions.

Posted on: 2015/6/26 20:33
Transfer the post to other applications Transfer


How to Test When You Don’t Know the Language
Home away from home
Joined:
2007/11/1 12:10
Group:
Registered Users
Posts: 329
Level : 16; EXP : 94
HP : 0 / 398
MP : 109 / 10603
Offline
How to Test When You Don’t Know the Language

Here are a few things you can always test—regardless of whether you speak the language.
Check the Layout

Ensure that the layout of the website or application does not have any obvious errors, such as characters overlapping each other or misalignment of headings and text. This happens sometimes in localization, where the site was designed for English but the localized version uses another character set.
Recheck Functionality

You can test any form using basic tests, such as trying to enter too much data in an edit box, attempting to submit without filling out all required fields, and double-clicking the buttons. In most cases, you’ll already have a passing familiarity with the application in your own language and will understand its goals and purpose and how to try to thwart them.

As you do so, make use of the online translator you prefer to make sure that the error messages match up as much as possible with the failure you elicited.

Checking the Copy

You might have access to the copy deck that includes the translated text in the application. In some cases, this only includes labels for controls.

Even if you don’t have a copy deck, you can use Google Translate or other free online services to spot check the interface. For example, you want to make sure that the label for the user name field is reasonably similar to “user name.” You won’t be responsible for verifying the idiomatic appropriateness of the label, but you’ll know whether it’s close. In some cases, this might be your only insight into the edit boxes and what you should enter in them.

Reviewing for Inconsistencies

You can review the copy at a very high nontextual level for inconsistencies. If you recognize the alphabet, you can tell if sentences are beginning with capital letters. You can check formatting. You can just go with your well-developed sense of right and wrong.

Use the Alphabet

Most foreign languages have extra characters with accents or umlauts. Some use entirely different alphabets. When testing an application in a different language, use that alphabet when you enter the data to test not only whether the application or website can process them, but also whether it presents that information back to the user correctly. That is, make sure the member name Günter displays correctly in static text and in the Edit Member Name edit box.

Spot the English

Even if you don’t speak the language of the application, you’ll know how to spot your own language, so search through the application or website for instances of untranslated text. Make sure that boilerplate pages, copyright notices, mouse-over text on images and fields, and error messages display translated. Also look at text inside images.

Identify these locations and share them with the team. Your stakeholders might decide not to translate all the text, but they should make that decision and not discover the oversight later. This is commonly known as localization: making sure that when the text is translated, it is completely and consistently translated.

Posted on: 2015/6/12 16:49
Transfer the post to other applications Transfer



 Top
« 1 (2) 3 4 5 ... 33 »




Copyright (c) 2015 FYIcenter.com
Search
Main Menu
Login
Username:

Password:

Remember me



Lost Password?

Register now!