Talking Usability: What I Learned Testing Software

I work on a small project team that has just enough people to keep the project somewhat on schedule. When the quality assurance manager asked for help to test software—I volunteered. My manager was delighted and disappointed that I volunteered to test software because he believed that testing software would take me away from my primary job—writing a user guide. As it turned out, testing software helped me to learn the system’s workflows and logic, which helped me to write the user guide.

While testing the software I found opportunities to put my technical writing skills to good use.  While referring to test cases to evaluate the software, I rewrote test cases that did not have clear and complete instructions. I created reports to identify errors to workflows, labels of buttons, and messages.

You might believe that correcting test cases is not your job and you are correct. It’s not your job to test software. I am not advocating that you work outside your job description. However, if test cases are your only source for understanding the navigation of the system then you might want to volunteer to rewrite them. On the other hand, you can always rely on the helpful and friendly developers.

Technical writers know the importance of getting the software correct to avoid their user guide (and training) to become a solution for poor design. Involving technical writers in the testing process brings the perspective of the end user. Bringing the perspective of the end user to the design effort ensures that designing a satisfying user experience is as just as important as meeting the release deadline.

Working outside your job description and raising your visibility above the expectations of coworkers will elevate you to new heights and put your skills to good use—helping to design the user experience.

I’m David Dick and I’m Talking Usability