Software Testing Lecture Series
Quality Assurance Overview
Return to:
Aunty Violet's Advice for the PC Impaired Home Page
Copyright © 1998 – 2000 Violet Weed, Inc. – Microsoft / Novell / Oracle / Sun Certified
Software Testing Lecture Series
It's my opinion that the Quality Assurance team should be involved in any software development project from "day one". Yes, at that first meeting where Management discusses, discards, shelves for a future date, or begins the tedious but necessary process of bringing a half-visualized concept to fruition as a user-friendly, hopefully ubiquitous software application, sitting at the meeting table between the Project Manager and the Sr. Developer should be a QA representative, generally the Sr. QA Analyst assigned to the project. Why? For several reasons. First of all, if the QA team is an active participant from the very beginning, then the Development team is more likely to accept them as partners in the overall development process, rather than perceive them as 'wannabee programmers' whose only role in life is to criticize the developers' work. Furthermore, the earlier the QA team is involved in the life-cycle process, the better they are able to understand the end-user requirements for the application under development. This understanding will help them build the best test lab possible as well as to develop thorough test plans and test cases. Moreover, it's important for the QA team to understand exactly what they are expected to test and, other than obvious crashes or data errors, what test results should be written up as defects. Oh? You say this information should be contained in the Detailed Design Document (DDD) and User Requirements Documents? Yes, surely you are correct! However, due to the fast pace of the world today and how quickly software must be created in order for a company to stay competitive, many software development projects are already halfway through coding before the Detailed Design document is even begun, and while the user requirements document is still in rough draft format. What does the Test Team use as reference materials for creating test cases and scenarios if there is no design document? Generally, they use the Test Plans that were created by the Quality Analyst assigned to the project. If the Analyst has based the test plans only on information contained in User Requirements documents or use cases, the likelihood is great that the Test Plans are incomplete or at least somewhat inaccurate. Before an effective set of Test Plans can be produced, it is necessary to understand exactly what needs to be tested, and why. You can't get that kind of knowledge just from reading documentation, you have to participate in the requirements gathering process itself. You need to hear the wants, needs and 'wish lists' of everyone involved: developers, managers, end-users as well as the guy/gal who is gonna fund this entire process. Obviously, this knowledge transfer begins at the very first development discussions and continues throughout the development life-cycle. So what exactly is the role of a Quality Assurance person? Quality Assurance for Software doesn't just mean finding the defects in the user interfaces or reports produced during the test phase. The role of "tester" is really a junior role within the Quality Assurance domain. Senior QA folks should be helping developers ensure that the number of defects decreases with each release of the application, by assuring continual improvement of the application's quality. They are also responsible for designing the review procedures, maintaining standards and even teaching the team 'new and improved' ways to design and develop applications. The role of Quality Assurance is more than just testing a application to ensure it matches 'specs'. QA also contributes to the design of the end application by pointing out functionality or performance issues that perhaps 'match specs', but do not give the end-users what they need or which will be too costly to provide in the end application, as they are now specified. Furthermore, Quality Assurance is typically involved in code reviews, hardware inspections – anything that affects or measures the application's quality as well as ensuring that the development process itself conforms to the software standards expected throughout their organization, not just for that particular development team. Of course, there are different levels of skillsets and job descriptions within the Quality Assurance domain. There are end-users who are very good at manual testing, if they are given a set of scripts or scenarios to follow and who are usually good at 'ad hoc' testing too. These folks are called 'subject-matter experts (SMEs) because they thoroughly understand the processes which are being computerized, and they have a definite testing role during User Acceptance Testing (UAT). The QA Manager should make sure that SMEs know how important a role they play, by inviting them to QA Team meetings and including them in any training classes for QA members. Bill Hetzel [author of "The Complete Guide to Software Testing" ISBN 0-89435-242-3] says that "requirements reviews, design reviews, and code reviews [are] tests". I agree with this idea and will go further to suggest that senior QA team members should not only have solid Business Analyst skills but should also be involved in requirements and design reviews. SQA Engineers performing 'whitebox' tests should also have a fundamental proficiency in the programming language(s) used for the application development. A good SQA Engineer is someone who, in other circumstances, might be described as having 'a stubborn streak to his/her personality'. After all, it's the role of the SQA Engineer to prove that the Application Under Test (AUT) is no good, is buggy, can be broken. The Tester shouldn't let anyone interfere in the test process – not the developers and not even the Project Manager who can't believe five new bugs have been added to the bug list and the application is due to be released day after tomorrow. (Having said that, however, it is usually senior management (CEO, Chairman, etc.) who dictate when the application is ready for release – they can override QA's 'veto' power for 'showstopper' defects.) When an SQA Engineers are testing software, they should be looking as hard as possible to find errors of all kinds. If instead they are spending time admiring the the developers' work, they will always miss defects in that same work. It's a well-known fact that you see what you expect to see. Don't believe me? Take a careful look at the second sentence in this paragraph. Do you see that "the" is repeated twice in a row? Did you catch that deliberate error the first time you read the sentence? Probably not, because your mind wasn't looking for typo's, it was trying to get the message in the sentence so it automatically overlooked the repeated word. However, a good proofreader would have been looking for repeated words, and would have caught, and flagged, the error. Good testers are looking for errors too. It's not their job to prove the application works; it's their job to prove it doesn't work! When a project is overdue and management is encouraging QA to 'stop finding so many bugs' — that's when a stubborn streak will come in handy. If you can't stand your ground and continue doing the job you were hired to do (find bugs), then you have no business being in Software Quality Assurance. A Development Manager once accused me of being a 'nitpicker' because I entered a 'showstopper' bug for a billing report whose bottom line was $16,000.00 out of balance. He said, "A $16,000.00 difference in a $1,100,000.00 return isn't that big a deal." No? If that were so, then why did they prosecute the clerk who'd made this same discovery in the previous release — and funnelled the 16 grand to her own private account? (The embezzlement happened before I came on board as QA Manager, of course.) I stood my ground with the Development Manager and the application went back to development where the problem was finally solved several weeks later. If I had caved to pressure, that company would have lost almost $256,000.00 to date, by my count, since this project was completed several years ago. A good SQA person has an overwe'ening desire to prove the application is a failure and his or her test cases should reflect that attitude. To reiterate, a strong backbone and a desire to break things are very highly desirable qualities for anyone who wants to make a secure career out of Software Quality Assurance. If you have a 'need to please', SQA isn't a good career choice. After all, would you buy or drive a car if you knew the brakes had been tested by someone who expected them to pass? I don't think so. You want a brake tester to be someone who will do everything she can think of and then some! to make the brakes fail. Then and only then will she grudgingly put a "seal of approval" on the brake pads. That's exactly the kind of attitude a good SQA Engineer should have. "The Bug Stops Here!" should be your rallying cry(but not your motto, 'cause that's Aunty's motto).
Quality Assurance Overview
Return to:
Aunty Violet's Advice for the PC Impaired Home Page
Copyright © 1998 – 2000 Violet Weed, Inc. – Microsoft / Novell / Oracle / Sun Certified