Although in recent years there has been an exponential increase in companies and development teams applying Agile methodologies, testing still seems to be lagging behind with most companies thinking they are doing Agile testing but in fact still using the waterfall method. Some of the biggest issues in Agile Testing were brought to light in a recent project that I was on. So how can we best apply Agile methodologies to best test applications?
Here’s what NOT to do:
· Specify testing as its own separate step in a development cycle
With the waterfall method, testing is made into its own step that is accomplished after development and before the release of an application. In most cases, this causes testing to be left until the very end making it a daunting task to start let alone finish. Instead, by making testing a mandatory step in the completion of each user story as well as including it as part of the story estimate, we can continually test the application we are developing and not let testing get out of hand and become a giant monster that we have to wrestle with before release. It also allows us to find small bugs and fix them quickly without allowing them to become a larger error that is going to take days if not weeks to fix (thus pushing the release date back).
· Make testing the sole responsibility of the QA team
If developers and QAs are not working hand in hand, more often than not, the responsibility of testing an application falls solely on the QA team. This causes the same pitfall as mentioned previously. QAs get bombarded with tests that they have to write after the user stories are completed. This way you run the risk of not only stressing out the members of the QA team but cause overhead as well by not having the tests completed by the end of the sprint. Instead, developers should feel some sense of responsibility to create simple tests for the code that they write. They could even help implement some of the tests through the BDD (behavior-driven development) process. This way the work is split up and QAs can focus on writing more complex and automated test cases.
· Silo testing requirements and findings
One of the biggest issues is the lack of communication between developers and QAs but also between teams (mixes of devs and testers). If the testing requirements or the actual application code goes through changes, different teams need to be made aware of the changes. If they are not then that cause the QA team to write tests that are following the wrong requirements. Lack of communication could also cause current passing tests to start failing because of changes to the code. By facilitating good communication between people and teams, you allow others to be aware of changes coming and make for an overall happier work environment and team members that trust and rely on one another to write a great application.
· Document and script tests in a separate repository away from the application
Documenting and scripting tests in their own separate repository area away from the application, allows tests to drift out of sync with the code they are running against and causing difficulty in finding and retrieving the right tests. By implementing a structure and method for storing and updating tests that allows the code to exist in the same repo as the automated tests (both for UI and/or API). This ensures that the tests stay in sync with the code as it evolves. As code is updated on branches, the tests would get updated at the same time.
These are just some of the biggest issues that I have seen while working on projects and with clients that are trying to implement Agile Testing. The good news is that they can all be easily fixed or even entirely avoided. Let me know what are some of the worst problems you have run into while trying to test applications in an Agile workspace.
