We have Jira. Notion. Confluence. Test management systems. AI assistants. Automated test suites running in CI/CD. So naturally, I made a paper notebook.
Not because I suddenly became nostalgic for the 1990s, and definitely not because I think QA teams should start documenting test cases with a pen. The reason is much simpler: after many years in software testing, I still find that some of my best testing happens before I open another tool.
When I start testing something new, I usually need to understand the problem first. What changed? What can go wrong? What assumptions are we making? What don't I understand yet? What did I just observe that looks strange?
And somewhere between Slack, Jira, browser tabs, API clients, DevTools, and documentation, those thoughts disappear surprisingly quickly. So I created the QA Notebook.
This is not a test case repository. That was probably the most important rule when I started designing it. I didn't want another place where a tester writes:
Step 1: Click Login
Step 2: Enter username
Step 3: Enter password
Expected result: User is logged in
We already have enough tools for storing things like that. I wanted something for the part of testing that happens before everything becomes structured and repeatable. Each testing session starts with a few simple questions: What am I testing? What changed? What can go wrong? What are the known risks? What did I learn? What is still uncertain? And finally: Do I have enough confidence to move forward?
Yes. No. Or with known risks.
The page next to it is intentionally mostly empty. Because testing doesn't always fit into predefined fields. Sometimes you need to draw a flow. Sometimes you write down three API responses. Sometimes you discover a weird state transition and draw arrows everywhere. Sometimes you have a hypothesis that turns out to be completely wrong ten minutes later. That's fine. The notebook should help the investigation, not force the investigation to fit the notebook. Good testing starts with questions, not test cases
One thing I've tried to put throughout the notebook is small reminders that interrupt the usual testing routine.
For example: A 200 OK response can be a bug.
Test what developers didn't think about.
Every assumption is a potential test case.
If the UI prevents something, check whether the backend prevents it too. A passing test only tells you what happened under one set of conditions.
These aren't supposed to be profound quotes hanging on an office wall. They're there because sometimes one question is enough to send your testing in a completely different direction.
You might be testing a perfectly normal form, see a reminder about boundaries and suddenly try the value just above the documented maximum.
You might be testing permissions and notice: A disabled button is not an authorization control. So instead of stopping at the UI, you inspect the API. That is exactly what I wanted this notebook to do: occasionally give the tester one more idea. Bugs need investigation, not just tickets. I also added dedicated bug investigation pages.
When something strange happens, my first instinct isn't necessarily to immediately create a Jira ticket. First I want to understand what I actually found.
What happened? What did I expect? Can I reproduce it? What changed? What evidence do I have? What am I assuming? What is the smallest reproducible case? That last question is particularly useful.
A giant broken workflow involving twelve steps, three users and two services isn't very helpful if you can reduce the same problem to one request. So the investigation pages have space to work through that before turning the finding into a polished bug report.
I also wanted the notebook to generate testing ideas. There are reference sections scattered through it rather than putting 150 pages of blank templates together and calling it a QA notebook.
There's SFDIPOT for when you think you've run out of things to test: Structure, Function, Data, Interfaces, Platform, Operations and Time.
There are reminders to look beyond functional behavior into performance, security, reliability, usability, accessibility, compatibility, scalability, recoverability, availability, localization and observability.
There are sections specifically about API testing: authentication, authorization, input validation, headers, CORS, status codes, rate limits, oversized requests and other things that are very easy to forget when the happy path works perfectly.
Toward the end I added practical reminders about decision table testing and state transition testing, because interesting bugs often don't live in a single condition or state. They live in combinations and transitions.
The notebook ended up being 162 pages, but the goal was never to create a QA textbook. It's something that should sit next to the laptop while you're actually testing.
Why paper? This is probably the strange part.
I work in IT. I build automation. I use AI. I write Playwright tests. I work with APIs and CI/CD. And I still like writing things down.
There is something different about having a notebook open next to the keyboard while investigating a system. I don't have to decide where the note belongs. I don't need to create a ticket. I don't need to format anything. I don't need another browser tab. I can just write: "Why did this return 200?" Circle it. Test something else. Come back to it twenty minutes later. Maybe it becomes a bug. Maybe it becomes a test. Maybe it becomes nothing because my assumption was wrong. That's testing.
The notebook doesn't need to preserve every thought forever. It needs to help me think while the investigation is happening. Automation Before Automation. There's a line in the notebook that probably summarizes the whole idea better than anything else: Think first. Test second. Automate when it makes sense. I'm obviously not against automation. Quite the opposite.
But automation becomes much more useful after we understand what behavior matters, what risks we're protecting against and what conditions are worth checking repeatedly.
Before asking "How do we automate this?", somebody still has to ask: "What should we test?" That's the space I wanted the QA Notebook to live in. Not instead of Jira. Not instead of Playwright. Not instead of AI. Just next to the keyboard. With a pen. And preferably a tester who keeps asking one more question.
QA Notebook — Think. Test. Question. Write it down.
by Liudas Jankauskas
https://www.amazon.com/QA-Notebook-Liudas-Jankauskas/dp/B0HH6MNG4Z
