Software testing is challenging and working as a tester in agile team can often be very challenging. I have been working with agile teams for a while now. In my experience, irrespective of the maturity and size of the team, as a tester, I have always faced following challenges
1. Sprint becomes mini waterfall
In many teams, sprint often becomes mini waterfall. It does not matter whether Sprint is a one week, two week or three week sprint – Sprint can always become mini waterfall. In my early days as agile tester, I used to wait for the stories to come my way and somehow all the stories would become available towards the end of the sprint. I struggled with it and tried to solve it in many different ways. In fact, with one of the team, we accepted it as a norm and assumed that first few days of the sprint, testers would work on the stories from last sprint. How naive, but hey that’s how we learn 🙂
2. Examples leave little time to explore
In some of the teams I have worked with, I struggled to find right balance between examples and exploration. I have worked with excellent business analysts who are very thorough and would come up with plenty of examples to ensure that there is no ambiguity. I have worked with excellent developers who would cover all the examples in their unit or integration test to ensure everything is covered. There is nothing wrong with that, however, as a tester it is important to remember that green can be misleading.
3. Lack of focused testing
As a tester in an agile team, it often becomes difficult to focus on testing. There are many things which require testers time. Some of the things we a need to work on are – prepare stories for the future sprint with business analysts, discuss stories of the current sprint with developers and BAs, keep an eye on broken build on CI, work with product owner for the demo, help developers with test data, environment set-up or unit testing, review unit, integration test, take care of non-functional testing when needed, test automation, support prod release, test in different environments and so on. This can often leave very little room for actual testing.
4. Ownership of test automation
Test automation is integral part of agile teams. I have seen many successful and unsuccessful test automation efforts. In my experience, biggest factor in the success or failure of automation effort is the ownership. If test automation is owned by the team, it has better chances of providing value. It’s difficult to promote this culture and it takes time. Often, testers in the team would want to treat test automation as their baby and would be reluctant to relinquish control and on the other side, developers might shy away from taking additional responsibility. So it’s a difficult task to get everyone onboard, but when team owns test automation, it provides fastest feedback and adds maximum value.
5. Complexity of environments
In many agile teams, continuous integration and deployment is a given. However, continuous deployment also means that environment is always moving. As a tester, it is important to be able to test in a stable environment whenever it is needed. However, sometimes it becomes difficult. Specially, when we need to promote code to staging and production, we want to be confident that we are promoting the version we have tested. I have seen many solutions – from elegant build pipelines in Jenkins to stop committing to master for a while policy. Solving this problem always becomes a problem because every application is different and environment often have many stakeholders (testers, developers, ops and so on).
6. Need to learn – continuously
When I started my career as a tester, I was happy with my ‘C’ editor and Unix box. I had no reason to step into the dev world and learn about installers, build tools or version control for that matter. However, with agile, this has changed. In agile team, it helps if testers are not afraid of tools and technology. Agile teams are often tool-rich and testers need to get involved in every stage – from checking code quality using check-style to analysing logs in tools such as Kibana and Splunk. This often makes job of a tester a bit more demanding and exciting at the same time.
So to summarise, as a tester working in an agile team, it’s important to ensure that sprints don’t become mini-waterfall, there is always time for focused testing sessions and exploration remains an integral part of testing. It is also important to think about and deal with the problems related to environment early, make the team responsible for test automation and most importantly – keep on learning continuously and ask yourself – how am I adding value to the team?
These were some of the challenges I usually face when I work as a tester in agile teams. What challenges do you face? How have you solved them? Let’s discuss.