Software Quality Assurance and not only 

The roles of QA Analysts

• Find defects
• This is the classic objective of testing. A test is running in order to trigger failures that expose defects.
• Generally, we look for defects in all interesting parts of the product
  

• Maximize bug count
• The distinction between this and “find defects” is that total number of bugs is more important than coverage.
• We might focus on only a few high risk features, if this is the way to find the most bugs in the available time.
  

• Block premature product releases
• This analyst stops premature shipment by finding bugs so serious that no one would ship the product until they are fixed.
• For every release decision meeting, the tester’s goal is to have new show stopper bugs.
  

• Help managers make ship / no-ship decisions
• Managers are typically concerned with risk in the field.
• They want to know about coverage, and how important the known problems are.
• Problems that appear significant on paper but will not lead to customer dissatisfaction are probably not relevant to the ship decision.
  

• Minimize technical support costs
• Working in conjunction with a technical support or help desk group, the test team identifies the issues that lead to calls for support.
• These are often peripherally related to the product under test
• For example, getting the product to work with a specific printer or to import data successfully from a third party database might prevent more calls than a data-corrupting crash.
  

• Assess conformance to specification
• Any claim made in the specification is checked.
• Program characteristics not addressed in the specification are not checked (as part of this objective).
  

• Conform to regulations
• If a regulation specifies a certain type of coverage, the test group creates the appropriate tests.
• If the regulation specifies a style for the specifications or other documentation, the test group should check the style.
• In general, the test group is focusing on anything covered by regulation and (in the context of this objective) nothing that is not covered by regulation.
  

• Minimize safety-related lawsuit risk
• Any error that could lead to an accident or injury is of primary interest.
• Errors that lead to loss of time or data or corrupt data, but that don’t carry a risk of injury or damage to physical things will be out of scope.
  

• Find safe scenarios for use of the product (find ways to get it to work, in spite of the bugs)
• Sometimes, all that you’re looking for is one way to do a task that will consistently work.
• To do one set of instructions that someone else can follow, which will reliably deliver the benefit they are supposed to lead to.
• In this case, the tester is not looking for bugs. He is trying out, empirically refining and documenting, a way to do a task.
  

• Assess quality
• This is a tricky objective because quality is multi-dimensional.
• The nature of quality depends on the nature of the product.
• For example, a computer game that is rock solid but not entertaining is a lousy game.
• To assess quality – to measure and report back on the level of quality
• We probably need a clear definition of the most important quality criteria for a product, and then we need a theory that relates test results to the definition.
• For example, reliability is not just about the number of bugs in the product.
• It is often defined as being about the number of reliability-related failures that can be expected in a period of time or a period of use.
• Reliability-related – In measuring reliability, an organization might not care, for example, about misspellings in error messages.
• To make this prediction, you need a mathematically and empirically sound model that links test results to reliability.
• Testing involves gathering the data needed by the model.
• This might involve extensive work in areas of the product believed to be stable as well as some work in weaker areas.
• Imagine a reliability model based on counting bugs found (perhaps weighted by some type of severity) per N lines of code or per K hours of testing.
• Finding the bugs is important.
• Eliminating duplicates is important.
  

• Verify correctness of the product
• It is impossible to do this by testing.
• You can prove that the product is not correct or you can demonstrate that you didn’t find any errors in a given period of time using a given testing strategy.
• However, you can’t test exhaustively, and the product might fail under conditions that you did not test.
  

Introduction to Software Testing

•     Software Quality Assurance
• It involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.
  

•     Software testing
• It is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test.
  

•     Software defect (BUG)
• Is an error, mistake, failure, or fault in a software that prevents it from behaving as intended
  

•     Defect tracking
• It means logging and maintaining bugs through a dedicated tool
  

•     Test Case
• A specific test to be performed, including the specific steps necessary for completing the test. Test cases typically describe actions or steps and the expected results of the action or step.
  

•     Use Case
• An implementation-neutral description of a reasonable action or task that an end user might want to accomplish. For example, a user might want to browse a site, but not necessarily view a site map. The action is general, and the use case is a tool for evaluating whether the general action can be accomplished in the particular instance of the site.
  

•     Review
• A process or meeting during which a work product or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review.
  

•     Risk
• A measure of the probability and severity of undesired effects.
  

•     Test Documentation
• Documentation describing plans for, or results of, the testing of a system or component, Types include test case specification, test incident report, test log, test plan, test procedure, test report.

•     Audit
• To conduct an independent review and examination of system records and activities in order to test the adequacy and effectiveness of data security and data integrity procedures, to ensure compliance with established policy and operational procedures, and to recommend any necessary changes.