---
title: "Catalyst 6: QA Testing (Overlooked)"
date: 2010-04-22
description: "From Overlooked to Center Stage   1.0 Presenting at the Atlanta Currents Conference (Overlooked)   1.1 Intro..."
canonical_url: https://idratherbewriting.com/2010/04/22/catalyst-6-qa-testing-overlooked/
---
# Catalyst 6: QA Testing (Overlooked)
As I was testing my instructions (one of the most important ways to review documentation), I kept running into bugs in the application. At first I forwarded them to the QA developers through email. I wasn't sure if they were already logged in JIRA or not, and I felt it wasn't my role to log bugs anyway.

But soon QA started asking me to simply log the bugs. They gave me the appropriate rights in the JIRA. Okay, I thought. I'll do it as a convenience to them. So I started to figure out JIRA, and I kept more up to date with the information and comments there. I started to log a few bugs, and then a few more. In a somewhat sadistic way, logging bugs felt therapeutic. Pretty soon I felt no fear at all and logged 25 bugs in one day. This got the attention of the developers and the project team in an astounding way.

Everyone was surprised at the degree of bugs I was finding. The QA lead had developed an extensive number of automated scripts, but he wasn't finding all the bugs I was finding. I was finding a surprising amount of bugs precisely because I was simply going through topic by topic in my help documentation and testing everything (really testing my instructions but also the application at the same time).

I realized that I had literally written a book on the application -- something no one else on the project had done. I knew the application as intimately and thoroughly as anyone else on the team, if not more. With this knowledge, especially combined with the user knowledge, I could see bugs in places QA never thought to look. Over the course of a week of heavy review of my help, I logged about 65 bugs.

One thing I was also doing was using [SnagIt](http://www.techsmith.com/screen-capture.asp) and [Jing](http://jingproject.com/) to show the bugs. All the other QA members just described the bugs with text. It quickly became clear that pictures were the preferred mode for developers to see bugs. They soon joked that unless the JIRA item included a screenshot, they wouldn't review it. After a few weeks, the QA team also started to include screenshots.

QA considered me an addition to their team and said I would make a great QA tester. I thought they might be upset at the QA spotlight I was taking, because I was logging three times as many bugs as they were, but instead they thanked me for logging the bugs and genuinely appreciated it. (It would save them face later to not have bugs found in the production release.)

Pretty soon in meetings I was no longer someone they passed over quickly at the end. I was a key voice in bug triage, scrum, and other meetings, where developers and project managers would need to evaluate the bugs they were going to fix. I wasn't just sitting there listening to others talk. Instead I was explaining the bugs I found, and evaluating the seriousness of the problems.

I noticed another thing -- if I logged a bug in JIRA, someone usually fixed it. Not always, but it was the secret passage way into influencing the application. Even small fixes involving textual changes were something I could sneak in and get done. Soon one of the new developers on the team starting coming to me to ask if his planned fix was all right with me. I already owned all the text in the interface, but now that domain was blending into functionality.

On one occasion, I found a screen to be particularly problematic. I had a tough time describing how it worked, and the video I created was even more problematic. I also logged about five bugs against that screen alone. I made such a big deal of it that I convinced the project manager that, despite the time crunch and our lack of resources to fix it, we couldn't skimp on this. He told me to get with the developers to redesign the page.