When the software project is ready to be delivered to the client, it is crucial to ensure the quality the client expects, as well as to check that the criteria that were agreed upon in the definition of the project are met. But, how do we provide quality software to the clients? The answer is by doing testing.
What is testing?
According to my experience in software projects, testing is a destructive process in which the main objective is to find defects in the code of the software. So, if you find defects your testing will be successful.
The role of the tester in the development process
The concept of the tester arises from the commitment to quality. Every development team in a software company should have at least one person responsible for ensuring the proper functioning of the software that was developed and is ready to be delivered to the customer. This person will test and ensure the quality of the software.
The tester should not be interpreted as someone who judges the work of the developer or who is constantly correcting what others are doing wrong, on the contrary, the tester should be seen as the one who is going to work together and in a team with the developer to improve the requirements requested by the clients and preventing them from finding errors.
That is why it is very important that both tester and developer work together to achieve the expected results in an efficient way. But, how do we achieve this? One of the central points for me is good communication. The tester should be able to clearly communicate the detected errors to the developer and cooperate with as much information as possible in order to reproduce them and avoid misunderstandings.
Testers should also:
- Work calmly under pressure
- Pay attention to details
- Be organized
- Able to solve problems
- Be methodic and creative
- Recommend ways to improve the software.
These two closely related concepts in the world of testing have similarities but not the same meaning.
On the one hand, when we Validate, we should ask ourselves the following question: Are we building the right system? The software should do what the customer actually asked for.
On the other hand, when we Verify, we should ask ourselves this question: Are we building the system correctly?. Verify that the software conforms to your specification.
With these two concepts, we can answer the question of Why testing is necessary? to verify that the software meets the requirements and validate that the functions are implemented correctly.
Moreover, other reasons are:
- To reduce risks
- To build confidence in my product
- Because failures are very expensive
- Because the existence of defects in the software is inevitable.
There are several principles of testing. Some of the most important to me when testing is:
- Testing shows the presence of defects. We have to be sure that the software we are going to test has defects and I, as a tester will find them.
- Exhaustive testing is impossible. It is considered impossible to test all software. I’m going to have to make a decision about what I’m going to test, and this depends on the scope of the tests defined in the plan.
- Early testing. Testing can begin from the moment the customer requests changes to the software or defines its requirements. It is not necessary to wait for the developer to deliver a version to be tested.
- Defects are grouped together. Defects in a given software or application tend to be grouped together. If I find a defect in a software module, I will have to pay attention because other defects may exist or be caused.
- Pesticide Paradox. Like the continued use of a pesticide, a set of test cases that are used repeatedly will decrease ineffectiveness, as new defects will not be found. It is necessary to define new test cases and include them in the plan or to change the data with which it will be tested.
- Testing depends on the context. The same test object will be different in diverse test contexts.
- The absence of errors is a fallacy. It is necessary to consider that all software or applications at the moment of being tested have errors. There is always something we can improve or solve.
Testing and documentation
Although documenting is a tedious task, I think it’s very important to do it because it’s evidence of all the testing we do on certain software. Besides, it’s a way of communicating with the team.
It is used to repeat test cycles when defects need to be corrected.
A good way to document for a tester is to make the definition of test cases. But, how should a test case be composed?
Some parts of the test cases could be:
- Test Case name
- Purpose of Test Case
- Test type
- Steps of execution
- Results obtained
- Expected results
- Status of executed test case
You can also add as documentation the testing plan, and something very important for me and necessary is to document the defect, so you can track it and it can be easily reproduced by the developer.
LEARN SOFTWARE TESTING IN PONDY IT TRAINING Iin Pondicherry.