TheLadders.com Developer Blog

Consider the following situation:

"
While testing the web site, QA goes to the "Join Now" page by clicking on a Job Listing from another website. After filling in the required information and submitting the form, they come to the Homepage (incorrect) rather than the View Job (correct) page. Why did that happen? The tester then opens up the issue tracking system and submits a new defect. They describe the steps they took and what they saw and submit the issue to a developer.

Now the developer has to reproduce the error. Which controller (an MVC architecture) was responsible for choosing the homepage for display? Which user was logged in? What was the state of the session at the time? What was the state of any other dynamic configuration on the site? What pages did they visit before coming to the page with the problem?

A lot of time is spent trying to rediscover information that was available at the time of the bug incident.
"

If you've ever been in this situation, say "Aye!"

Josh Levine, one of our developers had a good idea to address this situation. He wanted to create a client-side QA toolbar. That is, some AJAX code that runs in the browser, which is automatically attached to every page in our QA environment. The toolbar would expose server side state information and enable shortcuts for common testing and debugging needs.

The initial implementation had three functions:

1. Expose more information for QA to validate (not a replacement for functional testing, but a good shortcut)

2. Automatic issue submission (in our case, integrated with Atlassian JIRA)

3. Provide debugging information for the developers (session variables, click history, etc).

After some experience, we uncovered an additional use:

4. As a hook for other "session" based controls in the live environment. For example, choose a test cell (In our AB Testing framework), adjust error logging levels, quick-logout (usually a multi-step process), set and clear other flags and variables for testing and debuggnig purposes.

With all this information available, the situation plays out very differently. Now, when an error happens, QA can submit it with one click. And the submission can include controller name, username, JSP name, session state, click history, dynamic configuration data, etc. The QA person just has to add a few comments about what it is that was broken.

The model has proven to be extremely flexible and is responsible for substantial productivity gains for both QA and development.

The core functionality was completed and implemented in 4 days.

Look for Josh's post next, with details.