I am a tester and these are my perceptions and reflections on agile concepts. There are several agile frameworks available for implementation to guide meetup 10 people joined agile transformation.
I have not experienced many frameworks myself, but I have experienced several implementations in an agile organisations. One core theme in the agile movement is that everyone should test and no single person is responsible for quality. Still, there is a need for guidance and strategy within testing and quality. If we perceive these frameworks as something to implement and follow blindly, then I think it is doomed to fail. If you instead see them as building blocks, where you take them, tweak them and put them together, you will be less likely to fail. Because each organisation has its own structure, culture, products and people that together create a unique context. In each agile transformation you also see agile coaches.
If these coaches see the framework as a set of rules, instead of a set of guides, then you will probably not be able to tweak how you work with testing, thus being forced to follow the limitations of the agile framework. In that case, how can you coach a whole organisation on all its crafts? I rather see the need for expertise within each of these crafts to guide the agile implementation. But this should not be a problem. Continuous improvement is a natural philosophy of agile, meaning that evolving the implementation of agile and the framework should also be done?
When I study an agile framework such as SAFe, I find lots of good material and good ideas. On the other hand, I do not find much material on testing, culture of testing, test approaches or test strategy. In the bibliography list , I can find one book from Lisa Crispin and Janet Gregory, but that is it. I do not count TDD or ATDD as within the testing craft, rather a development craft. I think SAFe and probably other agile frameworks would benefit from some enrichment of test expertise. I also fail to see any known testers in the contributor list.
What I believe is a common theme in agile is that testing has no special seat at the table of leadership since everyone is expected to work with it. I believe this is wrong. That is why I want to contribute to the subject with my own thoughts, ideas, reflections and experiences on the subject in order to change, add and possibly remove some of their parts. I know that many great testers are struggling with this as well. So instead of saying that the frameworks are crap, I want to tweak them to become better to help in the agile transformation. I would believe, without any evidence, that a majority of the test community and product development companies have matured in their view on testing.
At conferences you less frequently see the argumentation that testing is not needed. From my own experience and perceiving the local market, there is often new assignments for testers. Many companies try to hire testers or get in new consulting testers. At least looking back a few years and up until now. At many companies there is an ever increasing focus and interest in Continuous Deployment.
Sadly, I see troublesome strategies for testing in many organisations. Some companies intend to focus fully on automation, even letting go of their so called manual testers. Other companies focus on automation by not accepting testers to actually test and explore. Haven’t testers been involved in the test strategy? Here are few of my pointers, arguments and reasoning. In 1999 James Bach wrote the article Automation Snake Oil , where he brings up a thoughtful list of arguments and traps to be avoided. Close to 17 years later, we see the same problems.
In many cases they have increased because of the Continuous Deployment ideas, but also because of those from Agile development. That is, if you ignore all the new ideas gained in the test domain as well as all research done. The miracle status of automation is not a new phenomenon, together with the lure of saving time and cost it is seducing. In some cases it will probably be true, but it is not a replacement of thinking people. Instead it could be an enabler for speed and quality. In 2009, Michael Bolton wrote an article that clarified a distinction between Testing and Checking.
Since then the definition has evolved. The latest article Testing vs. Most of the testers I know and that I debate with are aware of this concept and agree with the difference or acknowledge the concept. Furthermore when developing a new feature, are you focusing on automating checks fulfilling the acceptance criteria or do you try to find things that have not been considered by the team?