Review of The Perfect Tester by Christine Jackvony
Hello everyone! My name is Ekaterina and I am a QA specialist at SimbirSoft. I have been involved in quality assurance of IT products for 7 years, and during this time I have read many books and manuals. Many books on QA are many years old, and new ones appear quite rarely. In January 2024, “The Ideal Tester” by Christine Jackvony was published in Russian – so I immediately paid attention to this book. I will share with you my assessment and conclusions – what is useful in it and what is missing.
A little about the author of “The Ideal Tester”
Before testing Christine Jackvony worked in the field of music education. In IT, she started as a quality control engineer, then was the head of the quality control department, quality control manager and SDET, and is currently the chief quality engineer at Paylocity. She runs her own blog “Think Like a Tester” and writes books.
Let's figure out who this book is for
The book consists of 12 parts:
Why we test
Manual testing
How apps work
API testing
Mobile testing
Security testing
Performance testing
Usability and accessibility testing
Fundamentals of Software Development
Automated testing
Testing Strategies
Soft Skills for Testers
The author herself says that the book is ideal for both novice software testers and experienced specialists who want to fill in the gaps in their knowledge. She also suggests that the book may be of interest to programmers who want to think like a tester.
What I liked about The Ideal Tester
The book is easy to read thanks to the short chapters that cover everything in a concise manner. Christine provides many examples from her practice, so after reading it it seems like you've actually just talked to a fellow tester.
Christine discusses why software testing is necessary at all, how to conduct manual testing of functionality and how applications work, talks about API and mobile testing, security testing, performance, usability and accessibility. There are also chapters on the basics of software development and automated testing. In conclusion, the author talks about testing strategies and soft skills for testers. At the same time, this can be considered a minus of the book, since many topics are described superficially. But since the book is more focused on beginners, it is useful to learn what testing consists of. It is clear that after reading chapters on automation, load testing or security testing, you will not become a professional in this, but this may encourage you to study these aspects in more detail in other sources.
The book contains many small chapters that contain tips for testing certain functions – for example, testing date fields, phone number fields, forms, tips for uploading files, etc. Perhaps, for more experienced specialists, many tips will be obvious, but for beginners, a lot of useful information is collected.
I really liked the chapters about API testing. There are also screenshots from Postman with detailed descriptions of where to click to start using the tool, and even a link to a test site to practice on. I think this is very useful for beginners.
Christine also wrote how to test certain requests, create automated tests in Postman, and use variables. I think that even a person who has never tested APIs could start testing after reading this chapter.
I liked that the author gives many examples from personal experience. She talks about both her successes and failures. Due to this, there is a feeling of dialogue with a colleague, you understand that everyone can make mistakes and this is normal. And it also prompts the idea of writing down your successful and not so successful cases in work in order to share them someday.
Why don't I recommend this book to those who know nothing about QA?
I agree with the author that the book is for beginner QA specialists, but still for those who are already familiar with this IT area at a high level. In my opinion, it lacks important topics for beginners:
Almost at the very beginning there are chapters “Testing the test field” and “Break your application with one weird method”. If a person who just wants to enter QA takes this book, he may get the impression that testing is only about “breaking functionality” and not about quality assurance in general.
At the beginning, I would like to see chapters on testing processes, basic terminology, the role of QA on the project and those who are also part of the development team.
The book contains many cheat sheets on how to test, but there are no chapters describing the techniques. test designtypes and levels of testing, working with requirements, documentation. The book is no longer about fundamental knowledge, but about the practical experience of the author.
In the chapter “A Matter of Time” the author reflects on which tasks should be automated, and in the chapter “Time Management for Testers” strategies are written on how to keep up with tasks. But there is no chapter that would describe how to properly estimate a task.
A few more “minuses” of the book
There are also some pieces of advice in The Ideal Tester that I think are “bad advice” and beginners may find themselves in an awkward situation if they try to implement them:
“Not enough time? Involve developers and other team members”
The chapter “What to test when there is not enough time for testing” has advice
Involve developers and other specialists in testing, if there is not enough time for testing.
In my opinion, this is not viable advice.
If your team members realize that you haven't been given enough time to test, they will be happy to help you.
– Christine writes. She goes on to say that by delegating scenarios to different people on the team, “we could test four times as many scenarios as I would have tested alone.”
All team members have their own work and their own deadlines. And you can't just ask someone to help you do your work.
Organize a “bug hunt”
Christine also recommends organizing a bug hunt, during which all employees of the company will look for errors.
Don't be embarrassed if someone finds something you missed. When we test the same thing over and over again, our eyes sometimes get blurry..
Yes, sometimes this is practiced, but you need to understand that such actions must be agreed upon. You can't just write in the work chat: “Guys, check if there are any defects in this application.”
Maintain a checklist in Excel and Confluense
I found it odd how Christine Jackvony recommends organizing test plans (which I understand are like checklists). She suggests writing this checklist with checks in spreadsheets. For personal purposes, she uses Excel, and when she needs to share with someone on the team, she uses a spreadsheet in Confluence.
From my experience, I can say that companies usually do not welcome the use of spreadsheets; checklists and test cases are maintained in the Test Management System (TMS). Therefore, when you come to a company, you need to find out in which TMS the documentation is maintained, and not maintain it in Excel just because it is more convenient.
Generate test reports
In the chapter “Six Steps to Writing an Effective Bug Report,” Christine also writes about how to properly create a report in a table. But if you maintain documentation in a TMS, you don’t need to create any additional reports (unless there are other rules on your project). For example, I only encountered a requirement to create an additional report on one out of 10 projects. Usually, it is enough to fill in the results of the case/checklist run, indicating “passed/failed” (depending on the selected TMS). If you don’t understand whether any additional reporting is needed, it is better to clarify this point at the start of the work.
“There is no need to write test cases”
Christine Jackvony says she doesn't write step-by-step instructions (test cases):
Unless you're writing a test plan for someone you've never met, will never communicate with, and has never seen the application, there's no need to.
Test cases take a long time to write and are difficult to keep up to date, that's true! But if you're a newbie and have come to a project where detailed test cases are written, I don't recommend criticizing this process right away and switching to checklists on your own. You need to understand why this is the way things work in this case – maybe the project is complex, there is staff turnover, in such cases test cases are necessary.
Let's sum it up
To sum up, I can say that the book is more suitable for beginners who are already familiar with testing theory, basic terminology and have an idea of the development process and the role of QA in the team.
I recommend reading “The Ideal Tester” after other books for beginners. For example, you can start with Olga Nazina's books “Test Design. A Practical Guide for Beginners” and “Bug Tracking: Localization and Registration of Defects”, as well as Svyatoslav Kulikov's book “Software Testing. Basic Course”.
Christine Jackvony's book can be called a collection of notes of a tester. In my opinion, it lacks depth and fundamentality, but at the same time there is useful information that can be taken into account. I will separately note that the author talks about automated testing and gives advice on how to write code for tests correctly. But if you have not automated before, it is unlikely that “The Ideal Tester” will help you start automating tests.
I gave the book 3 out of 5 points. How do you rate it if you've read it too? 🙂
Useful links:
Localization of defects and registration of bug reports
When Test Metrics Are Useless
Thank you for your attention!
Read more useful materials for QA specialists on SimbirSoft social networks – VKontakte And Telegram.
