Mistakes Testers Make
Introduction
Although testing is the most time-consumining and expensive phase in the
Software development lifecycle of a project. There are mistakes most testers make while testing, such as in planning the testing effort, in dealing with personnel issues & in tackling that arise the tester is engaged in testing.
In a software development project, errors can come up at any stage & these
manifest themselves in the code. The problem is that in the early phases of development, the verification is done manually as no executable code exists. As errors are not removed at this stage, their presence becomes a nuisance during coding. So the finally constructed code not only has errors made during coding but also has requirement errors and design errors. Testing is the phase where errors carried over from all the previous phase detected. It plays a key role in quality assurance and ensuring the software’s reliability at different places. And the program is executed to check whether the errors exist or not.
Where are the mistakes?
Testing is the most important phase in the software development
Lifecycle & the maximum cost & effort are expended at this stage. But unfortunately, mistakes are made when testing software or planning a testing effort.
These mistakes can be broadly classified into three categories:
Planning the testing effort:
a. Performing functional testing only.
b. Under-emphasizing configuration testing:
c. Not testing installation procedures & documentation:
d. Completing one test task before moving to the next:
Planning the tests:
Let’s try & analyze each mistakes type. Most testers make the mistake of functional
testing, i.e. testing particular feature in isolation. For Example, in MS WORD, all the files creating text options are first demonstrated, & all then the editing features are examined. But one factor that is forgotten is that these features do not work in isolation. They interact among themselves. Functional testing doesn’t take this factor into account.
Introduction
Although testing is the most time-consumining and expensive phase in the
Software development lifecycle of a project. There are mistakes most testers make while testing, such as in planning the testing effort, in dealing with personnel issues & in tackling that arise the tester is engaged in testing.
In a software development project, errors can come up at any stage & these
manifest themselves in the code. The problem is that in the early phases of development, the verification is done manually as no executable code exists. As errors are not removed at this stage, their presence becomes a nuisance during coding. So the finally constructed code not only has errors made during coding but also has requirement errors and design errors. Testing is the phase where errors carried over from all the previous phase detected. It plays a key role in quality assurance and ensuring the software’s reliability at different places. And the program is executed to check whether the errors exist or not.
Where are the mistakes?
Testing is the most important phase in the software development
Lifecycle & the maximum cost & effort are expended at this stage. But unfortunately, mistakes are made when testing software or planning a testing effort.
These mistakes can be broadly classified into three categories:
Planning the testing effort:
a. Performing functional testing only.
b. Under-emphasizing configuration testing:
c. Not testing installation procedures & documentation:
d. Completing one test task before moving to the next:
Planning the tests:
Let’s try & analyze each mistakes type. Most testers make the mistake of functional
testing, i.e. testing particular feature in isolation. For Example, in MS WORD, all the files creating text options are first demonstrated, & all then the editing features are examined. But one factor that is forgotten is that these features do not work in isolation. They interact among themselves. Functional testing doesn’t take this factor into account.
a. Performing functional testing only:
As an example, sequences of operations such as ‘open a file, edit it, and edit one
page’ may not work though each of these features might work in isolation. Customers, on the other hand, need to combine all these features and then employ them. They will not go in for task orientation. In order to value what bugs the customer might see, we have to develop tests that criss-cross functional areas. This type of testing is called task-based testing, scenario testing. This criss-crossing of functions might not cover all the functions. So test cases should be conducted so that a certain number of functions are grouped together. However, testing should not be carried to a stage where a particular feature is made compatible with each and every other feature. For example, in MS Word there are so many features that it is not possible to carry out so many tests. Also, we might not use a set of features with a particular feature.
b. Under-emphasing Configuration Testing:
We have so far dealt with tests for features of a particular program Or software.
But we also have to look into how the software interacts with other software interacts with other software and different hardware. This kind of testing is very expensive and difficult to perform, as it requires a well-stocked lab filled with hardware of different types and various software. Those who have developed the software may claim that it meets industry standards, but in reality it doesn’t when tried out on different machines. Yet another type of testing is one that is done under stress, such as a large number of simultaneous transactions.
One major mistake developers make is that of putting off local & stress testing till the last minute. This is a very common mistake, as a result of which developers realize at the last minute that their software doesn’t work for more than of a few users.
c. Not testing installation procedures and documentation:
Documentation is the process of indenting comments in the software
to explain various steps. You should check proper documentation has been carried out. Otherwise it is difficult for another user to understand the program and maintain it over a period of time. Proper documentation is characteristic of good quality software. We should check for different installation procedures on different machines and also on the same machine, starting right from the first step. If the product runs into installation problems, it will make a long-lasting bad impression on the customer.
d. Completing one test task before moving to the next:
There is a general tendency to finish one testing task before moving on to the
next. But this is not the way testing should be done. We have to test all areas simultaneously, as an overall picture is than understanding thoroughly only a select area. If the problem areas in the entire software are discovered early then these can be tested more effectively. In the entire software, some areas are more prone to failure. A common mistake is to fail in risky areas. Testing these areas requires greater effort & is very crucial.
But how do we identify the risky areas? This can be done by talking to developers, workers, customer support people and others, and getting their opinion. You can also inspect previous data, such as bug reports from past products. On analyzing these reports you will get to know which areas are dangerous and which are not.
Personnel Issues:
a. Using testing as a transitional job for few programmers:
b. Appointing testers from the ranks of failed programmers:
c. Physical separation between testers and developers:
a. Using testing as a transitional job for few programmers:
When a newcomer is taken into company, the project manager does not know
much about his or her software development talents. Because the manager doesn’t want to take a risk by asking these newcomers to develop code, he uses them to test code, thinking that they would do less damage as testers than as developers.
In some companies, testers are students who may have to the office for summer project or those who do not have a formal degree or learning. Hiring such temporary testing staff would work only if testing were a shallow algorithmic discipline. However, good tester requires deep knowledge and experience in software development. Testing is the most important stage in the lifecycle of project, & having novices on the deck will only jeopardize the project.
b. Appointing testers from the ranks of failed programmers
In lot of companies, the testing job is viewed as punishment in work cycle of a developer. A major mistake that is committed is hiring failed programmers for this job. A person who is not good in programming may not be bad at testing.
So how do you setup a testing team? Well, you need to interview and hire applicant for the job by looking for some specific qualities. Lets take a look at the qualities a good tester must posses. These are:
Above average writing and verbal skills:
This is very important, as tester have to explain bugs clearly and concisely. Unless the bugs are pinpointed in great detail, it is difficult to correct them.
Systematic in approach:
They should be methodical and systematic in their approach to testing the software,
i.e. they should not leave certain code & then go back & test it again.
Being sceptical:
The tester should not take the software for granted; He should be rather suspicious about the assumptions until he sees concrete evidence. This is because many programmers, in order to make their work easy, make a number of assumptions, which are not true. In such cases, the software might work only for a certain range of tests. This is the very important quality of testers.
He should be willing to experiment:
The tester should explore all assumptions & should be in position to take the extra trouble in experimenting with the code. He should be willing to try new things.
As an example, sequences of operations such as ‘open a file, edit it, and edit one
page’ may not work though each of these features might work in isolation. Customers, on the other hand, need to combine all these features and then employ them. They will not go in for task orientation. In order to value what bugs the customer might see, we have to develop tests that criss-cross functional areas. This type of testing is called task-based testing, scenario testing. This criss-crossing of functions might not cover all the functions. So test cases should be conducted so that a certain number of functions are grouped together. However, testing should not be carried to a stage where a particular feature is made compatible with each and every other feature. For example, in MS Word there are so many features that it is not possible to carry out so many tests. Also, we might not use a set of features with a particular feature.
b. Under-emphasing Configuration Testing:
We have so far dealt with tests for features of a particular program Or software.
But we also have to look into how the software interacts with other software interacts with other software and different hardware. This kind of testing is very expensive and difficult to perform, as it requires a well-stocked lab filled with hardware of different types and various software. Those who have developed the software may claim that it meets industry standards, but in reality it doesn’t when tried out on different machines. Yet another type of testing is one that is done under stress, such as a large number of simultaneous transactions.
One major mistake developers make is that of putting off local & stress testing till the last minute. This is a very common mistake, as a result of which developers realize at the last minute that their software doesn’t work for more than of a few users.
c. Not testing installation procedures and documentation:
Documentation is the process of indenting comments in the software
to explain various steps. You should check proper documentation has been carried out. Otherwise it is difficult for another user to understand the program and maintain it over a period of time. Proper documentation is characteristic of good quality software. We should check for different installation procedures on different machines and also on the same machine, starting right from the first step. If the product runs into installation problems, it will make a long-lasting bad impression on the customer.
d. Completing one test task before moving to the next:
There is a general tendency to finish one testing task before moving on to the
next. But this is not the way testing should be done. We have to test all areas simultaneously, as an overall picture is than understanding thoroughly only a select area. If the problem areas in the entire software are discovered early then these can be tested more effectively. In the entire software, some areas are more prone to failure. A common mistake is to fail in risky areas. Testing these areas requires greater effort & is very crucial.
But how do we identify the risky areas? This can be done by talking to developers, workers, customer support people and others, and getting their opinion. You can also inspect previous data, such as bug reports from past products. On analyzing these reports you will get to know which areas are dangerous and which are not.
Personnel Issues:
a. Using testing as a transitional job for few programmers:
b. Appointing testers from the ranks of failed programmers:
c. Physical separation between testers and developers:
a. Using testing as a transitional job for few programmers:
When a newcomer is taken into company, the project manager does not know
much about his or her software development talents. Because the manager doesn’t want to take a risk by asking these newcomers to develop code, he uses them to test code, thinking that they would do less damage as testers than as developers.
In some companies, testers are students who may have to the office for summer project or those who do not have a formal degree or learning. Hiring such temporary testing staff would work only if testing were a shallow algorithmic discipline. However, good tester requires deep knowledge and experience in software development. Testing is the most important stage in the lifecycle of project, & having novices on the deck will only jeopardize the project.
b. Appointing testers from the ranks of failed programmers
In lot of companies, the testing job is viewed as punishment in work cycle of a developer. A major mistake that is committed is hiring failed programmers for this job. A person who is not good in programming may not be bad at testing.
So how do you setup a testing team? Well, you need to interview and hire applicant for the job by looking for some specific qualities. Lets take a look at the qualities a good tester must posses. These are:
Above average writing and verbal skills:
This is very important, as tester have to explain bugs clearly and concisely. Unless the bugs are pinpointed in great detail, it is difficult to correct them.
Systematic in approach:
They should be methodical and systematic in their approach to testing the software,
i.e. they should not leave certain code & then go back & test it again.
Being sceptical:
The tester should not take the software for granted; He should be rather suspicious about the assumptions until he sees concrete evidence. This is because many programmers, in order to make their work easy, make a number of assumptions, which are not true. In such cases, the software might work only for a certain range of tests. This is the very important quality of testers.
He should be willing to experiment:
The tester should explore all assumptions & should be in position to take the extra trouble in experimenting with the code. He should be willing to try new things.
Physical separation between testers and developers:
Developers & testers must often work together in debugging. It is
much easier to find bugs when the tester is able to understand the logic used by the developer easily. This is because developers often pay attention to documentation & the code is not properly understood. There is a well-built notion that programmers can’t test their own code. This notion is entirely false.
Another major problem in getting programmers to do testing is that they are neither trained nor motivated to test. The general feeling is that if you are testing programs you are doing low-grade work. But this trend is gradually changing in quite a few companies & testing.
Issues arising while the tester is engaged in testing:
a. Not paying attention to designing tests:
b. Being too specific about test inputs and procedure:
a. Not paying attention to designing tests:
A Tester generally has the speed in breaking the program as a programmer
has in writing code. The result is that design work is overlooked quality suffers. A tester has to be methodical in his approach. He has to layout all possibilities in advanced & especially take care to check out the special cases. These special cases are the same that the programmer also would have over looked, so the bugged that was not discovered by the programmer remains undiscovered by the tester. Reviews have to be carried out on the test design to find significant omissions.
b. Being too specific about test inputs and procedure:
Suppose you are testing a banking application. Here are 2 possible test designs:
Design 1:
Setup: Initialize the balance in account 12 with US $100.
Procedure:
Start the program.
Type 12 in account window.
Press OK.
Click on ‘Withdraw’ toolbar button.
In the withdraw popup dialogue, click on the ‘all’ button.
Press OK.
Expect to see a confirmation popup that says “You are about to withdraw all the money from this account. Continue?”
Press OK.
Expect to see a 0 balance in the account window.
Separately query the database to check that the zero balance has been posted
Exit the program with File - > Exit.
Design 2:
Setup: Initialize the balance with a positive value.
Procedure:
Start the program on that account.
Withdraw all the money from the account using ‘all’ button.
It’s an error if the transaction happens without a confirmation popup.
Immediately thereafter:
Ø Expect a US $0 balance to be displayed.
Ø Independently query the database to check that the zero balance has been posted.
The first design style has two advantages:
Ø The test will always be run the same way. You are more likely to able to reproduce the bug. So will the programmer.
Ø It details all the important expected results to check. Imprecise expected results make failure harder to notice. For example, A tester using the second style would find it easier to out look a spelling error in the confirmation popup, or even that it was the wrong popup.
However there are some disadvantages:
Ø The first style is more expensive to create.
Ø The inevitable minor changes to the user interface will break it, so it more expensive to maintain.
CONCLUSION
Testing is the most time consuming and expensive phase in Software development lifecycle. There are mistakes most testers make while testing.
In software development project, errors can come up at any stage and these manifest themselves in the code.
For removing mistakes from the project, we have to plan first i.e. (planning the testing effort), and try to a remove that errors and make the project success fully run.
Reference: -
Magazine: -
IT MANAGEMENT PROFESSIONAL
www.sofquality.com
www.testingprof.com
Developers & testers must often work together in debugging. It is
much easier to find bugs when the tester is able to understand the logic used by the developer easily. This is because developers often pay attention to documentation & the code is not properly understood. There is a well-built notion that programmers can’t test their own code. This notion is entirely false.
Another major problem in getting programmers to do testing is that they are neither trained nor motivated to test. The general feeling is that if you are testing programs you are doing low-grade work. But this trend is gradually changing in quite a few companies & testing.
Issues arising while the tester is engaged in testing:
a. Not paying attention to designing tests:
b. Being too specific about test inputs and procedure:
a. Not paying attention to designing tests:
A Tester generally has the speed in breaking the program as a programmer
has in writing code. The result is that design work is overlooked quality suffers. A tester has to be methodical in his approach. He has to layout all possibilities in advanced & especially take care to check out the special cases. These special cases are the same that the programmer also would have over looked, so the bugged that was not discovered by the programmer remains undiscovered by the tester. Reviews have to be carried out on the test design to find significant omissions.
b. Being too specific about test inputs and procedure:
Suppose you are testing a banking application. Here are 2 possible test designs:
Design 1:
Setup: Initialize the balance in account 12 with US $100.
Procedure:
Start the program.
Type 12 in account window.
Press OK.
Click on ‘Withdraw’ toolbar button.
In the withdraw popup dialogue, click on the ‘all’ button.
Press OK.
Expect to see a confirmation popup that says “You are about to withdraw all the money from this account. Continue?”
Press OK.
Expect to see a 0 balance in the account window.
Separately query the database to check that the zero balance has been posted
Exit the program with File - > Exit.
Design 2:
Setup: Initialize the balance with a positive value.
Procedure:
Start the program on that account.
Withdraw all the money from the account using ‘all’ button.
It’s an error if the transaction happens without a confirmation popup.
Immediately thereafter:
Ø Expect a US $0 balance to be displayed.
Ø Independently query the database to check that the zero balance has been posted.
The first design style has two advantages:
Ø The test will always be run the same way. You are more likely to able to reproduce the bug. So will the programmer.
Ø It details all the important expected results to check. Imprecise expected results make failure harder to notice. For example, A tester using the second style would find it easier to out look a spelling error in the confirmation popup, or even that it was the wrong popup.
However there are some disadvantages:
Ø The first style is more expensive to create.
Ø The inevitable minor changes to the user interface will break it, so it more expensive to maintain.
CONCLUSION
Testing is the most time consuming and expensive phase in Software development lifecycle. There are mistakes most testers make while testing.
In software development project, errors can come up at any stage and these manifest themselves in the code.
For removing mistakes from the project, we have to plan first i.e. (planning the testing effort), and try to a remove that errors and make the project success fully run.
Reference: -
Magazine: -
IT MANAGEMENT PROFESSIONAL
www.sofquality.com
www.testingprof.com
No comments:
Post a Comment