Quotes & Notes on “Agile Testing Condensed: A Brief Introduction” by Janet Gregory and Lisa Crispin

Collaborative testing practices that occur continuously, from inception to delivery and beyond, supporting frequent delivery of value for our customers. Testing activities focus on building quality into the product, using fast feedback loops to validate our understanding. The practices strengthen and support the idea of whole-team responsibility for quality.

This is the authors’ definition of Agile Testing. To me, the biggest differentiator from other testing definitions is that this one promotes to actively improve quality rather than only inform on the status of quality.

When the whole team is responsible for quality of the product as well as quality of the process, each team member needs to be proactive in solving problems.

Quality coaches might educate, prepare or motivate team members to become proactive.

There are many things to consider around your product domain. It is not only the software you are testing; it is the product that your end users depend on.

I find this advice needs to hold true for anyone working in software development.

Exploratory testing exposes misunderstandings about what the software is supposed to do.

These misunderstandings not only appear when coding is finished, but throughout the whole development lifecycle. From acceptance criteria definition to figuring out stress conditions of your productive systems, exploratory testing helps clarify assumptions.

Quality attributes – or as some people like to call them, non-functional requirements – are often overlooked when discussing a new feature or story. A quality attribute defines the properties under which a feature must operate.

Removing unused features can be just as important as adding popular new ones, since every line of code has a maintenance cost and adds risk.

“Keep only those things that speak to the heart, and discard items that no longer spark joy. Thank them for their service – then let them go.” as Marie Kondo would say.

This ability (observability) to recover so quickly s from production failures lets the team release continual small changes to the product fearlessly, and it’s what makes continuous delivery or deployment a safe practice.

Having an observable system might be an important factor for reducing your “release decision” time.

It’s becoming more common for teams to do exploratory testing in production, using release feature toggles to “hide” new features from customers until testing is complete.

Feature toggles have become a major game changer of how and when testing can be performed in a system.

We recommend that the developers, who are good at writing efficient, maintainable code, work together with the testers, who are good at specifying test cases, to automate tests through the UI as well as all other layers above the base level of the pyramid.

It is not only a good idea to follow this approach because you might not feel confident in using automation for your tests but as well because developers can be the ones maintaining the code and enriching it when necessary.

Turning testing problems into problems for the whole delivery team to address is vital to learning how to build quality into your products and achieving sustainable success.

---

Check Quotes & Notes for a full list of the books I have taken notes on.

I have taken all precautions to cite everything clearly, but if you are an author of this books and you feel that there is too much content of your book exposed or any other violation, please contact me so that we can correct that.