A stereotypical description of an application tester’s role is usually about being given specifications, reporting bugs, verifying and closing bugs. This stereotypical tester will have a part to play in a testing organization, but will always be considered an outsider to the project and will not have much impact on the project lifecycle.
If we step out of the boundaries and terminology used in testing, a test engineer is valuable to the project when he/she helps steer the project clear of pitfalls during the course of the project. Here are some areas that test engineers should be actively involved:
Deployment topology:
Do not wait until the application is developed to test the validity of the deployment topology. Once the deployment architecture and components are known and available, run performance tests on the topology by testing with a hello world application on the proposed deployment structure. This test will bring out issues such as version conflicts of software components like load balancers, web servers, app servers.
Participate in design and define coding standards:
Participating in the design phase helps a tester choose an automation tool that is most suited for the application. Automation tool vendors might say that any application can be recorded and played back. However, we might find that it is difficult to automate the application. A tester should be aware of how record and playback works.
Example: A web automation testing tool may be using the “id” attribute of an html tag to be able to playback what is recorded. If the development team uses technology like JSF where the id attribute will be generated dynamically, the id needs to be explicitly put in place, as otherwise automation will fail. A tester should work with the development team and ensure that the id attribute is part of the coding standard.
Performance test tools that work with one technology may not work well with others. An understanding of the application’s technology helps a tester select performance test tools that works best for the application.
Example: Testing a static website developed in PHP for performance is completely different from testing a web application that has complex user transactions.
Project development methodology:
An understanding of the project development methodology helps a tester choose the appropriate bug tracking software. Defect tracking tools that are very good with one methodology will fail with other. If the project is following Agile development techniques, using a defect tracking tool that is best suited for waterfall method will cause confusion. Choose a product that best aligns with the development methodology; otherwise look for a plugin to the product. Never force the fit.
Feedback:
One accurate measurement is worth a thousand expert opinions. For instance, it is always better to say that a particular page takes 35 seconds to load than saying that the page is ‘slow’. In case a fix is made, we’ll be able to easily compare the load times to check if the fix really addressed the issue.
Give the developer the exact scenario for the failure. My experience has shown that providing a script that a developer can run to reproduce the issue saves time compared to describing the bug in a wordy manner. Sometimes I just record the steps using a screen recorder. Providing insight into why a failure may have occurred also helps the development team.
Testers, you are in the best position to judge the current state of the project; your input is critical for the success of the project. Keep the team informed on the current status.
In conclusion, I have shown you a few ways that a tester can effectively contribute to the project.
About the Author
Modha Khammammettu Modha Khammammettu works for California Casualty Management Company and is responsible for Enterprise Architecture, QA, and Compliance. He has over 18 years experience in developing and testing Enterprise software applications. Modha is ITIL and Six Sigma Black Belt certified and holds a Masters degree in Engineering for Computer Science.