If you not yet familiar with a JTBD (Job To Be Done) framework, then take a look at this short 5-mins video from Clayton Christensen, professor at Harvard Business School:
JTBD in Agile software development process
Alan Klement wrote absolutely beautiful article about applience of JTBD concept to evolution of Scrum’s User Stories:
If you haven’t tried Job Stories yet, then give them a try! They really change software development process a lot to the better!
JTBD in test cases management process
Have you ever thought about test cases as workers, that you hire to do some job for you? These workers can do their job correctly, professionally, effectively or they can waste all your time, money and mental energy… Just think about it.
This is what JTBD in test cases management is all about:
Hire right test cases for a Job you have for them to be done
I’ll explain this concept.
The thing is that the same test case could be written with different amount of details. And the amount of details in test case is defined by a job that you hire this test case to do. I.e. JTBD — is what you need to keep in your mind while you write test cases.
Working with test cases for a decade I started to separate them in 3 simple categories: 1) ideas, 2) checklists and 3) classic test cases. They are not good, not bad, — they are just for different jobs to be done.
I. Test Ideas Lists
See? Just ideas. Neither “how to check”, nor “what is expected”, but only “what to check”. Nothing in description, just titles. Kinda “not to forget” list.
I don’t like such “test cases” because they are “fine”, they can do their job right only for the person, who made them. Such “test cases” I often find in teams with 1 QA engineer. He/she writes them for himsef/herself.
II. Check Lists
I just rewrote test ideas from the previous example and got this list. And this is my favorite! This is a middle way between unclear test ideas and heavy classic test cases.
These “test cases” are simply full sentences of what happens and at what conditions. The template to follow is this:
Something successfully/unsuccessfully happens if some condition satisfied
There is a number of huge profits to use this approach:
1. Test coverage improves. When I started to write full sentences for each test idea, I realised, that I can write not 1 test case for that, but a number. Because the same idea could be represented and interpreted in different ways. And each way — is a separate test case itself:
2. Structure appears and supports test coverage. I also started to add folders structure to make a better picture of test coverage.
3. Easy to start for a new member in a team. Each test case — is a finished, complete sentence of: what happens, at what conditions and what is expected. You don’t need to guess and assume. Or (if some uncertainty happens) then a new test case, a new more complete sentence appears.
4. Fast and easy to maintain. Such “test cases” do not contain description, steps, etc. — because they assume some initial level of familiarity with the product/service for those who use them. And this makes test cases fast and easy to write and update. You can always add steps there later if needed.
5. Execution first. These “test cases” really “fast like Ferrari”. A bunch of minutes — and you already with a list of them and eager to execute them on a real thing. And when you execute them, you find new uncovered scenarios and you write them and execute also very fast.
Bellissimo! Use this approach wherever you can!
III. Classic Test Cases
Everyone knows this: title, preconditions, steps with expected results.
Classic test cases are good when you document something for distributed teams, for long-term usage, for separate regression or user-acceptance teams usage.
Checklist test cases often start to contain something useful inside them (links, commands, references, explanations, etc.) — that’s why they tend to become classic test cases in future.
To finish this article I’d like to remember the definition of test case:
Test Case — is an instruction about test situation modelling
And it is JTBD that asks detalization for that instruction.
Often test cases have a number of jobs to be done. But for me one of the most important jobs that test cases do — is to be a knowledge base about the product/service.
Test cases — are knowledge base about a product or service
Specs very often are incomplete and pretty uncertain. Code is precise, but you need to know the programming language and be able to dive into context to answer the question about the product behavior. And only test cases — are the most full and most complete answer on product questions like: “what will happen if …?” or “what is default value for …?” or “what is reaction on …?” — and it’s an answer of person (QA Engineer) who saw the product/service the last before its was shipped to production.
This is the most important job that is done by test cases. And it should be kept in your mind when you design them: you don’t write tests, you describe, you document the system behavior in various situations of life.
Test Cases — what are they?
There is a formal definition of test case in Wikipedia or in ISTQB, but this definition would not help you to…
The Best Test Case
This article aims to share with you some principal understanding about the what an ideal test case is, what’s a…
Test Cases Design — what is it?
There is a formal definition of test cases design in Wikipedia, but as for me this definition leaves much to be…
Test Cases Structuration techniques
One of the main reasons why MS Word and MS Excel become an evil when you try to manage hundreds or thousands of test…
Always test these 5 conditions in software
Just wanted to remember you about 5 classic, yet very important conditions you should verify your software for. And I…
P.S.: I hope you liked an article! Please, don’t hesitate to give it some claps — so more people could read it!