Path toward Disposable Outsourcing: QA

Is there a better way to start a new year than writing a blog post? Of course there are plenty, but it just happens that I have one ready just in nick of time. So happy New Year, may it bring you success, prosperity, health, and happy outsourcing…

There is probably no easier way to introduce outsourcing in a software development organization than QA augmentation. Simplicity of it is actually deceiving and many companies pay high price for it. Check out my earlier post Pros and Cons of Outsourcing QA for more thoughts and tips. Despite its cons outsourcing QA remains extremely popular and thus should be considered for operation under DOM. Also in my view DOM is relatively easy to implement in QA Outsourcing engagements and thus might be considered as the best first step of embracing the DOM.

Path towards DOM in QA has many steps similar to those covered in Path toward Disposable Outsourcing: S/W Development. There are of course some subtle differences and specific steps important for Quality Assurance. Here are a few most important items:

  • Strict rules on bug submission / documenting. Some of the rules are enforced by bug tracking software. Depending on the sophistication of the tool you use you may find a substantial room for creativity – which is often not a good thing. I recommend using well defined rules and templates that spell out all components of the bug report. For example the bug title has to clearly identify the issue.

How many times do we have to say that, and yet, “Problem when loading the app” keep showing up… The standards need to be spelled out, delivered to the team and rigorously enforced. One approach of dealing with problems is to a put a bug in “Feedback” or similar status and require submitter to deliver appropriate content before the bug is put in the rest of the workflow.

Considering the abundance of QA workforce being brutal could be the way to go. “First time it’s your fault, second time it’s mine, and third… well, there is no third time”. Control can be applied to every bug or less reliably on spot check basis.

  • Regression and other functional test case suites should be developed at just the right level of details. Executing testing should engage testers’ brain not just fingers. That ensures quick learning of the application while maintaining knowledge. Producing large volume of testing documentation is not necessarily going to speed up transition, as a matter of fact it often rendered useless and abandoned by the new team. A simple rule of thumb is QA engineer should be able to execute existing test cases in two – three days and should be fully productive in not more than two weeks.

One of techniques that worked well in my experience is producing test cases at two levels. The first is high level that is typically linked to a single use case, the second level spells out details in a traditional test case format. This approach allows more experienced QA engineers use high level test cases and keeps them engaged, while detailed test cases provide step-by-step instruction of new team members.

  • Test data must be stored in a source control system. If produced in some automatic way only the data generation scripts should reside in the source control. This is critically important. You should be able to generate entire suite of test data out of the source control system for a specific version of the application, just treat test data as part of the source code. I have to note here that this task might require some of the top developers on the team as it requires in-depth understanding of schema / object model as well as solid coding techniques.

Getting test data to that level late in the project cycle appears as a daunting task. It is however important and should be done even if it impacts schedule. Savings down the line will more than pay for immediate loses, even if you never need to execute on DOM.

Test automation combines all software development and testing techniques. Developing test harnesses, frameworks and test cases is one of the most challenging tasks in application development. Unfortunately, labeled with “QA” it rarely gets the attention it deserves.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s