Test Cases on Job To Be Done
About JTBD
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
Example:
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
Example:
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
Example:
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.
Conclusion
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.
Further reading
P.S.: I hope you liked an article! Please, don’t hesitate to give it some claps — so more people could read it!
Thank you!
