With the really short release cycles in the Agile development world, the QA team is always time crunched to complete its test passes on time. In this blog I will be covering some core points, which if implemented successfully will give the QA team a face lift, in not just testing the product on time, but for having helped push quality upstream and inculcate the quality focus amongst other disciplines too viz. development, program management, product management teams.
Test Driven Development (TDD):
Test Driven Development’s adoption has been increasing by the day, given the value it brings to the table especially amidst tight deadlines. However, this is not easy to implement since it requires strong support from the entire team including management support. Theoretically in TDD, the developers will be creating automated tests, but the test team can certainly collaborate with them to understand customer requirements/feature specifications to create tests which would then become the basis for coding. Such collaboration is key in the Agile world which reiterates the underlying mantra that “Quality is the responsibility of the entire team”. In situations where TDD cannot be implemented due to lack of support, the testing community should at least push for the next point I will be discussing viz. “Improve the quality of the build available to test”
Improve the quality of the build available to test:
The quality of a build available to test largely depends on the source code quality, however as a tester there are things you can do to help improve the quality upfront. Work with the developers to give them a set of core tests (say build verification tests) which they can run before the build is released to test. This will help you save a lot of time in really focusing on product testing on stable builds. However, make this process easy for the developers by:
- automating the set of tests they need to run
- testing such automation code to ensure no test issues exist
- demonstrating the test execution for them a couple of times and being available if they need any help
Though this practice will improve the quality of your test effort, unless you collaborate with the developers they may see this as an overhead. Win their confidence by educating them on the time it would save for both the developers and testers. If you have difficulty implementing this, take your time in working with the developers over iterations. In the mean time, at least ensure you take on test case reviews with them to ensure their feedback has been incorporated. This also has an added benefit that the developers have a view into your test case suite and may sanity test their code for some scenarios at least involuntarily.
Pick Sprint contained and Sprint non-contained tasks with care:
As we all know, one of the core characteristics of Agile development is to deliver demonstrable code at the end of each Sprint. To achieve this, as a test team, exercise care in the Sprint planning meetings. Examples of test tasks that can stretch across Sprints include Performance testing, Security testing, compatibility testing to name a few. Start upfront on these test tasks and spread them across Sprints so these get the right test coverage and at the same time, become manageable for the dev and test teams. Postponing these until later in the game will prove risky both in terms of product release timelines and quality, thus impacting your overall project costs.
Build frameworks and utilities:
Look at opportunities to build productivity frameworks and utilities, outside of your core test automation efforts. E.g. look at utilities for test data creation such as user account creation, crawler to determine broken links on web pages, unattended product installations etc. Such frameworks and utilities will save you a lot of time and help you focus on areas that are best tested manually. Demo such test IP to the rest of the product team to help them understand scenarios when they can also benefit from them, helping improve overall test effort acceptance.
There potentially could be several more such things that the test team can take on to help push quality upstream and embrace everyone into its test efforts, however the above mentioned are areas the test team can delve into right away to start making a difference. Try these out if your team has taken the Agile route and I would be happy to hear from you with comments, questions, feedback.