I recently attended a conference session about a team's lessons learned from thousands of bug fixes. I thought the session might cover some patterns detected in the defects found, persistent defects that continued to appear even after being "resolved," how defects were prioritized and duplicates were eliminated, and so on.
But the session didn't yield that information and was not at all what I had hoped it would be. However, it did bring to mind a blog post I came across several years ago from a developer who, in his quest to become a better developer, kept a journal to record the defects he found.
Here's how you can become a better tester by journaling.
The benefits of journaling
Around a decade ago, back in the days of waterfall development, I worked on a QA team composed of eight testers, four senior testers, a QA lead, and a QA manager. There were also other resources who worked more closely with the customer, and all of these people could log defects for the application we were developing.
In eight months of testing an application with six major feature groups, we logged over 2,000 defects. It was impossible for any one person to remember the breadth and depth of that many defects. I personally logged over 400. I owned those defects from the time they were opened until the time they were closed, yet I couldn't remember the details from even that many defects.
As someone who has moved around from job to job and company to company—sometimes by choice, sometimes by necessity—it has been difficult to take all of the lessons learned with me when I transitioned from one job to the next. Most work products are proprietary, so you can't take anything specific with you that might light your way at the next job. But you can take the lessons learned.
Here's why that's important: If you work on similar applications, you may run into similar issues. If you tested a mobile application previously, you may encounter many of the same issues while working on a new mobile app. Knowing what those issues were may help you look out for them, and to notice them when you find them again.
Taking notes about the defects you uncover may help you remember how you found a particular issue in the first place, which may help you find it again. It may help you to find a similar issue again in a totally new context. It may also help you to compare and contrast certain behaviors in Android versus iOS, or to find browser-specific issues.
The best part is that you can take those general (non-proprietary) notes with you from one job to the next, for your own personal reference. A good tester will ask a lot of questions about how a feature works, but having a reference as a guide for common issues—based on prior defects you have uncovered—is a great way to remember some of the things you should be looking for.
Go old school
Plenty of studies—such as the one referenced here—have shown that taking handwritten notes versus electronic ones helps with memory retention.
"Basically, because we can keep pace typing but we can’t keep pace with handwriting, it means we have different ways of encoding the information, which in turn leads to richer memory."
There's also evidence that handwriting improves your creativity. It's a lot easier to draw a sketch with a pen or pencil and paper than on a touchscreen, on an electronic sketchpad, or with an electronic pen.
What to write in a testing journal
I've carried a legal pad for years to take notes at the various user group events I attend. I also use a smaller Moleskine notebook to take similar notes at meetings and conferences. I use Evernote frequently to organize clips or bookmarks of interesting testing blog posts I've discovered, or lists I've found of cognitive biases, heuristics of software testability, 10 sources of testing ideas, etc.
I used to take notes from the books I'd read and add them to a Word document. Now I keep notes from books, webinars, and podcasts, and organize them in Evernote, making it much easier to refer back to them later.
For the webinars I attend online, it's often easy to copy the precise description of the webinar from the official page or invite: a brief summary, the speaker's name and bio, the host, and the date the webinar occurred. Most webinars are recorded, so you can often also include a link to the recorded session in your notes.
I've always tried to take notes during backlog grooming sessions for stories I might not see in a test environment for a week or more. It's great to be able to refer back to my notes from when developers were breaking down a story and discussing technical details about it that may be relevant to what I need to test.
As I'm testing new stories or fixes to defects, many times something gets missed. It may be something that was included in the story description or acceptance criteria, or maybe it was another use case that wasn't considered. In the age of CI/CD, a story that is only half right or half done may still move to production (if it's not a breaking change). But it's important not to forget to record the remaining items that need to be completed to fulfill your requirements.
I've tested some very intractable defects that were extremely difficult to reproduce on command. Sometimes the only way to prove that I wasn't dodging such issues was to document precisely all the ways in which I'd tried to reproduce an issue.
I started with some of the easiest possibilities and progressed to the more difficult options. Even if I could never reliably reproduce the issue, I could document the avenues I had exhausted.
Have you ever been in a meeting to discuss a specific issue only to have five more issues brought up? Even if those items aren't germane to the meeting, it's important to record those items to capture potential issues and things that need testing, or to determine if a story or defect exists or needs to be created. Talking about issues doesn't do any good if they never get addressed.
Get better at writing
Even if you're recording notes just for yourself, the best way to become a better writer is to simply write as much as you possibly can. Writing will help you think through problems and decompose issues into smaller, more manageable bits that may be easier to solve.
Writing helps you to organize and crystallize your thoughts. To quote E.O. Wilson, "We are drowning in information, while starving for wisdom." The value of all this information is found not in the information itself, but in the person who has the ability to take information from various sources, analyze it, and provide good advice or make critical decisions from the available information.
If, as Lao Tzu said, "a journey of a thousand miles begins with a single step," then a journal of a thousand words begins with a single stroke of your pen or pencil. Start your journal today, and see where it leads you on your journey to becoming a better tester.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
