Test from theTop


Usually, when a software engineer suggests I read a book, it's an unsubtle way of saying I should "go educate myself".

The weird thing about me, is I will actually read any book. Especially when it's a semi-polite suggestion that I'm missing some key ideas.

One book changed my outlook on software so dramatically, I can't talk about high-level testing strategy without mentioning it.

By Gojko Adzic, published Jun 6, 2011, ISBN 978-1617290084

Testing software effectively requires that you know in detail how the application is meant to behave.

I know you're probably not going to read that book. I'll summarize.

The techniques presented are almost exclusively based on real world examples, with full accounts in the quoted words of the actual companies who found success by defining specifications for their software.

After working with these ideas directly for many years, I'm convinced. This is how software development should be done.

Specifications should be recorded in concise plain language, with key examples for each software feature.

A simplified example:

Given When Then language is an idiomatic grammar where system behavior is defined, and automated code can be directly linked and executed. But the scenario stands alone with or without automation.

This specification forms an incredible living documentation that empowers:

Product Owners - Who have a unified language to describe application features with every other part of the organization, including clients.

Developers - Who can clearly understand and reference the new work asked by clients, and further can directly automate the specification as a test.

Quality Engineers, Software Engineers in Test, User Acceptance Engineers - A clear, settled example of application behavior makes testing faster and less confusing.

What does this have to do with testing?

Tests without defined behavior are vague, their value is hard or impossible to quantify.

Automated tests that break (and they certainly will break) can fall back on these specifications for much faster manual testing. This is an important benefit of defined behavior, don't overlook it. I guarantee it will happen regularly.

I'll return to this subject when we talk about Test Coverage.

For now, let me know how you work with these concepts: