Agile Testing (Simplified)

It has been a little while since I have blogged about anything testing related. I have moved into a BA role for some time now and have been a bit disconnected from the testing community at large. Testing is still a passion of mine, and I will continue to express my thoughts on testing related topics.

What I am still passionate about is agile testing and how testers deliver value to agile teams.  There are a lot of great articles and books out there on agile testing, and I encourage everyone to reach out and explore those.  This article is really for those new to testing, new to testing in agile, PO’s, Development Managers, BA’s or anyone who is seeking to understand some nuances in agile testing.

I am intentionally leaving out what many refer to as ‘test automation’ because that should spawn a whole separate discussion. The following topics are testing-focused only, and are techniques that illustrate how testing can deliver value in an agile context.

  • Shifting Testing Left
  • Early Story Adoption
  • Test Shaped Design
  • Dev Pairing and Test Mobbing
  • Just-In-Time Research
  • Sharing Test Ideas
  • Desk Checks
  • Coding To Support Development & Testing
  • Bug Introspection

Shifting Testing Left:

A hugely popular term in testing circles but what the heck does it really mean? Quite simply, it is getting testing involved as early in the design and development cycle as possible. With small, co-located, focused agile teams, there is no excuse to not have testers involved from the onset of projects. Testers should be there to question designs, share experiences, use their product and domain knowledge to challenge things from the very beginning. If you feel your testers are being left out – try to change that. Your team will benefit from their presence in early discussions.

Early Story Adoption:

What differentiates agile from your traditional waterfall approach, is testers being involved from the very beginning on a particular story and working through the story alongside developers. I am a big fan of not proceeding with any work on a story until testing has chimed in on their test analysis of the story in general, the approach they will be taking to test it, sharing the oracles, heuristics and artifacts that they care about.

Ideally, a tester should never be testing a story that they are not intimately aware of.

Test Shaped Design

As testers are often the feature experts on the team, they can have a unique ability to shape the design of features in development. While the business folks and UX may have their own ideas of how to implement a new feature, testers have a unique voice that should be heard. Not only are they feature experts but quite often have expertise in the domain and of course should be the loud voice of your user. Couple this with their overall product knowledge and how various features interact with each other can certainly change the course of a design. This is much easier to do in an agile context and is welcomed when it happens!

Dev Pairing and Test Mobbing

A huge advantage of being part of a small agile team is the ability to sit with others while work is going on, engaging each other, asking tons of questions, identifying ‘what if’ scenarios, sharing expertise in domain, features, db, code, personas, scenarios, the list goes on and on.

This is incredibly valuable in a dev/test pairing but is also incredibly valuable as a mob of testers. I have seen a ton of great work done by testers getting in a room to breakdown epics and stories and use a group mentality of shared experience to plan out how to approach their testing.

Gone are the days of developers throwing an item over the wall to an oblivious tester to test.  At least I hope so anyway!

Just-In-Time Research

One strategy of agile, is only preparing enough work for the team to work on in the near-term. This allows for agility and the ability to shift focus and go off in a different direction quickly and as cheaply as possible.  This is advantageous to testers, as they can focus their energy on a smaller subset of items instead of trying to digest a huge entire solution design concept document.  By limiting the WIP and the number of stories that are fleshed out, this allows a more narrow focus by testers to allow them to do their due diligence in researching the business problem and solution. They can also question things earlier to help catch potential problems before they happen.

Sharing Test Ideas

Share how you will be testing, share how you will be testing, share… Ok, I think you get it. Testers should share as much as they can with their teams about how they will be validating the story. This goes beyond your basic acceptance criteria and should also delve into functional, non-functional, explicit vs implicit requirements, scenarios, edge cases, boundary conditions, etc.  The more the team knows about ahead of time, the better off they’ll be and it should help avoid the churn that finding bugs later can cause.

Our teams have a section on their story template where testers share the list of test ideas that will be tested as part of the story. Testers come up with this list as part of their analysis of the story. The whole idea is to share this before development begins, to highlight as many testing details as possible. Being agile makes this easier to do.

Desk Checks

The ability to test during development on a dev environment on a development branch is the boss! Doing this with the developer present is even better. The shared understanding of the testing approach and the ability to find issues before code is committed is so much more efficient and less costly. The turnaround time is instantaneous and bugs can be fixed as you encounter them.

The mandate of testers in agile should be to embrace bug prevention as much as possible as opposed to finding them later on.

Coding To Support Development & Testing

Coding skills in testing are inherently valuable. I have blogged in the past that I believe traditional test automation should be the domain of developers (or a specialized role).  However, testers should have some coding ability to support their testing and their teams. SQL scripts to create test or demo data, code to setup test environments, queries to gauge performance impacts, or quick ways of navigating through workflows. Essentially anywhere that code can aid in speeding up the efficiency of their testing but also help developers that they are working hand-in-hand with. Agile is a team sport and this can only help your team become more successful.

Bug Introspection

You found a bug during testing after a developer has committed their code. YAY right?  Not so fast. While catching bugs is always a good thing (before a customer gets their mitts on it), what should always be done is to do some introspection on why a bug slipped through the cracks. Did I not share my test idea early on? Did we not test for this during the desk check? Were we too busy to have test involved earlier? These are the types of questions we need to ask ourselves and of the team. A huge advantage of working in agile, is the ability to learn from mistakes and correct them right away.

Testers should treat these as learning opportunities to try and prevent this same thing from happening again.

This is by no means a comprehensive list of agile testing ideas. These are ones that I find particularly valuable and important to our teams.

If anyone has other items to share please reach out.