Basic Testcase Concepts

8/8/2019 Basic Testcase Concepts

1/18

http://www.testingtemplates.com/

Basic Testcase Concepts

A testcase is simply a test with formal steps and instructions; testcases are valuable because they

are repeatable, reproducible under the same environments, and easy to improve upon with feedback.A testcase is the difference between saying that something seems to be working okay and provingthat a set of specific tasks are known to be working correctly.

Some tests are more straightforward than others. For example, say you need to verify that all thelinks in your web site work. There are several different approaches to checking this:

you can read your HTML code to see that all the link code is correct

you can run an HTML DTD validator to see that all of your HTML syntax is correct, which wouldimply that your links are correct

you can use your browser (or even multiple browsers) to check every link manually

you can use a link-checking program to check every link automatically

you can use a site maintenance program that will display graphically the relationshipsbetween pages on your site, including links good and bad

you could use all of these approaches to test for any possible failures or inconsistencies in thetests themselves

Verifying that your site's links are not broken is relatively unambiguous. You simply need to decidewhich one of more of these tests best suits your site structure, your test resources, and your need forgranularity of results. You run the test, and you get your results showing any broken links.

Notice that you now have a list of broken links, not of incorrect links. If a link is valid syntactically, butpoints at the incorrect page, your link test won't catch the problem. My general point here is that youmust understand what you are testing. A testcase is a series of explicit actions and examinations thatidentifies the "what".

A testcase for checking links might specify that each link is tested for functionality, appropriateness,usability, style, consistency, etc. For example, a testcase for checking links on a typical page of a sitemight include these steps:Link Test: for each link on the page, verify that

the link works (i.e., it is not broken)the link points at the correct pagethe link text effectively and unambiguously describes the target pagethe link follows the approved style guide for this web site (for example, closing punctuation is or isnot included in the link text, as per the style guide specification)every instance of a link to the same target page is coded the same way

As you can see, this is a detailed testing of many aspects of the link, with the result that oncompletion of the test, you can say definitively what you know works. However, this is a simpleexample: testcases can run to hundreds of instructions, depending on the types of functionality beingtested and the need for iterations of steps.

Defining Test and Testcase ParametersA testcase should set up any special environment requirements the test may have, such as clearingthe browser cache, enabling JavaScript support, or turning on the warnings for the dropping of


2/18

cookies.In addition to specific configuration instructions, testcases should also record browser types andversions, operating system, machine platforms, connection speeds -- in short, the testcase shouldrecord any parameter that would affect the reproducibility of the results or could aid introubleshooting any defects found by testing. Or to state this a little differently, specify whatplatforms this testcase should be run against, record what platforms it is run against, and in the case

of defects report the exact environment in which the defect was found. The various required fields ofa test case are as follows

Test Case ID: It is unique number given to test case in order to be identified.

Test description:The description if test case you are going to test.

Revision history: Each test case has to have its revision history in order to know when and bywhom it is created or modified.

Function to be tested:The name of function to be tested.

Environment: It tells in which environment you are testing.

Test Setup: Anything you need to set up outside of your application for example printers, networkand so on.

Test Execution: It is detailed description of every step of execution.

Expected Results:The description of what you expect the function to do.

Actual Results: pass / failed If pass - What actually happen when you run the test. If failed - put indescription of what you've observed.

Sample TestcaseHere is a simple test case for applying bold formatting to a text.

Test case ID: B 001

Test Description: verify B - bold formatting to the text

Revision History:3/ 23/ 00 1.0- Valerie- Created

Function to be tested: B - bold formatting to the textEnvironment: Win 98

Test setup: N/A

Test Execution:1. Open program2. Open new document

3. Type any text4. Select the text to make bold.5. Click Bold

Expected Result: Applies bold formatting to the text

Actual Result: pass


3/18

Test Case 1

Test Case ID : Test Case TitleThe test case ID may be any convenient identifier, as decided upon by the tester. Identifiers shouldfollow a consistent pattern within Test cases, and a similar consistency should apply access TestModules written for the same project.

Test

Case

ID

Purpose Owner Expected

Results

Test

Data

Test

Tools

Dependencies Initialization Description

Purpose:The purpose of the Test case, usually to verify a specific requirement.

Owner:The persons or department responsible for keeping the Test cases accurate.

Expected Result :Describe the expected results and outputs from this Test Case. It is also desirable to include somemethod of recording whether or not the expected results actually occurred (i.e.) if the test case, oreven individual steps of the test case, passed.

Test Data:Any required data input for the Test Case.

Test Tools:Any specific or unusual tools or utilities required for the execution of this Test Case.

Dependencies :If correct execution of this Test Case depends on being pleceded by any other Test Cases, that factshould be mentioned here. Similarly any dependency on factory outside the immediate testenvironment should also be mentioned.

Initialization :

If the system software or hardware has to be initialized in a particular manner in order for this Testcase to succeed, such initialization should be mentioned here.

Description:Describe what will take place during the Test Case the description should take the form of a narrativedescription of the Test Case, along with a Test procedure , which in turn can be specified by test casesteps, tables of values or configurations, further narrative or whatever is most appropriate to the typeof testing taking place.


4/18

Test Case 2

Test ID Description Expected Results Actual Resuls

Test Case 3

Project Name Project ID

Version Date

Test Purpose

Pre Test Conditions

Step Test

Description

Test Data Test Actions Expected

Result

Actual

Result

Test Case 4

Test Case Description : Identify the Items or features to be tested by this test case.

Pre and post conditions: Description of changes (if any) to be standard environment. Anymodification should be automatically done

Case Component Author Date Version

Test Case Description

Pre and Post Conditions

Input / Output Specification

Test Procedure

Expected Results

Failure Recovery

Comments

Test Case 4 - Description

Case :Test Case Name

Component : Component Name


5/18

Author : Developer Name

Date : MM DD YY

Version : Version Number

Input / Output Specifications:Identify all inputs / Outputs required to execute the test case. Be sure to identify all required inputs /outputs not just data elements and values:

Data (Values , ranges, sets )

Conditions (States: initial, intermediate, final)

Files (database, control files)

Test ProcedureIdentify any special constrains on the test case. Focus on key elements such as special setup.

Expected ResultsFill this row with the description of the test results

Failure RecoveryExplanations regarding which actions should be performed in case of test failure.

CommentsSuggestions, description of possible improvements, etc.

Test Case 5

Test

Case

ID

Test

Case

Name

Test Case

Description

Test Steps Test

Case

Status

Test

Status

(P/F)

Test

Priority

Defect

SeverityStep Expected Actual

Test Case ID Test Case Title

Purpose

Pre Requisite

Test Data

Steps

Expected Result


6/18

Test Case ID Test Case Title

Actual Result

Status

Writing Test Cases for Web Browsers

This is a guide to making test cases for Web browsers, for example making test cases to show HTML,CSS, SVG, DOM, or JS bugs. There are always exceptions to all the rules when making test cases. Themost important thing is to show the bug without distractions. This isn't something that can be done

just by following some steps, you have to be intelligent about it. Minimising existing testcases..

STEP ONE: FINDING A BUG

The first step to making a testcase is finding a bug in the first place. There are four ways of doingthis:1. Letting someone else do it for you: Most of the time, the testcases you write will be for bugs thatother people have filed. In those cases, you will typically have a Web page which renders incorrectly,either a demo page or an actual Web site. However, it is also possible that the bug report will have noproblem page listed, just a problem description.2. Alternatively, you can find a bug yourself while browsing the Web. In such cases, you will have aWeb site that renders incorrectly.3. You could also find the bug because one of the existing testcases fails. In this case, you have aWeb page that renders incorrectly.4. Finally, the bug may be hypothetical: you might be writing a test suite for a feature withoutknowing if the feature is broken or not, with the intention of finding bugs in the implementation ofthat feature. In this case you do not have a Web page, just an idea of what a problem could be.

If you have a Web page showing a problem, move to the next step. Otherwise, you will have to createan initial testcase yourself. This is covered on the section on "Creating testcases from scratch" later.

STEP TWO: REMOVING DEPENDENCIES

You have a page that renders incorrectly.Make a copy of this page and all the files it uses, and update the links so they all point to the copiesyou made of the files. Make sure that it still renders incorrectly in the same way -- if it doesn't, findout why not. Make your copy of the original files as close to possible as the original environment, asclose as needed to reproduce the bug. For example, instead of loading the files locally, put the fileson a remote server and try it from there. Make sure the MIME types are the same if they need to be,etc.Once you have your page and its dependencies all set up and still showing the same problem, embedthe dependencies one by one.For example, change markup like this:...to this:/* contents of foo.css */


7/18

Each time you do this, check that you haven't broken any relative URIs and that the page still showsthe problem. If the page stops showing the problem, you either made a mistake when embedding theexternal files, or you found a bug specifically related to the way that particular file was linked. Moveon to the next file.

STEP THREE: MAKING THE TEST FILE SMALLER

Once you have put as many of the external dependencies into the test file as you can, start cuttingthe file down.Go to the middle of the file. Delete everything from the middle of the file to the end. (Don't payattention to whether the file is still valid or not.) Check that the error still occurs. If it doesn't, put thatpart pack, and remove the top half instead, or a smaller part.Continue in this vein until you have removed almost all the file and are left with 20 or fewer lines ofmarkup, or at least, the smallest amount that you need to reproduce the problem.Now, start being intelligent. Look at the file. Remove bits that clearly will have no effect on the bug.For example if the bug is that the text "investments are good" is red but should be green, replace thetext with just "test" and check it is still the wrong colour.Remove any scripts. If the scripts are needed, try doing what the scripts do then removing them -- for

example, replace this:document.write('

test');..with:

test
...and check that the bug still occurs.Merge any blocks together.Change presentational markup for CSS. For example, change this:...to:span { color: red; } /* in the stylesheet */ Do the same with style="" attributes (remove the attributes, but it in a block instead).Remove any classes, and use element names instead. For example: .
.a { color: red; }.b { color: green; }

This should be green.
...becomes:div { color: red; }p { color: green; }
This should be green.
Do the same with IDs. Make sure there is a strict mode DOCTYPE:Remove any elements. Remove any "lang" attributes or anything that isn't needed to showthe bug.If you have images, replace them with very simple images, e.g.:http://hixie.ch/resources/images/sample
If there is script that is required, remove as many functions as possible, merge functions together,put them inline instead of in functions.

STEP FOUR: GIVE THE TEST AN OBVIOUS PASS CONDITION

The final step is to make sure that the test can be used quickly. It must be possible to look at a testand determine if it has passed or failed within about 2 seconds.

There are many tricks to do this, which are covered in other documents such as the CSS2.1 Test Case


8/18

Authoring Guidelines:http://www.w3.org/Style/CSS/Test/guidelines.htmlMake sure your test looks like it has failed even if no script runs or anything. Make sure the testdoesn't look blank if it fails.

Creating testcases from scratch

STEP ONE: FIND SOMETHING TO TEST

Read the relevant specification.Read it again.Read it again, making sure you read every last bit of it, cover to cover.Read it one more time, this time checking all the cross-references.Read the specification in random order, making sure you understand every last bit of it.Now, find a bit you think is likely to be implemented wrongly.Work out a way in which a page could be created so that if the browser gets it right, the pagewill look like the test has passed, and if the browser gets it wrong, the page will look like itfailed.

Write that page.Now jump to step four above.

Test Cases & Explanation

We will not supply you with test input for most of your assignments. Part of your job will be to selectinput cases to show that your program works correctly. You should select input from the followingcategories:

Normal Test Cases: These are inputs that would be considered "normal" or "average" for your

program. For example, if your program computes square roots, you could try several positivenumbers, both less than and greater than 1, including some perfect squares such as 16 and somenumbers without rational square roots.

Boundary Test Cases: These are inputs that are legal, but on or near the boundary between legaland illegal values. For example, in a square root program, you should try 0 as a boundary cases.

Exception Test Cases:These are inputs that are illegal. Your program may give an error messageor it might crash. In a square root program, negative numbers would be exception test cases.

You must hand in outputs (saved in file form) of your test runs. In addition to handing in your actualtest runs, give us a quick explanation of how you picked them. For example, if you write a program tocompute square roots, you might say "my test input included zero, small and large positive numbers,perfect squares and numbers without a rational square root, and a negative number to demonstrateerror handling". You may give this explanation in the separate README file, or included alongside thetest cases.

You will be marked for how well the test cases you pick demonstrate that your program workscorrectly. If your program doesn't work correctly in all cases, please be honest about it. It is perfectlyvalid to have test cases which illustrate the circumstances in which your program does not yet work.


9/18

If your program doesn't run at all, you can hand in a set of test cases with an explanation of how youpicked them and what the correct output would be. Both of these will get you full marks for testing. Ifyou pick test cases to hide the faults in your program, you will lose marks.

White Box Test Case Design

Objective and Purpose

The objective of the "White Box Test Case Design" (WBTD) is to detect errors by means of execution-oriented test cases.Operational SequenceWhite Box Testing is a test strategy which investigates the internal structure of the object to beassessed in order to specify execution-oriented test cases on the basis of the program logic. In thisconnection the specifications have to be taken into consideration, though. In a test case design, theportion of the assessed object which is addressed by the test cases is taken into consideration. Theconsidered aspect may be a path, a statement, a branch, and a condition. The test cases are selectedin such a manner that the correspondingly addressed portion of the assessed object is increased.

The following White Box Test Case methods exist:

Path coverage

Statement coverage

Branch coverage

Condition coverage

Branch/condition coverage

Coverage of all multiple conditions

1. Path Coverage

Objective and PurposeIt is the objective of the path coverage to identify test cases executing arequired minimum number of paths in the object to be assessed. The executionof all paths cannot be realized as a rule.

Operational SequenceBy taking into consideration the specification, the paths to be executed and thecorresponding test cases will be defined.

2. Statement Coverage

Objective and PurposeIt is the objective of the statement coverage to identify test cases executing a

required minimum number of statements in the object to be assessed.

Operational SequenceBy taking into consideration the specification, statements are identified and thecorresponding test cases are defined. Depending on the required coveragedegree, either all or only a certain number of statements are to be used for thetest case definition.


10/18

3. Branch Coverage

Objective and PurposeIt is the objective of the branch coverage to identify test cases executing arequired minimum number of branches, i. e. at least once in the object to beassessed.

Operational SequenceBy taking into consideration the specification, a sufficiently large number of testcases must be designed by means of an analysis so both the THEN and theELSE branch are executed at least once for each decision. I. e. the exit for thefulfilled condition and the exit for the unfulfilled must be utilized and each entrymust be addressed at least once. For multiple decisions there exists theadditional requirement to test each possible exit at least once and to addresseach entry at least once.

4. Condition Coverage

Objective and PurposeThe objective of the condition coverage is to identify test cases executing arequired minimum number of conditions in the object to be assessed.

Operational SequenceBy taking into consideration the specification, conditions are identified and thecorresponding test cases are defined. The test cases are defined on the basis ofa path sequence analysis.

5. Branch/Condition Coverage

Objective and PurposeThe objective of the branch/condition coverage is to identify test cases

executing a required minimum number of branches and conditions in the objectto be assessed.

Operational SequenceBy taking into consideration the specification, branches and conditions areidentified and the corresponding test cases are defined.

6. Coverage of all Multiple Conditions

Objective and PurposeThe objective of the coverage of all multiple conditions is to identify test casesexecuting a required minimum number of all possible condition combinations

for a decision in the object to be assessed.

Operational SequenceBy taking into consideration the specification, condition combinations fordecisions are identified and the corresponding test cases are defined. Whendefining test cases it must be observed that all entries are addressed at leastonce.


11/18

Black Box Test Case Design

Objective and Purpose

The purpose of the Black Box Test Case Design (BBTD) is to discover circumstances under which the

assessed object will not react and behave according to the requirements or respectively thespecifications.

Operational Sequence

The test cases in a black box test case design are deviated from the requirements or respectively thespecifications. The object to be assessed is considered as a black box, i. e. the assessor is notinterested in the internal structure and the behavior of the object to be assessed.

It can be differentiated between the following black box test case designs:generation of equivalence classesmarginal value analysisintuitive test case definitionfunction coverage

1. Generation of Equivalence ClassesObjective and PurposeIt is the objective of the generation of equivalence classes to achieve an optional probability todetect errors with a minimum number of test cases.Operational Sequence

The principle of the generation of equivalence classes is to group all input data of a programinto a finite number of equivalence classes so it can be assumed that with any representativeof a class it is possible to detect the same errors as with any other representative of this class.

The definition of test cases via equivalence classes is realized by means of the following steps:

Analysis of the input data requirements, the output data requirements, and the conditionsaccording to the specifications

2. Definition of the equivalence classes by setting up the ranges for input and output data3. Definition of the test cases by means of selecting values for each class

When defining equivalence classes, two groups of equivalence classes have to bedifferentiated:valid equivalence classes

4. invalid equivalence classesFor valid equivalence classes, the valid input data are selected; in case of invalid equivalenceclasses erroneous input data are selected. If the specification is available, the definition ofequivalence classes is predominantly a heuristic process.

5. Marginal Value AnalysisObjective and Purpose

It is the objective of the marginal value analysis to define test cases that can be used todiscover errors connected with the handling of range margins.Operational Sequence

The principle of the marginal value analysis is to consider the range margins in connectionwith the definition of test cases. This analysis is based on the equivalence classes defined bymeans of the generation of equivalence classes. Contrary to the generation of equivalenceclasses, not any one representative of the class is selected as test case but only therepresentatives at the class margins. Therefore, the marginal value analysis represents anaddition to the test case design according to the generation of equivalence classes.


12/18

6. Intuitive Test Case DefinitionObjective and Purpose

It is the objective of the intuitive test case definition to improve systematically detected testcases qualitatively, and also to detect supplementary test cases.Operational SequenceBasis for this methodical approach is the intuitive ability and experience of human beings to

select test cases according to expected errors. A regulated procedure does not exist. Apartfrom the analysis of the requirements and the systematically defined test cases (if realized) itis most practical to generate a list of possible errors and error-prone situations. In thisconnection it is possible to make use of the experience with repeatedly occurred standarderrors. Based on these identified errors and critical situations the additional test cases willthen be defined.

7. Function CoverageObjective and PurposeIt is the purpose of the function coverage to identify test cases that can be used to proof thatthe corresponding function is available and can be executed as well. In this connection thetest case concentrates on the normal behavior and the exceptional behavior of the object tobe assessed.Operational Sequence

Based on the defined requirements, the functions to be tested must be identified. Then thetest cases for the identified functions can be defined.Recommendation

With the help of a test case matrix it is possible to check if functions are covered by severaltest cases. In order to improve the efficiency of the tests, redundant test cases ought to bedeleted.

How to Write Test Cases

To write test cases one should be clear on the specifications required for a particular case. Once thecase is decided check out for the requirments and then write test cases. For writing test cases firstyou must find Boundary Value Analysis. Let us write a test case for a Consignee Details Form.(Consignee Details : Consignee is the customer whoever to purchase our product. Here he want togive the information about himself. For example name, address and etc...)


13/18

Here is the screen shot of the form

Software Requirement Specification

According to the software requirement specification (SRS) one should write test cases upto expectedresults.

Here is the screen shot of SRS


14/18

Boundary Value Analysis:

It concentrate on range between minimum value and maximum values. It does not concentrate oncentre values.

For example how to calculate Boundary Value for Company name field

Minimum length is 4 & Maximum length is 15

For Boundary value you have to check + or minimum length and + or Maximum lengthfor Company name field minimum value =3,4,5maximum value=14,15,16

According to the Software Requirement SpecificationThe boundary values given above are

Valid values=4,5,14,15Invalid values=3,16 because this values are out of range where as given in software requirement

specification.

Test

Case

ID

Test Case

Description

Test Input Steps to

execute

test case

Expected Result Acutual

Result

Status

cd_001 CheckCompany

Company name: Enter allother data

An alert message


15/18

Test

Case

ID

Test Case

Description

Test Input Steps to

execute

test case


Result

Status

name for

mandatory

in the

CompanyDetailsform.

Click OKbutton.

Enter Companyname

cd_002 CheckCompanyname

for valid i/p

Company name:sdfgh Enter allother datain theCompanydetails

form.

Click OKbutton.

An alertmessageCompanydetails informationis stored

cd_003 CheckCompanyname forSpecialcharacters

Company name:*&^%$ Enter allother datain theCompanydetailsform.

Click OKbutton.

An alert messageCompany nameshould be incharacters

cd_004 Check forCompanyname Alphanumerics

Company name

:sdsw232

Enter allother datain theCompanydetailsform.

Click OKbutton.

An alert message

Company name

should be incharacters

cd_005 Check forCompanyname

Company name:434232 Enter allother datain the

An alert message

Company name


16/18

Test

Case

ID

Test Case

Description

Test Input Steps to

execute

test case


Result

Status

numerics Company

detailsform.

Click OKbutton.

should be incharacters

cd_006 Check forCompanynameinvalidvalues(3)

Company name:aaa Enter allother datain theCompanydetailsform.

Click OKbutton.

An alertmessageCompanyname should beatleast 4 andatmost 15characters

cd_007 CheckCompanyname forinvalidvalues(16)

Companyname:asdfghjklmnbvcxz


Click OKbutton.

An alertmessageCompanyname should beatleast 4 andatmost 15characters

cd_008 CheckCompanyname forvalidvalues(4)

Company name: asdf Enter allother datain theCompanydetailsform.

Click OKbutton.


cd_009 Check forCompanyname validvalues(5)

Company name: asdfm Enter allother datain theCompanydetailsform.



17/18

Test

Case

ID

Test Case

Description

Test Input Steps to

execute

test case


Result

Status

Click OKbutton.

cd_010 CheckCompanyname forvalidvalues(14)

Company name:asdfmvcxbnmjhg

Enter allother datain theloginpage.

Click OKbutton.


cd_011 Check forCompanyname validvalues(15)

Company name:asdfmvcxbnmjhge


Click OKbutton.


You have to write test cases for Boundary values also.For single user id field you have 11 test case including boundary value.

You have to write test cases upto expected result after getting software requirementspecification itself you can start writing a test cases.

After the creation of test cases completed.

Arrival of build will be arises to the testing field

Build->Its a complete project

After that you have to execute the test cases

EXECUTION OF TEST CASES

You have to check all the possible Test input given in test cases and then check whether all the testcases are executed or not

How to execute?

For example

whether you are checking company name as a mandatory meansyou need not give any input to Company name field and then enter password .then click OK buttonmeans.


18/18

That alert message Enter Company name: must be displayed. This was your expected result . If it ishappen while you are executing the test cases with the project .

Mandatory->compulsory

Documents

Basic Testcase Concepts