Implied Testing

Posted Mar 30th, 2016

Implied Testing is a way to write a test that indicates other parts of your workflow are working as you try to accomplish a goal. Make use of Implied Testing to minimize the amount of documentation and testing artifacts on a project. According to the Manifesto for Agile Software Development, we should favor working software over comprehensive documentation. While this sounds good in theory, all too often test teams are asked to produce documentation explaining what they plan to test (in detail). The concept of Implied Testing will help save a lot of writing as it will eliminate duplication, and streamline the tests that feed into automation, allowing for simpler, more re-usable scripts.

Why Do We Write Detailed Tests?

In an ideal Agile world we limit our test documentation and focus on automated tests, with manual smoke and exploratory tests to supplement them. Our Acceptance Criteria in the stories should guide the tests necessary for the story to be complete. Unfortunately, circumstances can require an extensive amount of test documentation artifacts to be produced. Why?

  • Your Customer Requires it: If you are working on an internal project with the players all working closely, you most likely don’t have to document much. The stakeholders trust your work and are present to see day to day results. But how about external customers? Maybe they’ve commissioned your team to create something. While there is trust, there is verification. As they are paying you to do that actual work, they still need to know their concerns are met. This is often accomplished by seeing a detailed test plan. Whether it’s going to be automated or not, they want to see something written in plain English.
  • You Require it: Let’s face it — a lot of us use offshore resources for our testing. As those teams are not usually present in the day-to-day scrum activities, and are not usually subject matter experts, you need to have them prove they understand the requirements. While daily calls and assurances are one thing, nothing beats having someone recite back to you what you just trained on. From a testing perspective, this means detailed documentation. All to often the communication gap has burned project teams when assumptions are made that the offshore team understands the concepts.
  • Management Requires it: Yes, I’m a manager, and sometimes I just need to be sure my team knows what they are doing. This is especially true with more junior members, and on risky and complicated projects. I know from experience that you can flesh out a lot of details if you write the tests down.

The common theme here is trust. You may want to go with minimal documentation, but unless you have a history with the test team, you want to verify.

Detailed, But Not TOO Detailed: Imply It!

I mentioned offshore teams as an example. Testing resources, especially automation engineers, are difficult to come by, especially with limited budgets. We often rely on offshore teams to do our manual testing for us. I worked with an offshore team for many years. We started with two types of testers — one that worked with the scrum team’s QA Analysts, and one that ran regression tests. The analysts were considered the Subject Matter Experts (SMEs). They wrote detailed, repeatable tests for the manual regression teams to run. This allowed us to plug and play any testers onto the regression team and know we would have consistent results. As our team evolved to be automation centric we needed to revise the artifacts the Analysts wrote. End-to-end Tests were outdated and replaced with more modularized tests. Detailed tests became more conceptualized. And this is where Implied Testing came in. We still needed to know they understood what to test, but we didn’t need the repeatable detailed tests for regression testers. The new recipient was the automation engineering team responsible for creating the automated tests.

Case In Point

This week I was reviewing tests from the team that showed where we could use the Implied Test concept:

Test 1: The test was basically that if you chose [this] option to make a discussion graded, then X appears. … Test 5: Grade a discussion

Instead, focus a unit test to check the option exists for Test 1, and then make Test 5 the UI test, which will cover the workflow. Then Test 1 is implied in the UI testing.

Use Implied Testing Everywhere

Once you get the hang of it, you will discover redundancy everywhere. Best of all, once you’ve eliminated the chaff, you can even use these tests as your Acceptance Criteria and cut down on the need for further documentation.

Joe Nolan (@JoeSolobx) is a Mobile QA Team Manager with over 12 years of experience leading multi-nationally located QA teams, and is the founder of the DC Software QA and Testing Meetup.

Written by

Joe Nolan


Agile Development