The Liberated Tester's Mindset | Why Didn't You Test That?

01:08 - Part one recap: Centralised test capability and model-based testing.

03:20 - Squads working to a blank canvas adopt agile better.

04:20 - Impact of management on innovation.

05:24 - DevOps/Agile cargo cult or test ecosystem.

07:41 - Scratching through the veneer of agile.

10:49 - The architect's end-to-end complexity.

12:34 - Test strategy analysis for managing cognitive load.

17:37 - DevOps for profiling data sets.

19:18 - Clarity on business cases at column level with models.

21:24 - Managing input chaos and change cadence.

25:00 - Anti-patterns and spectrum of control.

27:45 - Teams' skills and understanding.

29:02 - Dynamic model-based assets and mindset.

31:05 - Collaboration tool or testing framework?

32:40 - Loosing scalability.

34:17 - Model-based mindset gets the job done.

37:03 - Gunesh Patil is the Liberated Tester.

37:58 - Challenge the fear of 'why not?'

40:41 - Creativity is underrated.

43:16 - Componentising through collaboration.

44:10 - Outro: is quality everyone's responsibility.

Welcome to episode 8 of the Why Didn’t You Test That? Podcast, hosted by Huw Price and Rich Jordan! In this follow-up episode with Gunesh Patil, The Liberated Tester, Rich and Gunesh share their insights into what it means to be a liberated tester and how they approached the adoption of agile methodologies!

Rich and Gunesh propose the idea of using squads, working to a blank canvas, can obtain a better level of DevOps and agile ways of working. However, a lack of focus on spinning up teams to do integration testing ahead of bulky end-to-end testing, may lead organisations into a blinkered cargo cult way of working. The cargo cult way of working adds difficulty to sustaining a bi-weekly change cadence, by injected chaos in the system with every incremental change.

In terms of toolsets and architecture, a blank canvas helps squads see what’s not working and thus the challenges to face into. Gunesh suggests that emphasis needs to be on what’s possible to build rather than on the toolsets alone for avoiding sprints defaulting to mini waterfalls. This holistic approach enables stakeholders are to see and communicate requirements but also data dependencies.

At a high level, this boosts the success rate of a test strategy, as many angles will have already been considered, providing an outcome of good documentation rather than a reliance on head knowledge. In part, model-based testing gets teams making use of this documentation for initial component level testing. This leads to heightened collaboration between stakeholders.

With model-based testing, stakeholders are given the power to easily execute and comment on a system’s architecture at various stages, but also on the technical aspects of components. Isolation and integration can then be explored more freely with bulky end-to-end tests. This leads to a massive gain in time, quality and DevOps speed, and in turn, experimentation and feedback become standard and shared practice between test teams and stakeholders.