Specification
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 a website user
When I successfully login to the website
Then I should see a welcome message popup
And the message should contain my name
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.
-
Note*
If you are already writing user stories, that is simply not enough to get the full benefits of Specification.
There must be a unified effort across your organization. Starting from initial feature design, through development to quality assurance testing where the specification is the document of truth for each stake holder.
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:
-
Does your team define specifications for your projects? During which phase of development? Please reply and let me know! I read every response.
ross@testfromthetop.com