Drive Quality and Velocity with Test Abstracts

Six years ago, I began experimenting with Lean Test Plans as a way to help test teams drive project results. (I now call them Test Abstracts to distinguish from test instances that can also be called Test Plans.) Test Abstracts articulate the test approach and scope (what will be tested and how it will be tested). I also include an assumptions list, a risk register, a RACI chart, and important project related links.

When Test Abstracts are used, there is increased awareness that QA is tracking this collection of information in addition to testing and defect status. This contributes to successful on-time project delivery; risk and challenge visibility occurs early; meetings are effective and efficient as assumptions and risks are status checked quickly. Scope and timeline changes can be better negotiated and the quality-killing "QA Crush" at the end of the release cycle is lessened. The single page summary content has also been used to help auditors rapidly understand how the organization is going to achieve its compliance and quality goals.

Test Abstract elements

• Project name
• Project purpose statement
• Test approach description
• Test approach detail (bullet points)
• Link to the test plan (HP Quality Center, JIRA, TFS, Excel, etc.)
• Defect control links (tickets, queries, charts; HPQC, JIRA, TFS, etc.)
• Epic and story links (JIRA, TFS, VersionOne, etc.)
• Link to Project Management charter, detail pages
• Assumptions list
• Risk register
• RACI chart
• AUT/SUT diagram links
• Workflow diagram, process guideline, procedure, policy links

Observations

• Format is less important than content. My preference is for individuals doing the work to pick what works best for them (Confluence, SharePoint, Google doc, Word doc, etc.). Adopting what the Project and Engineering content is managed on is a good rule of thumb. When Test Abstracts are a new concept to a team, I help develop the content and demonstrate how it can be done.
• People like Test Abstracts. I found stakeholders like the early, clear communication. QA likes the control it gives them. As a manager, I like how Test Abstracts help us negotiate better when scope and timeline changes occur.
• QA Team confidence is higher when Test Abstracts are used.

Tips

• Use Plain English principles.
• Let Project Management manage dates. Train your team to discuss progress and expectations in terms of milestones in partnership with Project Management.
• A goal should be to have the main abstract page viewable on a single page or screen.

I've used Test Abstracts successfully at three organizations. A key to successful adoption is to identify and work with innovators and leaders on a team and provide a lot of support. Encourage them to experiment on making it work for them and perfecting it for their specific needs. As the early adopters experience success and ownership, others observe the positive results and join in.

Why do we test? What does QA do?

Recently I was asked for a definition of QA testing and what happens in QA in 1 to 3 sentences:

QA tests and checks software functionality, performance, integrations, and configurations.  We test to demonstrate that the software and system are "Fit-for-Use".  Testing and checking activities include requirements review, test planning, test execution, test progress and status reporting, development of test assets (diagrams, test cases, automation), and defect management.

Failures, errors, faults, defects, and bugs...

The Junit test framework TestResult class distinguishes between failures and errors.  The distinction is a failure is anticipated and an error is unanticipated.  I think this is a helpful distinction that can be used in general when describing problems we see when testing software.  Now, just need to do the same with faults, defects, and bugs.

"The test framework distinguishes between failures and errors. A failure is anticipated and checked for with assertions. Errors are unanticipated problems like an ArrayIndexOutOfBoundsException."