Agile Testing?

Recently I saw a post in a social media group talking about agile testing as something different than any other methodology form of testing. It then listed off many techniques stating that they are agile, like Usability, Acceptance and Stress testing as examples. My first thought when I saw it was, “Here we go again.”

Here is why I said that: Testing is Testing. It validates and mitigates the risks of any delivery. Each form of testing is exploring different aspects of code and the software as a whole.

Now the question is probably jumping to mind, “ acceptance testing is an agile term, isn’t it?” Yes, it is used a lot in agile shops, yet how is it different from Functional testing? Tests are there to validate the changes in each; they have another name.

The next thing to come up is that agile development testing is done continuously, not at the end. True, it is and needs to be due to the nature of the work. Does that mean it is a different test from a waterfall project? The only difference is that the test is more efficient and practical, focusing on the component. Most Waterfall test cases could become cumbersome and large enough that if an issue arises, it will take more time to find the problem than it would in an agile environment.

Even who does the testing is not that different. There are shared duties in an agile team as the members work with each other to get the work done. It is not much different from other methodologies where organizations see the benefit of other roles participating in the testing effort. In the end, they are executing tests.

Planning, now that is different, right? To help with the discussion, let’s paraphrase the manifesto: Interactions over planning. Looking at waterfall delivery where there is much planning ahead of time with sometimes documents over 50 pages on planning the test phase. In agile, there is still some planning to execute testing; the difference is that there is not much documentation. It usually is done face to face in sprint planning meetings or through conversations within the team during the sprint. There could be a set of guidelines, not rules, within the organization to conduct testing. These guidelines most likely will change to make things even more useful for everyone.

It is about the mindset and adapting the work to meet delivery demands; there isn’t a specific form of testing. What is different is how and when to create and execute those test cases. There is an additional focus on automation testing to help with regression due to the shorter delivery times.

With many conferences being cancelled or moved to virtual, one of the missed events this year was QAI Managers Workshop held during the QUEST conference. There is a virtual workshop with a very respectable schedule to continue the conversation and knowledge sharing to not take people away from work for full days. It is spread over six weeks for 2 hours one day a week. This workshop format will provide more value as discussions can now involve what is currently going on within teams and discuss issues in real-time.

https://softwarequalityconference.ca/