16 Jun AGILE TESTING
Testing intends to maintain and improve the quality of software over time.
One of the major shifts from traditional/waterfall software development to Agile software development is how testing is conceptualized and implemented. Some common attempts to become more agile include:
- Adding a dedicated tester to a team
- Including a “hardening sprint” prior to a release
- Automation of user journey tests that ordinarily would be performed by manual QA
While these can be important evolutionary steps to increasing software quality, they are evidence of a mindset that puts testing as a phase of work that occurs between development and release.
An Agile mindset sees testing as an integrated activity that is native to all stages of software development. It begins by understanding needs and how those needs will meet. Additionally, an Agile mindset is constantly evaluating work through a Lean lens; shortening feedback loops, reducing batch sizes, and tending to lead times.
Just as testing becomes a seamless part of the development cycle, the tester as a role becomes a fuzzy idea. While specific individual team members may bring deep expertise in testing, the team itself is responsible and constantly seeks to both share testing knowledge and practice. By continuously reflecting on what behaviors software should exhibit, and how those behaviors can be verified, Agile developers collaborate to produce not only well-designed code, though a suite of automated tests. This suite is tailored to their context and covers a range of functionality and levels of abstraction from single methods, to classes, to services, integrations, and system flows.
As artifacts, the tests themselves become the focal point for organizations early in adopting Agile ways of working, though the true power of Agile Testing is building shared understanding of user need early, and continuously comparing software solutions against those needs.
From a practice standpoint, there are several flavors of test-first software development that shared intents:
- To increase the likelihood of delivering correct behavior
- To decrease cost and risk of change
- To support evolution of the code base in order to match business need
By clearly specifying what software should do before it is written, we can more easily demonstrate its completion. By enabling the specifications to be executable, they become, in the words of Sandi Metz, “the wall against your back” [All the Little Things, https://www.youtube.com/watch?v=8bZh5LMaSmE] when it is time to change the code even/especially when those changes are to improve the code’s health. Without that wall, changes become magnitudes more risky and expensive. Clearly specifying behavior also requires that we are having the right conversations with the right people at the right time; a daunting and difficult undertaking at best. If building correct software correctly were easy, a lot fewer projects would fail, be late, or over budget.
These testing practices have been articulated by Mike Cohn in his Agile Testing Pyramid [Cohn, Michael. Succeeding With Agile.(2009). Addison-Wesley Professional.]; a good overview by Martin Fowler is here:http://martinfowler.com/bliki/TestPyramid.html .
|Test pyramid – Kevin Callahan|
While there may be some disagreement within Agile development communities on implementation tactics and specific layers of the pyramid, there is wide, if not universal, agreement that multiple levels of automated test coverage enable agility. The corollary to this is simply that unclean code does not scale. In other words, code violating any number of well-accepted principles can only be changed with unacceptable cost and/or risk, so it is easier to actively allow it to get worse than invest in improving it. Another name for this is technical debt (Cunningham, Ward. The WyCash Portfolio Management System. (1992). Retrieved May 5, 2016 from http://c2.com/doc/oopsla92.html)
It cannot be overemphasized that code adhering to the coverage outlined in the test pyramid can still be incredibly unclean and burdened with technical debt. Tests themselves can be both full of debt and the source of additional debt. Code reviewing both source code and tests is critical in addition to the outputs of the tests. Reviewers must have the knowledge and expertise to understand what they’re looking at!
Additionally, there is the question of test automation and what this means from varying perspectives. To a traditionally trained test engineer, this entails scripting a user path through the UI. As Fowler notes in the above article, this approach tends to quickly pass an inflection point between value and waste. Automated UI tests are brittle, easy to create though difficult to maintain, and tend to take a long time to run. To an Agile developer, (not a programmer or tester by title, though both by professional practice) test automation refers to a range of practices that map onto the test pyramid, namely unit tests, service-layer tests, UI tests, and some degree of manual exploratory testing. Clear understanding of these approaches, which can be articulated into a testing strategy, is key to the success of any long-lived enterprise software package.
It is important to note as well that even without the tooling ability to make specifications executable, the primary intent is to build shared understanding of the right thing. Rather than simply accepting a hand off of requirements, Agile developers will insist on conversations with key stakeholders to understand why specific behaviors are being requests. Agile stakeholders will welcome these conversations and be open to developer suggestions. Gojko Adzic’s excellent bookSpecification By Example is full of possible patterns, stories, and details about the critical important of building shared understanding and capturing intent.
All of this is a question of technical maturity, which takes substantial time and effort to build. Not only are tools and practices new, thinking is new. Changing how people think is perhaps the most difficult task of leadership and arguably the most important.
|Image courtesy of: https://less.works/less/principles/lean-thinking.html|
There is a reason that Toyota built its House of Lean on the foundation of Lean Thinking. In a Lean enterprise, the role of leadership is as coach and mentor toward new ways of thinking. This last point may be the most important of this entire article, and a topic for its own post!
Thank you to my fellow CodeGenesys coaches Nick Zdunic and Ajay Reddy for their input and suggestions to this post!
You can reach Kevin through his LinkedIn profile: https://www.linkedin.com/in/kevin-callahan-mspod-793895.