Welcome to my sixth blog post. If you’ve got this far and have been reading my previous blogs with intent, I want to thank you for sticking with me.
Slow, slow, quick, quick, slow. Which for those folk dancers among us will be all too familiar with. Not to be confused with the hardcore dance variant you understand.
Testers, or better still a folk dancing tester will have undoubtedly experienced working within several agile sprints. Innovating incrementally. Delivering working software to the audience on a regular basis. Depending on your ‘vertical slicing’ (you know – using your invisible cake slicer), then some releases will contain a seemingly never-ending series of sprints, with some feeling like they’re never going to end. Particularly, when you are constantly rolling over tickets into the next sprint. Yet the word ‘sprint’ makes me think ‘fast’ or to be at a heightened ‘pace’. 0-60mph in 3.4secs. Daley Thompson realising he’s left the gas on (showing my age there). You get the idea.
Some sprints can run like clockwork. Others, not so much. Some can be more arduous (or ‘challenging’ if you want to put a positive spin on this) and feel painfully slow. You know what I’m talking about – right? So we testers are anxiously wanting to forge ahead and get on with testing new and exciting features, etc but we’re being blocked by something. Maybe a key dependency is still outstanding or somebody somewhere is proverbially dragging their heels and we’re waiting on them to finish something before we can proceed. Or we can test aspects of ‘x’, but ‘y’ and ‘z’ are still being developed. Urgh. So by the time we get around to testing ‘y’ and ‘z’ does this mean our test effort for ‘x’ will have been invalidated and we need to test this again. Or maybe you tested ‘x’ when you were told it was ready to test and later find out (usually at the eleventh hour), that the requirements changed or a last-minute UI change was made and it will need testing again. Around and around we go.
I’ve never been to a dance class myself but ‘slow, slow, quick, quick, slow’ does remind me of testing software. You have a few sprints which take time and effort with one thing and another…slow, slow…then all of a sudden there’s a big push for testing to be completed, including a comprehensive round of regression and we’re expected to find every single bug in there in double-quick time before a deadline which has got to be hit no matter what…quick, quick…so we release into live and we’re back down to slow again. And breath. Before we do it all over again. Sound familiar?
I’m not a control freak per se but testing as an activity needs careful planning and control. You cannot predict the future and so with the best will in the world, you are going to need to implement measures of control throughout the entire software development process. Think of a ship at sea and a storm hits. You’re still going to need to ensure the ship maintains it’s course and heading as much as possible and ultimately reaches the desired destination in a timely manner. Whatever you do, don’t go under. That would be bad.
Moreover, planning need not be a document heavy or time-consuming process nor should it be. Being ‘agile’ does not mean you can simply dispose with test planning. That would be just silly. Take the time to set expectations with the rest of the team. Ensure you have made it clear what needs to be tested, why it needs to be tested, outline your dependencies, give an indication of how much resource you will need to complete this test effort and estimate how long all of this is going to take.
Influencing skills are very important to affect positive change or even just to gain ‘buy in’ from the rest of the team. The more you open up the mystery that is the world of software testing, the more the team will understand and empathise with your situation. You may even start to hear team members saying “well, we still need to do this and we also need to think about how this affects test effort” or “we’ll need to ensure this is done ahead of starting test execution so we’ll be testing what we intend to ship“, etc. Pretty amazing eh?
If all of this helps to avoid the quick, quick mad rush at the end and avoids the regression testing window being squeezed then surely this is a good thing. It might not look as good on the dance floor but the test manager will hopefully applaud your choreography. Encore! Encore!
Moreover, it’s worth considering the merits of test automation and how this could be used to undertake regression testing in parallel to testing new functionality. Having the peace of mind that these automated tests (let’s call them checks) are passing as you progress within each sprint will give the team confidence as you work towards a release. This, in turn, may also reduce the amount of any manual regression testing you may feel is required. Like I keep saying, you’re going to need both manual tests as well as automated checks/tests if you’re going to dance in an agile fashion.