This post will give an overview of how to make a testing team work effectively alongside a development team during an agile sprint.
The first step to ensuring the team works collaboratively is to make sure that all functionality that will be developed within the sprint, is well explained in frequent discussions and that everyone understands how each area will work. While some form of functional documentation for each feature is being distributed and reviewed by all parties, discussions should be happening with all team members about how this feature could be tested. They could possibly hold some brainstorming sessions to put together all their thoughts, having the development team involved in these discussions will not be a hinderance. Asking questions to the development team about any uncertainties that arise in these discussions is imperative, there may be areas that they haven’t thought of either, there may also be areas of deliberatly left to allow the development team a bit of creative freedom and to develop how they feel best suits.
Questions may be asked of the development team all through the sprint cycle and therefore, they should make themselves available as often as feasibly possible (obviously, they have to be left to develop the features as well).
Where possible, it will be ideal to automate as much testing as the team can manage, this will possible cause a bit of pain to set up in the first place but once this system is set up, this will then mean that future cycles will simply be a case of running the scripts that have been configured, rather than manually running every test. Writing an automated system may need to be planned out like a functional feature in the software. There are a few key points to take into account when automating a system:
Identify High Value Tests – Important to identify the test cases which will provide the largest return on their time investment. It shouldn’t be an aim to gain 100% automation coverage as it isn’t practical or cost-effective and would be almost impossible to achieve!
Automate What is Stable – Communicate with developers to make sure automated tests aren’t written for areas of code which are still in a volatile state, tests for stable areas will aid the teams effectiveness and avoid re-work.
Automated Tests Can be Run at Any Time – A large benefit of automated tests is that they can be scheduled for whenever they are needed.
Automation Helps Improve Software Quality – Automated tests generally run faster than a human tester, but it is important that the biggest benefit of automation will be seen in the next release of the product. To see the benefit of automation earlier, it is important to automate long repetitive tests to free up testers for other tasks.
Another method to aid productivity is Test Driven Development (TDD), I won’t go into the full details of this here but suffice to say, it is a practice where the developers write just enough code to pass a failing test. There are a series of simple steps to this:
-Developer works with the tester to write a test
-Developer writes code which make the test pass
-Developer refactors code to evolve it into better designed code
This process can benefit the testers for the following reasons:
Documentation and Working Examples of Code – by writing unit tests, the developers are providing the QA team with working samples of code. Meaning they can gain a stronger understanding of how the system works which will improve the quality of any functional tests then written by the testers.
Improves Code Quality – by having the unit tests written first, the quality of code will be stronger due to it being written to pass the tests. This will make the testers job easier later on in the cycle.
Team Works Together and Collaborates – there will be believers and non-believers or agile on all teams. To make this process work, it may be a good idea to pair up a believer and a non-believer to help spread the practice. If and when a team is all on board with TDD, the benefits for the product will soon become apparent.
If the team can work effectively and testers are able to set up an agile and automated environment, it will eventually lead to the testers being able to try some other methods to find defects such as exploratory testing!
2 thoughts on “Testing Effectively in an Agile Project”
Thanks for sharing your thoughts. It’s probably worth highlighting that a poor automation strategy can actually hinder a tester as opposed to helping them.
I’ve found from experience teams that sharing automation as a team of developers (everyone’s responsibility) generally reaps better results. It can also be a wise move to have a dedicated automation team responsible for automating regression checks which didn’t get done in previous release cycles.
What we have to remember is that automation if done correctly can be an aid to testing, not a solution.