How QA and technical writing go hand in hand

Traditionally, technical writers write and QA analysts test the application. However, turns out it pays to be curious and get your hands dirty. Indeed, what better way to know if your instructions work than first-hand experience with the application itself?

As many of my friends know, I am the kind of guy who likes to tinker with hardware and software alike… Therefore, QA seemed like a natural extension of technical writing to me. QA testing consists in completing a series of tasks with a given application to track bugs and other issues. They ensure that the application serves its purpose. In addition, QA testers can also make recommendations to improve the user experience, the UI and the application itself.

The mighty test case

Test cases are technical documents used by analysts, developers and testers to document the testing process. The document defines the tester’s mandate. As such, test cases must cover all the scenarios for the module or function that needs to be tested. Otherwise, testers may waste time wondering if they covered everything. Testers contribute to the document with comments about roadblocks. Once the tests are complete, the test cases are stored for future use. For instance, if issues are reported to user assistance or the help desk, we have to make revisions to the program. My prior experience with documentation helped me complete clear and precise test cases.

A good test case includes the following:

1. Test cases id (often the ticket number)
2. Test description
3. Clear steps to run the tests
4. Expected test results
5. Test results (pass or fail)
6. Comments/ screenshots about errors/improvement

QA procedure

Completing the QA process can be time-consuming, but it mostly involves communication and trust between the developers, the analyst and the tester. I ask many of the same questions as during an SME interview. Usually, it goes as follows:

1. The analyst and developer write the test case.
2. The tester and the developer have a quick discussion to answer the tester’s questions.
3. The tester runs the test and writes down the test results and comments on usability.
4. The developer makes changes to the application to correct any bugs.
5. Repeat step 2 and 3 until all the application is problem-free.

Putting the User Experience first

However, one of the most underappreciated jobs of a QA analyst is to keep the end-user in mind. If anything impedes the user experience, you should report it. For instance, I once compared the old version of a module to its successor. I found out that the new one lacked key features that previously were available. I often make comments about ambiguous tooltips, spelling errors, or anything that could improve the experience. Of course, you have to understand what is feasible before the release date. However, the good thing about Agile development is that there is often room for experimentation.