The role of testers in an Agile organization
Check out the article to know how the role of testers in Agile are embedded with the developers and work closely with them.
When development is iterative and Agile, testers need to be embedded with the developers and work closely with them.
In Agile development, and specifically in Scrum, the title of “tester” tends to disappear in favor of the universal use of “developer,” although the role of tester most decidedly does not disappear. Even though an entire Scrum team has responsibility for testing and code quality, someone on the team needs to be good at testing, and someone on the team needs to set up unit and regression test automation, run the end-to-end integration tests, and do manual exploratory testing on the whole product.
Adopting Agile methods doesn’t mean that developers do everything. Testers are necessary, whatever their title.
Exploratory testing
Time is of the essence in Agile development, so testing speed and short feedback loops are important.
One example is exploratory testing, also called ad hoc testing. It can find bugs that are outside the scope of the automatic testing. For instance, an ad hoc test can uncover user interface and user experience problems; most automatic testing can’t. Humans are necessary.
Exploratory testing doesn’t require a test plan. That speeds things up, since agreeing on test plans usually requires team discussions. A tester can show a bug he found in exploratory testing to the responsible developers right away.
Why can’t the developers do exploratory testing themselves? For the same reason that writers can’t edit their own material: Familiarity creates blind spots. After creating a feature, a developer knows the interface cold, and she knows how it is supposed to work. A separate tester has the advantage of coming to the software with fresh eyes.
Creating automated tests
Developers who practice test-driven development (TDD) learn to create their own automated tests, typically unit tests, and to run the test suite frequently to detect regressions. Creating tests that require significant setup and tooling (such as creating and populating a temporary database for the lifetime of the test) is outside the competence of some developers, but within the competence of many testers.
In a continuous integration/continuous development (CI/CD) process, testers need to provide input to what tests run in the pipeline. For example, after the developers perform a code check-in, the CI system runs the full suite of smoke and unit tests (mostly supplied by the developers) before accepting the new code. Then the QA staff or the CI system should run the suite of end-to-end integration tests (mostly written by testers). If the end-to-end tests are so lengthy that they could delay builds in the CI/CD pipeline, they can run nightly, outside of the pipeline.
Test early and often
Automated testing integrated with TDD and/or CI/CD contributes to the shift left testing strategy. Shift left refers to the position of testing in the software development lifecycle. Instead of constituting a large spike at the end (at the right of the timeline) that gates each product version release, it smears out to small blips throughout the process.
Testers can contribute to the Agile development process before developers write a line of code. Testers can gather information, help with requirements management, and help to define the acceptance criteria. In other words, Agile testing should begin on day one – or even before.
When an entire team is physically co-located, as prescribed by Agile principles, lots of interaction can happen informally. If testers sit in a different building than developers, there is too much friction to allow for a quick “Could you take a look at this?” moment.
That doesn’t mean that an Agile team needs to sit in an open-plan office at high tables wearing headphones. While virtual team co-location is possible with modern collaboration tools, it still introduces barriers and delays to interaction. So, ideally, Agile testers are physically embedded with the developers in their team, attend the same meetings, and see each other at the coffee pot.
Ultimately, moving testers into Agile teams can be a huge boon for the entire team – but that doesn’t mean it will be. There have been cases where the QA department was fired because “The developers can do the testing,” and product quality subsequently fell noticeably. Don’t be that organization. Instead, take full advantage of the software testing talent you have by allowing the testers to participate in the full Agile development lifecycle.
In this era of agile development and rapid customer response, testing can no longer be an adjunct to the development process. It should be an integral and strategic component of the workflow. Functionize helps organizations accomplish that goal, with our scalable, autonomous test platform. This white paper tells you more about Functionize, in the context of continuous testing.
by Martin Heller
Martin Heller is a freelance writer. Formerly a web and Windows programming consultant, he developed databases, software, and websites from 1986 to 2010. More recently, he has served as VP of technology and education at Alpha Software and chairman and CEO at Tubifi.
