Tutorials: Series H
Thursday, October 11th, 2001

Six concurrent tutorials taught by nationally recognized quality experts. Each tutorial is a one full day of an in-depth instruction in a specific software quality topic.

You must specify which tutorial you wish to attend (H1 through H6)

Tutorials marked with (CSTP) count towards the Certified Software Test Professional and cover the Body of Knowledge areas as indicated.

   Series M - Monday, October 8, 2001

   Series T - Tuesday, October 9, 2001

   Series W - Wednesday, October 10, 2001

   Series F - Friday, October 12, 2001   

Tutorial #H1 (Thursday 8:30 - 4:30 p.m.)

H1: User Acceptance Testing (Intermediate)(CSTP, Elective)

Robin F. Goldsmith JD

 ROLE OF USER ACCEPTANCE TESTING

        Why users may resist involvement

        Making users confident about testing

        Objectives, types, and scope of testing

        Acceptance testing as user’s self-defense

        Why technical tests don’t catch all the errors

        Essential elements of effective testing

        CAT-Scan ApproachÔ to find more errors

        Proactive TestingÔ Life Cycle model

        Separate technical and acceptance test paths

        Place of UAT in overall test structure

        Making sure important tests are done first

        Developer/tester/user test responsibilities

 DEFINING ACCEPTANCE CRITERIA

        Defining acceptance test strategy up-front

        Source and role of acceptance criteria

        5 elements criteria should address

        Functionality the user must demonstrate

        How much, how often user must test

        Determining system quality

        Who should carry out acceptance tests

        How acceptance tests should be performed

        Added benefit, revealing requirements errors

DESIGNING ACCEPTANCE TEST PLANS

        Expanding the acceptance criteria

        Allocating criteria to system design

        Refining the design to catch oversights

        Checklist of common problems to test

        Equivalence classes and boundary values

        Making quality factors (attributes) testable

        Structural testing applicable to users

        GUI features that always need to be tested

        Defining requirements-based tests

        Constructing use cases

        Cautions about use case pitfalls

        One- and two-column use case formats

        Turning use cases into tests

        Consolidating tests into efficient test scripts

CARRYING OUT ACCEPTANCE TESTS

        Differentiating test cases and test data

        Traps that destroy value of acceptance tests

        Warning about conversions

        Documentation, training, Help tests

        Configuration, installation, localization

        Security, backup, recovery tests

        Suitability of automating acceptance testing

        Performance, stress, load testing

        Issues on creating test conditions, data

        Capturing results, determining correctness

        User's defect tracking and metrics

Top of Page Tutorials: Series H

Tutorial #H2 (Thursday 8:30 - 4:30 p.m.)

H2: How to Choose a Testing Tool (Basic)(CSTP, #6)

Dorothy Graham

This tutorial counts as one day of training towards the Certified Software Test Professional requirements.

This tutorial provides guidance and practical help to those who are looking to purchase tools to help support the testing process. Tool support is available throughout the life cycle for different testing activities. The benefits and pitfalls of different types of tool are outlined. The place to start is not with a tool demonstration, but with an examination of current problems and bottlenecks (where is the pain?). A tool is one possible solution, but alternative solutions should also be considered. If tools are a good solution, a business case should be constructed quantifying the costs and projected return on investment. The evaluation and selection of the right tool is a (small) project in its own right.

Introducing a new tool into the workplace is not easy; nearly half of test execution tools purchased end up as "shelfware". A pilot project is needed to gain experience with the new tool and to establish the best ways to implement internal standards for using the tool.

When a capture replay tool is acquired for the first time, many organizations suffer unnecessary anguish
because of unrealistic expectations and lack of knowledge of how to structure a lasting and efficient test
automation "regime". Using case studies, templates and examples, this tutorial will show you what you can
expect when you begin trying to automate testing, and how to overcome many of the most common
problems.

Dorothy Graham is from Grand Rapids Michigan, but a UK resident for over 20 years, Dot has degrees in Mathematics, and worked for Bell Labs in New Jersey and for Ferranti Computer Systems and The National Computing Centre in Manchester, England. Dorothy is co-author with Mark Fewster of "Software Test Automation", published in 1999, and is co-author with Tom Gilb of "Software Inspection" published in 1993, both by Addison-Wesley. She was the originator and co-author of The CAST Report, on Computer Aided Software Testing tools. She has been involved in testing conferences since 1991 and was program chair for the first European testing conference in 1993. Sometimes described as a "technical entertainer", she is a popular and stimulating speaker at international conferences and seminars.

Top of Page Tutorials: Series H

Tutorial #H3 (Thursday 8:30 - 4:30 p.m.)

Patrick Johnson

This course shows how use case modeling and requirements management techniques can be used to define and document the requirements of a product that meets stakeholder needs.  Participants will learn how to elicit and manage changing requirements; analyze development problems, define the product vision and product features, define software requirements and requirement attributes, and maintain traceability for use in scope management, change management, and impact analysis.  Students gain an in-depth understanding of use case techniques through hands-on experience with actual use cases.

Recommended For

Technical, testing professional, and documentation managers, project leads, executives, application experts, business analysts, salespersons, and analysts/designers who are involved in requirements capture, specification, use, or management.

Objectives

§          Apply requirements management skills to create product requirements

§          Capture and document requirements with use case modeling techniques

§          Apply proven techniques for reaching and maintaining agreement with the stakeholders

§          Create a documentation hierarchy and standards for requirements

§          Understand the architecture of a simple requirements management system and maintain requirement attributes and traceability

§          Use requirement attributes and traceability links to manage scope and change throughout the life cycle of the product

§          Understand how requirements drive ongoing design, test, and user-documentation activities

Topics Covered

§          The requirements management process

§          The Rational Unified Process w/ UML

§          Analyzing the problem

§          Understanding stakeholders needs

§          Defining the systems: the vision, product features, and use case model

§          Finding actors and use cases

§          Managing system scope

§          Refiining the system definition

§          Detailing each use case

§          Managing changing requirements

§          Structuring the use case model using use case relationships (include, extend, generalization)

§          Requirements across the product life cycle

Prerequisites

A basic knowledge of project management and the software development life cycle is recommended.

Patrick Johnson has provided training and consulting on Rational’s products for several years.   His experiences range from modeling and analysis, requirements gathering to software quality automation, which enables him to provide expertise in each phase of the development and testing lifecycles… a unique skill set not common to the industry.   Also, he has effectively implemented Rational’s software quality methodology and tools on previous projects.  Patrick was instrumental in customizing Rational's testing methodology to develop a standardized testing methodology for large insurance company.  Because of Patrick’s expertise in Quality Structured Management Techniques and Quality Assurance for client/server applications, he was awarded the Quality Award by Shell’s management group in recognition for his innovative concepts and procedures that directly affected QUALITY.

Top of Page Tutorials: Series H

Tutorial #H4 (Thursday 8:30 - 4:30 p.m.)

This tutorial counts as one day of training towards the Certified Software Test Professional requirements.

Overview 

The heart of any test program is the test plan.  The test plan documents the procedures, tools and responsibilities for verifying compliance to the specifications and requirements.  Before an organization can start preparing the test plan they must determine their testing maturity.   This tutorial will discuss the Testing Maturity Model, Test Plan preparation and tool selection.  Special emphasis will be given to automated test tool selection.  It will provide valuable information and techniques that can be brought back to your organization and implement immediately.

Tutorial Outline 

v      Introduction

v      Testing Maturity Model

v      Level 1

v      Level 2

v      Developing Testing and Debugging Goals

v      Initiate Test Planning Process

v      Institutionalize Basic Testing Techniques and Methods

v      Level 3

v      Establish Testing Organization

v      Establish a Technical Training Program

v      Integrate Testing into the Life Cycle

v      Control and Monitor the Testing Process

v      Level 4

v      Establish an Organization-wide Review Program

v      Establish a Test Measurement Program

v      Level 5

v      Application of Process Data for Defect Prevention

v      Quality Control

v      Test Process Optimization

v      Test Cycle

v      Define Objectives

v      Prepare Test Plan

v      Introduction

v      Roles and Responsibilities

v      Test Program

v      Test Environment

v      Test Execution

v      Detailed Test Schedule

v      Test Procedures and Test Scenarios

v      Tool Selection

v      Test Performance Choices

v      Test Method Choices

v      Manual

v      Automated

v      Automated Tool Decision Process

v      Automated Test Tool Selection Process

v      Test

Learning Objectives

 1.       Determining your organizations Testing Maturity

2.      Learn how to progress to another level of testing maturity

3.      Learn the elements that make up a functional test plan

4.      Learn a process that can be uses to determine whether automated tools should be used

5.      Learn a process that can be used in selecting the best automated test tool(s)

Thomas C. Staab owns an independent telecommunications consulting firm.  He has over 9 years in the telecommunications field. In addition, he has over 25 years experience in the quality profession and holds a Master of Science degree in Quality Systems. His telecommunications consulting incorporates his extensive quality assurance and information technology into every project.  He has developed the test plan and coordinated the testing of numerous telecommunications systems for clients.  He brings this practical experience into the classroom.

Top of Page Tutorials: Series H

Tutorial #H5 (Thursday 8:30 - 4:30 p.m.)

This tutorial counts as one day of training towards the Certified Software Test Professional requirements.

This course will cover the test design phase of the testing lifecycle.   It starts with coverage of test case design techniques both for black and glass box testing.  This includes Equivalence Class partitioning, Boundary Value Analysis, Cause-Effect Diagram, and Decision Tables.  The second part of the course will cover test design activities and writing Test Design Specification including documenting test conditions, test cases, test scripts and procedures, and expected results.

Presentation Outline:

1. Test Case Design Techniques

Strategies for generating test cases

Black Box testing

Equivalence Class Partitioning

                Boundary Value Analysis

                Cause-Effect Diagram

                Decision Tables 

Glass Box testing

Statement/decision/condition coverage

                Path coverage

                Program complexity and basis path coverage

2.   System Test Planning

Why plan

Developing a test strategy

Components of a test plan

A test plan template

Creating a systems test plan

3.   Systems Test Design

Test design basics

Test design activities

Deliverables of the test design phase

Conditions and test cases

Procedures and expected results

Major areas of system testing

Business requirement testing

Preparing the Test Design Specification

                Defining test conditions

                Testing for missing business requirements

                Defining test cases

                Identifying data needed to execute tests

                Defining baseline data

                Determining expected results

                Defining test cycles

A Systems Test Specification template

Biography:

Dr. Magdy Hanna is a recognized educator, speaker and consultant in several related areas of software engineering.  Dr. Hanna brings over 20 years of experience with building and maintaining software systems.  As a consultant, he helped many organizations define and improve their software processes using disciplined software engineering approaches.  As an associate professor at the University of St. Thomas, he teaches graduate courses on several software engineering topics with emphasis on practical software quality techniques.  His distinguished seminars on various topics have been highly rated by software professionals. 

Top of Page Tutorials: Series H

Dr. Rebecca Staton-Reinstein

Despite the incredible pace of technology advancement, the looming Y2K showdown, more strategic uses of information on the Internet and in internal applications, globalization, downsizing, mergers and a plethora of other changes, establishing a viable Quality Assurance function is still as easy and as hard as it ever was.  The easy part is the body of solid practice developed over the last two decades which has established what works best in building, maintaining and continuously improving the QA function.  The hard part is still getting  managements buy in."  How does QA demonstrate its value to Information Technology executives, Project Managers and internal customer management?

1)       Applying quality principles

a)      Using QA, QC and QI effectively

b)      The strategic approach

2)       Definitions

a)      What is quality?

b)      Who is the customer?

c)      Who is the supplier?

d)      Who is my partner?

3)       QA the linkage to the business

a)      Defining the linkage

b)      Using the linkage effectively

c)      What do we need to know?

4)       Establishing the agenda for QA

a)      Surveying stakeholders

b)      Defining the need

c)      Tools and techniques

5)       Getting Started: Bookend Approach

a)      Requirements Control

b)      Change Control

6)       Step By Step QA practices

a)      Risk assessment

b)      Life Cycle implementation

c)      Standards creation

d)      Measurement

e)      Using Maturity Models

f)        Defect analysis

g)      Acquired software QA, QC

7)       Step By Step QC practices

a)      Reviews, Inspections

b)      Testing

c)      Change management

8)       Step By Step QI practices

a)      Process improvement

b)      Applying Statistics

9)       Who's responsible for QA, QC, QI

a)      Responsibilities at all levels

b)      Specific QA responsibilities

10)  Planning QA implementation, maintenance and improvement

11)  Getting management buy in

a)      Persuasive case building

12)  Implementation considerations

a)      Training

b)      Politics