Fundamentals of Software Testing
Software testing is a vast subject. There are software applications and system engineered for numerous domains and industries, and for a tester, every testing project is a new challenge because he has to understand the client’s point of view and the domain before moving on with testing activities. From project to project, a tester may have to change the testing methodologies as well. It is therefore very important to keep the fundamentals right. Getting the fundamentals right in the first place is biggest prerequisite to become successful in software testing.
Why Software Testing Is Necessary?
An error, defect or a bug can be caused by developers. It is not intentional but considering the complexity with which various software are being developed these days, it is quite possible for a developer to misunderstand and implement wrong logic and produce wrong code.
Testing is necessary because it helps us in identifying the faults in software. Once these defects have been detected they can be easily rectified and quality of the software can be improved. So, software testing is necessary so that bug free applications can be developed and delivered. When a company decides to develop software for a client there are certain legal, contractual and industry-specific requirements based on the deal is made. A quality conscious company will definitely include software testing in its best practices.
It is difficult to say how much testing is enough but the fact is that if testing is planned carefully and good test cases are made then it is very much possible to deliver high quality software.
Who Does The Software Testing?
There is often a debate on who should actually test the software. People often question that why developers are not allowed to test. Well, a developer generally checks his code several times before he submits it for testing and still in most cases it is never error free because a developer is generally blind to his own mistakes.
A tester on the other hand looks at software from the point of view of the client. He is unbiased and his focus is only on the specifications and the requirements. So, a tester is able to look into areas that a developer may have ignored. So, the testing should always be carried out by independent testers.
This approach does have some disadvantages. When the development and testing teams are different there is often a communication gap and sometimes, developers become careless towards coding and do not revise their code because they think that it is all a tester’s job thereby increasing the burden on the tester.
Many times developers share their work amongst each other and test each other’s work. This is known as buddy testing. Every development team should have dedicated testers and every project generally has at least one dedicated testing team. Some companies believe in having separate teams for different types of testing, this means different teams for usability, performance, security and other forms of testing. Some companies believe in outsourcing software testing work which means they hire a firm or independent testers or consultants to have a look at and test their project.
What Has To Be Really Tested?
The tester should have a good understanding about the project requirements. A fair idea about the real time scenario where the software will be implemented can help the tester understand how to carry out testing for the project. It is very important to know what has to be really tested in order to devise a testing strategy.
What Has To Be Really Tested?
When Is The Software Testing Done?
The earlier the testing team starts testing the software the easier it would be for the developers to complete the project on time and this would also save a lot of time, money and effort. Starting testing in the later stages of development can turn out to be an expensive matter as it is very difficult to rectify defects once the software has reached the final stages of development.Dividing software development into stages and then testing work done in every stage before moving on to the next stage helps in finishing the software development in time with good results. This also helps in better integration of different modules because you already know that every module has been tested independently and is working as per the given specifications.
How Often Do We Need To Test?
How often you need to test depends on how important the quality is for you. Ideally, testing should go hand in hand with development and a tester should focus on discovering maximum number of defects during the initial phases of software development so that if the design of the software requires any changes then it can be done early as it will be very difficult and expensive to make major changes in the project during the later stages of development.
How Often Do We Need To Test?
What Are Software Testing Standards?
Software testing standards are of great importance from the consumer’s as well as producer’s point of view. A consumer invests in the software and if the software is of good quality then at the end of the day he is satisfied that he has purchased the right thing for himself.
All reputed companies ensure that the software quality of product is governed by some sets of standards that have been approved by the public. By abiding by these standards a company gives assurance about its products and it is able to give guarantee to its customers only when it has followed some standards and knows that the software will behave in a certain manner. So, consumer knows that he is buying the right thing if it is of right standard.
From a producer’s point of view standards help in improving the quality of the final product. Once a company has finalized the standard that it has to follow then it becomes easier for them to work on other software projects and whenever they start a new project they do not need start everything from scratch.There are many types of software testing standards defined for evaluating quality of software which can greatly improve the effectiveness of software testing however it is believed that till now no such standards have been made that can cover all aspects of software testing.
Standards that emphasize on having testing as part of larger requirement or standards supporting software testing are the ones that can be of use for software testing.
What Is Software Testability?
Software testability is used to measure how easily a software system can be tested. Testability is calculated in the early phases of software development in order to find out how many resources will be needed to finish of the testing process. While testing helps in uncovering defects, testability plays a significant role in identifying the key areas where bugs remain hidden from a tester’s view. When testability is high it means that testing is easier and lower testability means that the testing effort should be increased. Testability can be determined by:
- Controllability: Testing process can be optimized only if we can control it.
- Observability: What you see is what can be tested. Factors affecting the final outcome are visible.
- Availability: In order to test a system we have to get at it.
- Simplicity: When the design is self-consistent, features are not very complex and coding practices are simple then there is less to test. When the software is not simple anymore it becomes difficult to test.
- Stability: If too many changes are made to the design now and then there will be lot of disruptions in software testing.
- Information: Efficiency of testing greatly depends on how much information is available for the software.
Here is what you need to know about testability:
- Higher testability means better tests and less amount of bugs
- Lower testability means the tests are not of great quality and there is a possibility of more bugs in the system
Software Verification VS Software Validation
Verification and validation are two very important terms in software testing. People often get confused between the two however these two terms are related to two different types of analysis. Validation is helps in building the right system. While carrying out validation we look at whether the system is in line with customer’s requirement or not.
Verification on the other hand helps in ensuring if the system is being developed in the right way. The focus of verification is on the quality of software that is being developed, whether it follows all the standards or not, is it well engineered?
So while validation checks if the specifications have been designed correctly to meet the customer’s requirement, the verification checks if the software has been developed as per the software quality standards and norms of the software engineering organization.
Software Verification VS Software Validation
Some theories suggest that verification is carried out in every phase of software development lifecycle but the same is not the case with validation. Validations are crucial in the beginning and towards the end of the project, i.e. during the requirement analysis and acceptance testing. This tactic is not fully correct and almost impossible to follow. The actual fact is that until today it has been observed that it is very difficult to capture the entire set of client requirements during the beginning of the project. Software requirements often undergo several changes even after the development has started. Many times the changes are requested by the development team itself. It is therefore important to carry out validation and verification processes in every phase of software development.
Today, testers usually consider verification and validation also known as V&V as a powerful way of looking at various aspects of the software.
Software Testing VS Software Debugging
This is another topic where people generally get confused. Software testing and debugging may sound like one and the same thing but that is not actually the case. To start with, the process of debugging starts when software testing gets over. While software testing uncovers defects, debugging removes defects from the system.
Once testing is completed the testers submits the reports and the development team starts looking for the root cause of the defects. In this process the developer scans all the related modules and tries to find out the problem in the code; once that is done it is time to rectify the defect. So, debugging is the process in which the cause of reported defects is found out and then defects are rectified step by step.
Debugging is the process of resolving existing issues. It not wise to rectify a defect till all possible reasons behind it isfully known. If you start debugging without complete knowledge about the defect then there are chances that in the process of rectifying one defect you may introduce some other in any of the interrelated modules. Developers should avoid experimentation at the time of debugging as this can cause a lot of problems. Once a defect is fixed the developer submits the work to the tester, who will thoroughly test the entire module.
- Software testing uncovers defects and debugging locates and corrects it.
- Software testing is a very important aspect of software development cycle whereas debugging is a result of testing activities.
- Testing begins soon after development starts. Debugging starts when testers start reporting defects.
- Software testing involves verification and validation (V&V) of the software whereas debugging looks in to actual cause behind the defect and corrects it.
What Is A Defect?
Defect is anything that is not in line with the software requirement specifications. Defect generally exists either in the code of the program or in its design. This results in incorrect output at the time of execution of the program.
- A piece of code is called buggy when it has too many defects.
- Bug reports the details about the nature of the bug.
- Bug tracking tools are employed to track bugs in a system.
- There is a very interesting testing technique in which defects are purposely injected into the code and then the outcome is monitored to check if the system works as expected in case of certain issues.
What Is A Defect?
What Are Severity And Priority?
Severity defines how severe will be the impact of a defect on the performance of the system. The severity can be of one of the following types:
- Critical: Such adefect does not allow the application to work properly due to system failure or corruption of data. Critical defects do not allow the user to move any further and puts them in a miserable position.
- Major: The major defects are little less severe than critical defects. They can cause system to fail, however in case of major defect there is another possible way of achieving the desired result and the user need not get trained for this.
- Moderate: These defects do not cause the system to fail but produce wrong or contradictory output.
- Minor: Defects that do not cause system failure or affect the usability of the system and can be easily rectified are known as Minor defects.
- Cosmetic: Defects related to the outlook or appearance of the system are called cosmetic defect.
When a defect is reported, the test report mentions priority along with the severity of the defect. Priority actually tells the developer the order in which defects should be resolved. It can be of the following types:
- Low: the defect does not require immediate attention and should be rectified after the defects with higher priority have been resolved.
- Medium: The defect should be resolved soon after the defects with higher priority have been resolved.
- High: The defect with high priority means that it requires immediate attention and should be resolved as soon as possible.
So, once you are provided with the report of severity and priority of defects here is what you need to know:
What Are Severity And Priority?
- If a defect has high priority and high severity, then it means that there is a problem in the basic functionality of the system and the user is not in a position to use the system. Such defects should be rectified immediately.
- Defects having high priority and low severity can be something like spelling mistake in the company’s name or issues with logo. Such defects are of low severity but must be rectified immediately and should be considered as high priority defect.
- High Severity and low priority defect means that there is a major defect in some module but the user would not be using it immediately so the defect can be rectified a little later.
- Low priority and low severity defects are generally cosmetic in nature and do not affect the functionality of the system hence such defects are rectified in the end.
TEST INSTITUTE™
