SOFTWARE TESTING LECTURE # 7 Test Case Design

SOFTWARE TESTING

LECTURE # 7

Test Case Design

ALI JAVED

Lecturer

SOFTWARE ENGINEERING DEPARTMENTU.E.T TAXILA

Email:: [email protected]

Office Room #:: 7

mailto:[email protected]

-Test Case

-Test Case Design- Design Function Tests- Design GUI Tests - Design System/Acceptance Plan- Review/Approve plan

Presentation Outline

A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system meets specifications.

A test case has components that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.

The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. It may take many test cases to determine that a software program or system is functioning correctly.

Test cases are often referred to as test scripts, and the collection of test cases are known as test suites.

Test Case

The steps for Test case Design and their tasks are shown in the figure.

The steps of test case design are::

Design function tests Design GUI testsDefine System/Acceptance tests Review Approve design

Test Case Design

Step 1

Design Function tests

Test Case Design (STEPS)

Task 1: Refine the Functional Test Requirements

At this point, the functional specification should have been completed. Itconsists of the hierarchical functional decomposition, the functional windowstructure, the window standards, and the minimum system requirementsof the system to be developed. An example of windows standards isthe Windows 2000 GUI Standards. A minimum system requirement couldconsist of Windows 2000, a Pentium IV microprocessor, 1-GB RAM, 40GBdisk

A functional breakdown consists of a list of business functions, hierarchicallisting, group of activities, or set of user profiles defining the basicfunctions of the system and how the user will use it. The criteria used to determine the successful execution of each function should be stated.

Examples of functions include: approve customer credit, handle order, create invoice, order components, receive revenue, pay bill, purchase items, and so on.

Test Case Design (Tasks)

Task 1: Refine the Functional Test Requirements ………CONTD.........

A functional breakdown is used to illustrate the processes in a hierarchicalstructure showing successive levels of detail. (see Exhibit 13.3).

A data flow diagram shows processes and the flow of data among theseprocesses. It is used to define the overall data flow through a system. A data flow diagram should be reviewed, and each major and leveled function should be listed and organized into a hierarchical list.

A functional window structure describes how the functions will beimplemented in the windows environment. Exhibit 13.4 shows a samplefunctional window structure for order processing.








Task 2: Build a test Matrix

The test matrix cross-references the tests to the functions. Thismatrix provides proof of the completeness of the test strategies, illustrating in graphic format which tests exercise which functions. The matrix is used as a control sheet during testing and can also be used during maintenance.

The business functions are listed vertically and the test cases are listed horizontally. The test case name is recorded on the matrix along with the number.

It is also important to differentiate those test cases that are manual andthose that are automated. One way to accomplish this is to come up witha naming standard that will highlight an automated test case; for example,the first character of the name is “A.”Exhibit 13.5 shows an example of a test matrix.


Step 2 Design GUI tests


The goal of a good graphical user interface (GUI) design should be consistentin “look and feel” for the users of the application. Good GUI design hastwo key components:

InteractionAppearance.

Interaction relates to how the user interacts with the application. Appearance relates to how the interface looks to the user.

GUI testing involves the confirmation that the navigation is correct; forexample, when an ICON, menu choice, or ratio button is clicked, thedesired response occurs.

Test Case Design (Steps)

Design GUI tests

Task 1: Identify the Application GUI Components

The graphical user interface provides multiple channels of communicationusing words, pictures, animation, sound, and video. Five key foundationcomponents of the user interface are windows, menus, forms, icons,and controls.

1. Windows — In a windowed environment, all user interaction withthe application occurs through the windows. These include a primarywindow, along with any number of secondary windows generated from the primary one.

2. Menus — Menus come in a variety of styles and forms. Examplesinclude pull-down menus, pop-up menus, option menus, and cascading menus.

3. Forms — Forms are windows or screens into which the user can addinformation.


Task 1: Identify the Application GUI Components

4. Icons — Icons, are valuable for instant recognition, ease of learning, and ease of navigation through the application.

5. Controls — A control component appears on a screen that allowsthe user to interact with the application and is indicated by itscorresponding action. Controls include menu bars, pull-downmenus, push buttons, check boxes, radio buttons, list boxes, and drop-down list boxes.

A design approach to GUI test design is to first define and name each GUIcomponent by name within the application as shown in Exhibit 13.6. In thenext step, a GUI component checklist is developed that can be used to verifyeach component in the table above.


GUI Component Test Matrix

With the GUI component test matrix below, each GUI component is defined and documented by name and GUI type. During GUI testing, each component is tested against a predefined set of GUI tests.

Task 2: Define the GUI Tests

In the previous task the application GUI components were defined, named,and categorized in the GUI component test matrix. In the present task, achecklist is developed against which each GUI component is verified. Thelist should cover all possible interactions and may or may not apply to aparticular component.

In addition to the GUI component checks above, if there is a GUI designstandard, it should be verified as well. Some of the typical GUI standards that should be verified include the following:

• Forms “enterable” and display-only formats• Wording of prompts, error messages, and help features• Use of color, highlight, and cursors• Screen layouts• Function and shortcut keys, or “hot keys”• Consistent font usage• Consistent color usage


s

Step 3

Define the System/Acceptance tests


Task 1: Identify Potential System Tests

System testing is the highest level of testing and evaluates the functionalityas a total system, its performance, and overall fitness of use.

Some common system test types include the following:

• Performance Testing — Verifies and validates that the performance requirements have been achieved; measures response times, transaction rates, and other time-sensitive requirements.

• Security Testing — Evaluates the presence and appropriate functioning of the security of the application to ensure the integrity and confidentiality of data.

• Volume Testing — Subjects the application to heavy volumes of datato determine if it can handle the volume of data.


• Stress Testing— Investigates the behavior of the system under conditions that overload its resources.

• Compatibility Testing — Tests the compatibility of the application with other applications.

• Usability Testing — Determines how well the user will be able to useand understand the application.

• Documentation Testing — Verifies that the user documentation isaccurate and ensures that the manual procedures work correctly.

Backup Testing — Verifies the ability of the system to back up itsdata in the event of a software or hardware failure.

• Recovery Testing — Verifies the system’s ability to recover from asoftware or hardware failure.

• Installation Testing — Verifies the ability to install the system successfully.


Task 2: Design System Fragment Tests

System fragment tests are sample subsets of full system tests that can beperformed during each spiral loop. The objective of doing a fragment testis to provide early warning of pending problems that would arise in the fullsystem test. Candidate fragment system tests include function, performance, security, usability, and documentation.

Non-fragment system tests include installation, recovery, e.t.c, which are probably going to be performed until the formal system test.

Function testing on a system level occurs during each spiral as the systemis integrated. As new functionality is added, test cases need to bedesigned, implemented, and tested during each spiral.


Task 2: Design System Fragment Tests

Typically, security mechanisms are introduced fairly early in the development. Therefore, a set of security tests should be designed, implemented, and tested during each spiral as more features are added.

Usability is an ongoing informal test during each spiral and shouldalways be part of the test strategy. When a usability issue arises, the testershould document it in the defect tracking system.

Documentation (such as online help) is also ongoing informal tests. It should be developed in parallel with formal system development during each spiral and not be put off until a formal system test. This will avoid last-minute surprises. As new features are added, documentation tests should be designed, implemented, and tested during each spiral.


Task 3: Identify Potential Acceptance Tests

Acceptance testing is an optional user-run test that demonstrates the ability of the application to meet the user’s requirements. The motivation for this test is to demonstrate rather than be destructive, that is, to show that the system works. Less emphasis is placed on technical issues and more is placed on the question of whether the system is a good business fit for the end user. The test is usually performed by users, if performed at all.


Step 4

Review/Approve Design


Task 1: Schedule/Prepare for Review

The test design review should be scheduled well in advance of the actualreview, and the participants should have the latest copy of the test design.

As with any interview or review, it should contain certain elements like what will be discussed, discussing the details, then summarizing those details.

The reviewer should state up front the estimated duration of the review and set the ground rule that if time expires before completing all items on the agenda, a follow-on review will be scheduled.

The purpose of this task is for development and the project sponsor toagree and accept the test design. If there are any suggested changes to thetest design during the review, they should be incorporated into the testdesign.


Task 2: Obtain Approvals

Approval is critical in a testing effort, because it helps provide the necessaryagreements among testing, development, and the sponsor. The bestapproach is with a formal sign-off procedure of a test design.

However, if a formal agreement procedure is not in place, send a memo to each key participant, including at least the project manager, development manager, and sponsor.

In the document attach the latest test design and point out that all theirfeedback comments.


Any question

Documents

SOFTWARE TESTING LECTURE # 7 Test Case Design