This two-day course is essential for those who want to understand the role of software testing as a technique for improving software quality.
The course starts with a discussion of key quality concepts and how they relate to software quality. During this discussion, the inherent limitations of software testing are identified and a number of alternative quality improvement techniques are described.
The course then moves on to introduce the 'software testing canvas' and describe how it can be used as a tool for understanding standard test levels and as a framework for developing a custom software testing strategy. The importance of adopting a risk-based approach to testing is emphasised.
Participants then learn how to design design functional (black-box) and structural (white-box) test cases, applying a variety of techniques with an emphasise on 'negative testsing'.
The theory presented during the course is enhanced by lively class discussions and practical exercises that provide an opportunity for participants to apply what they have learnt.
- Describes the role of software testing as a quality improvement technique by presenting six fundamental reasons for testing software that are based on a widely recognised definition of quality
- Incorporates the ISTQB's 'principles of software testing' with a practical explanation of what each principles means and how to apply it to real projects
- Provides an introduction to risk based testing that emphasises the importance of incorporating a risk based approach in testing strategies
- Incorporates two unique learning learning frameworks: the 'quality triangle' which is used to explain the underlying reasons for poor software quality and how poor quality can be rectified; and the 'software testing canvas' which is used to explain the different 'levels' of testing and for developing customised testing strategies
- Suitable for both experienced testers wanting to improve their testing skills as well as those moving into a software testing role for the first time
- Awareness of the limitations of software testing and understanding of when alternative quality improvement techniques should be used
- Ability to develop a custom software strategy using the 'software testing canvas' and design functional (black-box) and structural (white-box) test cases applying a variety of techniques
- Understanding of the need to incorporate exploratory testing into a test strategy to compliment scripted and automated testing
- Practical strategies for reporting test progress and increased confidence interacting with management
Who Should Attend
- Those who want to improve their software testing skills such as Test Engineers, Tester Analysts, Quality Assurance Staff, Agile Teams, Software Engineers, Software Developers, Business Analysts, Business Systems Analysts, Systems Analysts, Functional Analysts
- Those who need to plan and manage the software testing effort such as Test Managers, Quality Assurance Staff, Project Managers, Program Managers Product Owners, Product Managers, Scrum Masters
- Those who who want to gain an understanding of software testing as a quality improvement technique such as Test Managers, Project Managers, Program Managers Software Engineers, User Representatives, Product Owners, Product Managers, Scrum Masters, Requirements Engineers, Requirements Analysts, Human Factors Specialists, Software Developers, Process Engineers, Software Engineers, Process Group (SEPG) Staff, Methodologists, Process Improvement Staff
- 2 days full-time.
- Five Popular Assumptions About Software Quality
- Software Quality is a Measure of 'Excellence'
- The Five Views of Quality
- Software Defects
- Defects in New Software
- Defects in Modified Software
- Configuration Defects
- Verification and Validation
- Gaps Between the Views of Quality
- The Reason For Gaps
- Closing the Gaps
- Some Typical Problems With Software Quality
- Software Quality is Difficult to Measure
- Software Quality is Expensive
- Is Software Quality Expensive?
- The True Cost of Quality
- Quality Can Be Tested Into Software
- Software Quality Depends on Developer Skills
Introduction to Software Testing
- What Software Testing Is Not!
- The Principles of Software Testing
- Principle 1 - Testing shows presence of defects
- Principle 2 - Exhaustive testing is impossible
- Principle 3 - Early testing is desirable
- Principle 4 - Defects tend to cluster
- Principle 5 - Pesticide paradox - bugs become immune
- Principle 6 - Testing is context dependent
- Principle 7 - Absence of errors fallacy
- Applying Principle 1 - Testing Shows Presence of Defects
- Comparing Test to Pass and Test to Fail (Negative Testing)
- Applying Principle 7 - Absence of Errors Fallacy
- The Objectives of Software Testing
Software Testing Limitations
- Applying Principle 3 - Early Testing is Desirable
- The Limitations of Software Testing
- Late Discovery of Errors Triggers Rework
- Quality Improvement Throughout the Development Life Cycle
- Requirements Validation
- Static Source Code Analysis
- Configuration Management
- Defect Prevention
- Agile Software Development
Software Testing Strategies
- Applying Principle 6 - Testing is Context Dependent
- Defining Test Levels
- Component/unit testing
- Integration testsing
- System testing
- Acceptance testing
- Do Test Levels Provide a Good Contextual a Test Strategy?
- A Better Approach to Testing Context
- Why Perform the Test (Test Objective)?
- What to Test (Test Target)?
- What Is Needed to perform the Test (Environment)?
- How To Design the Test Cases (Test Basis)?
- How To Execute the Test?
- Who (or What) Will Perform the Test (Agent)?
- When Does the test Need to Be Performed (Schedule)?
- Where Will the Test Be Performed (Facilities)?
- Test Target
- Software Components
- Component Integration
- Software Features
- Feature Testing Requires Confidence in Component Integration
- Test Basis
- Definition of a Test Basis
- Testing is Not 'Black' and 'White'
- Designing Test Cases from a Test Basis
- Test Case Objective
- Executing Tests
- Configuring the System Under Test
- Stand Alone Component
- Stand Alone Feature
- End to End Components
- End to End Features
- An Incremental Approach to Building Confidence in Software
- Connecting to the System Under Test
- Program Code
- User Interface
- Test Agents
- Human Agents
- Test Automation
- Some Typical Strategies for Software Testing
- Unit Testing
- Systems Integration Testing
- User Acceptance Testing
- Regression Testing
- Developing a Custom Strategy
- Exploratory Testing
- Applying Principle 5 - Pesticide Paradox (Bugs Become Immune)
- What is Exploratory Testing
- Exploratory Testing Skills
- Exploratory Testing and Heuristics (Cheat Sheets)
- Comparing Exploratory, Scripted and Automated Testing
- Exploratory Testing Tools and Test Automation
- Strategies for Measuring Non-Functional Attributes of Software
Software Testing and Risk
- Applying Principle 2 - Exhaustive Testing is Impossible
- There Will Always Be a Risk That Software Contains Errors
- Software Testing Should
- Reduce the Risk of Failures
- Focus on Areas of High Risk
- What is Risk?
- The Possibility of Loss or Misfortune
- How Likely?
- How Bad?
- Applying Principle 4 - Defects Tend to Cluster
- In Components
- On Boundaries
- The risk paradox
- Finding bugs reduces the overall risk of failures
- Finding bugs in a component increases the risk of more failures in that component
Designing Test Cases
- Definition of a Test Case
- Test Cases
- Test Data
- Test Procedures
- Test Procedures
- Test Case Coverage
- Test Case Design Technique
- Functional, Specification Based, Black Box
- Structural, Code Based, White Box
Functional Test Case Design
- Equivalence Partitioning
- Identifying Boundaries
- Testing Between Boundaries (Partitions)
- Continuous and Discrete Values
- Partitions and Risk
- Coverage of Partitions
- Field Length Partitions
- Boundary Value Analysis
- Testing On Boundaries
- Testing Either Side of the Boundary
- Rounding and Precision
- Coverage of Boundaries
- State Transition Testing
- State Transitions Diagrams
- State Tables
- Valid Transitions - Test to Pass
- Invalid Transitions - Test to Fail
- Coverage of States and Transitions
- State Transition Testing as Requirements Verification Technique
Structural Test Case Design
- Statement Testing
- Counting Program Statements
- Measuring Statement Coverage
- Statement Coverage and Defensive Programming
- Branch/Decision Testing
- Modelling Decisions With Control Flow Graphs
- Coverage of Branches and Decisions
- Branch/Condition Testing
- Modelling Conditions With Control Flow Graphs
- Coverages of Branches and Conditions