Info Source - Volume IX, Issue 4 - Winter, 2009

Testing - “I’m not going to do it…You do it”

By Stefan Piechota

There is often some confusion in companies as to which roles stakeholders play in testing. Testing is often poorly defined and gets volleyed between Business Users, IT and Management:


Below are some thoughts on the areas of testing and some suggestions on which roles various stakeholders play in testing.

Overview

The following diagram gives a high level overview of the important areas that feed into testing (e.g., Requirements), the various types of testing and who is responsible for each of these testing areas:



Using the analogy of “building a house”, let’s demonstrate how Business Users, IT and Management, each with specific responsibilities, work as a team to build, test and implement a software application.

Setting the Foundation

It is important for Business Users to apply their real life experiences and be able to create the necessary tests for User Acceptance Testing (UAT). This will minimize the risk of them finding problems once the software application is deployed.

The UAT process starts with making sure there are clear Business Requirements. Business Requirements are derived from high level Business Needs along with any current issues or pain points the business users are experiencing. From prioritized Business Requirements, the Business Users should be able to create the necessary Use Cases in addition to mapping out the “As Is” and “To Be” Processes agreed to by all the Business Users. The Use Cases, “As Is” and “To Be” Processes created by the Business Users are all used to create the necessary Functional Requirements (see Diagram 1). IT assists the Business Users in confirming that the Functional Requirements are accurate for the proposed software application.

Building the House

Once IT (this may also be an Implementation Partner) receives the Functional Requirements from the Business Users, they should follow the standard SDLC (Software Development Life Cycle) process of creating Technical Requirements, developing/configuring code and then executing the testing life cycle, including: Unit Testing, Integration Testing and System Testing (see Diagram 1). Test results should be documented and completed before UAT testing begins. Following these steps before UAT will ensure the Business User’s effort and time is not wasted during UAT.

The IT department is responsible for making sure the software application available to the Business Users for UAT is fit for use. The Business Users should not be finding errors like: interface control problems, missing code logic or application malfunctions during UAT testing!

Inspecting the House

Next, Business Users need to create the Test Cases used in UAT as they know what tests are important and drive the most business value. Test Cases are created by the Business Users leveraging the work done in creating the Use Cases, “As Is”/”To Be” Processes and the Functional Requirements. Test Cases should be coordinated across multiple departments and flow into one another (e.g. an Order Test Case created by Sales should eventually trigger an Accounts Receivable Test Case in Accounting) and should also test alternate, exception and correction based conditions. IT will review the Test Cases for accuracy as they relate to the new or updated software application.

For each Test Case, one or more Test Scripts are written giving explicit instructions on:

Next, Business Users group the Test Scripts into logical Test Scenarios (for example one scenario might be to test US Orders and another scenario to test foreign Orders). IT will often assist the Business Users in creating and maintaining the necessary test data for the Test Scenarios. The Test Scenarios, along with identifying who and when the testing is going to occur, makes up the UAT Plan.

The execution of the UAT Plan should be a joint effort between the Business Users and IT with the Business Users leading the effort. The Business Users should set aside an appropriate amount of time to test and run through the UAT Plan. Because this testing involves coordination between business departments (e.g. Sales and Accounting) it is important that these groups be in close contact with one another during this testing period. The IT department should be available and responsive if issues or problems arise during UAT. Issues should be formally logged, reviewed by both Business Users and IT with an agreed on action plan on how and when to resolve the issues.

Business Users and IT may also work together when doing Performance Testing (e.g. Business Users may be asked to log on or run reports simultaneously so IT can measure performance). Once a software application is in production there may also be times when software updates/changes mandate Regression Testing. This may involve Business Users re-running UAT tests and/or having IT create automated test scripts to demonstrate that nothing “got broken”.

Management’s main role in testing is to ensure that both the Business Users and IT have adequate time and resources to perform testing. It is a reality that testing takes time away from day-to-day job activities. Management must therefore decide whether to backfill staff, alter vacation schedules and authorize necessary expenditure (e.g. travel expenses to bring the business groups together for testing). Finally, Management should recognize, support and congratulate the testing effort that both the Business Users and IT performed.

Conclusion

Not surprisingly, testing involves everyone’s cooperation to be successful. TSI finds that organizations which involve Business Users, IT and Management together in the testing effort are more likely to succeed. TSI conducts testing workshops and test planning to help organizations realize their testing potential. Contact TSI. for more detail.

Definitions

The following are definitions (in alphabetical order) of some major terms used in this whitepaper.

Term	Definition	Responsibility
Business Needs	A high level expression of a function/process that should be performed.	BU*
Business Requirements	Key step definitions that contain text describing what needs to be done and any key or unique constraints or expectations.	BU
Functional Requirements	Describes a set of inputs, behaviors, and outputs and may include calculations, technical details, data manipulation/processing and other specific functionality that define what a system should accomplish.	BU, IT
Integration Testing	Software modules/systems that are combined and tested as a group.	IT
Performance Testing	Quantitative testing that confirms speed/effectiveness of a computer, network, software program or device.	IT,BU
Regression Testing	Retesting to assure that no errors were introduced in the process of fixing a bug or introducing new code.	IT,BU
System Testing	All integrated components are tested as one complete system.	IT
Technical Requirements	Describes technical aspects related to performance, reliability, availability, configuration, and coding of a system.	IT
Test Case	A logical or physical description of a test linked to a Business/Functional Requirement that has a specific test objective.	BU, IT
Test Plan	A document containing the detailed testing approach that describes the testing aspects of the project and contains links to the Test Scenarios, Test Cases, Test Scripts and Test Results. Also serves as a means of communicating with the user and other stakeholders.	BU, IT
Test Scenario	A scheme for the execution of Test Cases/Scripts that follows a particular use of the application being tested (Use Case) with the appropriate Test Cases/Scripts included in the order in which they should be executed.	BU, IT
Test Script	The succession of coordinated steps and checks related to a physical Test Case including what to test, identifying who performs the test and instructions on how to test and compare to expected results.	BU, IT
Unit Testing	An individual piece of code (e.g. function/procedure) that is fit for use.	IT
Use Case	Describes interactions between actors (i.e., users) and systems/goals. Use Cases are useful in communicating functional requirements.	BU

* BU = Business Users