Quality Assurance and Testing

Quality Assurance in Software has many variations to it. At Moxie, we differentiate our QA projects into four basic categories:

  • Build
  • Automate
  • Agile
  • UAT

This whole interpretation came about because of the knowledge that no Automated QA tool in the world is able to test code completely and properly. In today’s environments, the code is even more complex and customized, and complex code makes it even more difficult for that code to be tested through some tool. Effectively, more and more companies realized that just buying licenses of an off-the-shelf tool may not be the answer for them.

So, if you have a low need for QA Tools, then how do we test your complex code? Today, most companies are adapting for “Agile Development” where the testing takes place simultaneously along with development. The testers sit side-by-side from the developers and work shoulder-to-shoulder to write and generate robust code that doesn’t require to be tested separately. But this process requires a high skill in the coding language and also requires more human resources rather than a tool to get the work done. This loses efficiency and monetary ROI in large complex environments.

There is other such dilemma that companies face in their decision making. Moxie has come up with a way to engage us with a simple decision-making chart:


When you have a very strong ‘development team’ that is building a strong software and you would rather just rely on a tool to get through QA quickly and move the results to production, then the best option is to ‘Automate’.

We cover a wide gamut of ‘Automated Tools’ including:

  • HP Mercury Suite
  • Quality Center
  • WinRunner
  • LoadRunner
  • Quick Test Pro
  • Rational SQA Suite
  • Rational Robot
  • Silk
Under this environment, the candidates are tool-centric and will test based on the tools needed.


When the complexity of the code increases, but the quantity of code is high, and you need to still maintain some amount of automated process to maintain speed and mitigate cost, you would need to build your own test harness, a test bridge, so to speak. For this you require resources that have a combination of strong coding skills and strong knowledge and understanding of automation.

Many companies have used Moxie resources to build these test harnesses. Other companies have requested us to build on top of ‘open source’ test tools like Selenium and WATIR, customize those tools to the environment that they are under to deliver the correcting testing environment.

This cannot be achieved without strong coders who are also testers.


Like build, agile requires a strong knowledge of the code, but the resource’s job is to sit with the developers and review and advice on the code, rather than coding it on their own. As opposed to building a ‘test harness’ you are building your software itself but simultaneously testing it. Many companies have found this their solution of choice, but many companies also may not be able to afford the talent necessary to have such strong technical resources who can code and test. The level of automation in this environment is minimal. It is almost completely a ‘manual testing’ environment.


Finally, there are some Moxie Clients that have already built and tested the code but are only interested in making sure that the functionalities have been achieved. In these cases they ask Moxie to perform only the User Acceptance Testing part. The skills required in this a very different from the first three in that, we don’t necessarily need to display ‘Coding’ or ‘QA Tool’ skills, but need to have a good analytical mind with strong logic and problem-solving skills. An solid understanding of the Client’s Industry vertical and business domain is definitely required.

Moxie typically finds itself in a UAT relationship, when we have been tasked with the ‘Business Analysis’ work as well. These two functions are bound at the hip. It is the “use cases” through our BA that get translated to “test cases” in our UAT.

This is how we interpret your development and testing environment and help you make better decisions on how to take the next step in ‘quality assurance’.

Some basic processing in testing that Moxie performs are:
  • Functionality Testing
  • Load & Performance Testing
  • Unit Testing
  • Smoke Testing
  • System Testing
  • Usability Testing
  • Regression Testing
  • Integration and Configuration Testing
  • Localizations Testing
  • Database and Data Integrity Testing