QTRACE - good exploratory testing tool

2 years ago, while still working in one of my last full time jobs (only working on contract these days), I saw a presentation given by HP about their latest exploratory testing application.

The app was very interesting and useful but unfortunately, it came only as part of Quality Center so not available to any private users.

Last week, while looking for some information on the uTest tester forum, I accidentally read this old post about an exploratory testing tool called QTRACE.

I already knew and used Rapid Reported (http://testing.gershon.info/reporter/) which I find useful but a bit too raw. QTRACE is much better in many ways.

QTRACE (http://www.qasymphony.com/qtrace-overview.html) is as good as the Quality Center exploratory testing software but with the great advantage of being free. The paid version offers only the advantage of exporting unlimited bug reports to a bug tracking system like Jira.


QTRACE works by recording all user activities and takes screenshots every time the screen changes or the user interacts with the application under test.

At the end of the recording, all steps and screenshots are displayed in the QTRACE EDITOR where more changes can be done:

- the screenshot names can be modified
- the task descriptions can be changed
- new tasks can be added
- notes can be added for tasks
- the screenshots can be annotated

The end result is a very visual oriented bug that should leave no questions for the developer on how the tester tested and what the problem is.

The bug can be exported in a WORD or PDF file and will include detailed information about the system used and the application tested.

The only problem that I can find with QTRACE is that lots of user activities are recorded and may need to be changed.

I have tried it with both a client Windows app and a website and it worked well in both occasions.

If sufficient time exists for bug reporting and the bug reporting standards are high in your company, you should add QTRACE to your QA apps toolkit.





Code refactoring for better test automation code

I took a break from test automation at the beginning of 2012 due to changing jobs.

Recently, I convinced my employer to buy the Ranorex test automation tool (http://www.ranorex.com) after using the tool's trial version to find a bad memory leak in a production application.

So, I resumed working on test automation with Ranorex and C#.

Initially, I created a few scripts through record and play so that I understand the objects used by the application and their attributes.

After the record and play scripts worked well, the real job started.

I cleaned the scripts up by removing duplicated code, making use of looping, variables, classes, using the repository as little as possible.

The scripts started to look better soon but I was still not very pleased with them.

They were clear enough to me but difficult to understand for another person with less Ranorex and application-under-test knowledge.

Some serious changes were needed but I had no clue how to do them.

Then, I found this amazing book at the local library about code re-factoring:
Refactoring: improving the design of written code.

The book presents many ways of improving the design of existing code such as:

- bad smells in code
- composing methods
- moving features between objects
- organizing data
- simplifying conditional expressions
- making method calls simpler
- dealing with generalization

It is written for people that know an object oriented language like C++, C# or Java (all examples are written in Java).

This book helped a lot improving my code by explaining how to

- replace temporary variables with queries
- remove flag control from conditional expressions
- replace nested conditional with guard clauses
- rename methods
- replace error codes with exceptions
- replace a group of parameters with an object
- move features between classes
and many more ....

A benefit of reading the book is that I have learned a few C# features like custom operators, get and set methods, assertions and exceptions.

I am so happy with this book that I am going to buy it to have it handy for future test automation projects.

It is a very good resource for any tester who aims at improving his coding skills for test automation.

Because, as the author of the book puts it, any fool can write code that a computer can understand, Good programmers write code that humans can understand. 

And for this, code re-factoring is essential.