Anatomy of a Software Development Role: Quality Assurance | Developer.com

The Quality Assurance (QA) role is the role responsible for guaranteeing a level of quality for the end client, and to help the software development team to identify problems early in the process. It is not surprising that people in this role are often known as “testers”. Of course, the role is more than just testing. It’s about contributing to the quality of the final product. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

What’s the Quality Assurance role?

The quality assurance (QA) role is one that is focused on creating a quality deliverable. In other words, it is the responsibility of the QA role to make sure that the software development process doesn’t sacrifice quality in the name of completed objectives. Click hereto see how the QA fits within the full organizational chart.

The QA role works with the Functional Analyst (FA) and the Solutions Architect (SA) to convert the requirements and design documents into a set of testing cases and scripts, which can be used to verify that the system meets the client needs. This collection of test cases and scripts are collectively referred to as a test plan. The test plan document itself is often simple providing an overview of each of the test cases. The testing cases and scripts are also used to validate that there are no unexplained errors in the system.

The test plan is approved by the Subject Matter Experts (SMEs) and represents the criteria to reach a project closing. If the test cases and scripts in the test plan are the agreed upon acceptance criteria for a project then all that is necessary is for project closure is to demonstrate that all of the testing cases and scripts have been executed successfully with passing results.

A test case is a general-purpose statement that maps to one or more requirements and design points. It is the overall item being tested. It may be a specific usability feature, or a technical feature that was supposed to be implemented as a part of the project.

Test scripts fit into the test cases by validating that case. Test scripts are step-by-step instructions on what to do, what to look for, and what should happen. While the test cases can be created with nearly no input from the architecture or design, the test scripts are specific to how the problem was solved by the software development team and therefore they require an understanding of not only the requirements, but also the architecture, design, and detailed design.

The quality assurance role is split into three parts:

First The role creates test cases and scripts.
Second The role executes or supervises the execution of those test cases and scripts.
Third The role facilitates or performs random testing of all components to ensure that there’s not a random bug haunting the system.

In some organizations, the quality assurance role has two specializations. The first is the classic functional testing and quality assurance as described above. The second, is a performance quality assurance role where the performance of the completed solution is measured and quantified. The performance QA role is an important part of the large system development quality assurance process.

The quality assurance role also has within it a wide range of potential titles and specific responsibilities. From the entry-level quality assurance professional who executes and document tests to the QA lead who works with the FA and SA to create the testing plan, cases, and scripts. The role also extends through QA manager position that may take responsibility for the quality of a solution. At this level the QA manager and solutions architect work as peers to ensure the final solution has the highest quality.

Getting Started as a Quality Assurance Professional

Split evenly with the developer role the standard QA role is an entry role into the software development process. The QA can be entered with a basic understanding of the process, and minimal – if any – prior experience.

The entry spot for the quality assurance role is simply running the testing scripts created by another quality assurance professional. This requires no special skills other than the willingness to step through a process one step at a time and to document the results. Once experienced with running scripts other parts of the software testing process will open up and eventually the opportunity to take on the quality assurance responsibility for a part of the system – or future systems may open up.

The role requires an attention to detail so anything that you can use to demonstrate this attention to detail is helpful. It is also helpful to demonstrate any time where you had to keep meticulous records, whether it was for a science experiment or any other kind of task. Since getting started with QA means taking good notes, penmanship is a plus. If this is a weakness, it’s possible in some cases to take notes electronically; good penmanship is replaced with the need to be effective at taking notes on the computer.

What’s in the Toolbox?

The QA toolbox is filled with things that make validation possible and easier. It includes automated testing tools and the skills necessary to validate applications, database values, and workflows when there is no easy way to validate the correct answer.

The first step is patience. Every test script in every test case must be run by hand. This process is often exhausting but necessary to validate both the software being developed but also the test scripts themselves. Screen capture utilities and screen annotation tools can be very helpful in the process of communicating the errors.

The next step is automated testing tools. These tools allow you to run a test script without the need to be manually banging out keys on a keyboard or clicks of a mouse. These tools come with recording software to allow you to record a set of steps and convert it into a scripting language. The scripting language allows the steps to be customized. By customizing the script from the recorded script it is possible to parameterize the set of steps so that different data can be used. At least one automated testing suite should be in your arsenal if you’re a serious QA professional.

Most automated testing tools also extend themselves into being used to test scalability and performance. These tools help to identify how a system will respond under heavy loads such as large numbers of simultaneous users, large amounts of data, and more.

As mentioned briefly above, the larger and more public the system, the more important performance testing becomes. Because of this, the skills of performance testing and interpreting the results of that testing become more valuable as the system’s importance increases. It is common to have QA analysts in a functional testing role; this is the kind of role that most people think of. QA analysts are also found in a performance-testing role, which is focused around the performance-testing aspects of a software solution.

Where’s the position heading anyway?

Quality in general has taken a beating over the last several years as high profile software failures have made it into the media and because there is a growing awareness that viruses are possible only because of a quality slip in the software that the virus attacks. Despite a growing awareness of software development failures there’s little growth in the QA role. This may be due to a variety of factors including: misunderstanding of what the QA role, the lack of understanding of the value, or simple ignorance of the need for quality assurance.

There’s a general misunderstanding by a great deal of business people and technical managers about what testing is – the primary focus of the QA role. It is believed that testing is something that the developer does. To some extent this is true, most developers do perform testing (although I’ve met a few for whom this skill was completely lacking.) However, whether you believe in the psychological concept of objective introspection – the process whereby you investigate your own thoughts, actions, and feelings – or not, it’s clear that having the same person who developed some a program test it leads to many more errors to be found later on. This is because the developer makes the same mental mistakes in testing as they did during the development. The result is that the defect slips through until much later in the process when it’s more expensive and harder to solve. As a result, even though the developer may run the initial unit tests, it is unwise to rely entirely on the developer for testing – despite this many organizations do. The QA role is designed to validate the developer’s tests but also to ensure that the work of several developers fit in together.

In some software the level of appropriate testing is so low as to make it seem completely unnecessary to have a QA role on the project. For instance, the development of a testing harness – code designed specifically to test other code, is rarely done with any testing what so ever. These is little need to test the harness itself as it will be well tested as it’s used as a tool to test other things. The thinking of many business and technical managers is that testing has value, but the value it has is low enough that less testing than might be appropriate is done. This misperceived position on quality sometimes prevents managers from allocating enough resources to the QA process.

In some cases when planning for the project the QA need is ignored completely. This is due to complete ignorance that this part of the process exists and that it’s a vital part of the software development process necessary to ensure a quality result.

All of these factors play into the future of the role. Luckily more work is being done on educating technical professionals as to the extent of the need for the quality assurance role and how that role fits into the overall needs of software development. Despite its rocky past QA is beginning to be invited as a full member, to the software development dinner table. It’s likely that the demand for quality assurance professionals will continue to rise, slowly but steadily.

Standing Out in the Crowd

Standing out of the crowd can be difficult to do when the expectations of the position are low and the role requires a constant tightrope walk between identifying too many non-conforming software components (a euphemism for a bug ridden software component) and not identifying enough problems with the software being tested. However, as difficult as this may seem it’s certainly possible with the right passion.

One of the best ways to stand out in the QA role is to have other tools in your toolbox that you’re able to use – even if you’re not adept at them. The ability to execute SQL statements to identify whether the data from the user interface is making it to the database or not is, for instance, a powerful way to test user interface code. In general, learning other ways to test is a skill that will prove its value as you become more and more respected in the QA role.

Another potentially important skill that can differentiate you is the ability to read and understand the underlying code that is the application. Whether the application was built with Java or Visual Basic the ability to read the code that makes up the application is valuable in helping to identify the specific spots where problems are occurring. This reduces the amount of time the developer must spend trying to sort through the code and find the problem. Obviously the expectation is not that you write code or that you can read the code as well as the developers, however, the ability to convert the knowledge that you have of what you’re seeing directly into the spot in the code where the problem lies will make you stand out from your peers.

The final skill which can help you stand out of the crowd is problem solving. (Ref: Problem Solving links here.) Being able to run the testing script and identify problems is what is required of the role, however, the role has the opportunity to dig into the problem and find out more about the problem and create a better understanding of the conditions where it does appear – and doesn’t appear. Creative problem solving and the ability to curiously seek out more information about the problem can separate you from the pack.

The Good, the Bad, and the Ugly

Never was it more true that each role is met with good things, bad things, and truly ugly things as it is in the QA role. The role in the right environment is a shining example of how one person, or a few people, can make an impact. However, in the wrong situation it can leave someone bitter, frustrated, and burnt out. Here are just a few of the good, bad, and ugly things about the QA role.

• Good: Quality – The QA professional can take pride in their ability to instill quality in the result of the software development effort. More than any other individual the QA professional can make sure that a quality product is being produced.
• Good: Involvement – Because all aspects of a system have to be assured for quality, the QA role often allows a person to be involved in many phases of a project, including the early ones.

• Bad: Don’t shoot the messenger – One of the challenges is that the QA role is designed to be the bearer of bad news. Because of this it’s easy for others on the software development team to develop a negative attitude towards the QA professional. That means a lot of work on the QA professional part to keep everyone in a positive frame of mind.

• Ugly: Balancing the amount of testing done – The ugly part of the QA role is realizing that there’s only a certain amount of quality that is appropriate for any given program. Some programs, such as those dealing with life or death situations, require substantial testing. However, many of the systems that we operate with today are not life-and-death situations and require only an appropriate level of quality assurance. The ugly part is that no two people will draw the line; on how much quality assurance must be done, in the same place.
• Ugly: Testing generally occurs after other things are done. This means that testing is often close to the deadline of when something is due to be completed. If others are late in completing their tasks, the QA person may have their time squeezed to near nothing.

Conclusion

The quality assurance role is one of the most undervalued and potentially impact roles in the software development process. Despite the public failures of software there is little progress in making the quality assurance role takes it’s rightful position of importance. Cost constraints are forcing organizations of all sizes to release earlier and earlier betas that encourage users to find the quality problems of the software on their own. In order for the software development industry to gain the professional respect it needs the position of the quality assurance role must be elevated.

About the Author

Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert’s more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server – Networking. You can reach Robert at [email protected]