Execute Tests

Seminars and Services We Offer to Perform this Process
Other Steps (Activities) We Can Help You With

Execute Tests

We can:

		teach you how to do this activity
	with our in-house or public seminars and e-learning

		show you how to do this activity
	with E-Coaching

lead your experts
through this
activity in a Facilitated JAD Session

There are 2 ways to conduct tests: on a computer by executing selected programs or modules under controlled conditions and in the form of quality assurance walkthroughs. In either case, test execution is not complete until identified discrepancies have been documented in a problem report and distributed to the appropriate parties for resolution.

Effective test execution
		is the only alternative to production disasters

		reduces the cost of failure

		decreases the probability of failure in production

		increases the end-users' confidence that the solution works as designed

		increases the developers' confidence in their solution

		creates problem reports that pinpoint the work that developers have to do

		captures statistical information that can be used to improve the overall development effort

When should you execute tests?

Testing is needed throughout the system development life cycle. During the analysis and design phase, the most common form of testing is a quality assurance walk-throughs Unit, integration, system, and end user acceptance testing should begin as soon as the required executable components of the system become available.

Who should execute tests?

A separate quality assurance group (Independent Verification and Validation) should be responsible for testing. The most commonly accepted practice is for developers to test their components while end-users test for business acceptance. The need for impartial testers increases as the complexity of the components or the need for quality increases.

Core+ Training for Business Systems Analysts

2-40 : How to Manage Small Projects

Overview Presentations for Management

5-20 : Requirement Gathering JAD Sessions in the 21st Century

5-30 : Business Analysis and User Acceptance Testing

Supplemental Training for Business Systems Analysts

3-30 : How to Prepare and Facilitate a Successful JAD Session

3-40 : How to Plan, Prepare, and Execute User Acceptance Testing

Other Products and Services

E-Coaching

JAD Facilitation

Tailored Training

Skills Assessment

The Small Project Guide



	Under Time Pressure?

	Learn how to run an efficient, effective JAD session that does this activity faster. How to Prepare and Facilitate a Successful JAD Session

	Our e-Coaching offer is a cost-effective alternative for small groups to learn these and other business systems analysis techniques at their own workplace or for follow-up after a training seminar


	your business analysis skills

	Analyze Business Problems
	Gather Prioritized Requirements
	Model and Analyze Business Processes
	Model Business Data
	Design Business Architecture
	Develop Quick Fixes
	Engineer Business Processes
	Evaluate Potential Solutions
	Engineer Test Data
	Plan Testing Activities

Requirements Solutions Group offers training as well as web-based and on-site consulting services to support a wide range of activities within the system development life cycle all targeted exclusively to the Business Analyst, Requirements Engineer and the Subject Matter Expert.

You can also visit our bookstore for the newest publications in the business systems analysis field

Problem Reports

A problem report is a record of a discrepancy between an expected result and an actual result observed during test execution.

Documentation of the problem

enables problem tracking and resolution,
establishes a basis for quality metrics and
serves as a learning tool for developers and end users.

The following table is a compilation of potential components that you can use to evaluate your problem reporting mechanisms.

Problem Report Item	Definitions and Examples
Problem Report ID	Unique identifier for the problem report
Description of the Problem	Short explanation of the identified discrepancy
Test Case ID	Unique identifier of the test case that was executed
Test Plan Name	Name of the test plan
Tester Comments	Notes from the test executor regarding reproduction of the error
Test Execution Document Reference	Identification and location of relevant documentation produced by the test
Requirement ID	What requirement statement regarding system behavior has been violated
Severity of Error	Use the software error categories
Who is Assigned to Repair	Project team member assigned to resolve reported discrepancies
Expected Repair Completion Date	Estimated date that the defective components will be available for re-testing
Status	Open: Assigned, In Progress, Repaired Closed: Deferred, Fixed, Non-Reproducible
Problem Resolution	Actions taken to rectify discrepancies
Actual Repair Completion Date	Date that the defective components became available for re-testing

How to Conduct a Walk-Through

To be effective, a walk-through requires advanced preparation by the participants, a clear set of rules, and the commitment by the organization to utilize the results to improve the product and the process.

Participants and their Roles

Moderator	runs the meeting makes sure everybody is heard keeps meeting focused on the goal of identifying errors
Presenter	presents the product being evaluated responds to any questions from the group
Reviewer	peers and managers of the author who can identify technical errors end users and their managers who can identify potential usage problems or concerns and factual errors special interest groups (SIG) who can evaluate the product from their perspective only.
Recorder	captures identified issues, concerns and discrepancies that are brought up

Critical Success Factors

Prior to the meeting, all participants have access to the product or deliverable that is being evaluated for a sufficient period of time (typically a minimum of 1 business day).

Prior to the meeting, all participants have been given the necessary tools and prerequisite knowledge to be able to evaluate the product.

There is a set time limit to any scheduled Walk-Through (typically 30 - 90 minutes).

The emphasis of the meeting is on finding errors and not defining solutions.

Prior to the meeting, expectations of the Walk-Through are established and managed throughout the session.