ApplicationTesting PG

Course Map
Application Testing School
Day 1 8:00 - 8:15 8:15 - 8:30 8:30 - 8:45 8:45 - 9:00 9:00 - 9:15 9:15 - 9:30 9:30 - 9:45 9:45 - 10:00 10:00 - 10:15 10:15 - 10:30 10:30 -10:45 10:45 - 11:00 11:00 - 11:15 11:15 - 11:30 11:30 - 11:45 11:45 - 12:00 12:00 - 1:00 1:00 -1:15 1:15 - 1:30 1:30 - 1:45 1:45 - 2:00 2:00 - 2:15 2:15 - 2:30 2:30 - 2:45 2:45 - 3:00 3:00 - 3:15 3:15 - 3:30 3:30 - 3:45 3:45 - 4:00 4:00 - 4:15 4:15 - 4:30 4:30 - 4:45 4:45 - 5:00 Module 1: Introduction 1.1 Course Introduction (0:30) 1.2 Ice Breaker (0:15)
Day 2 Morning Review
Module 2: Testing in Accenture 2.1 ADM Overview (0:30) ADM Activity (0:15) 2.2 V-Model (1:00)
Module 3: Assembly Test (Continued) Activity Part 1 - Create the Test Plan (1:45)
Break
Break Module 2: Testing in Accenture V-Model Activity (0:45) 2.3 Quality Management (0:30) LUNCH
Module 3: Assembly Test (Continued) 3.3 Prepare the Test (0:30) Activity Part 2 - Create the Test Script (1:00) 3.4 Execute the Test (0:15)
LUNCH Module 4: Product Test 4.1 Overview (0:30) 4.2 Plan the Test (0:15) 4.3 Prepare the Test (0:15) 4.4 Execute the Test (0:15) Break
Module 2: Testing in Accenture (Continued) 2.4 Test Management (1:00) 2.5 ADT Tools (0:15) ADT Tools Activity (0:30)
Break Module 2: Testing in Accenture (Continued) 2.6 Checkpoint (0:30) Module 3: Assembly Test 3.1 Overview (0:30) 3.2 Plan the Test (0:45) Day 1 Summary
Module 4: Product Test Activity Part 3 Execute the Test Script (1:45) 4.5 Checkpoint (0:30)
Module 5: School Closing 5.2 School Closing 0:15)
Presentations
Module 1: Introduction

Module 1 - Introduction to School
Copyright 2007 Accenture All Rights Reserved. Accenture, its logo, and Accenture High Performance Delivered are trademarks of Accenture.
Welcome!
Welcome to the Application Testing School!
Introductions
Copyright 2007 Accenture All Rights Reserved.
Z16327 2007 Accenture Technology Solutions. All Rights Reserved
Course Positioning
This course is part of the required Application Delivery curriculum for Solutions and within the scope of the Accenture Solutions Delivery Academy
Accenture Solutions Delivery Academy

Two-tier certification program, developed in collaboration with the Massachusetts Institute of Technology Professional Education Programs team This course fulfills the Application Testing Course requirement for the Application Developer certification For more information on the Delivery Academy, and to enroll in the program, visit:
https://deliveryacademy.accenture.com
Massachusetts Institute of Technology, Professional Education Programs

Through an agreement with MIT Professional Education Programs, we work with participating faculty members from MIT's School of Engineering who contribute to the ongoing development and review of the educational content, assessment, and implementation of the Accenture Solutions Delivery Academy. Professor Daniel Jackson served as the lead MIT Faculty Member on this course, contributing significantly to both the course content and instructional design. His areas of expertise include several areas of software construction, including development methods, automatic analysis of designs and specifications, and reverse engineering of code.
Icebreaker Activity
Locate the note card at your seat. Each person has a word on their note card that is one part of a matching pair. Find the person that has the note card that is the matching pair to yours. Once youve found your pair, introduce yourselves and find out the following: Name Role Reason for being here An interesting fact about you Introduce your partner to rest of the class.
Course Goals
What are your goals for this school? What do you hope to learn while you are here?
Course Goals
School Learning Objectives

At the end of this school you will be able to: Identify and describe the major testing tasks within ADM Describe the role and responsibilities of a tester Articulate how a developer contributes to a successful test execution Understand and apply the V-Model in application testing Read, understand, and correctly interpret functional specifications, requirements, and other test planning documentation, and state the requirements for the creation of each deliverable Generate effective TCERs and Test Scripts using the appropriate functional specifications, requirements, and test planning documentation Successfully execute Assembly and Product tests based on the appropriate test planning documentation Properly report defects found during test execution
School Agenda
Module 1: Introduction Module 2: Testing in Accenture Module 3: Assembly Test Module 4: Product Test Module 5: School Closing
School Expectations
For a successful class, please
Arrive on time Assist your colleagues; show respect to all individuals regardless of their skill and knowledge level Wear business casual attire Do not use class time to surf the net, check e-mail or use instant messaging Turn all cell phones off Adhere to attendance policy as directed by your local training coordinator
10
Questions/Comments
What questions or comments do you have?
11
Module 2: Testing in Accenture

Module 2 Testing in Accenture
Learning Objectives
Articulate ADMs high-level organization and structure Describe the Testing Framework Summarize how the V-Model is used to effectively test an application Identify and differentiate between the types of testing involved in the development lifecycle and explain their purpose and benefits, including:
Component Test Assembly Test Performance Test Product Test User Acceptance Test Operational Readiness Test
Map the phases of the software development lifecycle to the different test tasks related to those phases Define exit and entry criteria and summarize the importance of stage containment Summarize the importance of quality management in the testing process Describe the testers role in quality management Describe the various Quality Programs in Accenture, including QPI, SEPG, SQA, and CMMI Describe and differentiate between the various roles and responsibilities involved in a typical testing project Identify the critical aspects of managing the test process Describe the ADT Tools and explain their purpose Map the ADT tools to the phases of the V-model
Z16327 Copyright 2007 Accenture All Rights Reserved.
Module 2: Agenda
ADM Overview The V-Model Quality Management Test Management ADT Tools for Testing Checkpoint
Discussion: Have you used ADM?

As a class, discuss and share your experiences!
What is ADM? Have you ever used ADM on a project? What have been your experiences with ADM?
ADM Overview
What is Accenture Delivery Methods (ADM)?
A collection of methods that cover: Management Strategy and planning Development Operations
Which method are we talking about?

Accenture Delivery Methods for Custom Development Supports:
- Business process analysis - Technical architecture development - Organization design - Training development
ADM: How Do We Get There?

Links to access online: Accenture Delivery Methods for Custom Development:
https://methodology.accenture.com/core_custom/content/frame set_home.asp
Accenture Delivery Methods:

https://kx.accenture.com/Offerings/Pages/ADM.aspx
Accenture Delivery Methods
Activity
Stages Workstreams
Tasks
The Testing Framework

Test Strategy Test Stages
Functional Testing (component, assembly, product, UAT) Technical Testing (Performance, Operational Readiness Test)
Testing Tasks
Job Aid: https://methodology.accenture.com/core_custom/content/frameset_home.asp?page=testingfr ameworkoverview.asp

Overview of Testing Activities and Tasks in ADM

Test activities/tasks in ADM: Tasks related to testing are done throughout each phase.
V-Model Phase Plan Analyze Design Build Test/Deploy
ADM Test Activity

Prepare Test Strategy Plan the high-level tests (e.g., Product, Performance, UAT) Plan test done against the high level design (Assembly Test) Plan test done against detailed design (Component Test) Execute the different types of planned tests
11
Testing Tasks and Deliverables

Test Tasks 1. Define the Approach Test Deliverables Develop test approach Test Approach document Create work plan Work Plan section -ORSeparate testing work plan Create test plan Test Scenarios Test Conditions and Expected Results Test Cycle Control Sheet within the Test Plan composite Prepare the test cycle schedule
2. Plan the Test
3. Prepare the Test 4. Establish the Test Environment 5. Execute the Test
Execute test Documented actual results and fixed defects Fully executed Test Plan Sign-off Test Closure Memo Sign-off sheet
6. Close the Test
15
Testing Templates, Deliverables, Job Aids
16
Scenario Activity
Using the ADM website: You will work in teams of two With your partner, answer the questions on the worksheet provided Use the ADM website to assist you in finding the answers to the questions At the end of the activity, be prepared to share your answers with the class
https://kx.accenture.com/Offerings/Pages/ADM.aspx
17
Questions and Comments

18
Module 2: Agenda
19
Discussion: The V-Model

As a class, discuss and share your experiences!
What do you already know about the Accenture V-Model? Have you ever been on any project that used the V-Model? If you have used the V-Model, how has that experience differed from being on projects that did not use the V-Model?
20
Defining the V-Model

Plan Analyze Design Build Test Deploy
Operational Readiness Test Requirements
Functional Technical
User Acceptance Test
Product Test
Application Integration
Performance Test Assembly Test
Design
Detailed Design & Build

Component Test
21
Validation: Doing the Right Thing

Occurs across stages Deliverables meet Ensures that work:
Remains in scope Contributes to client value Has no undesired side effects
Requirements
Plan
Analyze
Design
Build
Test
Deploy
Operational Readiness Test
Product Test
Application
Integration
Done by inspection, simulation, or prototyping Uses the traceability matrix

Design
Performance Test
Assembly Test
Component Test
Validation
22
Verification: Doing it the Right Way

Occurs within each stage Confirms that deliverables are:
Correctly derived Conform to established quality standards
Requirements
Plan
Analyze
Design
Build
Test
Deploy
Accomplished via deliverable reviews and inspections
Product Test
Performance Test
Design
Assembly Test
Component Test
Verification Validation
23
Testing: The Right Thing Working the Right Way

Occurs across stages Checks that a specification is properly implemented Is done via test execution Must be structured and repeatable
Requirements User Acceptance Test
Plan
Analyze
Design
Build
Test
Deploy
Functional
Technical
Product Test
Application
Integration
Performance Test
Design
Assembly Test
Verification Detailed Design & Build Component Test Validation Testing
24
Repeatability
Present when the same test can be reused both within and across releases.
Benefits Ensures standardized, measurable processes Saves time through test reuse Allows for test automation, reducing overall test execution time and potential for human error
Approaches Provide detailed, step-bystep instructions and expected results in test scripts Separate test data from test scripts Update the test model to reflect changes made to the application over time
25
10
Entry and Exit Criteria

Product Test
Design
Entry / Exit Criteria Flow of Work

Component Test
Verification Testing Validation 26
Benefits of the Accenture V-Model

Lower defect resolution cost due to earlier detection Improved quality and reliability Reduction in the amount of rework Increased testing efficiency with added focus on testing objectives Better informed scope definitions through requirements traceability Improved risk management Success criteria determined up front encouraging a more focused effort Validation and verification at each level for stage containment Puts quality assurance back in the hands of the developer
28
11
Activity: V-Model Tests

You will be separated into 6 groups. Each group will be assigned one of the tests below: 1. Component 2. Assembly 3. Performance 4. Production 5. User Acceptance 6. Operational Readiness Spend 10 minutes identifying the following for your test: Purpose When it is used How it is used Best Practices Each group will present the key concepts of their test to the class.
29
Accenture V-Model
Product Test
Design

Component Test
Verification Testing Validation 30
12
ADM Test Activities

Perform Operational Readiness Test
Define Delivery Strategy Prepare and Execute UAT
Plan Product Test Plan Performance Test Plan User Acceptance Test Prepare and Execute Product Test Prepare and Execute Performance Test
Plan Assembly Test
Prepare and Execute Assembly Test
Plan Component Test

Build and Test Application Components 31
Stage Containment
With Stage Containment
More errors than defects Cost and effort for fixing problems is minimized
Defect Origin Analyze Design Detailed Design / Build Component Test Assembly Test Prod Test Deploy
Defect Discovered
Analyze
Design
Detailed Design / Build
Component Test
Assembly Test
Prod Test
Deploy
32
13
Stage Containment
Without Stage Containment
More defects than errors Fixes become more expensive and difficult
Defect Origin Analyze Design Detailed Design / Build Component Test Assembly Test
Prod Test
Deploy
Defect Discovered
Analyze
Design
Component Test
Assembly Test
Prod Test
Deploy
POTENTIAL CHAOS!
33
Stage Containment
Without Stage Containment
Detailed Design / Build Component Test Assembly Test
Defect Origin
Analyze
Design
Prod Test
Deploy
Defect Discovered
Analyze
Design
Component Test
Assembly Test
Prod Test
Deploy
WORST CASE!
34
14
Testing Process Overview

Testing Strategy
Establish the Test Environment
Develop the Approach
Plan the Test
Prepare for the Test
Execute the Test
Manage the Test Stage
35
Who Should be involved?

Project / Program Manager
Development Manager
Test Lead
Tester
Technical Support Manager
Application Designers Application Developers
Quality Architects
Technology Designers Technology Developers
Users
36
15

37
Module 2: Agenda
38
16
What do you already know?

Lets see what you already know about Quality Management. If you know the answer, shout it out
39
Quiz Question # 1
What is Quality Management?
40
17
Quiz Question # 2
What are we doing to mitigate quality issues?
A. Establishing a structured quality process program (QPI) that will directly impact project execution and delivery Benchmark our quality levels against CMMI Level 3 A&B Accept the current losses as normal and hope the problem doesnt get worse
B. C. D.
41
Quiz Question # 3
What will this mean for me?
A. I will receive training, coaching, and support in best practice process areas which will increase my professional development My project could be evaluated on a monthly basis on adherence to the defined best practices and metrics I will be expected to follow Accentures corporate methodology (ADM) from planning through to implementation while tailoring it to the needs of the client and the size of the project All of the above
42
B.
C.
D.
18
Quality Management Programs at Accenture
Accenture Quality Programs: QPI

Quality and Process Improvement (QPI) A structured quality program that directly impacts project execution and delivery Provides projects with:
Standard processes Tools Coaching Training on systems/software engineering and project management disciplines
Augments Accentures firm-wide methodology Provides monthly reviews against best practices Provides increased visibility into project execution
44
19
Accenture Direction: Reduce CoPQ

Chief Quality and Risk Officer Bob Frerichs wants to reduce the Cost of Poor Quality (CoPQ) to 2%.
Leadership support around increasing quality and delivery excellence starts from the top: As we continue to become a high-performing company ourselves, part of our differentiation will be superior execution and delivery. This is about increasing client satisfaction and quality and its also about taking the best of what we have to our clients each day. Our enhanced Quality program will take our execution and delivery to the next level. - Bill Green, Accenture CEO
45
46
20
Accenture Quality Programs:

Capability Maturity Model Integration (CMMI) Owned by Carnegie Mellon University (Software Engineering Institute), but is treated as public domain and its usage is free (http://www.sei.cmu.edu/cmmi) Provides best practices covering a products life cycle, which are organized into Process Areas Utilizes a system development organizations existing practices Addresses productivity, performance, costs and stakeholder satisfaction using best practices Intended to incorporate the content of CMM, while adding systems engineering content
47
CMMI at Accenture
CMMI is used at Accenture in the following ways:
Is used for continuous improvement of our development practices Applies to all systems development and/or maintenance projects Is used with the Accenture Delivery Suite to reinforce systems industrialization and high performance technology
48
21
CMMI Levels
Emphasis on continuous improvement
5 Optimizing
Improvement is based on common causes of variation Organizational innovation occurs
Process measured and statistically controlled
4 Quantitatively Managed
Quality & performance are understood and managed in statistical terms
Process characterized for the organization
3 Defined
Project-specific processes are based on a tailored version of an organization-wide process set
Process characterized for projects
2 Managed
Processes are planned, documented, performed, monitored, and controlled (at the project level)
Process unpredictable, poorly controlled and reactive

1 Initial
49
Benefits of CMMI
Cycle Time
Deliver faster than competitors. Accomplish more with less. Improve effectiveness of multi-site development. Improve accuracy of cost and time estimates. Improve ability to meet delivery commitments consistently and reliably. Reduce number of defects. Improve alignment of IT solutions to the needs of the business. Ensure investments target the right priorities. Optimize use of resources across priorities. Establish environment for continuous improvement through appropriate measurement.
Productivity
Predictability Quality
Application Portfolio Management Continuous Improvement
50
22
What do QPI and CMMI mean to me?

1. Follow Accenture Delivery Methods through the life cycle of the project. 2. Follow Code Standards during Design and Build. 3. Follow each projects processes for Configuration Management and Quality Reviews during Build and Component Test. 4. Help to identify process improvements.
51
52
23
Accenture Quality Programs: SEPG

Software Engineering Process Group (SEPG) Goal: To improve the effectiveness of software engineering processes in a development organization SEPG helps Accenture:
Establish process standards and maintain process metrics and quality criteria Serve as the focal point for technology insertion Provide key process education Provide project consultation Make periodic assessments and status reports
53
Accenture Quality Programs: SQA

The Software Quality Assurance (SQA) process verifies that processes and deliverables/work products comply with project standards and procedures. SQA reviews support the delivery of high-quality products and services.
SQA review benefits include:
Providing timely verification of the project's products and the related software development process. Identifying issues and concerns early, resulting in cost and time savings (i.e., reduced re-work). Identifying opportunities for continuous improvement on existing processes.
54
24
Difference between QA and Testing
55
Role of the Tester in Quality Management

What is the Testers Role in Quality Management?
Produce data for the Test Lead or Manager to collect for quality management purposes
Note: this refers to metrics data, not test data created for test execution
Provide accurate data on a regular basis to help the Test Lead generate accurate and effective metrics Know the importance for accurate data Provide accurate data to the Test Lead or Manager during various testing activities
56
25

57
Module 2: Agenda
58
26
Project Management during the Test Process

Project / Program Manager
Team members must know howrolesteams work together of each the the and responsibilities and Technical Support Development Test team member to understandLead to expect. interact with each other. what Manager Manager
Tester Application Designers Application Developers Quality Architects Technology Designers Technology Developers
Users
59
Discussion: Roles and Responsibilities

Work in groups of 4 or 5 With your group, try to identify at least 3 responsibilities for each of the following roles:
Test Lead Tester
Document your results on a flipchart and be prepared to share your thoughts with the class
60
27
Qualities of a Great Tester

A great tester should:
Catch the majority of application defects. Communicate defects clearly to the Fix-it team.
Most great testers share the following traits:

Good communication skills Detail orientation Ability to follow directions Strong understanding of testing concepts Ability to innovate
How would you rate yourself?
63
Testing Techniques
Black Box Testing White Box Testing Positive Testing Negative Testing Static Testing Dynamic Testing
64
28
Black Box Testing (Functional Testing)

Black Box testing ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.
Input
Executable Program
Output
Black Box Test
65
Black Box Testing

Advantages
Tester needs no knowledge of implementation, including specific programming languages. Tester and programmer are independent of each other. Tests are done from a users point of view. Test cases can be designed as soon as the specifications are complete.
Disadvantages
Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever. Without clear and concise specifications, test cases are hard to design. There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried. May leave many program paths untested.
66
29
White Box Testing (Structural Testing)

White Box testing takes into account the internal mechanism of a system or component. Requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission. All visible code must also be readable.
67
White Box Testing

Advantages
It is very easy to find out which type of input/data can help in testing the application effectively. It helps in optimizing the code (e.g., it helps remove the extra lines of code, which can bring in hidden defects).
Disadvantages
A skilled tester is needed to carry out this type of testing, which increases the cost. It is nearly impossible to look into every bit of code to find hidden errors, which may create problems and result in the failure of the application.
68
30
Positive Testing
Aimed at showing that the software works. Testing the system by providing valid data. Also known as "test to pass".
69
Negative Testing
Testing aimed at showing software does not work. Testing the system by providing invalid data. Also known as "test to fail".
70
31
Static Testing
Static Testing (also known as "Dry Run Testing") is a form of testing where the software isn't actually used. Syntax checking and manually reading the code to find errors are methods of static testing. This type of testing is mostly used by the developers. 'Static testing' is generally not taken as detailed testing, but checks mainly for the sanity of the code/algorithm, and to assess if the program is ready for more detailed testing, where methods like code review, inspection and walkthrough are used. Static testing can be done before compilation.
71
Dynamic Testing
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. Dynamic testing can take place only after compilation. It wont run otherwise.
72
32
Establishing the Test Environment

Testing Strategy Establish Test Environment
Test Environment
Develop Approach
Plan Test
Prepare Test
Execute Test
Manage Test Stage
73
Test Environment Guidelines

1. Determine environments required for testing. 2. Determine set-up requirements and lead time. 3. Emphasize configuration management. 4. Verify readiness of the test environment prior to starting the test. 5. Define an environment that allows testing automation. 6. Develop standards to ensure that the promotion process is conducted thoroughly and properly. 7. Implement checklists and test scripts in test standards.
74
33
Think About These

Are the required test environments ready when they are needed? Are the test environments stable? Who prepares and controls the test environments? Do you have to share the test environment with other groups? Do the test environments accurately reflect the production environment? In general, what would you like to see done differently with respect to establishing and managing the test environment?
76
Test Environment Considerations

To execute your test, you need to run the test against the product. The product should look, feel and act exactly as it would in production. Use a scaled down environment where the functionality is the same. Environment should be isolated. For each test stage or phase, you need to have separate environments.
77
34
The Test Lead and the Test Process
78
What are the Stages of Test Management?

1. 2. 3. 4. 5. Identify and prioritize expectations Plan the test Execute the test according to plan Continue to check the process Tailor the process
5 4
2 1
79
35
Using Metrics to Track Projects

What are Metrics? Metrics are critical to successful testing. A good set of metrics is like a compass; it tells you where you are and helps you get to where you want to be. Why Use Metrics to Manage Testing? Use of metrics allows a Test Lead to:
Facilitate Continuous Improvement Manage with Facts Solve the Problem, not the Symptom
80
How Metrics Can be Defined (using the GQM Paradigm)

A top-down approach for developing, selecting, and tailoring software metrics. This paradigm ensures that there is a purpose for collecting each metric. Each metric provides valuable information by answering a question, making it possible to make decisions and take actions in order to achieve organizational goals.
81
36
Discussion: Using GQM to Improve Management of the Test Process

GOAL Improve Management of the Test Process using the GoalQuestion-Metric (GQM) Paradigm. Discussion Questions What is the rate of test planning? What is the rate of test preparation? What is the rate of test execution? What is the rate of incoming problems? What is the rate of fixing problems?
82
Using the Metrics to Track Projects

Metrics enable the Team Lead or Project manager to:
Understand how well we are doing
Are we on schedule, behind or ahead?
Sample Testing Metrics

Number of defects by severity OR phase Delivered Quality Defect Removal Efficiency Defect Injection Rate Defect Density Testing Efficiency Productivity Average Turnaround Time for Defects/Enhancements
Measure the test process, and thereby facilitate the understanding and control of it Determine:
The earned testing progress/value The amount of testing remaining When testing will be complete
Justify the purchase of tools and the implementation of process improvements

83
37

84
Module 2: Agenda
85
38
Accenture Delivery Tools

Accenture Delivery Tools for Development are:
Accenture Delivery Tools for Development have:
86
Accenture Delivery Tools List

Tools
Rational RequisitePro Rational Software Modeler Rational Software Architect Rational Manual Tester Rational Functional Tester Rational Performance Tester ClearQuest Test Management
Use
Understand requirements and track their changes Model user interactions in order to validate the requirements Define test cases for the requirements
87
39

Tools
Use
Update the relevant UML models with changed or new requirements
88

Tools
Use
Create or update code, based on the model; the model and code are synchronized to reflect the change
89
40

Tools
Use
Create and maintain easy to follow manual tests with support for automated data entry and data verification to reduce human error
90

Tools
Use
Create and maintain automated scripts for regression testing of your applications With ScriptAssure to allow for changing user interfaces and script maintenance available in standard development languages
91
41

Tools
Use
Create or update code, based on the model The model and code are synchronized to reflect the change
92

Tools

Use
Define and group test cases Create the documents or automated scripts for executing the test cases, run test cases written with Rational Functional Tester or Rational Performance Tester Record the test results and store them in the backend database Analyze testing during planning through execution with built-in or custom-created queries or graphs
93
42
Activity: ADT Tools

You will be separated into 5 groups Each group will be assigned one of the tools below:
Rational RequisitePro Rational Manual Tester Rational Functional Tester Rational Performance Tester ClearQuest Test Management
Spend 5 minutes discussing the answers to the following questions for your tool:
In which phase would your tool be used? How do you think your tool would be used? What do you think the benefits are for using your tool?
Each group will share their responses with the class
94
Mapping ADT Tools and V-Model Stages

Plan Analyze Design Rational Software Architect Build Platform-specific Tools Test Manual Tester Functional Tester Performance Tester
Deploy
Requisite Pro
Software Modeler Requirements Requirements
Functional Functional Technical Technical
Product Test
Application Integration Application Integration
Performance Test Assembly Assembly Assembly Test Test
Design Design
Component Component Test Test Test
Verification Testing Validation
ClearQuest Test Management
Cprigt 2007 Accenture All Rights Reserved. oy h
95
43
Manual Testing Usage

Rich text editor Test step reuse library
Customizable
Central repository for distributed team access
Attach images and files
96
Functional Testing Usage

Eclipse or VS.NET-based editor and debugger ScriptAssure for test script resiliency
Java in Eclipse or VB.NET in VS.NET
Data-driven test assistance

Developer-strength editing
97
44
Performance Testing Usage

Visual test editor Real-time reporting
Resource data collection from Windows
Developer-strength editing
98
ADT Tools: Need more info?

Visit the ADT Tools knowledge exchange home page for more information.
https://kx.accenture.com/Communities/Pages/ADTC oP.aspx
99
45

100
Module 2: Agenda
101
46
Checkpoint
Checkpoint Quiz Round 1!
Checkpoint
47
Module 3: Assembly Test

Module 3 Assembly Test
Learning Objectives: Module 3

Define Assembly Test Summarize where the Assembly Test fits within ADM and the V-Model Develop an understanding and fluency with the functional specification documentation, including:
Requirements Use Case Model User Interface Design
Develop an understanding and fluency with the Test Plan/Process deliverables, including:
Test Conditions and Expected Results Test Scripts Test Cycle Control Sheets Test Data
Create concise and effective test conditions and expected results for an assembly test that reference all required specifications Create concise, effective and reusable test scripts for an assembly test Articulate the Developers perspective on the testing tasks for an Assembly test
Module 3: Agenda
Assembly Test Overview
Plan the Test Activity 1 Prepare the Test Activity 2 Execute the Test
Test Stages Overview

The goal of testing is to ensure the overall solution, its components, and its assembly of components meets the established functional and technical requirements. Because testing a business system is complex, testing is divided into stages that are based on the V-Model.
Test Stages
1. Component Test 2. Assembly Test 3. Product Test 4. Performance Test 5. User Acceptance Test 6. Operational Readiness Test
Notice that the Test Stages are based upon the V-Model.
Assembly Test in ADM and the V-Model

Product Test
Application Application Integration
Performance Test Assembly Assembly Test Test
Design
Component Test
Assembly Test: What is it?

Assembly Tests verify the assembly and combined operation of components (i.e., individual modules, interface modules, etc.). This ensures that the interactions between the components function correctly before building the overall solution.
Assembly Test Tasks

1. 2. 3. 4. 5. 6. Define the Approach Plan the Test Prepare the Test Establish the Test Environment Execute the Test Manage the Test
The same testing tasks apply to each and every test stage.
Assembly Test: How is it organized?

The assembly test progressively increases in complexity. First, the test verifies the low-level functionality of several small sets of related components.
Next, it verifies the functionality of inter-related assemblies
by assembling them into larger sets of related components
until progressive assembly testing verifies the low-level functionality across the system.
Assembly Test: Considerations

Keep in mind that the assembly test does not test complex functionality of the final product. Be sure to tailor the assembly test level to suit the custom software, packages, and enhancement projects. The boundaries between the component test and assembly test may overlap.
10
Module 3: Agenda
Assembly Test Overview Plan the Test
Activity 1 Prepare the Test Activity 2 Execute the Test
11
Plan Assembly Test in ADM

Occurs in the Design Application Activity Tasks include: Define Assembly Test Approach Define Assembly Test Conditions and Expected Results Define Assembly Test Cycles Perform Peer Review
12
Plan the Test: Inputs and Deliverables
13
The Test Plan: A Composite Deliverable

Test Approach Explains the objectives and scope of the test, entry and exit criteria, resources, key dates, etc. Explains what to test and how to carry out the test at a high level.
Test Scenarios and Test Conditions and Expected Results (TCER) Test Cycle Control Sheet Test Script
Defines when and by whom test cycles are executed. Details the exact steps that a tester must follow to complete testing (i.e., to test all the test scenarios and conditions). Test scripts also include the data that is used for testing.
14
Test Plan Overview

Together, the Test Cycle Control Sheet (TCCS) and the associated test scripts form the part of the Test Plan to be used by the test execution team. The TCCS is used to manage the execution schedule, since it lists every cycle that is executed, along with the associated start and stop dates and resources. The test scripts are followed by the testers and are used to document actual results.
15

Input Documents
Requirements Use Case Model User Interface Design Requirements Traceability Matrix
Deliverables
1. Test Scenarios (Usually created by Lead) 2. TCER - Test Conditions and Expected Results (This is the one we will focus on creating.)
The tester may or may not use all of the above input documents.
16
Plan the Test: Inputs

Requirements Document Contains a list of all the things the application needs to be able to do to meet the clients needs Is used as an input into planning the test to ensure that the application you are testing meets those requirements Requirements Traceability Matrix
Maintains the traceability from requirements to end products and from the end product back to requirements
17

Use Case Model
Describes a sequence of actions the application performs on behalf of a particular actor, which can be either a user or an external application. It includes:
Use case Activity diagram Use case diagram
Use the use case model as an analysis tool to drive out and fully understand the application's functional requirements.
18

User Interface Design
Consists of all of the design elements for all aspects of the user interface, from the initial site map to the detailed specifications for each page or window in the user interface. Provides programmers with all of the detailed information necessary to code the user interface.
Transforms the list of user interface and functional requirements developed in the Analyze Application activity into the visual representation of the site or application. Defines the users' interaction with the site. Specifies the behavior of every element of the user interface under all conditions.
19
TCER Creation Process

Test conditions define the tests to be performed. They should always match the development stages they relate to and the requirements and designs they intend to prove. Assembly test conditions should be directly traced back to the application design deliverables or to the detailed level functional requirements.
20
10
TCER Creation Process (continued)

In addition to normal positive conditions, the test conditions address the following:
1. Limit values. Values that are not within the normal range but are acceptable. 2. Negative values. Unacceptable values. 3. Exception values. Values that are not normal but can occur; they need special.
21
Test Condition Properties

Name and description of the test condition Expected result Begin these with an action verb: create, print, etc.
Example: Create invoice.
For each test condition, define a corresponding expected result.

Example: An invoice is created.
Requirement or design source
Each test condition is derived from one requirement or design item.
22
11
Test Conditions: Key Considerations

1. Consider if the test data should be embedded (explicitly specified) as part of the Test Conditions and Expected Results (TCER) document. 2. Document test conditions using a table or spreadsheet. 3. When appropriate, use the Test Plan Template to document test conditions, scripts, test cycle control sheets, etc., in one document, rather than creating these as separate deliverables.
23
Using the TCER Creation Process

1. Derive TCERs from Requirements (and/or Test Scenarios). 2. Trace each Test Condition back to a specific requirement. 3. Create Assembly Test TCERs during the Design stage and refine as the project progresses. 4. Verify that detailed functional requirements have been met. 5. Group TCERs logically by Test Cycle.
24
12
Key Characteristics of Good TCERs

1. Should provide a high degree of detail, both in the condition and the expected result. 2. Both the Assembly Test Condition and the Expected Result should closely match the corresponding Test Scenario and detailed Functional Requirement.
25
Examples: Good and Bad TCERs

1. Read the sample Test Conditions and Expected Results below. 2. Discuss: Which example is better? Why?
26
13
Examples: Good and Bad TCERs

1. Read the sample Test Conditions and Expected Results below. 2. Discuss: Which example is better? Why?
Figure 1b specifically addresses the stated requirement, and includes all necessary criteria to ensure that the requirement is fully satisfied.
27

28
14
Module 3: Agenda
Activity 1
Prepare the Test Activity 2 Execute the Test
29
Activity 1: Create a TCER

Activity Overview For this activity, you will be creating Test Conditions and Expected Results. There are three parts to this activity.
Part 1: Create TCERs from Business Requirements Part 2: Create TCERs from the User Interface Design Part 3: Create TCERs from Use Cases
Timing
1 hour 45 minutes
30
15
Activity 1 Part 1
Activity Overview Instructions For Activity 1, Part 1, you will be creating the Test Conditions and Expected Results based on the Business Requirements. 1. Review the following inputs:
a) Test Scenarios b) Requirements document
2. Create test conditions and expected results and fill out the TCER template 3. Peer Review
a) Find a partner and review each others TCERs against the given criteria b) Share your feedback with your partner
4. Class Debrief Timing 35 minutes

31
Activity 1 Part 2
Activity Overview Instructions For Activity 1, Part 2, you will be creating the Test Conditions and Expected Results based on the UI Design. 1. Review the following inputs:
a) Test Scenarios b) UI Design document

32
16
Activity 1 Part 3
Activity Overview Instructions For Activity 1, Part 3, you will be creating the Test Conditions and Expected Results based on the Use Case documents. 1. Review the following inputs:
a) Test Scenarios b) End User Use Case c) Launch WMA Use Case

33
Module 3: Agenda
Assembly Test Overview Plan the Test Activity 1 Prepare the Test Activity 2 Execute the Test
34
17
Prepare Assembly Test in ADM

Occurs in the Test Application Activity Tasks include: Confirm Assembly Test Cycles Create Assembly Test Scripts Establish Assembly Test Environment Update Common Test Data
35
Prepare the Test

Testing Strategy Establish Test Environment
Develop Approach
Plan Test
Prepare Test
Test Plan Test Approach Test Scenarios Test Conditions and Expected Results Test Cycle Control Sheet Test Script Test Data
Execute Test
Manage Test Stage
36
18
Prepare the Test: Inputs and Deliverables

Input Documents
Requirements Use Case Model User Interface Design Requirements Traceability Matrix Test Scenarios TCER Test Conditions and Expected Results
Deliverables
1. TCCS Test Cycle Control Sheet (Usually created by Test Lead) 2. Test script (This is the deliverable we will focus on creating)
37
The Test Plan: A Composite Deliverable

Test Approach Explains the objectives and scope of the test, entry and exit criteria, resources, key dates, etc. Explains what to test and how to carry out the test at a high level.
Test Scenarios and Test Conditions and Expected Results (TCER) Test Cycle Control Sheet Test script
Defines when and by whom test cycles are executed. Details the exact steps that a tester must follow to complete testing (i.e., to test all the test scenarios and conditions). Test scripts also include the data that is used for testing.
38
19
The TCCS (Test Cycle Control Sheet)
39
Test Cycle Control Sheet
Release Identifier - The specific product release number for which this deliverable was produced.
40
20
Product - The name of the product for which this deliverable was produced.
41
Platform - The type of application (operating system and hardware) on which the product was designed to run.
42
21
Configuration - A description of how the product is configured; for example, a specific application setting or a tool that was used to manage a group of application settings.
43
Test Model Status - An indicator of whether or not the deliverable has been approved by a project manager.
44
22
Test Model Version - The version number of the deliverable, indicating how many times it has been revised.
45
Prepared by - - The initials of the person who originally prepared this deliverable, and the date on which the deliverable was prepared.
46
23
Approved by - The initials of the person who approved the deliverable (if applicable), and the date on which it was approved.
47
Document Status - An indicator of whether or not the deliverable has been approved by a project manager.
48
24

Level - The test level in which the specified test cycle will be executed. Three levels of testing are planned for a solution. The first level is a high-level horizontal test through all of the functions in the solution. The second level is a number of detailed vertical tests testing each of the functions within the solution. The third level is exception processing.
49
Cycle Number - The sequence in which the test cycle will be run within the specified test level.
50
25
Description - A short description of the test cycle.
51
Scheduled Start/End Date - The dates on which the specified test cycle is scheduled to begin and end, respectively.
52
26
Actual Start/End Date - The dates on which the specified test cycle was actually started and completed, respectively.
53
The TCCS and Test Scripts

The Test Cycle Control Sheet (TCCS) defines when, and by whom, test cycles are executed. The test scripts are written up with input data to complete the test plan. Together, the TCCS and the associated test scripts form the part of the test plan to be used by the test execution team. The TCCS is used to manage the execution schedule, since this lists every cycle that is executed, along with the associated start and stop dates and resources. The test scripts are followed by the testers and used to document actual results.
54
27
Test Cycles: What are they?

They are logical groupings of test scenarios and conditions used to facilitate efficient test execution. High-level test cycles are already defined within the Test Approach document. The highlevel cycles are reviewed, refined, and completed. When designing test cycles, a balance is achieved between completely independent test cycles and sequential cycles that are dependent upon each other. Modular, structured cycles, and sub-cycles using independent test data facilitate reuse or re-execution for regression testing, as well as maintainability and extendibility for future releases.
55
Test Cycle Documentation

For each test cycle, specify:
Name and description of the cycle Business relevance Type of the cycle (such as online, batch, etc.) Execution dependency (some cycles cannot be executed until some others are executed) Approximate time span needed to execute the cycle
56
28
Grouping by Test Cycle: An Illustration

Two Examples of how test cycles can be grouped
Example 1
Logical Cycle Grouping
Example 2
Functional Cycle Grouping Check Out Book Reserve Book Check In Book Cancel Reservation
Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle 5 Cycle 6
Get Patron Info Get Book Info Process Loan Process Return Process Reservation Process Cancellation
57
Creating Test Scripts for an Assembly Test

Test Scripts: Detail the exact steps that a tester must follow to complete testing (i.e., to test all the conditions). Describe a part of or the whole test cycle. Include the data that is used for testing. Has a test condition for each test step traced back to a requirement item. Are documented using a table or spreadsheet format (or a test management tool). When to Write Test Scripts: To enable the tester to execute specific actions and compare actual results to expected results. Immediately prior to test execution. After sufficient application details are gathered to aid in the writing.
58
29
Characteristics of Good Test Scripts

Provide explicit, step-by-step instructions Are highly detailed Are reusable Cover all Test Conditions and Expected Results Reference necessary input data Follow a standard format
59
Test Script Fields
Step Number
1.001
Action / Description
Enter User Name Create User Password
Input Data
First Name: XXX Last Name: XXX Middle Initial: X Password: XXX Retype Password: XXX
Expected Result
Page displays the entered information Password is displayed as a series of asterisk (***)
1.002
The Step Number field identifies each step to be executed. When a defect is identified, the corresponding Step Number should be documented in the SIR.
60
30
Test Script Fields
Step Number
1.001
Input Data
Expected Result
1.002
The Action/Description field provides detailed directions as to HOW to execute each step, and should be based off of the existing Test Conditions. Each of these steps should begin with an action verb, and should only describe one action at a time.
61
Test Script Fields
Step Number
1.001
Input Data
Expected Result
1.002
The Input Data field lists each field for which the tester should input data to complete the Action/Description. Note that this field only lists the type of data to be entered (hence the XX format); the data itself is housed in a separate document.
62
31
Test Script Fields
Step Number
1.001
Input Data
Expected Result
1.002
The Expected Result field should be closely aligned with the existing Test Conditions and Expected Results. It should explicitly describe the result testers should see upon completing the action for that step.
63
Example of Test Scripts for Test Cycles

Two examples of how scripts can be written for test cycles Example 1
Logical Cycle Grouping Cycle 1 Cycle 2 Cycle 3 Get Patron Info Get Book Info Process Loan Script 2 Script 3 Script 1
Example 2
Functional Cycle Grouping Check Out Book Reserve Book Check In Book Script 1 Script 2 Script 3
Cycle 4 Cycle 5 Cycle 6
Process Return Process Reservation Process Cancellation
Script 4
Cancel
Reservation
Script 4
Script 5
64
32
Writing Test Scripts Test Conditions and Expected Results
Refine
Order
Test Scripts
65
The Importance of Test Data

Do you prepare test data based on previous experiences? What are the advantages of Common Test Data? Is test data always created for a stage from scratch?
66
33
Common Test Data

Common Test Data is shared between test stages used by the development and testing teams. This is created, updated, and used in the preparation and execution of each test stage: component, assembly, product, performance, and user acceptance.
67
Discussion: Common Test Data

What do you think is the advantage of having to use Common Test Data across test stages?
1. 2. 3. Improves testing productivity Reduces the burden on developers Simplifies regression testing
Given these benefits of Common Test Data, we need to effectively Plan for our Test Data.
68
34
How to Plan for Test Data

Plan to use common data across multiple tests and Test Cycles. Derive the test data from the Test Conditions and the Test Approach. Create increasingly complex data sets as business scenarios being tested also increase in complexity
69
Preparing an Assembly Test - Key Considerations

Things to think about when preparing an assembly test: Coincide the assembly testing schedule with the delivery of assemblies Creating assembly test plans for object-oriented applications requires more effort Prioritize the testing efforts Plan for migration
70
35

71
Module 3: Agenda
72
36
Activity 2a: Create the Test Script

Activity Overview Instructions During this activity you will be taking what you have learned to create a test script. 1. Review the Given Test Conditions and Expected Results document 2. Walkthrough the WMA application to understand how the application is supposed to work 3. Create a test script to test against each test condition 4. Peer Review 5. Class Debrief 2 hours
73
Timing
Module 3: Agenda
74
37
Execute Assembly Test in ADM

Occurs in the Test Application Activity Tasks include: Execute Assembly Test Perform Fixes Create Test Closure Memo
75
Execute the Test: Inputs and Deliverables
76
38
Test Script Execution Process

Prerequisites to Successful Test Execution
Planning and preparation are complete Inspections have occurred Environment is well established and ready Test team is trained Migration procedures exist Test tools are used
Process to Execute the Test

1. Execute the test scripts. 2. Compare the actual results to the expected results. 3. Identify and resolve any discrepancies. 4. Document the results.
77
Executing an Assembly Test - Key Considerations

Things to think about when executing an assembly test: Refine the test plan and model after running the first test cases Foster collaboration between testers and developers Set up the common test data for testing multiple applications Conduct thorough regression test
78
39

79
40
Module 4: Product Test

Module 4 Product Test
Learning Objectives: Module 4

Define Product Test Summarize where the Product Test fits within ADM and the V-Model Compare the processes and deliverables for planning, preparing and executing an Assembly Test and a Product Test, and articulate the differences Correctly execute the Product Test using functional specifications and requirements Create concise, effective and reproducible defect reports for a Product Test Articulate the Developers perspective on the testing tasks for a Product Test
Module 4: Agenda
Product Test Overview
Plan the Test Prepare the Test Execute the Test Activity 3
Checkpoint
Test Stages Overview (recap)

Goal of testing:
To ensure the overall solution, its components, and its assembly of components meets the established functional and technical requirements.
Testing is divided into stages that are based on the V-Model.
Test Stages
1. Component Test 2. Assembly Test 3. Product Test 4. Performance Test 5. User Acceptance Test 6. Operational Readiness Test
Notice that the Test Stages are based upon the V-Model.
Product Test in ADM and the V-Model
What is a Product Test?

The first point where the solutions functional and business requirements are tested together.
Product testing ensures: Business requirements are fulfilled. Functional specifications are correctly implemented. Complex business processes execute correctly. Business process errors and exception logic are handled correctly.
Product Test Tasks

1. Define the Approach 2. Plan the Test 3. Prepare the Test 4. Establish the Test Environment 5. Execute the Test 6. Manage the Test
The same testing tasks apply to each and every test stage.
Assembly - Product Test Differences

Assembly Test
Tests the assembly and combined operation of related components. Validates these individual components.
Product Test
First point where the solutions functional and business requirements are tested together. Tests that all functional and business requirements have been met by the system.
Ensures that the interactions between the components function correctly before building Ensures that users already have the overall solution. a working understanding of the system when they design and execute the User Acceptance Test (UAT). Sometimes called system test.
Inside the Product Test

Product Test is broken down into two separate tests that are used for systems with multiple applications (for example, enterprise application integration).
Application product test Integration product test
A test of the business requirements met by each individual application. An end-to-end test of the business requirements across all applications and platforms.
10
Product Test Process
11
Progressively Increase Test Complexity
12
Product Test Design Best Practice

Design and execute product testing in conjunction with end users and business sponsors wherever possible. This maximizes test coverage and relevance and ensures that users already have a working understanding of the system when they design and execute the User Acceptance Test (UAT).
13
The Testers Role
The testers role is to execute complete end-to-end business scenarios that map to the defined system requirements of the system.
14
Discuss: A Developers Perspective

Testers and Developers work closely together. What do you think a developer will be concerned about?
Whether all the business requirements have been properly implemented If end users are able to successfully execute end-to-end business scenarios If the system is fully integrated, stable, and operates according to requirements Testers will be testing the system based on the same set of requirements that the Development team used to design and build the system Defects found will indicate that the system does not behave as per the requirements
15

16
Module 4: Agenda
Prepare the Test Execute the Test Activity 3
Checkpoint
17
Plan Product Test in ADM

Occurs in the Analyze Application Activity
Tasks include: Define Product Test Approach Define Product Test Conditions and Expected Results Define Product Test Cycles Perform Peer Reviews
18
19

Input Documents Requirements (Business and Highlevel Functional) Use Case Model Requirements Traceability Matrix Test Scenarios (Usually created by Test Lead) TCER (Test Conditions and Expected Results)
Deliverables
The tester may or may not use all of the above input documents.
20
10
Discussion: Assembly vs. Product Test

How is creating the TCER different for a Product Test than it is for an Assembly Test?
21
Same Process, Different Scope
22
11
Planning Product Test - Key Considerations

Clearly define the boundary between Assembly testing and Product testing. Focus this test stage on the execution of the complex business processes. Pay attention to the efficiency of the Product test. Plan for regression testing. Ensure adequate product testing. Ensure test data is available and correctly associated with developed test scripts.
23
Planning Product Test - Key Considerations (cont)

Develop the test suite to support automated regression testing (where applicable). Account for additional levels of product testing. Test the applications compatibility. Model the test environments after the production environment. Emphasize security testing.
24
12

25
Module 4: Agenda
Assembly Test Overview Plan the Test Prepare the Test Execute the Test Activity 3 Checkpoint
26
13
Prepare Product Test in ADM

Occurs in the Test Application Activity Tasks include: Confirm Product Test Cycles Create Product Test Scripts Establish Product Test Environment Update Common Test Data
27
Prepare the Test
28
14
Prepare the Test: Inputs and Deliverables

Input Documents Requirements (Business and HighLevel Functional) Use Case Model TCERs Requirements Traceability Matrix Common Test Data Test Plan (Test Scripts Creation) Requirements Traceability Matrix
Deliverables
29
Discussion: Assembly vs. Product Test

How is preparing a Product Test different from preparing an Assembly Test?
30
15
Same Process, Different Scope
31
Preparing Product Test - Key Considerations

Things to think about when preparing a product test: Conduct a technical architecture product test, if necessary Define and execute communication procedures Ensure the technical support team sets up the test environment properly Keep the application documentation in sync with the application
32
16

33
Module 4: Agenda
Assembly Test Overview Plan the Test Prepare the Test Execute the Test
Activity 3
Checkpoint
34
17
Execute Product Test in ADM

Occurs in the Test Application Activity Tasks include: Execute Product Test Perform Fixes Create Test Closure Memo
35
Execute the Test: Inputs and Deliverables
The deliverables are documented actual results, fixed defects, and a fully executed Test Plan.
36
18
Prerequisites to Successful Test Execution

Planning and preparation are complete Inspections have occurred Environment is well established and ready Test team is trained Migration procedures exist Test tools are used
37
Execute the Test

Steps in Test Execution Overview 1. Execute scripts 2. Verify results 3. Document results and discrepancies
Execute the Test Scripts
Compare the Actual Results to the Expected Results
Identify and Resolve Any Discrepancies
38
19
Test Execution Tasks

1. 2. 3. 4. Execute test scripts. Record potential defects as SIRs. Work with the application team to resolve identified defects. Participate in the release control process to ensure that solutions meet business requirements. 5. Validate application fixes. 6. Inform the test lead of any issues that may affect the schedule, budget, or quality of the application or testing process.
39
Qualities of a Great Tester

A great tester should:
Catch the majority of application defects. Communicate defects clearly to the Fix-it team.
Most great testers share the following traits:

Good communication skills Detail orientation Ability to follow directions Strong understanding of testing concepts Ability to innovate
How would you rate yourself?

40
20
Finding Application Defects

1. Review the system functionality and test approach. 2. Execute script step compare actual result to expected result.
If there is a discrepancy:
Ensure you have executed the step correctly. Ensure you have entered the correct data. Ensure the data is correct, if possible. Review relevant business rules (as appropriate).
3. Document confirmed discrepancies as SIRs.

Include all relevant test data and business requirements information.
41
System Investigation Request (SIR)

Key form of communication between the Tester and Fix-it team Documented record of defects, errors, and faults discovered in an application
Includes impact and resolution (documented by Fix-It Team)
SIR Tool will vary from project to project
42
21
Guidelines to Produce an Effective SIR

Provides a clear, detailed description of the identified defect, including:
A description of when the problem occurred A description of the actions the tester took to encounter the defect Any additional information necessary to pinpoint the problem
Provides an estimated priority level Clearly describes the expected outcome Includes complete documentation of the resolution and object impacts (upon resolution) Includes accurate information Updated on a timely basis
43
SIR Priority Levels

Critical: Defect results in Fail-Stop
Must be fixed before next Pass
High: Defect results in Fail-Stop or Fail-Continue

Must be fixed before entering the next Stage
Medium: Defect results in Fail-Continue

Must be fixed before entering user acceptance Test Stage
Low: Defect results in Fail-Continue

Must be fixed before go live or approved for deferral
44
22
Executing a Product Test - Key Considerations

Things to think about when executing a product test: Refine the test plans after running the test scripts Set up common test data for testing multiple applications Budget extra time to resolve defects Conduct thorough regression test Leverage Accenture Delivery Tools to perform and execute the product test
45

46
23
Module 4: Agenda
Assembly Test Overview Plan the Test Prepare the Test Execute the Test Activity 3 Checkpoint
47
Activity: Execute the Test Script

Activity Overview Run your test scripts against the provided online application to identify bugs. Log bugs in the defect tracking tool. Participant Instructions Test scripts Online application Defect tracking log 1 hour 45 minutes
48
Inputs
Timing
24
Module 4: Agenda
Assembly Test Overview Plan the Test Prepare the Test Execute the Test
Activity 3
Checkpoint
49
Checkpoint
Checkpoint Quiz Round 2!
Checkpoint
25
Module 5: School Closing

Module 5 - School Closing
Looking Back
After completing this course, you should now be able to: Identify and describe the major testing tasks within ADM Describe the role and responsibilities of a tester Articulate how a developer contributes to a successful test execution Understand and apply the V-Model in application testing Read, understand, and correctly interpret functional specifications, requirements, and other test planning documentation, and state the requirements for the creation of each deliverable Generate effective TCERs and Test Scripts using the appropriate functional specifications, requirements, and test planning documentation Successfully execute Assembly and Product tests based on the appropriate test planning documentation Properly report defects found during test execution
School Recap
Through presentations, discussions, and activities, this course has covered the following topics:
Accenture Delivery Methods V-Model Quality and Test Management ADT Tools The Assembly Test The Product Test Creating Test Conditions and Expected Results Creating and Executing Tests Scripts
Reflections
What new insights, strategies, and skills have you gained from this school? How do you think you will use these new skills and insights on your current or next project?
Keep Moving Forward

Engage locally and globally Build your networkstay connected and build upon the relationships you developed this week Continue to build your skills Become an expert, but share your existing knowledge nowcontributing what you can will help you become a well-rounded programmer
Additional Resources
Seek assistance when you need it:
Use https://experts.accenture.com/ Join communities of practice Use the methodology! Visit https://kx.accenture.com/Offerings/Pages/ADM.aspx
The End of the Road

You will receive a brief school evaluation in your mailbox soon. Please complete and return this evaluation in a timely manner. Your input is very important to us and will help us to make this school better for future participants. Do you have any final questions/ comments? Thanks for participating in this school!
Activities
Module 2: ADM Activity
Module 2: Testing in Accenture ADM Activity: Participant Instructions
ADM Activity Participant Instructions

Estimated Completion Time: 15 minutes
Overview
In this activity you will use your knowledge of Accenture Methods to answer scenario-based questions.
Instructions
With your partner, answer the following questions. You may use the ADM website as a resource to assist you in answering your questions. Scenario 1: You have been assigned on a project, and have been asked to prepare a product test for the client application. Even though this is your first time working with a product test, your Team Lead is overloaded with work and doesnt have time to train you. So, you go to ADM to find out the information you need. 1. Where in ADM can you find out about preparing a product test?
2. What are all the things you need to do to completely prepare for a product test?
3. What are the inputs that need to be complete in order for you to begin to prepare for a product test?
4. One part of this task involves creating the test script for a product test. Youve never created a product test script before. What do you do?
Z16327 2007 Accenture. All Rights Reserved.
Mod2_ADMActivity_ParticipantInstructions.doc
Module 2: Testing in Accenture ADM Activity: Participant Instructions
Scenario 2: You just got back from a planned extended vacation. When you return from your vacation, you are assigned to a new project, to fill in on a short-term basis. The resource you are filling in for left unexpectedly due to a serious illness; as this was an unplanned leave, the resource was not able to hand off his/her assignments appropriately. Youve been given a Test Approach and a Requirements document, and have been told that you need to complete the Test Plan for the assembly test for the client application. 1. What do you do first?
2. Where do you go to find out what you need to do to complete the test plan?
3. What other documents do you need to complete in order to complete the test plan?
Mod2_ADMActivity_ParticipantInstructions.doc
Module 2: V-Model Activity
Module 2: Testing in Accenture V-Model Activity: Participant Instructions
V-Model Tests Activity Participant Instructions

Overview
In this activity you will research one of the types of testing and presenting your findings to the class.
Instructions
1. Faculty will break the class up into six different groups 2. Each group will be assigned one of the following tests: a. Component b. Assembly c. Performance d. Production e. User Acceptance f. Operational Readiness 3. For your assigned test, research the following information: a. What does your test do, and what is its purpose? b. Who typically performs your test? c. When does your test typically occur? d. What are the major inputs and deliverables for your test? e. What are some best practices? 4. Document your answers on a flipchart, and prepare to teach the class about your test
Mod2_VModelActivity_ParticipantInstructions.doc
Module 2: ADT Tools Activity
Module 2: Testing in Accenture ADT Tools Activity: Participant Instructions
ADT Tools Activity Participant Instructions

Overview
In this activity you will answer questions about one of the ADT Tools.
Instructions
1. You will be separated into 5 groups 2. Each group will be assigned one of the tools below: a. Rational RequisitePro b. Rational Manual Tester c. Rational Functional Tester d. Rational Performance Tester e. ClearQuest Test Management 3. As a group, spend 5 minutes discussing the answers to the following questions for your tool: a. In which phase would your tool be used? b. How do you think your tool would be used? c. What do you think the benefits are for using your tool? 4. Each group will share their responses with the class
Mod2_ADTToolsActivity_ParticipantInstructions.doc
Activity 1: Create the TCER
Module 3: Assembly Test Activity 1 Participant Instructions
Activity 1 - Create the TCER

Activity Overview
This activity is designed to teach you how to create test conditions and expected results for an assembly test. This activity is broken up into three parts: Plan to spend approx. 1 hour 45 minutes to complete this 3-part activity.
Activity 1 Part 1
1. Review the Test Scenarios document and the Requirements document. 2. Reflect on each business requirement and consider the following: a. What is the business requirement for and what does it accomplish? b. What would be the criteria used to validate the business requirement? 3. Using the TCER template, create a test condition and an expected result for each business requirement. Fill out each column of the TCER. 4. Trace each Test Condition back to a specific requirement. 5. Break into groups and perform a peer review of your work. a. During your peer review, you should be look for and discuss the following: i. What Functional Requirement is directly related to this Test Condition and Expected Result? ii. Are there other Test Conditions related to this Functional Requirement? If so, how does the Test Scenario differ? iii. Is the level of detail consistent across all Test Conditions and Expected Results? iv. Is a high degree of detail provided, both in the condition and the expected result? v. Does each Test Condition and Expected Result closely match a corresponding Test Scenario and Business Requirement? 6. Prepare to share your thoughts with the class.
Tip: Key criteria when writing TCERs. A high level TCER does not have specific functional or technical specifications (usually derived from a high level business requirement document).
Activity1_ParticipantInstructions.doc
Activity 1 Part 2
1. Review the Test Scenarios document and the UI Design document. 2. Reflect on each screen within the UI Design document consider the following: a. What is the purpose of the screen? What are you supposed to be able to accomplish? b. What would be the criteria used to validate that the screen functions properly? 3. Using the TCER template, create a test condition and an expected result for each business requirement. Fill out each column of the TCER. 4. Trace each Test Condition back to a specific requirement. 5. Break into groups and perform a peer review of your work. a. During your peer review, you should be look for and discuss the following: i. What Functional Requirement is directly related to this Test Condition and Expected Result? ii. Are there other Test Conditions related to this Functional Requirement? If so, how does the Test Scenario differ? iii. Is the level of detail consistent across all Test Conditions and Expected Results? iv. Is a high degree of detail provided, both in the condition and the expected result? v. Does each Test Condition and Expected Result closely match a corresponding Test Scenario and Business Requirement? 6. Prepare to share your thoughts with the class.
Activity 1 Part 3
1. Review the Test Scenarios document and the Use Case documents. 2. Reflect on each use case and consider the following: a. What is the use case for and what does it accomplish? b. What would be the criteria used to validate the use case? 3. Using the TCER template, create a test condition and an expected result for each business requirement. Fill out each column of the TCER. 4. Trace each Test Condition back to a specific requirement. 5. Break into groups and perform a peer review of your work. a. During your peer review, you should be look for and discuss the following: i. What Functional Requirement is directly related to this Test Condition and Expected Result? ii. Are there other Test Conditions related to this Functional Requirement? If so, how does the Test Scenario differ? iii. Is the level of detail consistent across all Test Conditions and Expected Results? iv. Is a high degree of detail provided, both in the condition and the expected result? v. Does each Test Condition and Expected Result closely match a corresponding Test Scenario and Business Requirement? 6. Prepare to share your thoughts with the class.
Module 3: Assembly Test Activity 1: TCER Template

Expected Result Release Requirement ID
Test Condition ID 0-1
Test Condition
Login with user
User succesfully logs in as a user where user's welcome screen is correctly displayed
R0
Copyright 2007 Accenture. All Rights Reserved
Activity1_TCERTemplate.xls
Module 3: Assembly Test Activity 1: Test Scenarios Input
Test Scenario Document Assembly Test: Workflow Management Application
Scenario ID Sub-Scenario ID
Description Test login to WMA to launch the Welcome page Test online help Test Create a work item from a template feature
Expected Result
Use Case/UI Design End User Welcome Page (UI Design)
Bus. Requirement ID
Pass 1 Status
Pass 2 Status
Pass 3 Status
1 2
1 2
R0
3.1 Test for keyword search to find specific work items
R1
3.2 From End User Welcome page, open Outstanding / Assigned work queue items Complete a work item with Freeform comments Change Status of Work Item Navigate away from WMA whilst working on awork item Test work items for Team Lead_Manager
R2
3 3 3 3
3.3 3.4 3.5 3.6
End User Launch Page (UI Design)
R4
4 4 4 5 5
4 4.1 4.2 5 5.1 Test Create a work item from a template feature Test Assign Work item Test Maintain Schedule Test Team Calendar Page under Maintain Schedule
2007 Accenture. All Rights Reserved.
Activity1_Input_Scenarios.xls
Module 3 Assembly Test Activity 1 Requirements Input
WMA Business Requirements

Author: Version: Issue Date: Last Saved On: [Author Name] 0.0 7/17/2007 8:48:00 AM
Application Testing
Module 3 Assembly Test Activity 1 Requirements Input
1 Business Requirements
1.1 Features and Functionalities approved for development
WMA Release 2 of the Workflow Management Application Project will include the analysis, design, development, testing and deployment of the following new features/functionalities: R0. Ability to log into the WMA application welcome screen R1. Ability for end user to create new work items using templates R2. Ability for users to conduct a keyword search to find specific work items R3. Ability for the end users to pull work out of a work queue based on skill set R4. Ability for user to open Outstanding / Assigned work queue items on the welcome screen R5. Ability to indicate to an end user that a work item in a queue is being worked by someone else R6. Ability to search pending work and open in view only mode R7. Ability to report statistics for Key Operating Indicators R8. Ability for administrator/manager to setup security levels R9. Ability to allow administrator/manager to update multiple work items concurrently R10. Ability for administrator/manager to view work queue statistics in real time R11. Ability for manager to sort work in queue to show work item prioritization R12. Ability for administrator/manager to add/update user skill sets R13. Ability for administrator/manager to add/maintain users and user profile information
Activity1.1_Input_Requirements.doc
Application Testing School End User Welcome Page

Description: Suggested welcome page for all users. - The logo will not act as a link to the Accenture homepage. While this link exists in other web apps on the Intranet, it is not appropriate for the WMA. - The only link off of the Welcome page is to the Assigned Work Queue. - Log off allows the End User, Team Lead, Team Manager and Billing Manager to properly close a session and disconnect the WMA from the server. Question: What would need to be done to add messages to the Welcome screen? For example, urgent updates, news, changes, etc. Ideally, these messages should be easily changed on a daily basis.
Activity 1 - UI Design Input
Logo
Welcome
Get Context Sensitive Help
Log off
Workflow Management Application

> Help Help topic 1 Help topic 2 Help topic 3 Help topic 4
Scheduled Work Queue (8)
Welcome to Workflow Management Application, John, Doe! Your last visit to WMA was 15-Aug-2004 8:05 am
August 20, 2004 @2004 Accenture Business Services for Utilities. All Rights Reserved. Confidential and Proprietary Information.
8/9/2007 4:45:49 PM
Activity 1 - UI Design Input
End User Launch Page

Description: - Table displays all items assigned to End User. - The number beside Assigned Work Queue indicates All items that belong to the End User. - Other Work is an expandable list containing options of Inbound Phone Call, Meeting, Specific Special Project and Other. - When Help is clicked a menu will pop up showing all help topics. - When the Work Item ID Number is clicked, user will be directed to the Work Item Detail screen. - Each row is colored according to business rules which determine the urgency level of that Work Item. - When the User checks the Get Context Sensitive Help checkbox, the mouse cursor will become a ?. When the User hovers the mouse over a field on the screen a text box will pop up and display the help content pertaining to that field. - The User must click on the Help links in order to open the Help knowledge base. Help opens in a separate browser window. Assumptions: - The Work Items are sorted by colour & then due date & then due time - Other is not an option that can be selected under Other Work. It is being used to demonstrate the ability to add additional Other Work selections to the list. Questions:
Logo
Welcome > Work Items List All Status
Get Context Sensitive Help
Log off
Workflow Management Application

> Help Help topic 1 Help topic 2 Help topic 3 Help topic 4
Work Items List - All Status

- Scheduled Work Queue (8) - Other Work Inbound Phone Call Meeting Special Specific Project Other ID 10001 10456 19763 20944 52512 86570 55422 99731 Business Function Business Function 1 Business Function 4 Business Function 6 Business Function 10 Business Function 3 Business Function 30 Business Function 5 Business Function 21 Status Assigned Assigned Pending Investigation Assigned Assigned Pending Investigation Assigned Assigned Due Date 10-AUG-2004 11-AUG-2004 20-AUG-2004 23-AUG-2004 11-SEP-2004 15-SEP-2004 20-OCT-2004 22-OCT-2004 Due Time 13:00 08:00 09:15 16:35 16:00 17:00 10:00 08:15
August 20, 2004 @2004 Accenture Business Services for Utilities. All Rights Reserved. Confidential and Proprietary Information.
8/9/2007 4:45:49 PM
Module 3: Assembly Test Activity 1.3 End User Use Case Input
1. Name
End User Experience
2. Description
The steps an end user experiences from logging into WMA until completing a work item in WMA.
3. Related Requirements
The following is a list of the requirement items and their IDs (from the Requirements document) that this use case is associated with:
Requirement ID R3.1 R3.6 R5.3 R5.4 R5.5 R5.15 R6.9 R10.2 R10.4 R10.5 R10.8 R10.20 R12.1 R12.2
Requirement Description Ability to display levels of urgency for trouble areas of work. Ability to record an audit trail. Ability to timestamp/userstamp a work item when it is first addressed by a user. Ability to timestamp/userstamp a work item each time the status of the work item is updated by the assigned user. Ability to timestamp/userstamp all work items at completion. Ability to track users time in day adequately even when not actively working in Workflow tool. Ability to track non-business function time in tool. Ability for user to add user comments on records, if applicable. Ability for user to view assigned work queue on login. Ability for user to change status of work item. Ability for status of work item to change automatically when the work item is first opened by an end user (Assigned -> Being Worked). Ability to copy & paste data between tool and legacy applications. Ability to require certain fields in the user interface. Ability to automatically validate population of required fields.
4. Actors
The following actors interact with this use case: Actor End User WMA Tool Legacy System Actor Description End User refers to the Clerks and CSRs who perform backoffice (nonphone) work. WMA is the Workflow Management Application being built to distribute, assign, track, and report backoffice work. Legacy system refers to the systems that produce backoffice exceptions and/or are used to complete backoffice work. Examples of legacy systems include CIS, ICSS, Energy, OWMS, and CDF.
Activity1.3_Input_EndUserUseCase.doc
5. Base Flow
The following base/main flow represents the use cases default or normal behavior when actors interact with this use case:
Step 1 2
Name WMA Tool Opens Select Assigned Work Queue Display Assigned Work Queue
Actor WMA Tool End User
Triggers User Login WMA Tool opened
Inputs Successful Login Click hyperlink to view assigned work queue
Description WMA tool opens to Welcome Page where end user has several options to select/click. End user clicks hyperlink to view his/her assigned work queue.
Outputs WMA Tool opened Assigned Work Queue selected Assigned Work queue is displayed and automatically ordered
WMA Tool
Assigned Work Queue selected
View Assigned Work Queue Select Work item Audit Trail
End User
4 5
End User WMA Tool
Assigned work queue is displayed and automatically ordered Assigned Work queue is displayed Work item selected
WMA displays work items in assigned work queue ordered based on color (yellow, red, then green), due date (the ones due the soonest on top) and due time.. (See Urgency Assessment topic in ABS_WMA Online Process Helpv7.0SL_NC-M.doc doc for details on when work items turn yellow) End user views level of urgency by color, work item ID (randomly generated #), business function, status, due date and due time. Assigned Work queue is displayed Work item selected. End user clicks/selects Work Item ID hyperlink of 1st work item in assigned work queue. WMA records entry in audit trail with time and user information. (See Items to Add to TrainingNov22.xls spreadsheet, rows #22 and #26 and the WMA_pagespecification document for details on audit trail. Also see Status Sequencing by Role.vsd for details on status changes for every possible scenario) WMA changes the status of the work item to Being Worked (means end user is currently working on work item in workflow). WMA records entry in audit trail with time of status change and user information. WMA displays details of work item in Work Item Details page such as account #, customer
Work Item selected Record in audit trail with user name, date/time, business function, etc.
Status Change to Being Worked Audit Trail Work item Details
WMA tool
Work item selected for first time by end user. Status change Work item Selected
Work item Selected
Status changed to Being Worked Record inserted into audit trail. Details of Work item displayed
7 8
WMA Tool WMA tool
New status, user info, date/time Work item Selected
name, error reason, etc. (different info for each work item...see Work Item Details wireframes and page specifications). The title of the Work Item Details page is Work Item Detail (Work Item ID#) Status. If the status is Pending Investigation, Pending Investigation is in the title and also defaults as the status in the Status dropdown box. If the status is Assigned, the work item status changes to Being Worked when the end user opens the work item, so Being Worked is in the title, but the Status dropdown menu defaults to blank in this case. End user reviews detailed information in work item. Highlight specific details of work item and copy Selected work item in WMA End user clicks on Legacy System icon Click on field in main retrieval window of Legacy system Enter or paste info into legacy system to retrieve relevant data Work performed in legacy system Comments field is optional in this scenario. End user highlights the account # or customer name or address within the work item and selects copy. End user selects legacy application icon on workstation to open the application. Legacy system opens to main retrieval window End user clicks on field within retrieval window of the legacy application and pastes the account # or customer name or address that was copied from WMA. Legacy system retrieves relevant data based on retrieval info that was either pasted or keyed in by the end user. End user completes work for the work item in the legacy application. End user toggles from the legacy application back to WMA. If needed, end user adds comments to the work item in WMA. (See the WMA_pagespecifications document for details on freeform comment field specs) After the work item is completed in the legacy system the end user toggles back to WMA and Info pasted (left navigation menu disabled...use r must Save and Close work item to exit page)
9 10
View Work item Details Copy Data
End User End User
Details of work item displayed
Info copied
11 12
Launch Legacy System Legacy System Opens Paste Data
End User Legacy System End User
13
14
Legacy System Retrieval
Legacy System
Information retrieved
15
16
Complete Work in Legacy System Add comments to WMA
End User
End User
Work completed in legacy system
Work completed in legacy system Comments added.
17
Status Change to Complete
End User
Work completed in legacy
Change status to complete
Status Change

system
changes the status of the work item to Complete (means no further action is required-work item is completed). -See Status Dropdown Revised.xls for list of statuses available for end users in dropdown menu. -See Online Help Field-Level Content Nov12.xls row #93 for status definitions) WMA records entry in audit trail with time of status change and user information. End user clicks Save and Close button to close the work item once they have changed the status to Complete. Workflow validates that all required fields are populated. If a required field is missing data, text appears advising user to populate required fields. WMA reverts back to assigned work queue once the end user closes the work item they had opened. Completed work item disappears from assigned work queue.
18 19
Audit Trail Close Work item
WMA Tool End User
Status Change Status Changed to Complete
New status, user info, date/time
Record inserted into audit trail. Work item closed in WMA tool
20
Assigned Work Queue Displayed
WMA tool
Work item closed
6. Alternative Flows
The following flows represent optional or exceptional behaviors of the use case:
Alternative Not first time work item opened by end user Work item cant be completed immediately
Alternative Description The end user views the assigned work queue and decides which work item to open. They may select a work item that they have never opened before, which is the scenario described above WMA automatically changes the status of the work item from assigned to being worked. However, the end user may select a work item that has been opened before (in this case the work item is in Pending Investigation status). WMA will not perform an automatic status change if the work item has been opened before. The scenario above describes a situation where the end user is able to complete the work item in the legacy system. The end user may look at the info in the legacy system and determine more work is needed at a later time before the work item can be closed. Instead of changing the status of the work item to Completed the end user would select Pending Investigation from the Status dropdown menu on the Work Item Details page. The Standard Comments field is enabled and required. Select the desired standard comment from the dropdown menu (See Online Help Field-Level Content Nov12.xls row #96 for list of standard comments in dropdown menu). After selecting a Standard Comment, a text box appears instructing the end user to enter specific information into the Freeform Comments field. The Freeform Comment field is required. Enter details about why the work item is still pending rather than being completed. (See Online Help Field-Level Content Nov12.xls row #98 for list of what to enter in Freeform comments for each standard comment). Click Save and Close button. An audit trail is recorded to reflect the date/time and user information with the status
Work item needs to be Escalated to a team lead
Work item was Mis-Routed
Work Item requires completion by another team that does not have access to Workflow
End user needs to perform Other Work
change. After clicking the Save and Close button, Workflow reverts back to the assigned work queue. The work item remains in the end users assigned work queue in Pending Investigation status. The scenario above describes a situation where the end user is able to complete the work item in the legacy system. The end user may look at the info in the legacy system and determine the work item needs to be reviewed by a team lead (it needs to be Escalated). Instead of changing the status of the work item to Completed the end user would change the status of the work item to Escalated. (See Online Help Field-Level Content Nov12.xls row #93 for status definitions) The Freeform Comments field is required so the end user can explain why they believe the work requires escalation. (See Online Help Field-Level Content Nov12.xls row #98 for list of what to enter in Freeform comments for each standard comment). Click Save and Close button. An audit trail is recorded to reflect the date/time and user information with the status change. After clicking the Save and Close button, Workflow changes the work item status to Escalated for the team lead/team manager to address and Workflow reverts back to the assigned work queue. NOTE: please do not describe work items as being re-routed to the team lead/team manager queue, as they can see all work items in all statuses. The work item status is just changed, which indicates to the team lead/team manager that his/her attention is required. The scenario above describes a situation where the end user views the details of the work item and then goes to the legacy application to investigate and complete the work item. When the end user views the work item in WMA they may determine the work item was incorrectly routed. In other words, the end user does not believe he/she has the appropriate skill-set to complete the work item. The end user changes the status of the work item to Mis-Routed. The Freeform comments field is required so the end user can explain why he/she believes he/she doesnt have the appropriate skill-set for the work item. (See Online Help Field-Level Content Nov12.xls row #98 for list of what to enter in Freeform comments for each standard comment). Click Save and Close button. An audit trail is recorded to reflect the date/time and user information with the status change. After clicking the Save and Close button, Workflow changes the work item status to Mis-Routed for the team lead/team manager to address and Workflow reverts back to the assigned work queue. The Escalated work item disappears from the assigned work queue.. NOTE: please do not describe work items as being re-routed to the team lead/team manager queue, as they can see all work items in all statuses. The work item status is just changed, which indicates to the team lead/team manager that his/her attention is required. The scenario above describes a situation where the end user views the details of the work item and then goes to the legacy application to investigate and complete the work item. When the end user views the work item in WMA they may determine the work item must be completed by another team. The end user selects Completion-Other Team from the Status dropdown menu. The Team field becomes enabled for the end users to select which team will complete the work item. (See the WMA_pagespecifications document for a list of teams in dropdown menu) The Freeform Comments field is required so the end user can explain the work done, work remaining and reason for sending work to another team. After clicking the Save and Close button, an audit trail is recorded to reflect the date/time and user information with the status change. The end user must manually give the work to the appropriate team outside of workflow to ensure the work gets completed. After clicking the Save and Close button, the work item disappears from the assigned work queue. The end user views his/her assigned work queue. There may be times when the end user has to do other work (exception work) such as meetings, training, special projects, inbound phone calls, etc. From the assigned work queue the end user will click on the desired Other Work hyperlink (see Other Work Exceptions_Maintain Schedule EventsNov16.xls spreadsheet for list of Other Work types). WMA then displays the Other Work page. The end user clicks Start button. At this time WMA records an audit trail with time and user information. When the end user is done with the other work the 5 Activity1.3_Input_EndUserUseCase.doc
Illegally exiting from Worfklow 2 People accessing the same work item
end user enters required comments (see Online Help Field-Level Content Nov12.xls spreadsheet (row #104: Comments box) for specific comments required for each type of Other Work). The end user clicks Stop button in WMA. WMA again records an audit trail with time and user information. WMA then automatically reverts to the assigned work queue. If the user clicks Stop button before entering comments, a validation message will appear, advising the user to enter comments (see WMA_pagespecifications for details on validation message). NOTE: If end user illegally exits from the Other Work screen, audit trail records time of exit, but no comments. This indicates to Team Lead/Mgr that page was illegally exited by the end user. Power Outage: User must re-log into Windows in order to re-access Workflow. See WMA Wireframes Iteration 1 document Warnings tab for details on effects of illegally exiting Workflow pages. See Item #37 in the Items to Add to Training document.
NOTES: See Online Help Field-Level Content Nov12.xls spreadsheet and page specifications for specific field definitions See Business FunctionsNov23.xls spreadsheet for list of business functions for Release 1. See ABS_WMA Online Process Helpv7.0SL_NC-M.doc document for specific detailed steps. See WMA wireframes Iteration 1 - Work Item Details - 19-Nov-2004 Update.vsd and WMA_pagespecification- Work Item Detailsupdatednov19.doc for details on system-generated data displayed at the top of each Work Item Details page (it is different for each business function).
7. Additional Information
The following section outlines additional information relevant to the use case.
If the workstation was to freeze at any point while in workflow and the end user is forced to reboot, the end user would log back into workflow and go back to where the end user had left off
Module 3: Assembly Test Activity 1.3 Launch WMA Use Case Input
1. Name
Launch of WMA
2. Description
The steps taken when opening the WMA tool.
3. Related Requirements
The following is a list of the requirement items and their IDs (from the Requirements document) that this use case is associated with: Requirement ID R4.1 R0 R8 Requirement Description Ability to setup security levels. Ability to login to the application with a user id. Ability for user to view assigned work queue on login.
4. Actors
The following actors interact with this use case: Actor End User Team Lead/Mgr WMA Tool Actor Description End User refers to the Clerks and CSRs who perform backoffice (nonphone) work. Team Lead/Mgr refers to the Team Leads and Team Managers who are responsible for the workload and end users that perform backoffice (non-phone) work. WMA is the Workflow Management Application being built to distribute, assign, track, and report backoffice work.
5. Base Flow
The following base/main flow represents the use cases default or normal behavior when actors interact with this use case:
Step 1
Name Click WMA icon
Actor End User
Triggers
Inputs
Description End User doubleclicks WMA icon on desktop. Can also: -right click on WMA icon on desktop and click Open.
Outputs
Access Workstation Login
WMA Tool
Double-Click on WMA icon
WMA tool accesses the workstation login
Recognized /Authenticate d user
Activity1.3_Input_LaunchWMAUseCase.doc
Module 3: Assembly Test Activity 1.3 Launch WMA Use Case Input
to recognize/ authenticate the end user. WMA tool opens. User id/security level WMA tool opens to the Welcome Page, displaying a personalized welcome statement with the end users name and the date/time he/she last visited Workflow.
3 4
WMA tool opens Display Main View
WMA Tool WMA Tool
Recognized/Authenticated user WMA tool opened
WMA tool opened
6. Alternative Flows
The following flows represent optional or exceptional behaviors of the use case:
Alternative Team Lead/Mgr opens WMA WMA tool accesses Workstation login but doesnt recognize user
Accessing WMA with multiple users End User Relaunch of WMA after previous session was exited illegally
Alternative Description When the Team Lead/Mgr opens WMA (using 1 of the methods indicated in step 1 above), WMA accesses workstation login information to recognize/authenticate Team Lead/Mgr. After recognized/authenticated, WMA tool opens to the Welcome Page displaying a personalized welcome statement with the Team Leads/Mgrs name and the date/time he/she last visited Workflow. A. When the user (could be end user/team lead/mgr) opens WMA, WMA accesses workstation login information to recognize/authenticate the user. If the user isnt recognized/authenticated, a login window appears prompting the user to enter his/her user id and password. The user enters his/her user id and password. When WMA recognizes/authenticates the entered user id and password, WMA is opened and the personalized Welcome pages are displayed with the appropriate left navigation menu based on security level. B. When the user (could be end user/team lead/mgr) opens WMA, WMA accesses workstation login information to recognize/authenticate the user. If the user isnt recognized/authenticated, a login window appears prompting the user to enter his/her user id and password. The user enters his/her user id and password. If WMA doesnt recognize/authenticate the entered user id and password, WMA displays a Login Failed message. The user has the option of re-entering the user id and password or communicating the issue to WMA Support team. If user A (could be end user/team lead/mgr) is logged into WMA system on the workstation and another user B (could be end user/team lead/mgr) attempts to log into WMA on the same workstation, a window will be displayed asking if user B would like to navigate away from the page to re-login into the WMA system as the new user. If an End User illegally exited (closed browser) a work item with Being Worked status to end their last WMA session, the next time the End User opens the WMA it will launch the Welcome Page. If an End User illegally exited (closed browser) a work item with a status other than Being Worked to end their last WMA session, the next time the End User opens the WMA it will launch the Welcome Page.
Activity1.3_Input_LaunchWMAUseCase.doc
Activity 2: Create the Test Script
Activity 2 - Create the Test Script

Overview
This activity is designed to teach you how to create test scripts for application testing. The key for successful test scripts is to write one script for each condition. Using a case application (for training purposes), you will examine the TCER and locate the condition to be tested. Then, you write one script for each condition. Next, you will do a peer review of your work and debrief with the entire class. Plan to spend approx. 1 hour to complete this activity.
Instructions
NOTE: You will need to use the case application to complete this activity. 1. Refine the test conditions and expected results to make sure they provide a high level of detail. NOTE: There are many different ways to logically order scripts; for example, they might be sequenced to represent one set path of functionality through a system. Refining and ordering TCERs can be an iterative process. 2. Order the test condition and expected results into a logical sequence such that a test pass can be executed in a natural manner. This order is typically documented in the Test Cycles. 3. Populate the test script template with the test scripts. 4. Review the created test script and make adjustments as necessary. 5. Peer Review your work following the instructions below.
Peer Review
1. You will be broken up into small groups. Trade your test scripts with someone in your group. 2. Look for the following: Were the test scripts written at the right level of detail? Did the test scripts test each Test Scenario? Could you execute another participants script? How accurately do you think you can execute the other participants test script? Would you have to vary from the written instructions at all? Is the Requirements Traceability Matrix updated correctly detailing each test condition that is being tested in this test script? Does the test script have any vague or insufficient details to make it unusable? Does each run consider the positioning of where you are at in the application so it flows correctly into subsequent runs/cycles? Are data requirements complete and correct? Does the test script cover all entry and exit points as per the UI design document(s) relating to the purpose of the test script?
1 Activity2_ParticipantInstructions.doc
Are minimum and maximum characters tested in the test script for data entry fields? Are all error conditions tested in the test script, including verification of the error message format and error indicator(s) presence with location of the indicators? Does the test script contain any redundant unnecessary testing?
3. Discuss your findings individually with your group. 4. Be prepared to participant in a class debrief discussion.
Tips: Refer to the Test Script template as needed.
The Step Number field identifies each step to be executed. When a defect is identified, the corresponding Step Number should be documented in the SIR. The Action/Description field provides detailed directions as to HOW to execute each step, and should be based off of the existing Test Conditions. Each of these steps should begin with an action verb, and should only describe one action at a time. The Input Data field lists each field for which the tester should input data to complete the Action/Description. Note that this field only lists the type of data to be entered (hence the XX format); the data itself is housed in a separate document. The Expected Result field should be closely aligned with the existing Test Conditions and Expected Results. It should explicitly describe the result testers should see upon completing the action for that step.
Keep in mind what good test scripts look like will help you when you set out to create them. Provide explicit, step-by-step instructions Are highly detailed Are reusable Cover all Test Conditions and Expected Results Reference necessary input data Follow a standard format
Module 3: Assembly Test Activity 2 Test Script Template
Test Script ID Requirement ID Condition ID Purpose Input Expected Output Environmental Need Dependency Procedure Test Script Execution
tsTEO0-1 R0 0-1 Verify that the user can successfully log into the WMA application system with the user type of End User N/A User Name/Password (Simulated with End User 01 Icon on desktop) End User 01 welcome screen is correctly displayed
Name: Steps
Purpose: Result
Pass1 Pass2
1. Ensure Virtual Image is correctly loaded and windows server desktop is correctly displayed. 2. Ensure that the desktop displays at least the following WMA user icons: End User 01, End User 02, End User 03, End User 04, Team Manager 01 3. On the desktop, double click on the End User 01 Icon to log into the WMA system as End User 01. 4. Ensure that Web browser opens up and redirects the user to the End User 01 Welcome screen. PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification.
Activity 2 Test Script Template
tsTEO0-2
N/A
Name: Steps
Purpose: Result
Pass1 Pass2
PASS 1 Passed/Failed PASS 2 Passed/Failed
If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification.
tsTEO0-3
Name: Steps
Purpose: Result
Pass1 Pass2
Test Script ID Requirement ID Condition ID Purpose Input Expected Output Dependency Procedure Test Script Execution
tsTEO0-4
Name: Steps
Purpose: Result
Pass1 Pass2
Module 3: Assembly Test Activity 2 - TCER Input
TCER - Test Conditions and Expected Results

Test Condition ID Test Condition Expected Result Release Requirement ID Pass 1 Status (P/F) Pass 2 Status (P/F)
User Login
0-1 0-2 Login with End User Login with Team Manager User succesfully logs in as End User 1 where End User welcome screen is correctly displayed User succesfully logs in as team manager where team manager welcome screen is correctly displayed 2 2 R0 R0
Create Work Item

1-1 Create a "Customer Driven Payment Enquiry" work item from a template feature with End User01 User successfully creates a new work item using a template 2 feature as End User01 System successfully returns no work item results based on the User's invalid search criteria 2 R1
Work Item Search

2-1 User executes a keyword search using invalid search criteria to find specific work items R2
Copyright 2007 Accenture. All Rights Reserved.
Activity2_Input_TCER.xls
Activity 3: Execute the Test
Module 4: Product Test Activity 3: Participant Instructions
Activity 3 Execute Product Test Scripts

Estimated Completion Time: 1 hour 45 minutes
Overview
A test script details the exact steps that a tester must follow to complete testing (i.e., to test all the conditions), and each usually describes a test cycle. Test scripts also include the data that is used for testing. Each step of a test script has an associated test condition that can be traced back to a business requirement. In this activity, you will execute existing test scripts. You will find a variety of real-life situations in executing these scripts and have an opportunity to discuss and debrief the experience.
Instructions
Step One: Execute the Test Script 1. Execute the first test script tsTEO01TC01, by following the script in the application. 2. As you execute the test script, identify potential defects. 3. Compare the actual result to the expected result. If there is a discrepancy: Ensure you have executed the step correctly. Ensure you have entered the correct data. Ensure the data is correct, if possible. Review relevant business rules (as appropriate). 4. Document confirmed discrepancies as SIRs. Include all relevant test data and business requirements information. Ideally, SIRs should include clear and detailed description of the defect, priority level (e.g., High, Medium and Low), and the exact steps to replicate the issue.
5. Ensure each defect is logged and tracked individually. Documentation of defects during testing provides a place to identify downstream impacts of the defect on other teams.
6. Make the description of the issues/SIRs specific enough so that the fixing team does not need real-time interaction with the testing team to understand the content and the context of the issues/SIRs. 7. Repeat steps 1-6 for the next test script: tsTEO01TC02. 8. Stop after executing the second test script and wait for the class debrief.
Activity3_ ParticipantInstructions.doc
Step Two: Class Debrief 1. Be prepared to participate in a class discussion about the first two test scripts in this activity. Step Three: Execute the Remaining Test Scripts 1. Go back up to Step One: Execute the Test Script and repeat steps 1-6 for the remaining test scripts, executing one script at a time. Execute the remaining scripts in the following order: a) Execute Test tsTEO01TC03 b) Execute Test tsTEO01TC04 c) Execute Test tsTEO01TC05 d) Execute Test tsTEO01TC06 e) Execute Test tsTEO01TC07 Step Four: Peer Review Break into teams of two. Work individually to review your partners logged bugs against the review criteria and discuss your findings with your partner. Review Criteria for Activity 1. Were the scripts executed in the correct sequence? 2. Did the scripts run successfully? 3. Compare actual results to expected results. 4. Analyze the test results with exit criteria to determine if you are ready to close the testing stage. Review Criteria for SIR Logs 1. Identify and document the defects identified during the test execution. 2. Ideally SIRs should include clear and detailed description of the defect, priority level (e.g., High, Medium and Low), exact steps to replicate the issue. 3. Ensure each defect is logged and tracked individually. 4. Documentation of defects during testing provides a place to identify downstream impacts of the defect on other teams. 5. Ensure that there is a project standard on how to document issues and defects clearly. Make the description of the issues/SIRs specific enough so that the fixing team does not need real-time interaction with the testing team to understand the content and the context of the issues/SIRs
Z16327 2007 Accenture. All Rights Reserved. 2 Activity3_ ParticipantInstructions.doc
Step Five: Class Debrief 1. Be prepared to participate in a class discussion about this activity.
Tips and Tricks

On-the-Job Overview of Test Execution 1. Execute test scripts. 2. Record potential defects as SIRs. 3. Work with the application team to resolve identified defects. 4. Participate in the release control process to ensure that solutions meet business requirements. 5. Validate application fixes. 6. Inform the test lead of any issues that may affect the schedule, budget, or quality of the application or testing process. Finding Application Defects 1. Review the system functionality and test approach. 2. Execute script step compare actual result to expected result. If there is a discrepancy: Ensure you have executed the step correctly. Ensure you have entered the correct data. Ensure the data is correct, if possible. Review relevant business rules (as appropriate).
3. Document confirmed discrepancies as SIRs. Include all relevant test data and business requirements information. How to create a SIR Provides a clear, detailed description of the identified defect, including: A description of when the problem occurred A description of the actions the tester took to encounter the defect Any additional information necessary to pinpoint the problem
Provides an estimated priority level Clearly describes the expected outcome Includes complete documentation of the resolution and object impacts (upon resolution) Includes accurate information
Updated on a timely basis
SIR Levels Critical: Defect results in Fail-Stop Must be fixed before next Pass Must be fixed before entering the next Stage Must be fixed before entering user acceptance Test Stage Must be fixed before go live or approved for deferral High: Defect results in Fail-Stop or Fail-Continue Medium: Defect results in Fail-Continue Low: Defect results in Fail-Continue
Module 4: Product Test Activity 3: Test Scripts Input
Test Scripts Product Test Workflow Management Application Release 3

Author: Version: Issue Date: Last Saved On: Last saved by: MRT 1.0 June 22, 2007 8/10/2007 9:13:00 AM MRT
Activity3_Input_TestScripts.doc
Script # 1
BF Code: TEO01
Test Script ID Requirement ID Purpose Input Expected Output Environmental Need Dependency Procedure Test Script Execution Name: Steps 1. Execute the procedure Login by launching End User 01 Icon on the desktop 2. Create work item. 3. Fill in the mandatory fields. 4. Save and Create PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification. Purpose: Result
Pass1 Pass2
tsTEO01TC01 Verify that End User is able to create a work item (Telephone Complaint) Input: Customer Number = 8877554422 Work Item successfully created by End User N/A
Script # 2
BF Code: TEO02
Test Script ID Requirement ID Purpose Input Expected Output Environmental Need Dependency Procedure Test Script Execution Name: Steps 1. Execute the procedure Login by launching End User 04 Icon on the desktop 2. Access Scheduled Work Queue 3. Locate work item and complete the task PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification. Purpose: Result
Pass1 Pass2
tsTEO02TC02 Verify that End User 04 is able to successfully complete a work item Input: Customer Number = 1122334455 Work Item successfully completed by End User 04 N/A
Script # 3
BF Code: TEO03
Test Script ID Requirement ID Purpose Input Expected Output Environmental Need Dependency Procedure Test Script Execution Name: Steps Purpose: Result
Pass1 Pass2
tsTEO02TC03 Verify that End User 02 is able to login successfully and view the correct welcome page greeting message Input: End User 02 login welcome page greeting message = Welcome to the Work Flow Application System, _EU02, UU_EU02 N/A
1. Execute the procedure Login by launching End User 02 Icon on the desktop 2. Expected Result: End User is able to login successfully and view the welcome page greeting message Welcome to the Work Flow Application System, _EU02, UU_EU02 PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification.
Script # 4
BF Code: TEO04
Test Script ID Requirement ID Purpose Input Expected Output Environmental Need Dependency Procedure Test Script Execution Name: Steps Purpose: Result
Pass1 Pass2
tsTEO02TC04 Verify that End User 01 is able to Complete the work item. Input: Assigned to = UU_EU01, UU_EU01 Work Item successfully Completed N/A
1. Execute the procedure Login by launching End User 01 Icon on the desktop 2. Access Scheduled Work Queue from left navigation menu. 3. Select work item 1213 from Queue and change the status to Completed 3. Select Save and Close 4. Expected Result: User should have successfully saved the work item without any errors PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification.
Script # 5
BF Code: TEO05
Test Script ID Requirement ID Purpose Input Expected Output Environmental Need Dependency Procedure Test Script Execution Name: Steps 1. Execute the procedure Login by launching End User 01 Icon on the desktop 2. Access Scheduled Work Queue from left navigation menu. 3. Select work item from Queue and change the status to Pending Investigation 4. Close the browser prior to saving the page, the system prompts a message Are you sure you want to navigate away from this page? Click OK 5. Re-launch End User 01 login from the desktop 6. Expected Result: End User should view the welcome page. PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification. Purpose: Result
Pass1 Pass2
tsTEO05TC02 Verify that End User 01 is able to change status of the work item to Pending Investigation Input: Assigned to = UU_EU01, UU_EU01 Work Item successfully assigned to End User N/A
Script # 6
BF Code: TEO06
Test Script ID Requirement ID Purpose Input Verify that the widget is correctly created in the database Input: Expected Output Environmental Need Dependency Procedure Test Script Execution Name: Steps Purpose: Result
Pass1 Pass2
tsTEO06TC01
Customer Account No: = 9876543211 Property Type = Measured Contact Name = John Newton Customer FullName = John Newton Customer Address L1 = 55 Bently Drive Post Code = OX2 5TR Telephone Number = 18654445555 (numerics only) Select Work from the dropdown list Payment Amount = 44.99 Date Payment made = Select 20-Jun-2007 from the calender function Payment Method = Credit or Debit Card Where Payment made = Bank Is this part of the bulk payment = No Action Required = Enter the following comments Client enquiring about payment Widget successfully created
N/A
1. Execute the procedure Login by launching End User 01 Icon on the desktop 2. Click Create Work Item expandable list in left navigation menu. 3. Click Customer Driven Payment Enquiry (under Create Work Item) in left navigation menu. 4. Fill in the Customer Account No. field in form using input data 5. Select Commercial from the dropdown list under Customer Type
6. Select Measured from the dropdown list under Property Type 7. Fill in the following fields using input data: Customer FullName Contact Name Customer Address L1 Post Code Payment Amount 8. Select Date Payment made as 25-Jun-2007 from the calender function 9. 10. 11. 12. Select Credit or Debit card from the dropdown list under Payment method Select BANK from the dropdown list under Where Payment made Select No for question Is this part of a bulk payment? Enter free format text Client enquiring about payment under Action required
13. Fill in the Telephone Number field in form using input data and select Work from the dropdown list 14. Select Save and Create to complete the process PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification.
Script # 7
BF Code: TEO07
Test Script ID Requirement ID Purpose Input Expected Output Environmental Need Dependency Procedure Test Script Execution Name: Steps 7. Execute the procedure Login by launching Team Manager 01 Icon on the desktop 8. Click Scheduled Work Queue expandable list in left navigation menu. 9. Find a work item for the list which shows status as Unassigned and select it by double clicking the corresponding ID # 10. Scroll down to the bottom of the page 11. Select Assigned from the dropdown list under Status 12. Select UU_EU01, UU_EU01 from the dropdown list under Assigned to 13. Enter free text under Comments Re-assigned to EU01 as it required urgent action 14. Click Save and Close PASS 1 Passed/Failed PASS 2 Passed/Failed If passed, P; if failed, F and the bug ID from defect management tool for identification. If passed, P; if failed, F and the bug ID from defect management tool for identification. Purpose: Result
Pass1 Pass2
tsTEO07TC02 Verify that Team Manager is able to successfully assign a work item to End User 01 Input: Assigned to = UU_EU01, UU_EU01 Work Item successfully assigned to End User N/A
Activity 3 - SIR Report Template
SIR Report
Issue ID Status Priority Severity Test script number Pages / Components Summary Description Build number Date resolved Resolution details
TE003-01
Open
Low
Low
tsTEO02TC03 Welcome Launch Page
Welcome message verbal is not correctly displayed when user logs into the WMA application
After user has successfully logged into the WMA system, the welcome R2 greeting message is displayed incorrectly. Defect Recreation Steps: 1. Execute the procedure Login by launching End User 02 Icon on the desktop Expected Result: End User is able to login successfully and view the welcome page greeting message Welcome to the Work Flow Application System, UU_EU02, UU_EU02 Actual Result: End User is able to login successfully and view the welcome page greeting message: "Welcome to Workflow Management Application, UU_EU02, UU_EU02"
Activity3_SIR Report_Template.xls
Activity 3 - SIR Report Template
Issue ID
Status
Priority
Severity
Test script number
Pages / Components
Summary
Description
Build number
Date resolved
Resolution details
Activity3_SIR Report_Template.xls

ApplicationTesting PG

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ApplicationTesting PG

Caricato da

Copyright:

Formati disponibili

Course Map

Application Testing School

Day 2 Morning Review

Module 5: School Closing 5.2 School Closing 0:15)

Application Testing School

Application Testing School

Copyright 2007 Accenture All Rights Reserved.

Z16327 2007 Accenture Technology Solutions. All Rights Reserved

Application Testing School

Accenture Solutions Delivery Academy

Z16327 2007 Accenture Technology Solutions. All Rights Reserved

Application Testing School

Massachusetts Institute of Technology, Professional Education Programs

Copyright 2007 Accenture All Rights Reserved.

Z16327 2007 Accenture Technology Solutions. All Rights Reserved

Application Testing School

Copyright 2007 Accenture All Rights Reserved.

School Learning Objectives

Z16327 2007 Accenture Technology Solutions. All Rights Reserved

Application Testing School

Copyright 2007 Accenture All Rights Reserved.

Copyright 2007 Accenture All Rights Reserved.

Z16327 2007 Accenture Technology Solutions. All Rights Reserved

Application Testing School

Copyright 2007 Accenture All Rights Reserved.

Z16327 2007 Accenture Technology Solutions. All Rights Reserved

Module 2: Testing in Accenture

Application Testing School

Module 2: Testing in Accenture

Application Testing School

Z16327 Copyright 2007 Accenture All Rights Reserved.

Application Testing School

Module 2: Testing in Accenture

Copyright 2007 Accenture All Rights Reserved.

Discussion: Have you used ADM?

Copyright 2007 Accenture All Rights Reserved.

Z16327 Copyright 2007 Accenture All Rights Reserved.

Application Testing School

Module 2: Testing in Accenture

Which method are we talking about?

ADM: How Do We Get There?

Accenture Delivery Methods:

Copyright 2007 Accenture All Rights Reserved.

Z16327 Copyright 2007 Accenture All Rights Reserved.

Application Testing School

Module 2: Testing in Accenture

Accenture Delivery Methods

The Testing Framework

Job Aid: https://methodology.accenture.com/core_custom/content/frameset_home.asp?page=testingfr ameworkoverview.asp

Z16327 Copyright 2007 Accenture All Rights Reserved.

Application Testing School

Module 2: Testing in Accenture

Overview of Testing Activities and Tasks in ADM

V-Model Phase Plan Analyze Design Build Test/Deploy

ADM Test Activity

Copyright 2007 Accenture All Rights Reserved.

Testing Tasks and Deliverables

2. Plan the Test

6. Close the Test

Copyright 2007 Accenture All Rights Reserved.

Z16327 Copyright 2007 Accenture All Rights Reserved.

Application Testing School