Anatomy of a Software Development Role: Quality Assurance, Page 2
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.
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 Robert.Bogue@CroweChizek.com