An independent Quality Assurance (QA) is standard in the industry, to ensure the quality of software. We provide not only testing itself, but a complete Quality Assurance services.

Quality Assurance

Quality Assurance is an entire set of management and technical activities that ensure the product matches all requirements. In fact, QA is paramount at XTLabs, Inc. and everything we do comes down to Quality Assurance. The well-known diagram below best illustrates our approach towards improving our process and towards a constant increase in quality.

We understand Quality Assurance as continuous work on making our process smooth, predictable, and controllable. We think that it is very important to keep it "step-by-step"; in other words, not only the steps themselves are important, but also their sequence.

Let's take a moment to go into the details of each step:

Plan step

All jobs on the project, on every level, start with planning. Everything begins with envisioning, specification on various levels, and plans.
Then comes the Do phase.

Do step

Here we have a defined policy on how things should be organized. We follow the basic principles of the Rational Unified Process (RUP) from Rational Technologies. This is a de-facto leading standard for software development methodology, employed by the best companies in the industry. Companies like Microsoft and IBM are partnering with Rational to make use of RUP and create joint products supporting RUP.

The core ideas of RUP (iterative development, sustainability to changes, careful QA and risk management, etc.) are very much suitable for our situation, in which we often work with dynamic business cases. On the diagram above, the horizontal trends represent activities. The graph shows the amount of activity spent in each phase. On the whole, the graph illustrates how various activities (efforts) are spent among various project phases.

Check step

This step is about checking to ensure whether what has been done meets planned requirements and specifications. Checking is done in various areas:

• Check specification: check existing functionality vs. planned specification
• Check scheduling: Planned scheduling vs. real milestones
• Check budget: planned resources and budget vs. time spent and invoices issued

The "price-time-functionality equation" is a powerful metaphor. Failing to set all three corners of this triangle on firm footing can mean high project risk. We carefully discuss each requirement and business constraint with the client to make sure we arrive at the most desirable 'triangle' for the client. Software Quality Control is a crucial part of the process. The testing facility (used in the first step) allows us to test our applications on various platforms, such as Windows, Windows 2000, Windows XP, Macintosh, and in UNIX -family (Linux, FreeBSD etc.) environments.

We run our products through a number of tests:

Functionality Testing - validation of the entire application, ensuring that there are no "invalid content," functionality, or application errors. For regression testing, tests may be partially automated. Interface Testing - checking of visual design in accordance with corporative standards. Usability Testing Website Integrity Testing (Web applications) - detection of broken links and "orphan pages" Specification Fulfillment Testing Coding Style Verification, based on corporate tester Outgoing Documentation Testing

1. Performance, Load, Volume and Stress testing, Benchmark testing
2. Compatibility and Portability Testing - Verification of software operation across different hardware and software configurations (operating systems, browsers) for which it was designed
3. Database Operations Analysis - Monitoring of database activity, checking all queries and transactions between a Web application and SQL Server; identifying where and why transactions may be performing poorly.

Act step

The ACT step is about analyzing the results of the previous step (CHECK) and making appropriate decisions on how to improve the quality of the process or product.

The following are two examples of how this scheme is applied to the real process: on the coding level and on the management level.

• Coding A programmer needs to write a procedure. First, he plans the algorithm and defines the input and output parameters. Next, he writes the code - the "DO" part. Checking whether the procedure works correctly under various circumstances is the "CHECK" part. Subsequently, he decides whether this procedure should be included in the code repository.

• Management A project needs to be completed. First, the specs are written, the team assembled, and resources are allocated. Next, the development begins. Last of all come testing and bug-fixing, and only then the project is analyzed and documentation goes to the "knowledge base."

Our process may vary slightly depending on the particular customer, but the above are a few quality principles that we adhere to on all projects.