At the end of December 1999 system administrators were on standby 24/7 . They tested (at the time it was not cool to say “agile testing”) and simulated moving from 99 to 00. That was the case again on 1st January 2022. Microsoft Exchange on-premise version is playing up a bit.

How Microsoft names its updates of the malware-scanning engine is the root cause of the issue. They put the year, month and day at the front of another four-digit number: 220101 and 0001. Windows mathematically checks the latest update on a system and uses the latest update on the system. The update of the 1st January is:

2,201,010,001

While this number is stored in a field that has a limit of 31 bits, the highest number represented is:

2 to the power of 31: 2,147,483,648

When Microsoft issued a new update starting with 22, it simply exceeded the maximum value that can be represented in binary symbols.

Messages are blocked in transport queues. Emails are not delivered. Happy New Year 2022!

The morale of the story is that agile testing should be in the DNA of every software company, even the biggest on the planet. Agile testing blends manual, automated and exploratory testing into ways of working that cover a software end-to-end. All the good stuff is here on Lisa Crispin’s website.

Agile Testing Quadrants

Also from the website of Lisa Crispin, the glamour-less chart here below is a great help for anyone wanting to build quality in their software product.

Listen to the 5-hour course on Informit.com to learn the foundation principles, concepts and practices for successful testing in agile teams.

Light the fireplace. Get cozy and read “Beautiful Testing” a compilation of 23 essays written by 27 leading testers and developers. It illustrates qualities and techniques that make testing an art. Buy it at your favourite book store or on Amazon

But what is agile testing about?

Agile testing is a software development practice that helps to fill the gap between the business and technology. It helps the technical teams understand business goals and fulfil their duty to deliver a bug-less software. Agile Testing brings context in the way developers and software testers test. Thus, it gives quick feedback for better and faster deployment cycles and promotes frequent, automated testing of new code as it is completed stipulating that bugs should be fixed as soon as they are found.

Agile testing is not a phase. It involves everyone delivering a shippable product. It shortens the response time of feedback.

Testing is a core part of agile software development. Unlike the good old days of testing, it is not a separate phase. It is not mimicking steps out of an excel spreadsheet. Agile testing is about continuous testing that goes hand-in-hand with the development stream and provides constant feedback to the business.

Pillars of agile testing

There are 4 pillars of agile testing:

  • Behavior-driven development (BDD)
  • Acceptance-test-driven development (ATDD)
  • Exploratory testing
  • Session-based testing

Behavior-driven development

At the core of behavior-driven development (or BDD) is the link between the business and technology. Teams create “scenarios” that define the “what” and the interactions in the IT systems. This link is all about communication. BDD is example-focused communication. Business analysts, developers and testers document scenarios that everyone can understand.


They are written in a structured format using a Given / When / Then syntax (more details on the cucumber.io website). Scenarios contain information on how a functionality “behaves” going through scenarios, or situations given a variation of the parameters. Scenarios are the specification of the software but they are executable. They are made up of specifications and inputs. They (of course) should be automated.


The plan with behavior-driven development is that teams create the scenarios, they then build the tests for these scenarios (which all fail at first) and then lastly code the functionality that makes the scenarios pass.


The main advantage of BDD is that not only individual components are tested but an end-to-end functionality.

Acceptance-test-driven development

Acceptance-test-driven development put the acceptance criteria of a functionality at the center of the development. It brings the business (or the customer), the developer and the tester to the same table:

  • the business focuses on the problem to solve
  • the developer defines how the problem shall be solved (architecture, code, cloud etc)
  • the tester looks at what could possibly go wrong

Acceptance criteria represent how the business will “accept” a functionality built by the IT team. It shall be integrated into the scenarios of the behavior-driven development.

Exploratory Testing

Exploratory testing – or “guerilla” testing as I like to call it – focuses on interacting with the shippable product. It lets testers test in a non-scripted way. It’s chaotic. Some like to “break” the system as mindset for exploratory testing. Testers think of possible user or system behaviors and test them. It’s about being creative. Testers elaborate plans around edge cases as the automation harness should capture the main stream. Bugs found during exploratory testing are of course logged in the bug tracking system and fixed within the sprint.

Session-based Testing

Session-based testing is the revenge of the testing team. It’s a time-boxed session. Testers challenge the development team covering 5 proof points:

  • Past: what was done in the test
  • Results: what the tester discovered or achieved
  • Obstacles: what are the problems discovered
  • Outlook – what are the remaining areas to be tested
  • Feelings – what is the feeling of the tester on the software

Session-based testing is a collaborative way of unlocking the potential of the testing team, keeping the development team honest and giving confidence to the scrum master that a team performs.

Agile Testing as 2022 resolution?

It’s not too late to add agile testing to your list of this year’s resolutions. Get started! Agile testing is compatible for every team size. Feel free to reach out if you have questions.

This post is also available on LinkedIn

Summary: