Basic Test Case 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 proving that 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 the links 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 would imply 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 relationships between 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 the tests themselves
Verifying that your site's links are not broken is relatively unambiguous. You simply need to decide which one of more of these tests best suits your site structure, your test resources, and your need for granularity 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, but points at the incorrect page, your link test won't catch the problem. My general point here is that you must understand what you are testing. A testcase is a series of explicit actions and examinations that identifies 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 site might 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 page
the link text effectively and unambiguously describes the target page
the link follows the approved style guide for this web site (for example, closing punctuation is or is not 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 on completion of the test, you can say definitively what you know works. However, this is a simple example: testcases can run to hundreds of instructions, depending on the types of functionality being tested and the need for iterations ofsteps.

Defining Test and Testcase Parameters
A testcase should set up any special environment requirements the test may have, such as clearing the browser cache, enabling JavaScript support, or turning on the warnings for the dropping of cookies.
In addition to specific configuration instructions, testcases should also record browser types and versions, operating system, machine platforms, connection speeds -- in short, the testcase should record any parameter that would affect the reproducibility of the results or could aid in troubleshooting any defects found by testing. Or to state this a little differently, specify what platforms 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 of a 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 by whom 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, network and 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 in description of what you've observed.

Sample Testcase
Here 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 text
Environment: Win 98
Test setup: N/A
Test Execution:

Open program
Open new document
Type any text
Select the text to make bold.
Click Bold

Expected Result: Applies bold formatting to the text
Actual Result: pass

Testcase definition
Define testcases in the Definition pane of the Component Test perspective. This is also where you define the hosts on which the testcases will run. Once you define the testcase element in the Definition pane, its contents appear in the Outline pane. You can add elements to the testcase's main block, and once your definition is complete you can prepare it to run and create a testcase instance.

Testcase stages
As you work with testcases in the Component Test perspective, they go through different stages, from definition to analysis. Each stage is generated from the previous one, but is otherwise unrelated: for example, although a testcase instance is generated from a testcase definition, changes to the definition will not affect the instance

Creating manual testcases
Create manual testcases to guide a tester through the steps necessary to test a component or application. Once you have created a manual testcase, you can prepare it to run.

Adding manual testcases
To add a manual testcase to the Component Test perspective, follow these steps:
1.In the Definition pane, right-click on Testcases and click: New > Testcase
2.In the New Testcase wizard, select the project you want to define the testcase in.
3.Name the project and click Next.
4.Select the Manual scheduler.
5.Click Finish to add the testcase to the Testcase folder under the selected project.
The contents of the testcase appear in the Outline pane. To start with, it contains a main block, which will organize all the other contents of the testcase.

Creating HTTP testcases
Create HTTP testcases to run methods and queries against an HTTP server. You can define HTTP testcases by importing an HTTP XML file that defines a set of interactions, or you can define it using the tasks below. Once you have defined the testcase, you can prepare it to run.
Creating Java testcases
Create Java testcases to test static Java methods by calling them and verifying the results. Once you have defined the testcase, you can generate an instance of it, and edit the instance's code to provide the logic for evaluating each task and verification point.

Adding Java testcases
To add a Java testcase to the Component Test perspective:
1.In the Definition pane, right-click on Testcases and click: New > Testcase
2.In the New Testcase wizard, select the project you want to define the testcase in.
3.Name the project and click Next.
4.Select the Java scheduler.
5.Click Finish to add the testcase to the Testcase folder under the selected project.
The contents of the testcase appear in the Outline pane. To start with, it contains a main block, which will organize all the other contents of the testcase.

Reusing testcases
You can reuse existing testcase definitions when you define new ones. This lets you define testcases for common sequences (such as logging into an application) that you can then reuse in more complex compound testcases.
To reuse a testcase:
1.Select the testcase you want to add the existing testcase to.
2.In the Outline pane, right-click the block you want to add the testcase to and click Add Testcase Definition Reference.
3.In the Add Testcase Definition Reference wizard, select the testcase you want to reuse.
4.Click Finish.
The reused testcase is incorporated by reference: its definition is still maintained separately, and the compound testcase definition will pick up changes to the testcases it reuses. However, when you create a testcase instance, the generated code for the referenced testcase definition will be stored as part of the referencing testcase instance. In other words, reuse happens only at the definition level: at the instance level, each reusing testcase creates its own copy of the reused testcases.

Test Cases & Explanation
We will not supply you with test input for most of your assignments. Part of your job will be to select input cases to show that your program works correctly. You should select input from the following categories:

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 positive numbers, both less than and greater than 1, including some perfect squares such as 16 and some numbers without rational square roots.

Boundary Test Cases: These are inputs that are legal, but on or near the boundary between legal and 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 message or 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 actual test runs, give us a quick explanation of how you picked them. For example, if you write a program to compute 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 demonstrate error handling". You may give this explanation in the separate README file, or included alongside the test cases.

You will be marked for how well the test cases you pick demonstrate that your program works correctly. If your program doesn't work correctly in all cases, please be honest about it. It is perfectly valid to have test cases which illustrate the circumstances in which your program does not yet work. If your program doesn't run at all, you can hand in a set of test cases with an explanation of how you picked them and what the correct output would be. Both of these will get you full marks for testing. If you pick test cases to hide the faults in your program, you will lose marks.

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 the specifications.
Operational Sequence
The test cases in a black box test case design are deviated from the requirements or respectively the specifications. The object to be assessed is considered as a black box, i. e. the assessor is not interested 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 classes
>Marginal value analysis
>Intuitive test case definition
>Function coverage

1. Generation of Equivalence Classes :
Objective and Purpose :
It is the objective of the generation of equivalence classes to achieve an optional probability to detect 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 program into a finite number of equivalence classes so it can be assumed that with any representative of 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 conditions according to the specifications

2. Definition of the equivalence classes by setting up the ranges for input and output data

3. Definition of the test cases by means of selecting values for each classwhen defining equivalence classes, two groups of equivalence classes have to be differentiated:
valid equivalence classes
invalid equivalence classes For valid equivalence classes, the valid input data are selected; in case of invalid equivalence classes erroneous input data are selected. If the specification is available, the definition of equivalence classes is predominantly a heuristic process.

4. Marginal Value Analysis :
Objective and Purpose :
It is the objective of the marginal value analysis to define test cases that can be used to discover errors connected with the handling of range margins.
Operational Sequence :
The principle of the marginal value analysis is to consider the range margins in connection with the definition of test cases. This analysis is based on the equivalence classes defined by means of the generation of equivalence classes. Contrary to the generation of equivalence classes, not any one representative of the class is selected as test case but only the representatives at the class margins. Therefore, the marginal value analysis represents an addition to the test case design according to the generation of equivalence classes.

5. Intuitive Test Case Definition
Objective and Purpose :
It is the objective of the intuitive test case definition to improve systematically detected test cases qualitatively, and also to detect supplementary test cases.
Operational Sequence :
Basis 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. Apart from the analysis of the requirements and the systematically defined test cases (if realized) it is most practical to generate a list of possible errors and error-prone situations. In this connection it is possible to make use of the experience with repeatedly occurred standard errors. Based on these identified errors and critical situations the additional test cases will then be defined.

6. Function Coverage Objective and Purpose
It is the purpose of the function coverage to identify test cases that can be used to proof that the corresponding function is available and can be executed as well. In this connection the test case concentrates on the normal behavior and the exceptional behavior of the object to be assessed.
Operational Sequence
Based on the defined requirements, the functions to be tested must be identified. Then the test 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 several test cases. In order to improve the efficiency of the tests, redundant test cases ought to be deleted.

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 Sequence
White Box Testing is a test strategy which investigates the internal structure of the object to be assessed in order to specify execution-oriented test cases on the basis of the program logic. In this connection the specifications have to be taken into consideration, though. In a test case design, the portion of the assessed object which is addressed by the test cases is taken into consideration. The considered aspect may be a path, a statement, a branch, and a condition. The test cases are selected in such a manner that the correspondingly addressed portion of the assessed object is increased.

The following White Box Test Case methods exist:
1. Path coverage
2. Statement coverage
3. Branch coverage
4. Condition coverage
5. Branch/condition coverage
6. Coverage of all multiple conditions

1.Path Coverage
Objective and Purpose
It is the objective of the path coverage to identify test cases executing a required minimum number of paths in the object to be assessed. The execution of all paths cannot be realized as a rule.
Operational Sequence
By taking into consideration the specification, the paths to be executed and the corresponding test cases will be defined.

2. Statement Coverage
Objective and Purpose
It 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 Sequence
By taking into consideration the specification, statements are identified and the corresponding test cases are defined. Depending on the required coverage degree, either all or only a certain number of statements are to be used for the test case definition.

3. Branch Coverage
Objective and Purpose
It is the objective of the branch coverage to identify test cases executing a required minimum number of branches, i. e. at least once in the object to be assessed.
Operational Sequence
By taking into consideration the specification, a sufficiently large number of test cases must be designed by means of an analysis so both the THEN and the ELSE branch are executed at least once for each decision. I. e. the exit for the fulfilled condition and the exit for the unfulfilled must be utilized and each entry must be addressed at least once. For multiple decisions there exists the additional requirement to test each possible exit at least once and to address each entry at least once.

4. Condition Coverage
Objective and Purpose
The objective of the condition coverage is to identify test cases executing a required minimum number of conditions in the object to be assessed.
Operational Sequence
By taking into consideration the specification, conditions are identified and the corresponding test cases are defined. The test cases are defined on the basis of a path sequence analysis.

5. Branch/Condition Coverage
Objective and Purpose
The objective of the branch/condition coverage is to identify test cases executing a required minimum number of branches and conditions in the object to be assessed.
Operational Sequence
By taking into consideration the specification, branches and conditions are identified and the corresponding test cases are defined.

6. Coverage of all Multiple Conditions
Objective and Purpose
The objective of the coverage of all multiple conditions is to identify test cases executing a required minimum number of all possible condition combinations for a decision in the object to be assessed.
Operational Sequence
By taking into consideration the specification, condition combinations for decisions are identified and the corresponding test cases are defined. When defining test cases it must be observed that all entries are addressed at least once.

Test Cases :::::

How to write TEST CASES?
To write test cases one should be clear on the specifications required for a particular case. Once the case is decided check out for the requirments and then write test cases. For writing test cases first you 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 to give the information about himself. For example name, address and etc...)

Here is the screen shot of the form


Software Requirement Specification
According to the software requirement specification (SRS) one should write test cases upto expected results.

Here is the screen shot of SRS

Boundary Value Analysis:
It concentrate on range between minimum value and maximum values. It does not concentrate on centre 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 length
for Company name field minimum value =3,4,5
maximum value=14,15,16

According to the Software Requirement Specification
The boundary values given above are

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




>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 requirement specification 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 test cases are executed or not

How to execute?>For example
whether you are checking company name as a mandatory means
you need not give any input to Company name field and then enter password .then click OK button means.
That alert message “Enter Company name:” must be displayed. This was your expected result . If it is happen while you are executing the test cases with the project .
Mandatory->compulsory

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



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 some method of recording whether or not the expected results actually occurred (i.e.) if the test case, or even 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 fact should be mentioned here. Similarly any dependency on factory outside the immediate test environment should also be mentioned.

Initialization :
If the system software or hardware has to be initialized in a particular manner in order for this Test case 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 narrative description of the Test Case, along with a Test procedure , which in turn can be specified by test case steps, tables of values or configurations, further narrative or whatever is most appropriate to the type of testing taking place.

Test Case 2


Test Case 3

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. Any modification should be automatically done.

Test Case 4 - Description

Case : Test Case Name

Component : Component Name

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 Procedure
Identify any special constrains on the test case. Focus on key elements such as special setup.

Expected Results
Fill this row with the description of the test results

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

Comments
Suggestions, description of possible improvements, etc.

Test Case 5




WEB TESTING

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. The most 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 doing this:
1. Letting someone else do it for you: Most of the time, the testcases you write will be for bugs that other 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 no problem page listed, just a problem description.
2. Alternatively, you can find a bug yourself while browsing the Web. In such cases, you will have a Web site that renders incorrectly.
3. You could also find the bug because one of the existing testcases fails. In this case, you have a Web page that renders incorrectly.
4. Finally, the bug may be hypothetical: you might be writing a test suite for a feature without knowing if the feature is broken or not, with the intention of finding bugs in the implementation of that 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 create an 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 copies you made of the files. Make sure that it still renders incorrectly in the same way -- if it doesn't, find out why not. Make your copy of the original files as close to possible as the original environment, as close as needed to reproduce the bug. For example, instead of loading the files locally, put the files on 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, embed the dependencies one by one.
For example, change markup like this:
link rel="stylesheet" href="foo.css"
...to this:

Each time you do this, check that you haven't broken any relative URIs and that the page still shows the problem. If the page stops showing the problem, you either made a mistake when embedding the external files, or you found a bug specifically related to the way that particular file was linked. Move on 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 cutting the file down.
Go to the middle of the file. Delete everything from the middle of the file to the end. (Don't pay attention to whether the file is still valid or not.) Check that the error still occurs. If it doesn't, put that part 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 of markup, 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 the text 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:
;
..with:

test

...and check that the bug still occurs.
Merge any < style > blocks together.
Change presentational markup for CSS. For example, change this:
< font color="red" >
...to:
span { color: red; } /* in the stylesheet */

Do the same with style="" attributes (remove the attributes, but it in a < style > 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< meta >elements. Remove any "lang" attributes or anything that isn't needed to show the 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 test and 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 Authoring
Guidelines:
http://www.w3.org/Style/CSS/Test/guidelines.html
Make sure your test looks like it has failed even if no script runs or anything. Make sure the test doesn'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 page will look like the test has passed, and if the browser gets it wrong, the page will look like it failed.
Write that page.
Now jump to step four above.

Note: This information is collected.

ISTQB Foundation Exam Preparation

Exam Preparation follows :

Each and every syllabus module contains :
> Description of the module.
> Content of the module.
> Module Regarding Document.
> A simple test on the module.

Fundamentals of testing :
This section looks at why testing is necessary, what testing is, explains general testing principles, the fundamental test process, and psychological aspects of testing.

1.0 Fundamentals (or) Principles of testing
1.1 Why is testing necessary
1.2 What is testing
1.3 General testing principles
1.4 Fundamental test process
1.5 Psychology of testing
Prepare a bit from here Chapter 1

Take a Small Test now :
1. Use numbers 1 to 5 to indicate which fundamental test process the following major tasks belong to:
1 for planning and control,
2 for analysis and design,
3 for implementation and execution,
4 for evaluating exit criteria and reporting, and
5 for test closure activities.

A. _____ Creating the test data
B. _____ Designing test cases
C. _____ Analyzing lessons learned
D. _____ Defining the testing objectives
E. _____ Assessing whether more tests are needed
F. _____ Identifying the required test data
G. _____ Comparing actual progress against the plan
H. _____ Preparing a test summary report
I. _____ Documenting the acceptance of the system
J. _____ Re-executing a test that previously failed

2. What should be taken into account to determine when to stop testing?
I. Technical risk
II. Business risk
III. Project constraints
IV. Product documentation

A. I and II are true; III and IV are false
B. III is true; I, II, and IV are false
C. I, II, and IV are true; III is false
D. I, II and III are true; IV is false

3. How can software defects in future projects be prevented from reoccurring?
A. Creating documentation procedures and allocating resource contingencies
B. Asking programmers to perform a thorough and independent testing
C. Combining levels of testing and mandating inspections of all documents
D. Documenting lessons learned and determining the root cause of problems

4.Use numbers 1 to 5 to indicate which fundamental test process the following major tasks belong to:

1 for planning and control,
2 for analysis and design,
3 for implementation and execution,
4 for evaluating exit criteria and reporting, and
5 for test closure activities.

K. _____ Reporting the status of testing
L. _____ Documenting the infrastructure for reuse later
M. _____ Checking the test logs against the exit criteria
N. _____ Identifying the required test environment
O. _____ Developing and prioritizing test procedures
P. _____ Comparing actual vs. expected results
Q. _____ Designing and prioritizing test cases
R. _____ Assessing whether the exit criteria should be changed
S. _____ Receiving feedback and monitoring test activities
T. _____ Handing over the testware to the operations team


Testing throughout the software lifecycle :
Explains the relationship between testing and life cycle development models, including the V-model and iterative development. Outlines four levels of testing:
• Component testing
• Integration testing
• System testing
• Acceptance testing
Describes four test types, the targets of testing:
• Functional
• Non-functional characteristics
• Structural
• Change-related
Outlines the role of testing in maintenance.

2.0 Testing throughout the life cycle
2.1 Software development models
2.2 Test levels
2.3 Test types: the targets of testing
2.4 Maintenance testing
Prepare a bit from here Chapter 2

Take a small test now :

1. What test can be conducted for off-the-shelf software to get market feedback?
A. Beta testing
B. Usability testing
C. Alpha testing
D. COTS testing

2. Fill in the Blanks now :

1. _____ are the capabilities that a component or system must perform.
2. Reliability, usability, and portability are examples of _____.
3. Hardware and instrumentation needed for testing are parts of a _____.
4. _____ is also known as structural testing.
5. _____ ignores the internal mechanisms of a system being tested.
6. Which test level tests individual components or a group of related units?
7. Which test level determines if the customer will accept the system?
8. _____ checks the interactions between components.
9. _____ is usually performed on a complete, integrated system.
10. _____ is another name for unit testing.

3. Which test levels are USUALLY included in the common type of V-model?

A. Integration testing, system testing, acceptance testing and regression testing
B. Component testing, integration testing, system testing and acceptance testing
C. Incremental testing, exhaustive testing, exploratory testing and data driven testing
D. Alpha testing, beta testing, black-box testing and white-box testing

Static techniques :
Explains the differences between the various types of review and outlines the characteristics of a formal review. Describes how static analysis can find defects.

3.0 Static techniques
3.1 Reviews and the test process
3.2 Review process
3.3 Static analysis by tools
Prepare a bit from here Chapter 3

Take a small test now :

1.Which typical defects are easier to find using static instead of dynamic testing?

L. Deviation from standards
M. Requirements defects
N. Insufficient maintainability
O. Incorrect interface specifications

A. L, M, N and O
B. L and N
C. L, N and O
D. L, M and N

2. In a formal review, who is primarily responsible for the documents to be reviewed?

A. Author
B. Manager
C. Moderator
D. Reviewers

3.What are the typical six main phases of a formal review?

Test Design Techniques :
Explains the differences between the various types of review and outlines the characteristics of a formal review. Describes how static analysis can find defects.

4.0 Test Design Techniques
4.1 Identifying test conditions and designing test cases
4.2 Categories of test design techniques
4.3 Specification-based or black box techniques
4.4 Structure-based or white box techniques
4.5 Experience-based techniques
4.6 Choosing test techniques
Prepare a bit from here Chapter 4

Take a small test now :

1. Features to be tested, approach, item pass/fail criteria and test deliverables should be specified in which document?
A. Test case specification
B. Test procedure specification
C. Test plan
D. Test design specification

Which aspects of testing will establishing traceability help?

A. Configuration management and test data generation
B. Test specification and change control
C. Test condition and test procedures specification
D. Impact analysis and requirements coverage

Test Management
This section explains how to identify test conditions (things to test) and how to design test cases and procedures. It also explains the difference between white and black box testing. The following techniques are described in some detail with practical exercises:
• Equivalence partitioning
• Boundary value analysis
• Decision tables
• State transition testing
• Statement and decision testing
In addition, use case testing and experience-based testing (such as exploratory testing) are described and advice is given on choosing techniques.

5.0 Test management
5.1 Test organisation
5.2 Test planning and estimation
5.3 Test progress monitoring and control
5.4 Configuration management
5.5 Risk and testing
5.6 Incident or bug management
Prepare a bit from here Chapter 5

Take a small test now :

1. Which of the following is a KEY task of a tester?
A. Reviewing tests developed by others
B. Writing a test strategy for the project
C. Deciding what should be automated
D. Writing test summary reports

2. Which of the following are test leader's vs. tester's tasks?
A. Adjust plans as needed
B. Analyze design documents
C. Analyze overall test progress
D. Assess user requirements
E. Automate tests as needed
F. Contribute to test plans
G. Coordinate configuration management
H. Coordinate the test strategy
I. Create test specifications
J. Decide what to automate

Tool support for testing :
Different types of tool support for testing are described throughout the course. This session summarises them, discusses how to use them effectively and how to best introduce a new tool.

6.0 Tool support for testing
6.1 Types of test tools
6.2 Effective use of tools, potential benefits and risks
6.3 Introducing a tool into an organisation
Prepare a bit from here Chapter 6


Take a small test now :

1) Match the test tool classifications to the test tools.

1. Test management—applies to all test activities
2. Static testing—facilitates static analysis in detecting problems early
3. Test specification—generates tests and prepares data
4. Test execution and logging—runs tests and provides framework
5. Performance and monitoring—observes systems behavior
6. Specialized—caters to specific environment or platform
7. Other—assists in other miscellaneous testing tasks

A. ___ Configuration management tools
B. ___ Coverage measurement tools
C. ___ Debugging tools
D. ___ Dynamic analysis tools
E. ___ Incident management tools
F. ___ Industry-specific tools
G. ___ Modeling tools
H. ___ Monitoring tools
I. ___ Performance testing tools
J. ___ Platform-specific tools

2. Which of the following are potential benefits of using test support tools?

A. Ensuring greater consistency and minimizing software project risks
B. Reducing repetitive work and gaining easy access to test information
C. Performing objective assessment and reducing the need for training
D. Allowing for greater reliance on the tool to automate the test process

Mail me for answers.
All the best :-)

Please follow this post often to see latest questions updated.

Note:- This is just for reference. Don`t not completely refer this for your exam.

Statement Coverage & Decision Coverage

ISEB Foundation Certification Syllabus Covers three TEST DESIGN TECHNIQUES,
The 3 categories are :
1) Specification based or Black box testing.
2) Structured-based or White-Box Techniques.
3) Experienced Based Techniques.

As per the request of my blog readers I would like to post the "Structured-based or White-Box Techniques" first then later on continue with other design techniques.

TEST DESIGN TECHNIQUES for Structured-based (or) White-Box Techniques are:
-> Statement Testing Coverage
-> Decision Testing Coverage

{Statement Coverage & Decision Coverage : These 2 topics are covered in ISEB foundation Syllabus in 4th chapter "TEST DESIGN TECHNIQUES".}

Structured-based or White-Box Techniques :

White Box Testing :
-> Testing based on Knowledge of internal structure and logic.
-> Logic errors and incorrect assumptions are inversely proportional to a path’s execution probability.
-> We often believe that a path is not likely to be executed, but reality is often counter intuitive.
-> Measure Coverage.

Structured-based or White-Box Techniques is based on an identified structure of the software or system, as seen in the following examples:
Component level: The structure is that of the code itdelf, ie., statements, decisions or branches.
Integration level : The structure may be a call three (a diagram in which modules call other modules).
System level : the structure may be a menu structure, bussiness process or webpage structure.

Structure-based or white-box testing can be applied at different levels of testing. Here we will be focussing on white-box testing at the code level, but it can be applied wherever we want to test the structure of something - for example ensuring that all modules in a particular system have been executed.

** Further we will discuss about two code-related structural techniques for code coverage, based on statement and dicision, are discussed.

** For decision testing, a control flow diagram may be used to visualize the alternatives for each decision.

As said earlier, I focus main on code-related structural techniques. These techniques identify paths through the code tha need to be excercised in oredr to acheive the required level of code average.

These are methods that can be deployed that can make the identification of white-box test cases easier - one method is control-flow graphing, control flow graphing uses nodes, edges and regions.. I will show them in detail with examples here..

Now comming to the actual topic :

TEST DESIGN TECHNIQUES for Structured-based (or) White-Box Techniques are:
-> Statement Testing Coverage
-> Decision Testing Coverage

1. Statement testing & Coverage :
A Statement is:
>> 'An entity in a programming language, which is typically the smallest indivisible unit of execution' (ISTQB Def).
A Statement coverage is:
>> 'The percentage of executable statements that has been exercised by a test suite' (ISTQB Def)

Statement coverage:
-> Does not ensure coverage of all functionality
->
The objective if the statement testing is to show that the executable statements within a program have been executed at least once. An executable statement can be described as a line of program sourse code that will carry out some type of action. For example:


If all statements in a program have been executed by a set of tests then 100% statement coverage has been acheived. However, if only half of the statement have been executed by a set of tests then 50% statement coverage has been acheived.

The aim is to acheive the maximum amount of statement coverage with the mimimum number of test cases.

>>Statement testing test cases to execute specific statements, normally to increase statement coverage.
>>100% statement coverage for a component is acheived by executing all of the execuatbel statements in that component.

If we require to carry out statemtnt testing, the amount of statement coverage required for the component should be stated in the test coverage requirements in the test plan.We should aim to acheive atleast the minimim coverage requirements with our test cases. If 100% statement coverage is not required, then we need to determine which ares of the component are more important to test by this method.

>>Consider the following lines of code:

>> 1 test would be required to execute all three executable statements.

If our component consists of three lines of code we will execute all with one test case, thus acheiving 100% statement coverage. There is only one way we can execute the code - starting at line number 1 and finishing at line number 3.

>>statement testing is more complicated when there is logic in the code
>>For example..

>>Here there is one executable statement i.e., "Display error message"
>> hence 1 test is required to execute all executable statements.

Program code becomes tough when logic is introduced. It is likely what a component will have to carry out different actions depending upon circumstances at the time of execution. In the code examp,e shown, the component will do different things depending on whether the age input is less than 17 or if it is 17 and above. With the statement testing we have to determine the routes through the code we need to take in order to execute the statements and the input required to get us there!

In this example, the statement will be executed if the age is less than 17, so we would create a test case accordingly.

>> For more complex logic we could use control flow graphing
>> Control flow graphs consists of nodes, edges and regions

Control flow graphs describes the logic structure if the software programs - it is a method by which flows through the program logic are charted, usign the code itseld rather than the program specification. Each flow graph nodes and egdes The nodes represent computational statements or expressions, and the edges represent transfer of control between the nodes. Together the nodes and edges encompass an area known as a region.

In the diagram, the structure represents an 'If Then Else Endif' costurct. NOdes are shown for the 'If' and the 'Endif'. Edges are shown for the 'Then' ( the true path) and the 'Else ( the false path). The region is the area enclosed by the nodes and the edges.

>>All programs consists of these basic structures..

This is hetzel notation that only shows logic flow.

There are 4 basic structures that are used withn control-flow graphong.

The 'DoWhile' structure will execute a section of code whilst a feild or indicator is set to a certain value. For example,


The 'Do until' structure will execute a section of code until a field or indicator is set to a certain value. Foe example,

The evaluation of the condition occurs after the code is executed.

The 'Go To' structure will divert the program execution to the program section in question. For example

>> SO the logic flow code could now be shown as follows:

If we applied control-flow graphing to our sample code, then 'if Then Else' structure is applicable.
However, while it shows us the structure of the code, it doesn`t show us where the executabel statements are, and so it doesn`t help us at the moment with determining the tests we required for statement coverage.

>> we can introduce extra nodes to indicate where the executable statements are

>> And we can see the path we need to travel to execute the statemen in the code.

What we can do is introduce extra nodes to indicate where the statements occur in the program code.
NOw in our example we can see that we need to answer 'yes' to the question being posed to traverse the code and execute the statement on line 2.

>> Now consider this code and control flow graph:

>> We will need 2 tests to acheive 100% statement coverage.

Program logic can be a lot more complicated than the examples I have given so far!
In the source code shown here, We have executable statements associated with each outcome of the question being asked. We have to dosplay an error message if the age is less than 17( answering 'yes' to the question), and we have display 'costomer OK' if we answer 'No'.
We can only traverse the code only once with a given test; therefore we require two tests to acheive 100% statement coverage.

>> And this example...

>> We will need 3 tests to acheive 100% statement coverage.

NOw it get even more complecated!
In this example, we have a supplementary question, or what is know as a 'nested if'. If we answer 'yes' to 'If fuel tank empty?' we then have a further question asked, and each outcome of this question has an associated statement.

Therefore we will need two tests that answer 'yes' to 'if fuel tank empty'
* Fuel tank empty AND petrol engine ( to execute line 3)
* Fuel tanl empty AND NOT petrol engine( to execute line 5)
one further test will be required where we anser 'no' to 'if fuel tank empty' to enable us to execute the statement at line 8.

>>And this will be the last example for statement coverage.. we will then go for decision coverage.

>> We will need 2 tests to acheive 100% statement coverage.

In this example,,, we ahve two saperate questions that are being asked.

The tests have shown are
* A coffee drinker who wants cream
* A non coffee drinker who doesn`t want cream

Our 2 tests acheive 100% statement coverage, but equally we could have had 2 tests with:
* A coffee drinker who doesn`t want cream
* A no-coffee drinker who wants cream

If we were being asked to acheive 100% statement coverage, and if all statements were of equal importance, it would n`t matter which set if tests we chooose.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Checking your calculation values:

Minimum tests required to acheive 100%

Decision coverage >= Statement coverage
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Decision testing & Coverage
A Decision is :
>> ' A program point at which the control flow has two or more alternative routes. A node with two or more links to saperate branches.'(ISTQB Def)
A Decision Coverageis :
>> ' The percentage if the decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage.' (ISTQB Def)

Decision Coverage :
>>

The objective of decision coverage testing is to show all the decisions within a component have been executed at least once.
A decision can be described as a line of source code that asks a question.
For example:

If all decisions within a component have exercised by a given set of tests then 100% decision coverage has been achieved. However if only half of the decisions have been taken with a given set of tests then you have only achieved 50% decision coverage.
Again, as with statement testing, the aim is to achieve the maximum amount of coverage with the minimum number of tests.

>> Decision testing derives test cases to execute specific decision outcomes, normally to increase decision coverage.
>> Decision testing is a form of control flow testing as it generates a specific flow of control through the decision points.

If we are required to carry out decision testing, the amount of decision coverage required for a component should be stated in the test requirements in the test plan.
We should aim to achieve atleast the minimum coverage requirements with our test cases. If 100% decision coverage is not required, then we need to determine which areas of the component are more important to test by this method.

>> Decision coverage is stronger than statement coverage.
>> 100% decision coverage for a component is achieved by exercising all decision outcomes int he component.
>> 100% decision coverage guarantees 100% statement coverage, but not vice versa.

Decision testing can be considered as the next logical progression from statement testing in that we are not much concerned with testing every statement but the true and false outcomes from every decision.
As we saw in our earlier examples of the statement testing, not every decision outcome has a statement( or statements) to execute.
If we achieve 100% decision coverage, we would have executed every outcome of every decision, regardless of whether there were associated statements or not..

>>Lets take earlier example we had for statement testing:

>>This would require 2 tests to achieve 100% decision coverage, but only 1 test to achieve 100% statement coverage.

In this example there is one decision, and therefore 2 outcomes.
To achieve 100% decision coverage we could have two tests:
* Age less than 17(answer 'yes')
* Age equal to or greater than 17 (answer 'no')
This is a greater number of tests than would be required for statement testing as statements are only associated with one decision outcome(line 2).

>> Again, consider this earlier example :

>> we will need 2 tests to achieve 100% decision coverage & also 2 tests to achieve 100% statement coverage.

This example would still result in two tests, as there is one decision therefore 2 outcomes to tests.
However, we would need two tests to achieve 100% statement coverage, as there are statements with each outcome of the decision.
So,in this instance, statement and decision testing would give us the same number of tests. NOte that if 100% coverage is required, statement testing can give us the same number of tests as decision testing, BUT NEVER MORE!

>>Lets look at some more examples now..

>> We will need 3 tests to achieve 100% decision coverage, but only 1 test to achieve 100% statement coverage.

Here we have an example of a supplimentary question, or a 'nested if'.
We have 2 decisions, so you may think that 4 tests may be required to achieve 100% decision coverage( two for each decision).
This is NOT the case! We can achieve 100% decision coverage with three tests - we need to exercise the 'Yes' outcome from the first decision ( line 1) twice, in order to subsequently exercise the 'Yes' and then the 'No' outcome from the supplementary question(line 2).
We need a further third test to ensure we exercise the 'No' outcome of the first decision( line 1 ).
There is only one decision outcome that has an associated statement - this means that 100% statement coverage can be achieved with one test.

>> As more statements are added, the tests for decision coverage are the same:

>> 3 tests to achieve 100% decision coverage, and 2 tests to achieve 100% statement coverage.

We have now introduced a statement that is associated with 'No' outcome of the decision on line 2.
This change affects the number of tests required to achieve 100% statement coverage, but does NOT alter the number of tests required to achieved 100% decision coverage - it is still three!

>And again an example..

>> 3 tests to achieved both decision and statement coverage.

Finally, we have statements associated with each outcome of each decision - the number of tests to achieve 100% statement coverage and 100% decision coverage are now the same.

>> And Last Example..

>> We will need 2 tests to achieve 100% decision coverage and 100% statement coverage.

We looked at this example of the "if Then Else' structure when considering statement testing.
As the decisions are separate questions we only need two tests to achieve 100% decision coverage( the same as the number required for statement coverage).
You may have thought that four tests were required - exercising the four different routes through the code, but remember, with decision testing our concern is to exercise each outcome of each decision atleast once - as long as we have answered 'Yes' and 'No' to each decision we have satisfied the requirements of the techinique.
The tests we have illustrated would need the following input conditions:
* Coffee drinker wanting cream.
* Non Coffee drinker not wanting cream ( but milk).

Equally, we could have chosen the following input conditions:
* Coffee drinker not wanting cream( but milk).
* Non coffee drinker wanting cream.

>> Then What about loops?

>> If we choose an initial value of p=4, we only need 1 test to achieve 100% statement and 100% decision coverage.

The control-flow graphs we showed earlier depicted a 'Do While' construct.
To reiterate, thw 'Do While' structure will execute a section of code whist a field or indicator is set to a certain value. For example,

The evaluation of the condition occurs before the code is executed.

Unlike the 'If Then Else', we can loop around the 'Do While' structure, which means that we exercise different routes through the code with one test.
As in the above diagram, if we set 'p' with an initial value '4', the first time through the code will :
* Go from line 1 to line 2
* Answer 'Yes' to the 'If' on line 2 ( if p<5)
* Execute the statement in line 3 (p=p*2, so p now equals 8)
* Go from line 3, through line 4 to line 5
* Execute the statement on line 5 ( which adds 1 to 'p', making it`s value '9')
* Execute the statement on line 6, which takes it back up to line 1.

Again we execute the code, with the value of 'P' now '9'
* GO from line1 to line2
* Answer 'NO' to the 'if' on line 2 (If p>5)
* Go from line 4 to line 5
* Execute the statement on line 5( which adds 1 to 'p', making it`s value '10')
* Execute the statement on line 6, which takes it back up to line 1.

Once more we execute the code
* Line 1 - 'P' is not less than '10' ( it is equal to 10), therefore, we exit this structure.

1 test - it achieves 100% statement coverage and 100% decision coverage.

>> And it`s same for 'Do until' structure

>> IF we choose an initial value of A =15, we only need 1 test to achieve 100% Decision coverage and 100% statement coverage.

The control flow structures we showed earlier also depicted a 'Do Until' structure.
To reiterate, the 'Do Until' structure will execute a section of code until a field or indicator is set to a certain value. For example,

The evaluation of the condition occurs after the code is executed.
Unlike the 'If Then Else', we can loop around the 'Do Until' structure, which means that we exercise different routes through the code with one test.
In the example above, If we set 'A' with an initial value of '15', the first time through the code will:
* Go from line 1 to line 2
* Answer 'Yes' to the 'If' on line 2 (If A<20)
* Execute the statement on line 3 ( A=A*2,which makes A=30)
* GO from line 3, through the line 4 to line 5
* Execute the statement on line 5( which adds 1 to 'A', making its value '31'.
* Execute the statement on line 6, Which takes back to line 1

Again we execute the code, with the value of 'A' now '31'
* Go from line 1 to line 2
* Answer 'No' to the 'If' on line 2 (If A < 20)
* Go from line 2, through line 4 to line 5
* Execute the statement on line 5( which adds 1 to 'A', making it`s value '32')
* Execute the statement on line 6, which exits the structure('A' is greater than 31)

1 test - it achieves 100% statement coverage and 100% decision coverage.

END...

Tester’s Aptitude/Knowledge Test

Note : This is not a ISEB/ISTQB certification sample test.But, this test is for all who have knowledge and experience in software testing. According to the marks your grade is decided. Read further..

Introduction

The tester’s aptitude test has been compiled to assist the test manager/team leader in the recruiting of good quality testers. This test should be used in conjunction with other interviewing techniques.

Structure
The test comprises of 25 questions, each carrying different marks. The questions have been designed to test a broad knowledge of testing from scenario testing to specific questions on testing tools.

Marking
Total number of questions 25..

• D.-.Score less than 50% - Fail
• C.-.Score 50% to 65% - Trainee Tester
• B.-.Score 65% to 80% - Tester
• A.-.Score more than 80% - Senior Tester

Questions :

1.What statement do you consider to be most important and why?
a) Testing has the primary intent of showing the system meets the users needs.
b) Testing has the primary intent of finding faults

2.You have run all your tests and they all pass. Is this good news or bad news?

3.What would you do if you were asked to test a system which is unfamiliar to you has out-of-date or inadequate documentation?

4.In running a test you find the actual result does not match the expected result – what would you do?

5.Do you consider positive or negative testing to be most important or trying to break the system - and why?

6.How would you define a good test?

7.You have been assigned to test the new Triangle Determination Application (see screen shot below).

As you can see the screen consists of three text fields and a single button. The user is expected to enter an integer value into each of the three text fields. Upon hitting the OK button the program will print a message in a separate dialog box stating whether the triangle is scalene (all sides are different lengths), isosceles (two sides are the same length), or equilateral (all three sides are the same length).

Write a set of test cases (i.e. specific sets of data) that you feel would adequately test this program. Write the tests so that someone other than you can run them.

8.In testing the above application you identify what you believe to be a fault – instead of printing the message concerning the type of triangle in a separate dialog box the application is printing the message in the space between the 3 text fields and the OK button. What should your next step be (answer and state why)?
a) Continue testing to the end of the script, and then report the bug.
b) Stop testing, report the bug immediately, then continue alternative scripts
c) Stop testing, report the bug and await a fix.
d) Continue testing and report the bug later, along with those found in other scripts

9.You have raised a fault, but Development are unable to reproduce it. What should your next step be? (Give answer and state why)
a) Let development sign off the bug as not reproducible.
b) Sign off the bug yourself as not reproducible.
c) Tell development the bug definitely exists and you will not pass it unless fixed.
d) Re-test and upon confirmation provide more detailed information to Development, talking them through each stage if necessary.

10.Scenario:
You have two sets of tests to run on the new version of the software.
Test Set 1: a test set to provide confidence that software has not regressed from the previous version.
Test Set 2: a detailed test set to investigate potential faults in the new release of software.
Having run test set 1 you discover a number of faults in the new version of software – what do you do?

11.Draw and explain the ‘V’ Model and how testing fits into the Development Lifecycle. Indicate on the model where you would design your tests.

12.Describe the stages of testing and what the objectives are at each stage.

13.Explain what you understand by the terms:
Regression Testing and Re-Testing

14.Scenario:
You have planned to run 600 tests on your own. Each test will take approximately 10 minutes to run. Your manager has told you that you must complete these tests within one week. What would you do?

15.Do you consider testing tools to be valuable during the testing process – why/why not?

16.List 3 test tool categories and describe what each can do.

17.Name 2 standards that refer to testing

18.How would you test these requirements:
a) The system must be user-friendly
b) The system must be easy to install
c) The following response times are to be achieved with the new system:
• Initial loading of the web application must be achieved within 3 seconds
• Updating of the information on the web page must be no more than 5 seconds

19.Why do you consider testing to be necessary?

20.A hotel telephone system can perform 3 functions:
• Call another hotel room by entering a room number (201 to 500)
• Call an external line by entering a 9, followed by the number
• Call various hotel services
• 0 = Operator
• 7 = Room Service
• 8 = Reception
Write a set of test cases to adequately test this telephone system

21.Describe what you understand about the term “Static Testing” and list 3 static testing techniques.

22.How would you prioritise your tests (list 5)?

23.Scenario:
You are testing 2 programs and have 3 weeks to test them both. Having run all of your tests on both programs you finish testing within 2 weeks. You need to decide which of the 2 programs you would re-visit and run further tests against. Choose which program you would re-test (can choose only one!) – and state you reasons:
Program A
Programmer: A
Complexity Level: 2
Lines of Code: 2000
Number of tests: 100
Number of bugs found: 10
(1 high severity, 3 medium & 6 low)
Program B
Programmer: B
Complexity Level: 2
Lines of Code: 2000
Number of tests: 100
Number of bugs found: 50
(10 high severity, 25 medium & 15 low)

24.An ATM has been specified to work in the following way:
Enter a card and if the card is invalid reject the card and exit system. If it is a valid card then enter a PIN number. Check to see if the PIN is invalid – if it is then display a message ‘invalid pin number, please re-enter’. If 3 attempts are made with an invalid pin then the machine keeps the card. If it is a valid PIN then the user can select one of the following transactions:
• Cash Withdrawal without receipt
• Cash Withdrawal with receipt
• Balance Enquiry
• Statement request
• Cancel
What tests would you produce to test this application? State any assumptions when testing

25.The following is an extract from a fault log, write down any potential problems or omissions with this:


So now its time to compare your answers with the actual answers..

1.They are both accurate! The purpose of testing is to find faults AND ensure it meats the users needs (fit for purpose).

2.It depends on how good your tests were and what they were testing. To have justified confidence in the software we must have confidence in our tests, data and environment.

3.Talk to users, developers and analysts to understand what the system is supposed to do.
Document this understanding and get it reviewed and use this as a substitute for the Requirements/Design documentation.
Talk with testers who have tested the system previously
Read whatever is available and clarify assumptions

4.The tester should first establish whether the reason is because of a test fault (i.e. they have made a mistake) or whether it is an environment fault. If neither of these are true then they should then check to see whether this fault has already been raised. If not then either raise the fault or more preferable – talk to the development group to check the fault out.

5.They are as important as each other. However testers need to have a different mindset to developers and therefore should actively look for potential faults. If we only concentrate on positive tests (show that the system does what it should do) then we will potentially experience problems when the system goes live. If we only concentrate on negative tests (showing the system doesn’t do what it shouldn’t) then again we could potentially miss significant faults. However if we look primarily at breaking the system then we may find lots of faults (the what if scenarios) but we may not establish if the system is going to meet the users needs and requirements. A balance is needed with all three approaches.

6. A good test is one that can potentially find a fault in the system. If this test does not find a fault then it will give us a certain amount of confidence.
Tests must also be efficient – we should not have tests which all do the same thing.

7.Do you have a test case:
1. for a valid scalene triangle?
2. for a valid equilateral triangle?
3. for a valid isosceles triangle?
4. for each of the three permutations of two equal sides in valid isosceles triangles?
5. in which one side has a length of zero?
6. in which one side has a negative length?
7. in which the sum of the length of two sides is equal to the length of the third?
8. for each of the three permutations of case 7?
9. in which the sum of the length of two sides is less than the length of the third?
10. for each of the three permutations of case 9?
11. in which all side lengths are zero?
12. which uses non-integer input values?
13. which uses the wrong number of input values?
14. did all your test cases specify the expected output?
Myers states that experienced professional programmers score on average 7.8 out of the first 14 questions. Extra points can be given for further tests such as performance, reliability and configuration.

8.This is not a serious problem. The message is being printed. The best solution would be (a) or (d) – it is essential that faults be raised as soon as possible so that Development can fix them. However this is dependent on the severity and priority of the fault. This fault is not stopping any further testing on this script – it might be that other similar problems occur with other messages and this extra information might assist development with further investigation

9.The answer is (d) – it might be our environment or it could have been fixed by some other fault fix in the new version.

10.First we should investigate the faults – is it because we had run our tests wrongly, or that we were running the tests on the wrong environment?
Assuming that it is because the software has regressed – then we must establish the nature of the faults and severity of the faults.
It is probably inefficient to run any further tests at this stage. We should work with development in getting a new version of the software with the faults fixed and re-tested before running test set 2.

11.


The key aspect here is that testing should happen throughout the Development Lifecycle. Also designing of the test cases should happen as soon as possible.

12. Component Testing
Lowest level of testing, detail, finding faults, performed by the developers
Component Integration
Combining components, testing interfaces, performed by developers, various types of integration (top-down, functional, bottom up and big bang). Business scenarios and non-functional aspects if possible.
System Testing (functional and non-function)
Testing the system as a whole. Testing requirements and business processes. Also testing non-functional aspects such as Performance, usability etc.
System Integration
Testing the system with other systems and networks
Acceptance Testing
Testing by users/customers to gain confidence that the system is going to support the business as well as meet their requirements.

13.Regression Testing:
Running tests to ensure that the software has not regressed in anyway as a result of changes to the software and/or environment. Regression testing is running passed tests again to ensure that they still pass.
Re-Testing
This is running a test again that had found a fault to check that the fault has been fixed correctly. Re-testing is running a failed test again to ensure that it now passes.

14.Assuming there are 7hours per working day. This task would take you:
600x10 = 6000 minutes = 100 hours = 14.286 days
There are a number of options that could be considered:
􀂉 Work overtime (this should not be considered as a first resort)
􀂉 Ask for more staff to help (again this may not be the best approach, particularly if you need to spend time training and mentoring the new staff)
WE SHOULD:
􀂉 Re-prioritise our tests and run the most important tests first
􀂉 Assuming that not all the 600 tests would have been run within this time, risk assessment need to be made as to the consequences of not running the extra tests.
􀂉 After this initial week and the system is implemented there is no reason why the extra tests could not be run (assuming that you are given the time)

15.Testing tools are very important to assist the tester in their work. Using tools can also potentially make the tester more efficient in their work – they are able to run more tests (using regression testing for example). Or they can quickly compare 3 reports (comparison tool).
The tools in themselves however do not make good testers and also should not be considered if the test process is in ‘chaos’.

16.􀂉 Requirement Testing Tools
􀂉 Test Design Tools
􀂉 Test Data Preparation Tools
􀂉 Regression Testing tools
􀂉 Debug Tools
􀂉 Dynamic Analysis Tools
􀂉 Coverage Measurement Tools
􀂉 Static Analysis Tools
􀂉 Performance Testing Tools
􀂉 Test Management Tools
􀂉 Network monitoring tools
􀂉 Test Harness or Simulation tools
The importance of this question is to see if the candidate has any knowledge about tools. We do not want the names of tools but want to know if the candidate can distinguish between the types of tool.

17.Any of the following:
BS 7925-1 (Glossary of testing terms), BS7925-2 (Component Testing), ISO9000 and ISO9001 (Quality standards), IEEE829 (Test Documentation), IEEE1028 (Reviews), IEEE1044 (Incidents)

18.How would you approach these requirements:
a) The system must be user-friendly
What do we mean by ‘user-friendly’? Questions to ask:
􀂉 Friendly to whom?
􀂉 Who are the users?
Test approaches:
􀂉 Talk to the users
􀂉 Document assumptions
􀂉 Compile test scenarios for people who have not seen the system
􀂉 Document tests and review these with the users

b) The system must be easy to install
What do we mean by ‘easy? Questions to ask:
􀂉 For whom?
􀂉 Is there any installation documentation to follow?
Test approaches:
􀂉 Follow installation documentation (if there is any)
􀂉 Allow tests to be run by an inexperienced user to see how easy it is
􀂉 Document tests and review these with the users

c) The following response times are to be achieved with the new system:
• Initial loading of the web application must be achieved within 3 seconds
• Updating of the information on the web page must be no more than 5 seconds
Once more we need to ask some probing questions surrounding this requirement:
􀂉 What happens if we don’t meet the times?
􀂉 Would a range of values be better?
􀂉 What is happening on the network?
􀂉 Are these average times or are they ‘peak’ times?
􀂉 What is involved in updating – how much information?
In attempting to test this requirement we would document the exact criteria for the test and the simplest way would be to time a number of tests and supply the average.

With all these 3 requirements, what we are looking for is to see whether the potential tester will challenge the requirements of whether they would just accept them and try to test to the best of their ability.

19.􀂉 There are faults in the software
􀂉 Failures in live operation can be expensive
􀂉 Sometime a ‘legal’ or contractual requirement
􀂉 To asses the quality of the software
􀂉 To preserve the quality of the software
􀂉 To help achieve quality software (by finding and removing the faults)

20.

21.Static Testing is non-execution of the code. Techniques include; reviews, inspections, walkthroughs, individual techniques such as desk checking, data-stepping and proofreading. There is also static analysis (data flow and control flow analysis)

22.
• ask the customer to prioritise the requirements
• ask the customer to prioritise the tests
• what is most critical to the customer’s business
• test where a failure would be most severe
• test where failures would be most visible
• test where failures are most likely
• areas changed most often
• areas with most problems in the past
• most complex areas, or technically critical

23.Key points:
1. Different programmers wrote A and B
2. Complexity level of the programs are the same
3. Size of the programs are the same
4. Tester is the same for testing A and B
5. Number of tests run on both programs is the same
6. Number of bugs is higher in program B
Program B seems to have far more faults therefore we would be inclined to spend the further week testing Program B, as there is likely to be more bugs to find. We may also not be very confident at this point with Program B therefore we need to see our confidence increased.

24.1. Invalid Card – reject card and exit
2. Valid Card and Invalid PIN – error message ‘invalid pin…’ (then enter valid pin)
3. Valid Card and Invalid PIN – error message ‘invalid pin…’ (then enter another 2 invalid Pins)
4. Valid Card, Valid Pin & Cancel (correct length pin)
5. Valid Card, Valid Pin in a large number – but the pin number contains more than the maximum number – should error
6. Valid Card, Valid Pin & Cash Withdraw without receipt
7. Valid Card, Valid Pin & Cash Withdraw with receipt
8. Valid Card, Valid Pin & Balance enquiry
9. Valid Card, Valid Pin & Statement Request
10. Destructive tests include:
• Putting in 2 cards
• Putting correct pin, but adding an extra number to make invalid
Assumptions:
1. Can insert up to 3 invalid pins and machine retains card
2. Can only select one transaction and then have to re-insert card
3. Pressing cancel will return card

25.Potential Problems/Omissions
􀂉 No date on log as to when raised
􀂉 No keywords (i.e. screen) so that searches can be performed preventing duplication of fault logs
􀂉 No status of the log (opened/fixed/closed/cleared etc.)
􀂉 No owner of the log.
􀂉 Has priority – but no severity (i.e. risk to the customer)
􀂉 No version number of the system being tested – it is very likely that the testers are on a different version to development and that it was a fault but has been inadvertently fixed on this latest software
􀂉 Query the priority of this log (should it be a 3?)
􀂉 No actual error message on the log – this may give some clue to the developer about the nature of the fault
􀂉 Response seems to be leading to a dialogue – if we are not careful this fault will never be fixed! Tester should talk to the developer rather than sending another message via the fault log.
􀂉 The response by the developer points to another part of the system (security) – this may be an indication of developers trying to quickly close the issue without performing sufficient investigation. It could however be because the tester has not spent enough time documenting the problem.

NOW WHAT IS THE RESULT
• D.-.Score less than 50% - Fail
• C.-.Score 50% to 65% - Trainee Tester
• B.-.Score 65% to 80% - Tester
• A.-.Score more than 80% - Senior Tester