‘Can’t Test, Won’t Test’? – How the agile testing academy is changing the way developers think about testing

This article has been written by Taheerah Atchia, Head of Testing, CDL. 

Listening to the voices in our industry, I frequently hear the not-unfamiliar tale that befalls many a company’s foray into Agile Transformation: a decision is taken to change methodology, squads are quickly sprung, training may or may not be rolled out—and then teams are expected to just get on with it. Unsurprisingly, the results can be less than ideal and, seemingly frequently, testing roles are the last to be considered. Often the horse has bolted before anyone has noticed, by which time dysfunctional behaviours may have already set in.

Our organisation faced some of these challenges when I first joined. The testers were still using some not-quite-Agile practices, and skills and knowledge gaps existed in both theoretical and practical terms. The rest of the team had marched on without them, perhaps with a couple of missteps of their own—before looking around and wondering why no-one else was right behind them. With everyone doing ‘their bit’ in isolation, a joined-up approach to ‘Quality’ wasn’t foremost on people’s minds. A course correction was needed so that we wouldn’t end up pulling forward in different directions and without a common purpose.

Testers needed vital upskilling. Teams needed some refocusing too, to work more cohesively. Something needed to be done to help everyone reach the brave new world together.

If you want something done right

The idea started with a simple premise: a note to self to host some ‘Agile Testing workshops’. I scoured the internet for something that would provide the training required. Most Agile courses are purely theory-based, with maybe an exercise or two thrown in to illustrate the value of faster iterations. Courses focusing solely on Agile Testing were rare and were similarly lacking. We needed something more than the standard-issue; a complete overhaul of theory and real-world application, with exercises that would actually cement learning in a fun, interactive, and meaningful way. I wanted people to be able to take what they’d learned in the classroom and apply it the moment they sat back at their desks.

Before long it dawned that the best way to get what we wanted was to design it ourselves. The Agile Testing Academy was born.

Anatomy of an Academy

The advantage of contriving a training programme yourself is that it can be tailored to deliver what is relevant for the groups undertaking it. We designed the curriculum to provide a thorough grounding of everything a modern QA needs to know to confidently handle a variety of different situations. Obviously that is a lot! It was no surprise, therefore, that the concept quickly grew to a 5-day course, encompassing everything from the origins of Agile, an in-depth examination of Delivery Lifecycle activities from a QA point of view, Automated Testing, Performance Testing and other Non-Functionals, and Security Testing. The running theme through each day focused on Left-Shifting practices, collaboration, and the mantra that ‘quality is everyone’s responsibility’.

Learning through play

A 5-day course, with a jam-packed timetable, can be challenging for students to absorb. It was therefore vital to cement the material with activities to aid comprehension and retention. The course incorporated a strong practical focus, with virtually all topics underpinned by an activity. Care was paid to design activities that embraced learning theory for adults and centred primarily on gamifying the content. Discussions about identifying waste in processes were taught using a lightning-round buzzer game. Teaching people to spot Agile antipatterns took the form of custom-created bingo cards. The differences between Lean and Scrum were illustrated by making pizzas from unfired clay ‘dough’, slime ‘sauce’, and fired clay ‘toppings’. The value of Left-Shifting was taught by sabotaging LEGO model building by withholding pieces or providing instruction booklets with pages missing (missing items were returned to the teams after the teaching moment, so their models could be completed). Almost all activities were carried out in groups to maximise interaction and sharing of ideas, playing back their approaches to the rest of the class to enhance collective learning. The class size was capped to 15 individuals to allow for the focused attention students would require of their instructors, as well as to have appropriate group sizes for the activities.

Trial, learn, adapt

We were also keen to ‘eat our own dog food’ by putting the course together. Choosing to embrace Lean principles, the synopsis, curriculum, activities, and supporting material were all designed ‘just in time’ and incorporated feedback and suggestions from a wider audience to make sure we were hitting the right notes. A trial run of the course was performed with a small group of ‘guinea pigs’ to test drive the material and see how it landed. In true ‘trial, learn, adapt’ style the feedback was used to improve a couple of activities, introduce a new activity, and to rework some of the structure and timings of one of the days. This was an invaluable part of the process and enabled the real classes to land successfully with very little adaptation needed. Trainers are humans too, and they also benefit from continuous improvement!

Demonstrating openness to feedback encouraged attendees and contributors to provide constructive feedback in a safe manner. This led to what proved to be an instrumental alteration of the classroom make-up: the inclusion of other roles.

We’re in this together

Promoting concepts like Left-Shifting and a collective responsibility for quality can be somewhat of a tough sell to some teams. Traditional fears or a lack of buy-in can derail efforts to work collaboratively, and it is often a hard-fought battle of hearts and minds that needs to be waged in order to change perceptions. What better way to improve these behaviours than to foster a collaborative cross-role work ethic in the Academy classes themselves?

The notion of including Developers (and other roles) in what was perceived as ‘a testing course’ was met with a predictable level of resistance from some individuals – a perfect opportunity to practice those influencing skills! After some discussion and negotiation it was agreed that the first course could be used as a trial for the mixed roles format, with feedback from the group being the deciding factor in whether to roll this pattern out universally. The agreed group composition would be 8 Testers, 4 Developers, 2 Product Owners and 1 Analyst. All roles were to attend the first two days of the course (covering the origins of Agile, and the Delivery Lifecycle & Left-Shifting), with the Developers also attending the third day (Automated Testing). Testers would complete the full programme.

The question was, would it all pay off?

Success stories

The first course sitting was not without its challenges. The practical exercises for Automated and Performance Testing needed further refinement to balance for the differing levels of experience and knowledge. Apart from this, the days ran largely without a hitch – finishing on time, and incorporating all the material that was planned.

The biggest wins came through the activities and the group mix.

Different roles were speaking to each other, in some cases for the first time. Understanding another person’s point of view is the first step in establishing common ground, and this was happening in spades. The activities and discussions had the result of not only cementing the learning in the way envisaged, but also expanding people’s horizons. The class provided a perfect hotbed for collaboration, exchanging ideas, and building common understanding. People were engaged and laughter echoed round the room. Smiles were prevalent. The delivery had definitely hit its stride.

Word spread of people’s experiences of the first course. Different roles were singing its praises and following cohorts quickly became oversubscribed, with a waiting list needing to be established for keen individuals. We’d definitely succeeded in building a demand for learning!

Having fun on a course is all well and good—but key aims still needed to be met. Would the collaborative feel established in the classroom translate to better behaviours and approaches when the attendees returned to the real world?

The results are in

The Academy had definitely bred an enthusiasm and appetite to make changes in squads’ day-to-day work. One of the early successes was a clutch of Developers establishing collaborative working groups to push positive change out further to other teams. In other teams, individuals who had been stalwart opponents of Left-Shifting were now the ones advocating for it in their spheres of influence.

Testers found their voices and their confidence. Concepts that had been mere buzzwords to them prior to the course were now understood and being used in conversations with other roles. Testing approaches and practices were brought up to modern-day standard, with a departure from exhaustive test scripts in favour of lighter weight exploratory and risk-based techniques. Collaborative working increased, with improvements to the quality of delivery outputs. Defects decreased as the focus shifted to preventing them from occurring.

Anecdotal evidence is, of course, subjective. We were keen to capture feedback from the course attendees, as well as those whom they worked with. A survey was devised for the Testers, with qualitative feedback obtained by interview and discussions. The data corroborated the hypotheses; of the 24 respondents to the survey the following trends emerged:

  • An increase in knowledge of Agile: 96% said their knowledge increased, with 79% saying it has increased noticeably or significantly
  • An increase in knowledge of Left-Shifting: 100% said their knowledge increased, with 79% saying it has increased noticeably or significantly
  • Specific improvements to collaborative activities: 54% said that Developers were involving them more in development, 50% said they were pairing more in general, and 50% said they were considering testability of stories
  • Improvement in knowledge/capability in Exploratory Testing (71%)
  • Improvement in knowledge/capability in Risk-Based Testing (83%)
  • Improvement in knowledge/capability in Automated Testing (75%)
  • Improvement in knowledge/capability in Performance Testing (83%)

Of course, it wasn’t all plain sailing. Change never is.

Overcoming challenges

Although a lot of positive changes had come as a result of applying what they’d learned, attendees faced inevitable challenges when meeting with a dose of everyday reality. Some team members who had not participated in the Academy were, of course, resistant to the more collaborative team focus and shift in approach. Elsewhere, the drive to pair and instil TDD practices exposed a lack of experience amongst some Developers. Testers, although brimming with purpose and an elevated knowledge base, nonetheless had a lack of real-world experience of applying some techniques. Some of these challenges require further investment in training (which is planned), but changing mindset could be dealt with head-on. Fortuitously, the Academy had anticipated this, with a portion of Day 2 dedicated to mind hacks used to overcome resistance!

Whilst a full exploration of NLP-style practices was not possible given the already-packed schedule, the instructors were able to lean on their experience in consulting to impart some valuable techniques. A few of the techniques explored include:

  • Build empathy and understanding by taking time to explain what you want to try and the reasons why
  • Ask questions rather than argue. This prompts others to think about a challenging situation and can bring them round to your way of thinking
  • Have different roles pair on work to increase understanding and collaboration
  • Use the safe space afforded by retrospectives to raise challenging situations
  • Build agreement to try different approaches for one iteration, facilitating a ‘try before you buy’ ethos
  • Show the value of any successes – shout about those victories from the rooftops and be sure to celebrate any wins as this boosts morale and sways opinion!
  • Find or encourage a ‘co-conspirator’ within the team who can lend support to trialling new initiatives and to encourage others to adapt
  • Aim for small, incremental changes to behaviour rather than expecting/attempting a big bang approach. Change takes time
  • Don’t give up!

A number of attendees put these techniques into practice, in particular asking questions, building empathy/understanding, pairing, and finding a co-conspirator. These techniques, combined with trialling new ideas and celebrating successes, have seen the tide begin to turn.

Big things have small beginnings

Overall, the advent of the Agile Testing Academy has spearheaded a charge towards meaningful change. A few months since its unveiling have passed, and the teachings and material continue to prove useful for those who participated. A larger programme is in the works to bring the same level of teaching to all roles, with an ‘Advanced Diploma’ being drafted to delve into some topics in greater detail. Ultimately, it has already achieved large inroads in improving collaboration and approaches within teams, starting to break down those traditional walls between roles and responsibilities, and bringing everyone round to embracing a whole-team responsibility for quality. Not bad going for what was meant to be ‘a few Agile Testing workshops’.

Taheerah specialises in Agile testing and transformation programmes, developing teams to realign their thinking and methods of working.

The Agile Testing Academy has been shortlisted in the Deloitte Most Innovative Project category of the European Software Testing Awards.



Related Posts