1. Software Quality Assurance
Lecture 01

2. Quality
It is very easy to define quality, but if you think really hard, it is not that easy to define quality
“The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.”
“The degree to which a system, component, or process meets specified requirements.”
“The degree to which a system, component or process meets customer or user needs or expectations.”

3. Synonyms of Quality Excellence  Superiority  Class  Eminence
 Value
 Worth

4. Software Quality
Software quality is a field of study and practice that describes the desirable attributes of software products.

5. Why Software Quality?
to make sure that the final product built is as per the requirement specification and comply with the standards.

6. Customer Satisfaction
A quality product satisfies the customer.
A satisfied customer comes back for more and provides positive referrals.
And, let’s not forget that with the explosion of social media channels such as Twitter and Face book, positive referrals can spread quickly.
Of course that means poor quality and dissatisfaction can also be communicated quickly, if not even quicker than the good ones.

7. So the term software quality assurance would mean that the software guarantees high quality

8. What is a Software Defect
“A defect is an error or a bug, in the application which is created. A programmer while designing and building the software can make mistakes or error. These mistakes or errors mean that there are flaws in the software.”
“When actual result deviates from the expected result while testing a software application or product then it results into a defect. Hence, any deviation from the specification mentioned in the product functional specification document is a defect. In different organizations it’s called differently like bug, issue, incidents or problem.”

9. “When the result of the software application or product does not meet with the end user expectations or the software requirements then it results into a Bug or Defect. These defects or bugs occur because of an error in logic or in coding which results into the failure or unpredicted or unanticipated results.”

10. Information about Defects / Bugs:
While testing a software application or product if large number of defects are found then it’s called Buggy.
When a tester finds a bug or defect it’s required to convey the same to the developers.
Thus they report bugs with the detail steps and are called as Bug Reports, issue report, problem report, etc.

11. This Defect report or Bug report consists of the following information:
 Defect ID – Every bug or defect has it’s unique identification number  Defect Description – This includes the abstract of the issue.  Product Version – This includes the product version of the application in which the defect is found.  Detail Steps – This includes the detailed steps of the issue with the screenshots attached so that developers can recreate it.  Date Raised – This includes the Date when the bug is reported

12. Reported By – This includes the details of the tester who reported the bug like Name and ID  Status – This field includes the Status of the defect like New, Assigned, Open, Retest, Verification, Closed, Failed, Deferred, etc.  Fixed by – This field includes the details of the developer who fixed it like Name and ID  Date Closed – This includes the Date when the bug is closed  Severity – Based on the severity (Critical, Major or Minor) it tells us about impact of the defect or bug in the software application  Priority – Based on the Priority set (High/Medium/Low) the order of fixing the defect can be made.

13. Effects of Software Defects
Bugs can have a wide variety of effects, with varying levels of inconvenience to the user of the software.
Some bugs have only a subtle effect on the program’s functionality, and may thus lie undetected for a long time.
More serious bugs may cause the software to crash or freeze.
 Others qualify as security bugs and might for example enable a malicious user to bypass access controls in order to obtain unauthorized privileges
 The results of bugs may be extremely serious
 In 1996, the European Space Agency’s US $1 billion prototype Arian 5 rocket was destroyed less than a minute after launch, due a bug in the on-board guidance computer program

14. In June 1994, a Royal Air Force Chinook crashed into the Mull of Kintyre, killing 29 people. An investigation uncovered sufficient evidence to convince that it may have been caused by a software bug in the aircraft’s engine control computer
 In 2002, a study commissioned by the US Department of Commerce’ National Institute of Standards and Technology concluded that software bugs are so dominant and detrimental that they cost the US economy and estimated US $59 billion annually, or about 0.6 percent of the gross domestic product.

15. Categories of Software Defects
Four general categories of software defects tend to be significant in product liability : –
Errors of commission (something is done that is wrong) –
Errors of omission (something was left out by accident)
– Errors of clarity and ambiguity, (two people reach different interpretations of what is meant)
– Errors of speed or capacity (the application works, but not fast enough)

16. Software Defect Origins
Errors in Requirements
 Errors in Design
 Errors in Source code
 Errors in User Documentation
 Errors due to “Bad fixes”
 Errors in Data and Tables
 Errors in Test Cases

17. Error in Requirements
All four categories of defect are found in requirements
• The two most common problems are errors of omission and errors of clarity and ambiguity.
• If requirements errors are not prevented or removed, they flow downstream into design, code, and user manuals.
• Errors which originate in requirements tend to be the most expensive and troublesome to eliminate later.

18. Formal requirements methods:
Requirements based on natural language will always be troublesome.
• Several formal requirements methods have been developed (but are not widely used)
• DE Marco's structured English
• IBM's HIPO diagrams (Hierarchy plus Input, Processing, Output),
• the Problems Statement Language (M),
• WarnierOrr Diagrams,
• the Structured Analysis and Design (SADT) technique

19. Error in Design:
Design ranks next to requirements as a source of very troublesome, and very expensive errors.
• All four categories of defects are found in software design and specifications, as might be expected.
• The most common forms of design defects are errors of omission where things are left out, and of commission, where something is stated that later turns out to be wrong.
• Errors of clarity and ambiguity are also common, and many performance related problems originate in the design process as well.

20. Errors in Code:
All four categories of defects can be found in source code, with errors of commission being dominant while code is under development.

21. Perhaps the most surprising aspect of coding defects when they are studied carefully is that more than 50% of the serious bugs or errors found in the source code did not truly originate in the source code.
• A majority of so-called programming errors are really due to the programmer not understanding the design, or the design not correctly interpreting a requirement.
• This is not a surprising situation.
Software is one of the most difficult products to visualize prior to having to build it.

22. • Built-in syntax checkers and editors associated with modern programming languages can find many "true" programming errors (such as missed parentheses or looping problems)
• Even poor structure and excessive branching can now be measured and corrected automatically.
• The kinds of errors that are not easily found are deeper problems in algorithms or those associated with misinterpretation of design.

23. Errors in Documentation:
User documentation in the form of both manuals and online information can contain errors of omission and errors of commission
• The most common kind of problem is that of errors of clarity and ambiguity.

24. Errors in Data:
The topic of data quality and data defects is usually outside the domain of software quality assurance
• Since one of the most common business uses of computers is specifically to hold databases, repositories, and data warehouses the topic of data quality is becoming a major issue.
• Data errors can be very serious and they also interact with software errors to create many expensive and troublesome problems.

25. Many of the most frustrating problems that human beings note with computerized applications can be traced back to data problems.
• Errors in utility bills, financial statements, tax errors, motor vehicle registrations, and a host of others are often data errors.

26. Defect Discovery:
Defects are discovered by developers & testers (usually) before release
• Defects are discovered by customers and users (usually) after release
• Defects discovered after release can be embarrassing for the development team

27. Defect Discovery by Customers:
Rule 1: Defect discovery is directly related to the number of users
• Rule 2: Defect discovery is inversely related to the number of defects

28. Inspections
Inspections are critical examinations of software objects by human inspectors aimed at discovering and fixing faults in the software systems
• Inspections are critical reading and analysis of software code or other software artifacts, such as designs, product specifications, test plans, etc
• Inspections are typically conducted by multiple human inspectors, through some coordination process. Multiple inspection phases or sessions may be used
• Faults are detected directly in inspection by human inspectors, either during their individual inspections or various types of group sessions
• Identified faults need to be removed as a result of the inspection process, and their removal also needs to be verified

29. Defect Removal Efficiency:
The defect removal efficiency (DRE) gives a measure of the development team ability to remove defects prior to release.
It is calculated as a ratio of defects resolved to total number of defects found.
It is typically measured prior and at the moment of release.

30. Calculation
DRE = Number of defects resolved by the development team / total number of defects at the moment of measurement.

31. Example
For example, suppose that 100 defects were found during QA/testing stage and 84 defects were resolved by the development team at the moment of measurement. The DRE would be calculated as 84 divided by 100 = 84%