Many people’s doesn’t aware of the Testing Tsunami, If they do not plan project properly, as a result they set their project at high risk and Testing Tsunami comes in the picture. In this article we will try to cover the “What is Testing Tsunami and how to survive?”
What is Testing Tsunami?
As you aware of in general terms Tsunami is also called as “tidal waves” and Testing Tsunami means tidal wave of testing work which arises at the end of development cycle. The software development workload curve is exact opposite of testing workload curve. The development workload curve starts with initially high and gradually decreases upon completion of work. However once the more development work done or development is completed then the testing workload increases and graph goes high. At this point tester needs to be start with testing new features as well as the retest the old features as regression. The execution of regression suite is must before we are moving to release to production. Integration testing also plays an important role in testing, if any module is interacting with the third party or other system integration testing must be carried out.
The dedicated testing like Performance, load, stress and security testing needs to be performed after development cycle. The majority of the testing is to be carried out nearing deadlines or nearing towards the end testing budget. So mitigate all testing efforts we need Test Planning accordingly. To tackle with such testing efforts we need to take some steps as early as possible. The first thing is to involve testing of testing team from early stage of SDLC and you should consider testers while do budgeting of the project from day one.
Now question in your mind is that “What tester will do if requirement gathering is not yet completed?” then answer to this question is, before start testing first step we need to do is setting up a controlled testing environment. Also the software development process is a chaotic process and sometimes developer unable to perform the end to end testing on developer machine and they need properly setup environment to test developed feature or part of feature. The setting up test environment may vary based on company to company. Along with this we should make sure that the required tools like defect tracking tool, any specific tools required for project, databases, server needs to be up and running.
Tester also spends some time to get familiar with the system under test and think of test cases which needs to be executed later stage. The output of requirement gathering meetings is the Requirements Specification documents. Based on these documents we need to write down the detailed test cases. Generally these documents mostly cover positive scenarios and many negative test scenarios are associated with each positive scenario, so such positive and negative scenarios are needs to be figure out and tested.
How to survive in Testing Tsunami?
Following best practices can be used to survive in Testing Tsunami.
One of the best practices I ever heard is Daily builds; particularly automated daily builds come after every day when implementations or fixes are done by developers. This practice has many advantages, first is developer needs to cross check before check-in the code into repository, that means developer needs to check-in the working code and make sure that no any errors while building the code. Second is tester get the build every day so he is able to add issues observed while testing every day rather filing issues later. As a result the pressure of testing tsunami gets distributed and testing tasks are distributed over the period instead of short time period. This practice helps to get time for tester to log the issues and for developer to fix the issues, which gives the result into accurate project management. Sometime it is terrifying to hear that many company project do not accept the build unless and until the application development is not completed or not test further if any bug is found in the code. These are the real example I have heard, but this is not a good practice to work on.
Proof of Concept (PoC):
Along with above practice here is another practice which helps to reduce the testing effort in tsunami called as Proof of Concept (PoC). Sometimes Proof of concept is also called as Proof of Principle. A proof of concept is a term used for the demonstration of something. Such method is mainly used when the non-existence or weak documentation of specs. We can say POC is a prototype that is deliberate to decide the achievability, however it does not signify deliverables.
Effective End to end Test Cases:
Writing effective test cases is a skill and this can be achieved by experience. Such efficient test cases will definitely help to get test execution in more planned manner.
You should think from end user’s point of view and understand the application in depth which helps to covers the end-to-end cases. Following points keep in mind while writing cases:
- Use proper naming conventions for Test cases.
- Test case description should be self explanatory.
- Pre-conditions and assumptions should be considered in advance while writing test cases.
- Test data should be prepared and clearly mentioned in the test cases.
- Proper Expected Result should be added in each test case.
- Attach artifacts and relevant documents with the test cases.
- Test cases must be simple, clear and easy to understand.
- Try to create reusable test cases.
- If any requirements get change then timely update or work on maintenance of test cases.
- Make sure that you are adding post conditions if any.
We can say the Testing is project management function instead of quality function and testing is used to get the current state of the overall project, True picture. Generally immense workload wait for testers at the end of the project, then as a tester you should make sure that you are moving up the testing activities as early as possible.
I hope this article will not completely neglect the impact the testing tsunami but it will help to reduce the impact with the better Test planning and use of accurate practice.