MS Computer Science Virtual University of Pakistan

CS-706 Software Quality Assurance Viva Preparation

CS-706 Software Quality Assurance Viva Preparation

1.What is Quality?

Answer: the standard of something as measured against other things of a similar kind; the degree of excellence of something.
2.What is Software Quality?
Software Quality
• Low levels of defects when deployed, ideally approaching zero
• Low levels of defects when deployed, ideally approaching zero
• A majority of clients with high user-satisfaction when surveyed
• A structure that can minimize ―bad fixes‖ or insertion of new defects during repairs
• Effective customer support when problems do occur
• Rapid repairs for defects, especially for high-severity defects
3.Why Software Quality?
 Reduces time to market for new products
 Enhances market share compared to direct competitors
 Minimizes ―scrap and rework‖ expenses
 Attracts and keeps ―top-gun‖ personnel
 Minimizes the risk of serious litigation
 Minimizes the risk of serious operating failures and delays
 Minimizes the risk of bankruptcy or business failures, which may be attributed directly to poor quality or poor software quality
6. What is a Software Defect?
• A software defect is an error, flaw, mistake, failure, or fault in software that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result)
• Software defects are also known as software errors or software bugs
7. Categories of Software Defects 
Categories of Software Defects
• Errors of commission
• Errors of omission
• Errors of clarity and ambiguity
• Errors of speed or capacity
8. 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
• We‘ll discuss all of them in detail, when we talk about different processes of software development life cycle
9. Software Defect Elimination Strategies?
Effective defect prevention
• High levels of defect removal efficiency
• Accurate defect prediction before the project begins
• Accurate defect tracking during development
• Useful quality measurements
• Ensuring high levels of user-satisfaction
11. Defect Prevention?
o Direct fault detection and removal
o Failure observation and fault removal
16. Data Quality

Answer: Data quality is a perception or an assessment of data’s fitness to serve its purpose in a given context. Aspects of data quality include: Accuracy. Completeness. … Consistency across data sources.
17. Software Requirements

Answer: Software Requirements is a field within software engineering that deals with establishing the needs of stakeholders that are to be solved by software
19. Prevention Vs Removal
For requirements errors, prevention is usually more effective than removal
• Joint application development (JAD), Quality Function Deployment (QFD), and prototyping are more effective in defect prevention
• Requirements inspections and prototyping play an important role defect removal
20. Writing Requirements
Requirements specification should establish an understanding between customers and suppliers about what a system is supposed to do, and provide a basis for validation and verification
• Typically, requirements documents are written in natural languages (like, English, Japanese, French, etc.)
• Natural languages are ambiguous
• Structured languages can be used with the natural languages to specify requirements
These languages cannot completely define requirements
They are not understandable by all stakeholders
21. Design
Design is an activity of creating a solution that satisfies a specific goal or need
• Design is the backbone of all products and services
• Considered an artistic and heuristic activity
22. Software Design
Software design is an artifact that represents a solution, showing its main features and behavior, and is the basis for implementing a program or collection of programs
• Design is a meaningful representation of something that is to be built. It can be traced to a customer‘s requirements and at the same time assessed for quality against a set of pre-defined criteria of ―good‖ design
• Software design is different from other forms of design because it is not constrained by physical objects, structures, or laws
23. Design and Quality
Design is the place where quality is fostered in software engineering
• Design provides us with representation of software which can be assessed for quality
• Design is the only way that we can accurately translate a customer‘s requirements into a finished software product or system
24. Design Process
It is a sequence of steps that enables a designer to describe all aspects of the software to be built
• During the design process, the quality of the evolving design is assessed with a series of formal technical reviews or design walkthroughs
• Needs creative skills, past experience, sense of what makes ―good‖ software, and an overall commitment to quality
25. Cohesion
Cohesion is the qualitative indication of the degree to which a module focuses on just one thing
• In other words, cohesion is a measure of the relative functional strength of a module
• A cohesive module performs one single task or is focused on one thing
• Highly cohesive modules are better, however, mid-range cohesion is acceptable
• Low-end cohesion is very bad
26. Types of Cohesion
Answer: Types of Cohesion
• Coincidental cohesion occurs when unrelated components of a system are bundled together
• Logical cohesion occurs when components performing similar functions are put together (e.g., error handling)
• Temporal cohesion occurs when components that are activated at a single time or time span are put together
• Procedural cohesion occurs when the elements in a component form a single control sequence
• Communicational cohesion occurs when all elements of a component operate on the same input data, produce the same output data, or operate on one area of a data structure
• Sequential cohesion occurs when the output of one element in a component serves an input for another element
• Functional cohesion occurs when each part of a component is necessary for the execution of a single function
• Object cohesion occurs when the functions of a common class of objects are aggregated with the class. In this scheme, interfaces are specified to reveal as little as possible about the inner workings of the object
27. Coupling and Type of Coupling
Answer: Coupling
• Coupling is a qualitative indication of the degree to which a module is connected to other modules and to the outside world
• In other words, coupling is a measure of interconnection among modules in a software structure
Loose coupling is better. Simple connectivity is easier to understand and less prone to ―ripple effect‖
Type of Coupling
• Indirect coupling occurs when one object interacts with another object through a third component, usually a controller. Another form of indirect coupling occurs when using a data-driven style of computation
• Data coupling occurs when a portion of a data structure is passed among modules. When using data coupling, shorter parameter lists are preferred to longer ones
• Stamp coupling occurs when a portion of data structure is passed among modules. When using stamp coupling, a smaller number of actual arguments are preferable to a larger number because the only data that should be passed to a module is what it requires
• Control coupling occurs when information is passed to a module that affects its internal control. This is undesirable because it requires the calling module to know the internal operation of the module being called
• External coupling occurs when a module depends on the external environment
• Common coupling occurs when modules access common areas of global or shared data. This form of coupling can cause one module to unintentionally interfere with the operation of another module
• Content coupling occurs when one module uses information contained in another module
28. Design Methods
Use a design method, which is most suitable for the problem at hand. Don‘t just use the latest or the most popular design method
• There are many structured design and object-oriented design methods to choose from
• Follow the design method‘s representation scheme. It helps in understanding design
29. Coding Defects
All four categories of defects are found in source code
o Errors of commission
o Errors of omission
o Errors of ambiguity and clarity
o Errors of speed and capacity
30. What is a Review?
A process or meeting during which a work product, or a set of work products, is presented to project personnel, managers, users, or other interested parties for comment or approval. Types include code review, design review, forma qualification review, requirements review, test readiness review
o IEEE Std. 610.12-1990
31. Kinds of Reviews?
Business reviews
• Technical reviews
• Management reviews
• Walk-throughs
• Inspections
35. Inspection Steps
Answer: Overview
• Provides the inspection participants a background and understanding, when warranted, of the scheduled inspection material
• Allows time for the inspection participants to sufficiently prepare for the inspection meeting and list potential defects
Inspection meeting
• Identifies defects before work product is passed into the next project stage
• Fixes identified defects and resolves any open issues noted during the inspection
• Verifies that all defects and open issues have been adequately fixed, resolved, and closed out
6. ETVX Representation
The model expressed as a set of
interconnected activities each of which has four sets of attributes

Entry (E)
The Entry section defines the entry criteria that must be satisfied for the process to be initiated, and list the work products that must be available as inputs to the process
Task (T)
The Task section defines work to be carried in performing the process. The order of the task is generally, but not strictly sequential. Some tasks may be concurrent with other tasks
Validation /Verification (V)
The validation/verification section defines steps for validating/verifying that the process has been properly executed, and that the associated work products meet project objectives
Exit (X)
The Exit section defines the exit criteria that must be satisfied for the process to be terminated. The exit criteria usually define completion and verification work products, in terms of qualitative aspects of the products
38. Inspection Process
Inspection Process
• Planning and scheduling
• Overview
• Preparation
• Inspection meeting
• Analysis meeting
• Rework
• Follow-up
• Prevention meeting
• Data recording and reports
• Inspection process monitoring
• We‘ll be using the ETVX model to describe the steps in the inspections process
42. Basics of Software Testing
Testing is one of the most important parts of quality assurance and the most performed QA activity
• Testing has been a basic form of defect removal since software industry began
• For majority of software projects, it is the only form of defect removal utilized
43. Test Planning and Preparation
 Goal Setting
 Test Case Representation
 Test procedure preparation
44. Generic Testing Process
Test planning and preparation
• Test execution and related activities
• Analysis and follow-up
45. Testing Objectives
Answer: Make the software bug free.
47. Characteristics of Testable Software
• Observability
• Controllability
• Decomposability
• Simplicity
• Stability
• Understandability
49. Broad Categories of Testing
General testing
• Specialized testing
• Testing that involves users or clients
50. Testing Techniques
Black-box testing (BBT)
– aka functional/behavioral testing
• White-box testing (WBT)
– aka structural/glass-box testing
51. Black-Box Testing
Black-box testing alludes to tests that are conducted at the software interface
• Although they are designed to uncover errors, they are also used to demonstrate that software functions are operational, that input is properly accepted and output is correctly produced, and that the integrity of external information is maintained
• A block-box test examines some fundamental aspect of a system with little regard for the internal logical structure of the software
52. White-Box Testing
White-box testing of software is predicated on close examination of procedural detail
• Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and/or loops
• The ―status of the programs‖ may be examined at various points to determine if the expected/asserted status corresponds to the actual status
53. Cyclomatic Complexity

Answer: Cyclomatic Complexity is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code.
58. Testing Strategy
Testing Strategy
• Unit testing
• Integration testing
• Validation testing
• System testing
59. The “V” Model of Software Testing

Answer: V Model or Verification and Validation Model. Every testing execution should follow some sequence and V Model is the perfect way to perform the testing approaches. In V Model there are some steps or sequences specified which should be followed during performing test approach. Once one step completes we should move to the next step. Test execution sequences are followed in V shape.
60. System Integration

Answer: systems integration is the process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole.
61. Validation Testing
After software has been integrated, a set of high-order tests are conducted
• Validation criteria (established during requirements analysis) must be tested
• Validation testing provides final assurance that software meets all functional, behavioral, and performance requirements
• BBT techniques are used exclusively here
62. Specialized Testing
Specialized Testing
• Recovery testing
• Security testing
• Stress testing
– Sensitivity testing
• Performance testing
64. Debugging
Debugging occurs as a consequence of successful testing
• That is, when a test case uncovers an error
• Debugging is the process that results in the removal of the error