Skill Category 7. Quality Control Practices

Transcription

1 Skill Category 7 Quality Control Practices Testing Concepts Developing Testing Methodologies Verification and Validation Methods Software Change Control Defect Management Process Management Processes CSQA - 1

2 Quality Control Basics Quality control measures a product against the existence of an attribute Determines whether the product conforms to a standard or procedure (also known as compliance checking). Management is responsible for enforcing compliance to standards and procedures. CSQA - 2

3 Process Workbench and Components Graphical Representation of a Process Rework No Input(s) DO Procedures Check Procedures Yes Deliverable(s) Tools(s) Standard(s) Policy CSQA - 3

4 Test Stages Unit testing Integration testing System testing User acceptance testing CSQA - 4

5 Independent Testing Independent test team responsibilities: System testing Oversight of user acceptance testing Provide an unbiased assessment of the quality of an application Support or participate in other phases of testing including executing special test types such as performance and load testing CSQA - 5

6 Independent Testing Independent test manager responsibilities: Planning and estimating tests Designing the test strategy Ensuring tests are created and executed in a timely and productive manner Reviewing analysis and design artifacts Chairing the test readiness review Managing the test effort Overseeing acceptance tests CSQA - 6

7 Independent Testing Independent tester responsibilities: Developing test cases and procedures Planning, capturing, and conditioning test data Reviewing analysis and design artifacts Executing tests Utilizing automated test tools for regression testing Preparing test documentation Tracking and reporting defects CSQA - 7

8 Static vs. Dynamic Testing Static Testing: Testing performed without executing code Dynamic Testing: Testing is being executed on the machine CSQA - 8

9 The V Testing Concept Denotes Continuous Testing During the Development Process: At pre-determined points Using static and/or dynamic test techniques CSQA - 9

10 The V Testing Concept Operational or Business Need Verify Operational or Business Need Acceptance Test Validate Operational or Business Need Define Requirements System Test Verify Requirements Validate Requirements Static Design System Verify Design Integration Test Validate Design Dynamic Build System Unit Test Verify Construction Validate Construction CSQA - 10

11 Test Objectives A statement of what the test team or tester is expected to accomplish during a specific testing activity Are usually defined during requirements analysis, and guide the development of test cases, test scripts, and test data Enhance communication by defining the scope of the testing effort, and provide a way to gauge testing progress and success CSQA - 11

12 Reviews and Inspections Are Performed To: Maximize team talent Identify defects. Educate a large number of people quickly Rules Review the product not the producer Identify defects and issue, don t resolve them Every member is responsible for success CSQA - 12

13 Review Formats Informal Techniques Little/no preparation No formal documentation Little measurement Semi-Formal Techniques Author presents material Wide range of discussion Metrics should be captured Formal Techniques Formal process with well-defined roles Moderator leads review Checklists and formal documentation Metrics captured CSQA - 13

14 Types of Reviews In process Review Checkpoint Review Phase-end Review Software requirements Review Critical Design Review Test Readiness Review Post-implementation Review Inspections CSQA - 14

15 Testing Methodology What type of project? Who will conduct testing? When will testing occur? What type of software? What are the tradeoffs? What is project s scope? What are the Critical Success Factors? CSQA - 15

16 What Type of Project? Traditional Development System (Waterfall) Client/Server Interactive Development/ Prototyping/CASE Object-Oriented System Maintenance / Legacy Systems Purchased / Contracted Software CSQA - 16

17 Management of Verification and Validation Management of software development verification and validation activities: Begins at the start of a project Performed for all SDLC processes and activities. CSQA - 17

18 Reviews and Inspections Are Performed To: Maximize team talent Identify defects Educate a large number of people quickly Review Formats Informal (peer review and desk checks) Semi formal (JAD joint application development) Formal (Inspection) CSQA - 18

19 Verification Techniques Types of Reviews Feasibility reviews Requirements reviews Design reviews Code walkthroughs Code Inspections Requirements tracing CSQA - 19

20 Validation Techniques White Box Testing Structural testing based on knowledge of internal code structure and usually logic driven Statement coverage Decision Coverage Condition Coverage Decision/Condition Coverage CSQA - 20

21 Validation Techniques Black Box Testing Functional testing based on external specifications without knowledge of how the system is constructed - usually data or business process driven Validates that each input produces the appropriate output Equivalence partitioning Boundary analysis Exploratory Testing (Error Guessing) CSQA - 21

22 Structural and Functional Testing Structural Testing Advantages The logic of the software s structure can be tested Parts of the software will be tested which might have been forgotten if only functional testing was performed Disadvantages Its tests do not ensure that user requirements have been met Its tests may not mimic real-world situations CSQA - 22

23 Structural and Functional Testing Functional Testing Advantages Simulates actual system usage Makes no system structure assumptions Disadvantages Potential of missing logical errors in software Possibility of redundant testing CSQA - 23

24 Software Configuration Management Constant program changes Well-formulated and well-documented procedures Program manipulation prevention No unauthorized use. Primary objective of SCM: Get the right changes installed at the right time CSQA - 24

25 Change Control Procedures All proposed changes should be in writing Major changes should be approved by the Configuration Control Board Developers should make and document the program changes, not the operations group Someone independent of the person who designed and made the change should be responsible for testing the final revised program The documentation system should be updated with all change sheets or change registers and printouts CSQA - 25

26 Defect Management Process The primary goal is to prevent defects The process should be risk driven. Defect measurement should be integrated into the development process. The capture and analysis of the information should be automated. Defect information should be used for process improvement. CSQA - 26

27 Defect Reporting Ensure the defect is corrected Report status of the application Gather statistics used to develop defect expectations in future applications Improve the software development process. CSQA - 27

28 Defect Management Requires a communication mechanism, either manual or automated Facilitates communication between test and development teams What to report? Defect name and type Severity and priority Status Date and time of detection Location identified (e.g. component, GUI, etc.) Detailed description Component or program where defect was found Screen prints, etc. Stage of origination (may be added later) Person assigned to correct Correction effort in hours CSQA - 28

29 Severity vs. Priority Based on pre-defined severity descriptions, the test team should assign the severity of a defect objectively. In large projects, it may be necessary to assign a priority to the defect which determines the order in which defects should be fixed. CSQA - 29

30 A Sample Defect Tracking Process Execute the tests Log any discrepancies Determine if the discrepancy is a defect Assign the defect to a developer Resolve the defect CSQA - 30

31 Using Defects for Process Improvement Go back to the process that originated the defect to understand the root cause Go back to the verification and validation processes which should have caught the defect earlier CSQA - 31

32 Sample Questions Which of the following is NOT a verification technique: a. Feasibility Review b. Design Review c. Requirements Review d. Code Inspection e. Unit Test Which of the following is NOT a structural technique: a. Executing all statements at least once b. Executing each decision with all possible outcomes at least once c. Executing test cases based on classes of data d. Executing each decision direction at least once CSQA - 32

33 Sample Questions Which of the following is NOT a verification technique: a. Feasibility Review b. Design Review c. Requirements Review d. Code Inspection e. Unit Test Which of the following is NOT a structural technique: a. Executing all statements at least once b. Executing each decision with all possible outcomes at least once c. Executing test cases based on classes of data d. Executing each decision direction at least once CSQA - 33

34 Sample Questions As a test manager for a large IT department, you ve been asked what information should be recorded about each defect that is uncovered. Identify and briefly describe what you believe are the four most important characteristics that should be recorded about a defect. CSQA - 34