Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
15Activity
0 of .
Results for:
No results containing your search query
P. 1
Structured Testcase Design

Structured Testcase Design

Ratings:

4.0

(1)
|Views: 956|Likes:
Published by Kapil Samadhiya
Structured Testcase Design: This document is very useful for all Software Testing Professionals. You can get clear concept of Software Testing / Quality Assurance.



Thanks,

Kapil Samadhiya
Structured Testcase Design: This document is very useful for all Software Testing Professionals. You can get clear concept of Software Testing / Quality Assurance.



Thanks,

Kapil Samadhiya

More info:

Published by: Kapil Samadhiya on Oct 21, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

10/14/2011

pdf

text

original

 
Structured Testcase Design
S. VasantAbhishek Datta
Member of Technical StaffMember of Technical StafCadence Design SystemsCadence Design Systems
ABSTRACT
A structured approach is required in practically all aspects of Software Testing. A methodicalapproach to Testcase design involves a degree of planning, considerations of ease of execution andmaintainability. The paper 
Structured Testcase Design
focuses on the implementation and structureof the overall test framework and how testcases should be designed. It also attempts to share theexperiences of the authors and what they consider to be the "best practices" that have been identifiedin this domain. It addresses issues such as
 scalability, modularity, version-control, robustness, portability
and
documentation
of testcases.
 
1 Introduction
Software today is getting more and more complex. The traditional ad hoc approach to testingis rapidly being seen as neither efficient nor effective enough to handle this increasingcomplexity. Scope
It does not discuss what the intent of a testcase should be. A high-level picture of the Test CaseDesign Process is shown in Fig 2. (See appendix) as a flowchart. We will not elaborate on the process details and instead concentrate on the structural aspects of testcase design. It is observedhowever, that though the paper is not process-centric, the process is integral to the testcase designactivity and familiarity with it is assumed.
1
 
2 Test Case Design Considerations
This section discusses design aspects that should help in better structuring of testcases.
2.1 Modularity
It should be understoodwhile designingtests that the Application Under Test (AUT) willundergo aseries of radical changes and mysterious transformations in the course of it's life cycle. Even if thatdoes not appear to be the case in the present it is a fair assumption to make of the future.Changes in the AUT test environment, platform et al, place considerable stress on a testcase unit toevolve and change correspondingly. Deciding on a modular design can help reduce the angst of testmaintenance.So what is a modular testcase design?It is usually possible to break up a testcase into component parts. One could do this by askingquestions of the kind:
What is my test harness viz. the test execution framework?
What is my "golden" data?
What are my test sources?
What are the setup scripts, if any?The answers to these questions should allow thetestcase operation to be broken up into functionallydistinct parts. The components are then analyzed for -
2.1.1 Invariance
Does a component of your test change across
Other tests in the testsuite?
Other platforms?
With revisions in the functionality of the AUT?
2
 
The invariant parts will typically include those components that make up the test harness e.g. toolsetup and result verification tool(s).
2.1.2 Parameterization
To what degree is it possible to parameterize certain attributes of these components?The benefits ofdoing the aboveanalysis are manifold -
Once it is known that certain components of a testcase are invariant across the testsuite then thesecan be collapsed into a common set and placed at a central location. Those elements that have been deemed as parameters can be set at the same central location. This greatly facilitates testmaintenance.
The parameterization of testcase elements and abstraction of a common set of test features 'forces'a consistent testcase design. Testcases are typically added in increments corresponding to thedelta changes in the AUT over a period of time, possibly by different individuals. It becomesimportant to have a consistent test design to ease the understanding of the testcase structure anddebugging test failures in regression testing. It is all very well to advocate a standard testcasedesign in Process Guideline Documents but it is generally seen that when the overall testframework dictates a set of parameters for a testcase to plug-in and execute correctly then thetestcases are created in much more consistent manner.
Characterizing the testcase in terms of discrete functional units helps in classifying which portions of the testcase need to be under version control and which don't. This is described in asubsequent section on Version Control.
It is seen that designing in terms of parameterized modules increasesthe overall scalability of thetest-framework. Once the interfaces between the test-harness and the tests are clear, it is easier toadd new tests and change the test harness itself without affecting the functioning of the existingtests.
3

Activity (15)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Kanak Mane liked this
Yogeesh Babu liked this
sameergundu liked this
qaswedfrt45 liked this
leelamanohark liked this
adisorm liked this
kallamsrs liked this
hkvissa liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->