In the last twoposts, I discussed about how the qTrace team adopts exploratory testing and how that technique/mindset shines in projects where changes and unknowns are inevitable (which is a characteristic that all my projects in the past and probably in the future). This post describes how qTrace improves productivity of exploratory testers.
As a recall, exploratory testing is a process where testers design and execute test on the fly without the need for pre-defined test scripts. This is generally a mentally intense process because testers need to focus their mind on the application at hand, the path to explore (or backtrace) and observe any unexpected behavior. What usually happens during such process is that testers will go into the flow, a kind of mental state where their productivity often peaks. (I highly recommend this book if you want a more thorough treatment of this psychological concept than the Wikipedia entry.) If you are passionate in what you’re doing, I bet you must have experienced this type of mental state before. I myself have experienced it countless of times when programming and it usually manifested having me losing track of time and forgetting about my hungry belly and thirsty throat. Usually before I knew it, many hours had already passed.
Now, any interruption to this kind of mental state is highly counter-productive for it is difficult to get into it in the first place. If testers have to work under constant interruption, getting into a flow is almost impossible. You already know what are some examples of interruption could occur in your typical work day, do you? Phone calls, emails, meetings, lunch breaks etc. Ever wonder how many self-help books you read talk about the dead of meetings or how to manage emails effectively? Then again, these are popular but not the fiercest enemies of productivity, for they still don’t happen frequently enough to testers. The number one killers of the flow, and thus productivity, are usually the tools employed to do one’s work. Let me elaborate…
Think about a typical exploratory testing session. A tester would launch the application and perform testing on it. Every few seconds or so, she would note down the steps performed or interesting observation (so that she could either backtrack and/or report later) on a piece of paper (or some Notepad-like tool). Then go back to testing. Every few minutes or so, she would capture a screenshot, open it in an editor (usually Paint isn’t up to the task and a more sophisticated image editing tool is needed), annotate it with information like what keys she pressed and what buttons she clicked etc. Then go back to testing. Then take more notes and capture more screens. When she’s ready to submit a bug or improvement request, she would launch the defect tracker website, gather all her notes, screenshots and certainly brain power (mostly memory) to compose a defect report with screenshots, associated steps to reproduce and notes, test environment information etc. Then go back to testing. Sometimes when a defect is too complicated, she would launch Word and compose a more detailed bug report with multiple screenshots and attach it to the bug tracker. You see? Major interruption happens in matter of seconds. How does that affect the flow? Well, what flow? For I can hardly imagine a tester going into any flow under such constant interruption.
Now, think about a different tester with a different tool, qTrace in this case. She would launch qTrace and the application under test. Every once in a while, and if really necessary, she would enter a note into qTrace which sits quietly on a corner ready to accept input with just a single keystroke. Most of the time, it’s only her and the appellation under test with no thing in between. Whenever she feels enough for an exploratory session (i.e. a bug has been found), she would asks qTrace to show up an editor presenting each and every screenshot and action she has gone through and performed in an orderly and accurate manner. Every note she took is also automatically associated with a screen and action performed just before she had taken the note. Not only that, test environment and application information are also automatically captured and displayed. Now she can annotate the screens some some easy to use tools like callout, crop, arrow, blur etc. Finally, with just a few clicks from within qTrace, she could submit a well-structured and nicely-presented bug report in Word, PDF or JPG format to the bug tracker, be it Jira, Bugzilla, VersionOne, HP Quality Center, Team Foundation Server or our very own qTest. Did you see the difference? In the previous scenario, the tester does everything, noting every single step, capturing every screen, tracking test environment, associating steps and notes to screens and dealing with a bunch of different tools in order to be able to submit a defect. In the second scenario, qTrace silently, effectively and singlehandedly handles most of those activities, freeing testers to focus on their testing process and achieve the flow. That is exploratory testing at its best.
If you are an exploratory tester looking for the one tool that effectively supports your testing process instead of pulling you out of the flow, qTrace is certainly worth looking at. What stops you from spending 15 minutes trying a tool that could possibly save you hundreds of hours and help you discover many more bugs every year? And if you happen to have some ideas that helps us improve how qTrace works so that it benefits you even more, please do not hesitate to let me know. Thank you!