What is Quality Assurance?

During my time as a Quality Assurance Engineer, I would wind up explaining to curious people that what I did was more than just testing software. So, what is Quality Assurance if it’s not just software testing? Quality Assurance is an approach to developing software. It begins with software design and ends with documentation of the product.

Q. A. on Design

Usually there are two parts of the design. You usually have a requirements document and a technical specification. Requirements documents usually have more to do with business needs but can contain flowcharts for different processes involved in the software. Most good Quality Assurance Engineers excel at picking out areas where processes can break down. This skill set doesn’t need to be limited strictly to software processes. If there’s a business process like shipping or communication with clients or other employees, QA Engineers can be useful in making certain that these processes run smoothly by identifying possible problem areas.

Once the requirements document is complete, or if none is drawn up, a technical design or specification should be drawn up. By taking the time to do this, you can avoid having to back up and rework sections of the code, which wastes developers’ time, and do this rework on paper in the document which takes considerably less time and costs less. Now, in most cases, your developers will be in a better position to identify problems in the design related to the feasibility of implementing the design. QA Engineers can help identify usability problems and testability problems. In other words, they can help tailor the design to make the end product easier for end users to use and to make testing simpler and quicker. The first is a great selling point and the second will increase the quality of the product while decreasing the time to market.

Q. A. during Development

Quality Assurance isn’t just for Q. A. Engineers or software testers. If you can get developers to approach their development with a Q. A. mindset, it will greatly increase the quality of the project. They will also usually save time in the long run to implement Q. A. during the development. This will be explained with each practice you can implement during development.

The first thing you can do while developing to insure the quality of your software is to comment your code. Even if the comments contain is a list of arguments the function or method takes, what effect it has, and what it returns, this practice is invaluable for other developers who are programming similar or dependent functions. It also serves as a guide for white-box testing and unit testing.

Unit testing is another great practice for maintaining software quality. Unit testing is the practice of writing tests for each function or method within the program. It’s a deep level test, but it insures that each function or method does what it’s supposed to do at a fundamental level.

As an example of unit testing, let’s assume that you’ve just written a function that creates a user record for your application. It takes arguments for the different user attributes and returns true or false based on whether it successfully created the user object. You write a unit test that insures that it returns true when it has all the required arguments and false when it doesn’t.

The following day, you add some more attributes to the user record and update the creation function to reflect these changes. Now, to make sure that these changes didn’t fundamentally change the effect of the function. If it did, that’s fine, just update your unit test. Make sure you make the changes to any functions that call creation function you changed and then run the unit tests for all of the dependent functions. If you do this while the changes are still fresh in your mind, then you can avoid going back later and trying to remember what the differences were.

One method of using unit tests during development to keep the quality up on is continuous integration. Continuous integration is the practice of running the unit tests each day or each time you commit code changes to your repository. If the test results are gathered and failures are reported each day or on a regular basis, then broken code doesn’t get perpetuated because you’re alerted the second a change breaks something in the code.

Q. A. after Development

This portion of Quality Assurance what people usually consider Quality Assurance. As we have already seen, Q. A. is much more than just testing after development. Testing software usually breaks down into a couple of different stages. The first step in testing software is to formulate a test plan. This is usually done during development based on the technical specification and then is followed up after development is complete to insure that any deviations from the specification are accounted for. In a best case scenario, the specification would be updated and the Quality Assurance engineers informed. The test plan’s purpose should be to insure that the program meets the specification.

Once the test plan is drawn up, the testing takes place. The test plan should be specific enough that even a junior tester with limited experience could follow its directions and successfully report on the program their testing.

Q. A. after Product Release

After the product is released, bugs will still be found. The most important things to keep in mind after the product ships are keeping track of bugs, collecting as much information about how to reproduce them, and figuring out how to avoid similar bugs in future releases. This area goes far beyond this short summary is intended for, so I’ll be treating it in future posts. The remainder of post-release debugging boils down to training your support and Q. A. personnel to handle the information given them by customer.