ShailajaKiran

Sample Paper

2008-07-25T02:55:00.000-07:00

1 Which of the following is a major task of test planning?
A Determining the test approach.
B Preparing test specifications.
C Evaluating exit criteria and reporting.
D Measuring and analyzing results.

2 Which of the following statements is MOST OFTEN true?
A Source-code inspections are often used in component testing.
B Component testing searches for defects in programs that are separately testable.
C Component testing is an important part of user acceptance testing.
D Component testing aims to expose problems in the interactions between software and hardware components.

3 In a system designed to work out the tax to be paid: An employee has £4000 of salary tax free.
The next £1500 is taxed at 10%.
The next £28000 after that is taxed at 22%.
Any further amount is taxed at 40%.
To the nearest whole pound, which of these groups of numbers fall into three DIFFERENT equivalence classes?

A £4000; £5000; £5500.
B £32001; £34000; £36500.
C £28000; £28001; £32001.
D £4000; £4200; £5600.

4 Which of the following will NOT be detected by static analysis?
A Parameter type mismatches.
B Errors in requirements.
C Undeclared variables.
D Uncalled functions.

5 Which of the following test activities can be automated? i Reviews and inspections.
ii Metrics gathering.
iii Test planning.
iv Test execution.
v Data generation.

A i, iii, iv.
B i, ii, iii.
C ii, iv, v.
D ii, iii, v.

6 Which of the following is an objective of a pilot project for the introduction of a testing tool?
A Evaluate testers’ competence to use the tool.
B Complete the testing of a key project.
C Assess whether the benefits will be achieved at reasonable cost.
D Discover what the requirements for the tool are.

7 What is the MAIN purpose of a Master Test Plan?
A To communicate how incidents will be managed.
B To communicate how testing will be performed.
C To produce a test schedule.
D To produce a work breakdown structure.

8In a REACTIVE approach to testing when would you expect the bulk of the test design work to be begun?
A After the software or system has been produced.
B During development.
C As early as possible.
D During requirements analysis.

9 What is the objective of debugging? i To localise a defect.
ii To fix a defect.
iii To show value.
iv To increase the range of testing.

A i, iii.
B ii, iii, iv.
C ii, iv.
D i, ii.

10 Given the following decision table

What is the expected result for each of the following test cases?A.TC1: Fred is a 32 year old smoker resident in London
B.TC3: Jean-Michel is a 65 year non-smoker resident in Paris

A A – Insure, 10% discount, B – Insure, no discount.
B A – Don’t insure, B – Don’t insure.
C A – Insure, no discount, B – Don’t insure.
D A – Insure, no discount, B – Insure with 10% discount.

11 Which of the following are valid objectives for testing?
i.To find defects.
ii.To gain confidence in the level of quality.
iii.To identify the cause of defects.
iv.To prevent defects.

A i,ii, and iii.
B ii, iii and iv.
C i, ii and iv.
D i,iii and iv.

12 The process of designing test cases consists of the following activities:
i. Elaborate and describe test cases in detail by using test design techniques.
ii. Specify the order of test case execution.
iii. Analyse requirements and specifications to determine test conditions.
iv. Specify expected results.
According to the process of identifying and designing tests, what is the correct order of these activities?

A iii, i, iv, ii.
B iii, iv, i, ii.
C iii, ii, i, iv.
D ii, iii, i, iv.

13 What is the main purpose of impact analysis for testers?
A To determine the programming effort needed to make the changes.
B To determine what proportion of the changes need to be tested.
C To determine how much the planned changes will affect users.
D To determine how the existing system may be affected by changes.

14Which of the following requirements would be tested by a functional system test?
A The system must be able to perform its functions for an average of 23 hours 50 mins per day.
B The system must perform adequately for up to 30 users.
C The system must allow a user to amend the address of a customer.
D The system must allow 12,000 new customers per year.

15 In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free.
The next £1500 is taxed at 10%.
The next £28000 after that is taxed at 22%.
Any further amount is taxed at 40%.To the nearest whole pound, which of these is a valid Boundary Value Analysis test case?

A £28000.
B £33501.
C £32001.
D £1500.

16 Which of the following defines the sequence in which tests should be executed?
A Test plan.
B Test procedure specification.
C Test case specification.
D Test design specification.

17 Given the following state transition

Which of the following series of state transitions below will provide 0-switch coverage?

A A, B, E, B, C, F, D.
B A, B, E, B, C, F, F.
C A, B, E, B, C, D.
D A, B, C, F, F, D.

18 Given the following decision table

What is the expected result for each of the following test cases?
A. Frequent flyer member, travelling in Business class
B. Non-member, travelling in Economy class

A A – Don’t offer any upgrade, B – Don’t offer any upgrade.
B A – Don’t offer any upgrade, B – Offer upgrade to Business class.
C A – Offer upgrade to First, B – Don’t offer any upgrade.
D A – Offer upgrade to First, B – Offer upgrade to Business class.

19 During which fundamental test process activity do we determine if MORE tests are needed?
A Test implementation and execution.
B Evaluating test exit criteria.
C Test analysis and design.
D Test planning and control.

20 What is the difference between a project risk and a product risk?
A Project risks are potential failure areas in the software or system; product risks are risks that surround the
project’s capability to deliver its objectives.
B Project risks are the risks that surround the project’s capability to deliver its objectives; product risks are
potential failure areas in the software or system.
C Project risks are typically related to supplier issues, organizational factors and technical issues; product risks
are typically related to skill and staff shortages.
D Project risks are risks that delivered software will not work; product risks are typically related to supplier issues,
organizational factors and technical issues.

21 Given the following specification, which of the following values for age are in the SAME equivalence partition?
If you are less than 18, you are too young to be insured.
Between 18 and 30 inclusive, you will receive a 20% discount.
Anyone over 30 is not eligible for a discount.

A 17, 18, 19.
B 29, 30, 31.
C 18, 29, 30.
D 17, 29, 31.

21 Considering the following pseudo-code, calculate the MINIMUM number of test cases for statement coverage, and the MINIMUM number of test cases for decision coverage respectively.

READ A
READ B
READ C
IF C>A THEN
IF C>B THEN
PRINT "C must be smaller than at least one number"
ELSE
PRINT "Proceed to next stage"
ENDIF
ELSE
PRINT "B can be smaller than C"
ENDIF

A 3, 3.
B 2, 3.
C 2, 4.
D 3, 2.

23 Which of the following is a benefit of independent testing?
A Code cannot be released into production until independent testing is complete.
B Testing is isolated from development.
C Developers do not have to take as much responsibility for quality.
D Independent testers see other and different defects, and are unbiased.

24 Which of the following tools is most likely to contain a comparator? A Dynamic Analysis tool.
B Test Execution tool.
C Static Analysis tool.
D Security tool.

25 Given the following State Table:

Which of the following represents an INVALID state transition?

A E from State S2.
B E from State S3.
C B from State S1.
D F from State S3.

26 Which of the following is a characteristic of good testing in any life cycle model?
A All document reviews involve the development team.
B Some, but not all, development activities have corresponding test activities.
C Each test level has test objectives specific to that level.
D Analysis and design of tests begins as soon as development is complete.

27 Which activity in the fundamental test process includes evaluation of the testability of the requirements and system?
A Test analysis and design.
B Test planning and control.
C Test closure.
D Test implementation and execution.

28 The following statements are used to describe the basis for creating test cases using either black or white box techniques:
i information about how the software is constructed.
ii models of the system, software or components.
iii analysis of the test basis documentation.
iv analysis of the internal structure of the components.Which combination of the statements describes the basis for black box techniques?

A ii and iii.
B ii and iv.
C i and iv.
D i and iii.

29 What is typically the MOST important reason to use risk to drive testing efforts?
A Because testing everything is not feasible.
B Because risk-based testing is the most efficient approach to finding bugs.
C Because risk-based testing is the most effective way to show value.
D Because software is inherently risky.

30 Which of the following defines the scope of maintenance testing?
A The coverage of the current regression pack.
B The size and risk of any change(s) to the system.
C The time since the last change was made to the system.
D Defects found at the last regression test run.

31 Which is the MOST important advantage of independence in testing?
A An independent tester may find defects more quickly than the person who wrote the software.
B An independent tester may be more focused on showing how the software works than the person who wrote
the software.
C An independent tester may be more effective and efficient because they are less familiar with the software
than the person who wrote it.
D An independent tester may be more effective at finding defects missed by the person who wrote the software.

32 For testing, which of the options below best represents the main concerns of Configuration Management?
i. All items of testware are identified and version controlled;
ii. All items of testware are used in the final acceptance test;
iii. All items of testware are stored in a common repository;
iv. All items of testware are tracked for change;
v. All items of testware are assigned to a responsible owner;
vi. All items of testware are related to each other and to development items.

A i, iv, vi.
B ii, iii, v.
C i, iii, iv.
D iv, v, vi.

33 Which of the following would be a valid measure of test progress?
A Number of undetected defects.
B Total number of defects in the product.
C Number of test cases not yet executed.
D Effort required to fix all defects.

34 Which of following statements is true? Select ALL correct options
Regression testing should be performed:
i once a month
ii when a defect has been fixed
iii when the test environment has changed
iv when the software has changed

A ii and iv.
B ii, iii and iv.
C i, ii and iii.
D i and iii.

35 In which of the following orders would the phases of a formal review usually occur?
A Planning, preparation, kick off, meeting, rework, follow up.
B Kick off, planning, preparation, meeting, rework, follow up.
C Preparation, planning, kick off, meeting, rework, follow up.
D Planning, kick off, preparation, meeting, rework, follow up.

36 Which of the following are valid objectives for incident reports?
i. Provide developers and other parties with feedback about the problem to enable identification, isolation and correction as necessary.
ii. Provide ideas for test process improvement.
iii. Provide a vehicle for assessing tester competence.
iv. Provide testers with a means of tracking the quality of the system under test.

A i, ii, iii.
B i, ii, iv.
C i, iii, iv.
D ii, iii, iv.

37 Consider the following techniques. Which are static and which are dynamic techniques?
i. Equivalence Partitioning.
ii. Use Case Testing.
iii.Data Flow Analysis.
iv.Exploratory Testing.
v. Decision Testing.
vi Inspections.

A i-iv are static, v-vi are dynamic.
B iii and vi are static, i, ii, iv and v are dynamic.
C ii, iii and vi are static, i, iv and v are dynamic.
D vi is static, i-v are dynamic.

38 Why are static testing and dynamic testing described as complementary?
A Because they share the aim of identifying defects and find the same types of defect.
B Because they have different aims and differ in the types of defect they find.
C Because they have different aims but find the same types of defect.
D Because they share the aim of identifying defects but differ in the types of defect they find.

39 Which of the following are disadvantages of capturing tests by recording the actions of a manual tester?
i The script may be unstable when unexpected events occur.
ii Data for a number of similar tests is automatically stored separately from the script.
iii Expected results must be added to the captured script.
iv The captured script documents the exact inputs entered by the tester.
v When replaying a captured test, the tester may need to debug the script if it doesn’t play correctly.
A i, iii, iv, v.
B ii, iv and v.
C i, ii and iv.
D i and v.

40 Which of the following is determined by the level of product risk identified?
A Extent of testing.
B Scope for the use of test automation.
C Size of the test team.
D Requirement for regression testing.

Answers
Q No Ans
1. A
2. B
3. D
4. B
5. C
6. C
7. B
8. A
9. D
10. C
11. C
12. A
13. D
14. C
15. B
16. B
17. A
18. C
19. B
20. B
21. C
22. A
23. D
24. B
25. B
26. C
27. A
28. A
29. A
30. B
31. D
32. A
33. C
34. B
35. D
36. B
37. B
38. D
39. A
40. A

Sample Paper 9

2008-07-16T03:20:00.000-07:00

1. Deciding How much testing is enough should take into account :-
i. Level of Risk including Technical and Business product and project risk
ii. Project constraints such as time and budget
iii. Size of Testing Team
iv. Size of the Development Team

a) i,ii,iii are true and iv is false
b) i,,iv are true and ii is false
c) i,ii are true and iii,iv are false
d) ii,iii,iv are true and i is false

2. Test planning has which of the following major tasks?
i. Determining the scope and risks, and identifying the objectives of testing.
ii. Determining the test approach (techniques,test items, coverage, identifying and interfacing the teams involved in testing , testware)
iii. Reviewing the Test Basis (such as requirements,architecture,design,interface)
iv. Determining the exit criteria.

a) i,ii,iv are true and iii is false
b) i,,iv are true and ii is false
c) i,ii are true and iii,iv are false
d) ii,iii,iv are true and i is false

3. Evaluating testability of the requirements and system are a part of which phase:-
a) Test Analysis and Design
b) Test Planning and control
c) Test Implementation and execution
d) Evaluating exit criteria and reporting

4. One of the fields on a form contains a text box which accepts alphabets in lower or upper case. Indentify the invalid Equivalance class value.
a. CLASS
b. cLASS
c. CLass
d. CLa01ss

5. In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10% The next £28000 is taxed at 22% Any further amount is taxed at 40% Which of these groups of numbers would fall into the same equivalence class?
a) £4800; £14000; £28000
b) £5200; £5500; £28000
c) £28001; £32000; £35000
d) £5800; £28000; £32000

6. Which of the following has highest level of independence in which test cases are :
a) Designed by persons who write the software under test
b) Designed by a person from a different section
c) Designed by a person from a different organization
d) Designed by another person

7. We use the output of the requirement analysis, the requirement specification as the input for writing :-
a) User Acceptance Test Cases
b) Integration Level Test Cases
c) Unit Level Test Cases
d) Program specifications

8. Validation involves which of the following
i. Helps to check the Quality of the Built Product
ii. Helps to check that we have built the right product.
iii. Helps in developing the product
iv. Monitoring tool wastage and obsoleteness.

a) Options i,ii,iii,iv are true.
b) ii is true and i,iii,iv are false
c) i,ii,iii are true and iv is false
d) iii is true and i,ii,iv are false.

9. Which of the following uses Impact Analysis most?
a) Component testing
b) Non-functional system testing
c) User acceptance testing
d) Maintenance testing

10. What is the expected result for each of the following test cases?

A. Citibank card member, holding a Silver room
B. Non Citibank-member, holding a Platinum room

a) A – Don’t offer any upgrade, B – Don’t offer any upgrade.
b) A – Don’t offer any upgrade, B – Offer upgrade to Gold.
c) A – Offer upgrade to Silver, B – Offer upgrade to Silver.
d) A – Offer upgrade to Gold, B – Don’t offer any upgrade.

11. Repeated Testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the changes in the software being tested or in another related or unrelated software component:
a) Re Testing .
b) Confirmation Testing
c) Regression Testing
d) Negative Testing

12. Impact Analysis helps to decide :-a) How much regression testing should be done.
b) Exit Criteria
c) How many more test cases need to written.
d) Different Tools to perform Regression Testing

13. Functional system testing is:
a) testing that the system functions with other systems
b) testing that the components that comprise the system function together
c) testing the end to end functionality of the system as a whole
d) testing the system performs functions within specified response times

14. Consider the above state transition diagram of a switch.
Which of the following represents an invalid state transition?
a) OFF to ON
b) ON to OFF
c) FAULT to ON

15. Peer Reviews are also called as :-a) Inspection
b) Walkthrough
c) Technical Review
d) Formal Review

16. Consider the following statements:
i. 100% statement coverage guarantees 100% branch coverage.
ii. 100% branch coverage guarantees 100% statement coverage.
iii. 100% branch coverage guarantees 100% decision coverage.
iv. 100% decision coverage guarantees 100% branch coverage.
v. 100% statement coverage guarantees 100% decision coverage.

a) ii is True; i, iii, iv & v are False
b) i & v are True; ii, iii & iv are False
c) ii & iii are True; i, iv & v are False
d) ii, iii & iv are True; i & v are False

17. The Kick Off phase of a formal review includes the following :-
a) Explaining the objective
b) Fixing defects found typically done by author
c) Follow up
d) Individual Meeting preparations

18. Match every stage of the software Development Life cycle with the Testing Life cycle:i. Hi-level design a Unit tests
ii. Code b Acceptance tests
iii. Low-level design c System tests
iv. Business requirements d Integration tests

a) i-d , ii-a , iii-c , iv-b
b) i-c , ii-d , iii-a , iv-b
c) i-b , ii-a , iii-d , iv-c
d) i-c , ii-a , iii-d , iv-b

19. Which of the following is not phase of the Fundamental Test Process?a) Test Planning and Control
b) Test implementation and Execution
c) Requirement Analysis
d) Evaluating Exit criteria and reporting

20. Which of the following techniques is NOT a black box technique?
a) State transition testing
b) LCSAJ (Linear Code Sequence and Jump)
c) syntax testing
d) boundary value analysis

21. Success Factors for a review include :
i. Each Review does not have a predefined objective
ii. Defects found are welcomed and expressed objectively
iii. Management supports a good review process.
iv. There is an emphasis on learning and process improvement.

a) ii,iii,iv are correct and i is incorrect
b) iii , i , iv is correct and ii is incorrect
c) i , iii , iv , ii is in correct
d) ii is correct

22. Defects discovered by static analysis tools include :
i. Variables that are never used.
ii. Security vulnerabilities.
iii. Programming Standard Violations
iv. Uncalled functions and procedures

a) i , ii,iii,iv is correct
b) iii ,is correct I,ii,iv are incorrect.
c) i ,ii, iii and iv are incorrect
d) iv, ii is correct

23. Test Conditions are derived from :-
a) Specifications
b) Test Cases
c) Test Data
d) Test Design

24. Which of the following is true about White and Black Box Testing Technique:-
a) Equivalance partitioning, Decision Table and Control flow are White box Testing Techniques.
b) Equivalence partitioning , Boundary Value Analysis , Data Flow are Black Box Testing Techniques.
c) Equivalence partitioning , State Transition , Use Case Testing are black box Testing Techniques.
d) Equivalence Partioning , State Transition , Use Case Testing and Decision Table are White Box Testing Techniques.

25. Regression testing should be performed:
i. every week
ii. after the software has changed
iii. as often as possible
iv. when the environment has changed
v. when the project manager says

a) i & ii are true, iii, iv & v are false
b) ii, iii & iv are true, i & v are false
c) ii & iv are true, i, iii & v are false
d) ii is true, i, iii, iv & v are false

26. Benefits of Independent Testing
a) Independent testers are much more qualified than Developers
b) Independent testers see other and different defects and are unbiased.
c) Independent Testers cannot identify defects.
d) Independent Testers can test better than developers

27. Minimum Tests Required for Statement Coverage and Branch Coverage :-Read P
Read Q
If p+q > 100 then
Print “Large”
End if
If p > 50 then
Print “pLarge”
End if
a) Statement coverage is 2, Branch Coverage is 2
b) Statement coverage is 3 and branch coverage is 2
c) Statement coverage is 1 and branch coverage is 2
d) Statement Coverage is 4 and Branch coverage is 2

28. Minimum Test Required for Statement Coverage :-Disc = 0
Order-qty = 0
Read Order-qty
If Order-qty >=20 then
Disc = 0.05
If Order-qty >=100 then
Disc =0.1
End if
End if

a) Statement coverage is 4
b) Statement coverage is 1
c) Statement coverage is 3
d) Statement Coverage is 2

29. The structure of an incident report is covered in the Standard for Software Test Documentation IEEE 829 and is called as : -
a) Anomaly Report
b) Defect Report
c) Test Defect Report
d) Test Incident Report

30. Which of the following is the task of a Test Lead / Leader.
i. Interaction with the Test Tool Vendor to identify best ways to leverage test tool on the project.
ii. Write Test Summary Reports based on the information gathered during testing
iii. Decide what should be automated , to what degree and how.
iv. Create the Test Specifications

a) i, ii, iii is true and iv is false
b) ii,iii,iv is true and i is false
c) i is true and ii,iii,iv are false
d) iii and iv is correct and i and ii are incorrect

31. Features of White Box Testing Technique :-i. We use explicit knowledge of the internal workings of the item being tested to select the test data.
ii. Uses specific knowledge of programming code to examine outputs and assumes that the tester knows the path of logic in a unit or a program.
iii. Checking for the performance of the application
iv. Also checks for functionality.
a) i, ii are true and iii and iv are false
b) iii is true and i,ii, iv are false
c) ii ,iii is true and i,iv is false
d) iii and iv are true and i,ii are false

32. Which of the following is a part of Test Closure Activities?i. Checking which planned deliverables have been delivered
ii. Defect report analysis.
iii. Finalizing and archiving testware.
iv. Analyzing lessons.
a) i , ii , iv are true and iii is false
b) i , ii , iii are true and iv is false
c) i , iii , iv are true and ii is false
d) All of above are true

33. Which of the following will be the best definition for Testing :-a) The goal / purpose of testing is to demonstrate that the program works.
b) The purpose of testing is to demonstrate that the program is defect free.
c) The purpose of testing is to demonstrate that the program does what it is supposed to do.
d) Testing is executing Software for the purpose of finding defects.

34. Which of the following is not a type of incremental testing approach?a) Top down
b) Big-bang
c) Bottom up
d) Functional incrementation.

35. Drivers are also known as:
i. Spade
ii. Test harness
iii. Scaffoldinga) i , ii are true and iii is false
b) i , iii are true and ii is false
c) ii , iii are true and i is false
d) All of the above are true

36. Exit Criteria may consist of :-i. Thoroughness measures , such as coverage of code, functionality or risk
ii. Estimates of Defect density or reliability measures.
iii. Residual risk such as defects not fixed or lack of test coverage in certain areas
iv. Verifying the Test Environment.
a) iv is correct and i,ii,iii are incorrect.
b) i,ii,iii is correct and iv is incorrect
c) ii is correct and i,ii,iii are incorrect
d) iii and iv are correct and i,ii are incorrect

37. Which of the following helps in monitoring the Test Progress:-i. Percentage of Test Case Execution
ii. Percentage of work done in test environment preparation.
iii. Defect Information e.g. defect density, defects found and fixed
iv. The size of the testing Team and skills of the engineers

a) iv is correct and i,ii,iii are incorrect
b) i,ii,iii are correct and iv is incorrect
c) i,ii are correct and iii,iv are incorrect
d) i,iv are correct and ii , iii are incorrect

38. The selection of a test approach should consider the context :-i. Risk of Failure of the Project, hazards to the product and risks of product failure to humans
ii. Skills and experience of the people in the proposed technique, tools and methods
iii. The objective of the testing endeavor and the mission of the testing team.
iv. The size of the testing Team

a) i,ii,iii,iv are true
b) i,ii,iii are true and iv is false.
c) ii,iii,iv are true and i is false.
d) i,iv are true and ii, iii are false.

39. In case of Large Systems :-a) Only few tests should be run
b) Testing should be on the basis of Risk
c) Only Good Test Cases should be executed.
d) Test Cases written by good test engineers should be executed.

40. The Provision and Management of a controlled library containing all the configurations items is called asa) Configuration Control
b) Status Accounting
c) Configuration Identification
d) Configuration Identification

Answers :

1 c
2 a
3 a
4 d
5 d
6 c
7 a
8 b
9 d
10 d
11 c
12 a
13 c
14 c
15 c
16 d
17 a
18 d
19 c
20 b
21 a
22 a
23 a
24 c
25 c
26 b
27 c
28 b
29 a
30 a
31 a
32 c
33 d
34 b
35 c
36 b
37 b
38 b
39 b
40 a

Sample Paper 8

2008-05-07T03:49:00.000-07:00

1. Deliverables of test design phase include all the following except (Testing
artifacts)
a) Test data
b) Test data plan
c) Test summary report
d) Test procedure plan

2. Which of the following is not decided in the test-planning phase? (Testing
artifacts)
a) Schedules and deliverables
b) Hardware and software
c) Entry and exit criteria
d) Types of test cases

3. Typical defects that are easier to find in reviews than in dynamic testing are:
A. deviations from standards,
B.requirement defects,
C.design defects,
D.insufficient maintainability and incorrect interface specifications.
E.All of the above.

4. Load Testing Tools (Per. Testing)
a) reduces the time spent by the testers
b) reduces the resources spent (hardware)
c) mostly used in web testing
d) all of the above

5. Reviews, static analysis and dynamic testing have the same objective –
A.identifying defects.
B. fixing defects.
C. 1 and 2
D. None

6. Defect arrival rate curve:
A. Shows the number of newly discovered defects per unit time
B. Shows the number of open defects per unit time.
C. Shows the cumulative total number of defects found up to this time.
D. Any of these, depending on the company.

7. What are the 2 major components taken into consideration with risk analysis?
(Test Mgmt)
a) The probability the negative event will occur
b) The potential loss or impact associated with the event
c) Both a and b
d) Neither a nor b

8. We can achieve complete statement coverage but still miss bugs because:
A. The failure occurs only if you reach a statement taking the TRUE branch of an IF
statement, and you got to the statement with a test that passed through the FALSE
branch.
B. The failure depends on the program's inability to handle specific data values,
rather than on the program's flow of control.
C. Both A and B
D. We are not required to test code that customers are unlikely to execute.

9. Who is responsible for conducting test readiness review? (Performing
Test)
a. Test manager
b. Test engineer
c. both A & B
d. Project Manager

10. What if the project isn't big enough to justify extensive testing? (Test Mgmt)
a) Use risk based analysis to find out which areas need to be tested
b) Use automation tool for testing
c) a and b
d) None of the above

11. What are the key features to be concentrated upon when doing a testing for
world wide web sites (Test Execution)
a) Interaction between html pages
b) Performance on the client side
c) Security aspects
d) All of the above

12. What can be done if requirements are changing continuously? (Test Mgmt)
a) Work with the project's stakeholders early on to understand how
requirements might change so that alternate test plans and strategies
can be worked out in advance, if possible.
b) Negotiate to allow only easily-implemented new requirements into the
project, while moving more difficult new requirements into future
versions of the application
c) Both a and b
d) None of the above

13. The selection of test cases for regression testing (Testing artifacts)
a) Requires knowledge on the bug fixes and how it affect the system
b) Includes the area of frequent defects
c) Includes the area which has undergone many/recent code changes
d) All of the above

14. Measurement dysfunction is a problem because:
A. Even though the numbers you look at appear better, to achieve these numbers, people are doing other aspects of their work much less well.B. We don't know how to measure a variable (our measurement is dysfunctional) and
so we don't know how to interpret the result.
C. You are measuring the wrong thing and thus reaching the wrong conclusions.
D. All of the above.

15. What do you mean by “Having to say NO” (test planning process)
a. No, the problem is not with testers
b. No, the software is not ready for production
c. Both a & b
d. none of the above

16. According to the lecture, there are several risks of managing your project's schedule
with a statistical reliability model. These include (choose one or more of the following):
A. Testers spend more energy early in the product trying to find bugs than preparing
to do the rest of the project's work more efficiently
B. Managers might not realize that the testing effort is ineffective, late in the project,
because they expect a low rate of bug finding, so the low rate achieved doesn't
alarm them.
C. It can increase the end-of-project pressure on testers to not find bugs, or to not
report bugs.
D. All of the above

17. Operations testing is (Performing Test)
a. compliance testing
b. disaster testing
c. verifying compliance to rules
d. functional testing
e. ease of operations

18. Tools like change Man, Clear case are used as (test planning process)
a. functional automation tools
b. performance testing tools
c. configuration management tools
d. none of the above.

19. Important consequences of the impossibility of complete testing are (Choose one or more answers):
A. We can never be certain that the program is bug free.
B. We have no definite stopping point for testing, which makes it easier for some
managers to argue for very little testing.
C. We have no easy answer for what testing tasks should always be required,
because every task takes time that could be spent on other high importance tasks.
D. All of the above.

20. Which is not in sequence in 11 Step Software Testing process (Tester’s
Role SDLC)
a Assess development plan and status
b Develop the test plan
c Test software design
d Test software requirement

21. In the MASPAR case study:
A. Security failures were the result of untested parts of code.
B. The development team achieved complete statement and branch coverage but
missed a serious bug in the MASPAR operating system.
C. An error in the code was so obscure that you had to test the function with almost
every input value to find its two special-case failures.
D. All of the above.

22. Complete statement and branch coverage means:
A. That you have tested every statement in the program.
B. That you have tested every statement and every branch in the program.
C. That you have tested every IF statement in the program.
D. That you have tested every combination of values of IF statements in the program

23. What if the project isn't big enough to justify extensive testing? (Test Mgmt)
a) Use risk based analysis to find out which areas need to be tested
b) Use automation tool for testing
c) a and b
d) None of the above

24. Security falls under (Performing Test)
a. compliance testing
b. disaster testing
c. verifying compliance to rules
d. functional testing
e. ease of operations

25. Which is the best definition of complete testing:
A. You have discovered every bug in the program.
B. You have tested every statement, branch, and combination of branches in the
program.
C. You have completed every test in the test plan.
D. You have reached the scheduled ship date.

26. What is the concept of introducing a small change to the program and having the
effects of that change show up in some test? (Testing concepts)
a) Desk checking
b) Debugging a program
c) A mutation error
d) Performance testing
e) Introducing mutations

Static Techniques : Reviews process

2008-03-01T23:19:00.000-08:00

Review Process

> Reviews vary from very informal to very formal. (i.e well structured and regulated)
> The formality of a review process is related to such factors as:
*** The maturity of the development process
*** Any legal or regulatory requirements
*** The need for an audit trail
> The way a review is carred out depends on the agreed objective of the review.

If the formal development processis not followed, then it may be difficult to introduce a formal review process; work products may not be consistently produced from project to project, therefore we cannot always state that, for example, 'reviews will be carried out on functional specification'.
Some reviews are more formal than others; if reviews have not been carried in an organization before, it may not be sensible to introduce the most formal reviw type, which are inspections.
There may be legal or regulatory requirements that consider certain types of reviews to be carried out on certain work products. For rxample, standards relating to safety-critical software may deem it mandatory to carry out code inspections.

different reviews can have different objectives, forexample:
> To find defects
> To gain understanding
> To dicuss and reach decisions by consensus.

Phases of a formal review

A formal review consists of the following activities:
> Planning
> Kick-off meetings
> Individual checking/study (preparation)
> Inspection logging/review meetings
> Re-work/follow up
> Matrics/sign-off

> Planning :
*** Select personnel
*** Allocate roles
*** Define the entry an dexit criteria(for more formal review types)
*** Select which parts of the document to review

> Kick-off :
*** Distribute documents
*** Explain objectives, process and documents
*** Check entry criteia (for more formal reviews types)

It is extremely important that time is taken to plan the review activitites thoroughly - who is going to be involved, when the review meeting is going to take place, that everythign required to carryout the review (source documents, reference documents, for example) is available, and that participants are allocated sufficient time to carry out the activities assigned to them.

A kickoff meeting is likely to take place to ensure that everybosy is involved in the review process understands what his/her specific roles amd responsibilities are.
Different roles can be assigned to perticipants in order to give the review process more focus-instead of everybody checking for everything, they look at certain aspects of the review item, for example, ensure that everybosy contained in the review item corectly reflects what is in the source document.

> Individual Preparaton :
*** Work dine by each participant on their own prior to the review meeting.
*** Potential defects should be noted
*** A proposed grading is given (according to agreed standards)-this will be re-evaluated at the review meeting
*** Questions and comments noted.

Once roles and responsibilities have been assigned, individual preparation can then commence.
Roles can be allocated to individuals where they check that the review items against company standards, or check that the document cna be used as a source for the next activities - this could be preparing an acceptance test plan from the user requirements documents, or creating test cases from the same document.

> Review Meeting :
*** Discussions and/or logging
*** Documents results or minutes(for more formal review types)
*** Parcipants may simply note handling the defects, or
*** Make recommendations for handling the defects, or
*** Make decisions about the defects.

The review meeting needs to be managed, time-boxed and organized. The person leading the review must make sure that there is not too much time spent on one topic to the detriment of others and that the meeting is not dominated by a few people - everyone must be given an opportunity to speak.
The person leading the review must also ensure that the meeting does not become unruly(lots of people talking at the same time about different things)and that the focus kept on the review item.
At the meeting someone should be given responsibility for taking the minutes of the meeting and documenting any remedial actions and any follow-up activities(further meetings, formal sign-off).

> Rework :
*** Fixing the defects found
*** Normally performed by the author

> Follow-up :
*** Checking the defects have been addressed
*** Gather metrics
*** Check on exit criteria(for more formal review types)

A report of the review meeting should be produced and distributed.
It is the author`s responsibility to carry out any changes required of the review item.
It is all participants responsibility to suggest any process improvements- to the review activity itself and the structure of the review item(could ti be made better in anyway?).

Static Techniques : Reviews and the test process

2008-01-30T23:59:00.000-08:00

What are Reviews?

> A way of testing software work products( e.g. documents, code)
> Can be Performed well before dynamic test execution.
> They are most beneficial when performed as early as possible in the development life cycle.

There are different levels of review, from very informal through to very formal, they all have their benefits and should be used through out the software development life cycle.

ISTQB DEFINES Review : An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include Management Reviews, Informal Reviews, Technical reviews, Inspection ans walkthrough.

> Defects found during reviews are often much cheaper to remove than those found during dynamic execution.
> A review be done as a completely manual activities, but there is tool support.
> The main manual activity is to examine a work product and make comments about it.

The cost of finding and fixing defects increases over time. For example, If an error is made it is defect detected in the requirement at the specification stage, then it is relatively cheap to fix. However, not finding and fixing the defect until acceptance test or live use will be much more expensive.
Tools can assist in administering the review activities, but the reviewers will still be required to manually examine the work product.

What can be reviewed?

Any software work product can be reviewed :
> Requirement Specification
> Design Specification
> Code
> Test Plans
> Test Specification
> Test cases
> Test Scripts
> User Guides
> Web pages

Any other type of design document can also be reviewed such as date flow diagrams and entity relationship diagrams.
But it does not stop there, there is also benefit for the test plan and tests to be reviewed as well the code itself.
Lastly, the system documentation such as user manual and help text can also benefit from reviews.

Benefits of reviews

> Early defect detection and correction
> Fewer defects
> Reduced testing time and cost
> Reduced development time scales.
> Development productivity improvements
> Life time cost reductions
> Improved communication

Analysis have been performed on projects using reviews and it is estimated that ongoing reviews cost around 15% of the total development budget.
These costs include all the preparatory work required for the reviews to take place. For example who will be involved in the review, agreeing the date and time for the review and sending the document out prior to the review. Time much be allowed for each reviewer to read the document prior to the review meeting.
The costs also include the actual review meeting any follow up work required. Follow-up work can sometimes involve investigation of issues, correcting the document and producing a report detailing the outcome of the review. The report would detail the actions required, by whom, whether another review meeting is necessary. Metrics would be kept of the number of faults found which, when analyzed later could lead to process improvements.

> They can find omissions in requirements which are unlikely to be found in dynamic testing
> Remember verification and validation?

Well founded statistics estimate that 60% of the defects have already been made before coding/implementation has started, therefore it makes sense to carry out early lifecycle testing activities.
Early defects(faults) are often the most important to find; they have the characteristic to multiply thenselves top-down.
Tom De Marco said that "One of the main reasons for project failure is ambiguity in the requirements".

Objectives of reviews

> Reviews have the same objective as static analysis and dynamic anlysis of software
****** TO identify defects.
> The different techiniques are complementary
****** They can find different types of defects effectively and efficiently.
> Remember : Reviews identify defects, dynamic testing reveals failures.

In particular, the work product is being reviewed to validate it against actual requirements and to verify that it has been created to the appropriate standard and contains everything it should.
It is vital that the review team work together to acheive a consensus of opinion regarding the work product being reviewed.
Another objective of the review process is that the review team work together to improve the quality of the item being reviewed - it is a constructive, not destructive process.

Typical defects that are easier to find in reviews

> Deviations from standards
> Requirements defects
> Design defects.
> insufficient maintainability
> Incorrect interface specification

We will look at different types of reviw later but the reviews of documents such as user requirements, functional specifications and technical specifications are usually incremental.
The first review will usually raise sme questions and issues, points of clarification as to how a particular requirement will be tested. Or it could be an inconsistency in naming say 'a customer' or a client. These will need to be resolved and the document re-reviewed.
It may also be the case that all issues cannot be resolved at once. one issue may need to be resolved before others can be addressed, or having resolved one issue, this is turn raises further issues.
Reviews are therefore an iterative process.

The Benefits of early test design

2008-01-06T17:49:00.000-08:00

Benefits of early test design

> 60% of the defects have already been made before coding/implementation has started.
> The thought process of designing tests early int eh lifecycle helps to verify the test basis inconsistencies and omissions.
> Their removal will increase the quality of the test basis and help to prevent defects from being introduced into the code.

As we know that the later in the lifecycle defects are detected, the more expensive they are to fix. It is most cost effective to find and fix requirements defects at the requirements stage. Building the right software correctly gives a lower cost overall.

The thought process of designing tests in the early lifecycle can help to prevent defects from being introduced into code. We some times refer to this as 'verifying the test basis via the test design'. The test basis includes documents like the requirements and design specification.

According to ISTQB
Requirement : A condition or capability needed by a user to solve a problem or acheive an objective that must be met or prossessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

Test Basis : All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis.

Test Case : A set of input values, execution preconditions, expected results and execution post cnditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

> Documents reviewed can help to prevents defects occuring in to the code.
> Static analysis of code can identify defects in the cde and give a measure of complexity of the code.
> Time invested in early life cycle test activities will reap many benefits
* Quality of product and documentation improved
* Defects found are relatively cheap to fix.
* Fewer defects by reducing fault multiplication.

There are different types of reviews we can carry out, but an objective of all types of reviews is to find defects.

Time invested in early lifecycle test activities will reap many benefits:
* Quality if product improved at all stages in the process
* Reduce the number of faults to detect by reducing fault multiplication
* Less rework at later development stages.
* System implemented on time and to budget.

ISTQB defines
Review : An evaluation of the product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walkthrough.

When we look at the test principles you will see the following test principle is related to this discussion:
Testing Principle - Early Testing : Testing activities should start as early as possible in the software or system development lifecycle, and should be focused on defined objectives.

Software Testing Best Practices

2007-12-11T01:42:00.000-08:00

The Foundational practices are the rock in the soil that protects your efforts against harshness of nature, be it a redesign of your architecture or enhancements to sustain unforeseen growth. Every time we conclude a study or task force on the subject of software development process I have found one recommendation that comes out loud and clear.

"We need to adopt the best practices in the industry." While it appears as an obvious conclusion, the most glaring lack of it's presence continues to astound the study team.

The best practices can be classified into the following types:

a) Basic Best Practices
b) Foundational Best Practices
c) Incremental Best Practices

a) Basic Best Practices
They are the training wheels you need to get started and when you take them off, it is evident that you know how to ride. But remember, that you take them off does not mean you forget how to ride. This is an important difference, which all too often is forgotten in software. "Yeah, we used to write functional specification but we don't do that anymore" means you forget to ride, not that you didn't need to do that step anymore. The Basic practices have been around for a long time.

Functional Specifications
The testers use this to write down test cases from a black box testing perspective. The advantage of having a functional specification is that the test generation activity could happen in parallel with the development of the code. This is ideal from several dimensions. It gains parallelism in execution, removing a serious serialization bottleneck in the development process.

Reviews and Inspection
It is argued that software inspection can easily provide a ten times gain in the process of debugging software. Not much needs to be said about this, since it is a fairly well known and understood practice.

Formal Entry and Exit Criteria
The idea is that every process step, be it inspection, functional test, or software design, has a precise entry and precise exit criteria. These are defined by the development process and are watched by management to gate the movement from one stage to another.

Functional Test – Variations
Most functional tests are written as black box tests working off a functional specification. The number of test cases that are generated usually are variations on the input space coupled with visiting the output conditions.

Multi-platform Testing
When code is ported from one platform to another, modifications are sometimes done for performance purposes. The net result is that testing on multiple platforms has become a necessity for most products. Therefore techniques to do this better, both in development and testing, are essential.

Internal Betas
Techniques to best conduct such an internal Beta test are essential for us to obtain good coverage and efficiently use internal resources. This best practice has everything to do with Beta programs though on a smaller scale to best leverage it and reduce cost and expense of an external Beta.

Automated Test Execution
The goal of automated test execution is that we minimize the amount of manual work involved in test execution and gain higher coverage with a larger number of test cases. The automated test execution has a significant impact on both the tools sets for test execution and also the way tests are designed.

‘Nightly’ Builds
The concept of a nightly build has been in vogue for a long time. While every build is not necessarily done every day, the concept captures frequent builds from changes that are being promoted into the change control system.

b) Foundational Best Practices
The Foundational practices are the rock in the soil that protects your efforts against harshness of nature, be it a redesign of your architecture or enhancements to sustain unforeseen growth. They need to be put down thoughtfully and will make the difference in the long haul, whether you build a ranch or a skyscraper. Their value added is significant and established by a few leaders in the industry. Unlike the Basics, they are probably not as well known and therefore need implementation help. While there may be no textbooks on them yet, there is plenty of documentation to dig up.

User Scenarios
One of the viable methods of testing is to develop user scenarios that exercise the functionality of the applications. This best practice should capture methods of recording user scenarios and developing test cases based on them. In addition it could discuss potential diagnosis methods when a specific failure scenario occurs.

Usability Testing
Usability testing needs to not only assess how usable a product is but also provide feedback on methods to improve the user experience and thereby gain a positive quality image. The best practice for usability testing should also have knowledge about advances in the area of Human Computer Interface.

In-Process ODC Feedback Loops
Orthogonal defect classification is a measurement method that uses the defect stream to provide precise measurability into the product and the process. Given the measurement, a variety of analysis techniques have been developed to assist management and decision-making on a range of software engineering activities.

Multi-Release ODC/Butterfly
The technology of multi-release ODC/Butterfly analysis allows a product manager to make strategic development decisions so as to optimize development costs, time to market, and quality issues by recognizing customer trends, usage patterns, and product performance.

“Requirements” for Test Planning
One of the roles of software testing is to ensure that the product meets the requirements of the clientele. Capturing the requirements therefore becomes an essential part not only to help develop but to create test plans that can be used to gauge if the developed product is likely to meet customer needs.

Automated Test Generation
Almost 30% of the testing task can be the writing of test cases. To first order of approximation, this is a completely manual exercise and a prime candidate for savings through automation.

c) Incremental Best Practices
The Incremental practices provide specific advantages in special conditions. While they may not provide broad gains across the board of testing, they are more specialized. These are the right angle drills -- when you need it, there's nothing else that can get between narrow studs and drill a hole perfectly square. At the same time, if there was just one drill you were going to buy, it may not be your first choice. Not all practices are widely known or greatly documented. But they all possess the strength that are powerful when judiciously applied.

Conclusion
So clear is its presence that it distinguishes the winners from the also-ran like no other factor. The search for best practices is constant. Some are known and well recognized, others debated, and several hidden.
Note : Get more topics from Exforys Online Tutorials.

Testing : Introduction to CMM

2007-12-11T01:37:00.000-08:00

Quality software should reasonably be bug-free, delivered on time and within budget. It should meet the given requirements and/or expectations, and should be maintainable. In order to produce error free and high quality software certain standards need to be followed.

Software Quality:
Quality software should reasonably be bug-free, delivered on time and within budget. It should meet the given requirements and/or expectations, and should be maintainable.
In order to produce error free and high quality software certain standards need to be followed.

Quality Standards
ISO 9001: 2000 is Quality Management System Certification. To achieve this, an organization must satisfy ISO 9001: 2000 clauses (clauses 1 - 8).
Six Sigma is a process improvement methodology focused on reduction in variation of the processes around the mean. Its objective is to make the process defect free.
SEI CMM is a defacto standard for assessing and improving processes related to software development, developed by the software community in 1986 with leadership from SEI. It’s a software specific process maturity model. It provides guidance for measuring software process maturity and helps process improvement programs.

SEI CMM is organized into 5 maturity levels:
Initial
Repeatable
Defined
Manageable
Optimizing
1)Initial
The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.

2) Repeatable:
Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

3) Defined:
The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.

4) Managed:
Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

5) Optimizing:
Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

Comparison of CMM and ISO

Conclusion:
CMM ensures that the process followed for developing a product produces error free product. A company which is process driven is more successful than the company which is people driven. Hence a company needs to have a good process for software development for it to be successful.

Life Cycle of Testing Process

2007-12-02T09:23:00.000-08:00

Life Cycle of Testing

This article explains about Different steps in Life Cycle of Testing Process. in Each phase of the development process will have a specific input and a specific output. Once the project is confirmed to start, the phases of the development of project can be divided into the following phases:

* Software requirements phase.
* Software Design
* Implementation
* Testing
* Maintenance

In the whole development process, testing consumes highest amount of time. But most of the developers oversee that and testing phase is generally neglected. As a consequence, erroneous software is released. The testing team should be involved right from the requirements stage itself.

The various phases involved in testing, with regard to the software development life cycle are:

1. Requirements stage
2. Test Plan
3. Test Design.
4. Design Reviews
5. Code Reviews
6. Test Cases preparation.
7. Test Execution
8. Test Reports.
9. Bugs Reporting
10. Reworking on patches.
11. Release to production.

Requirements Stage :
Normally in many companies, developers itself take part in the requirements stage. Especially for product-based companies, a tester should also be involved in this stage. Since a tester thinks from the user side whereas a developer can’t. A separate panel should be formed for each module comprising a developer, a tester and a user. Panel meetings should be scheduled in order to gather everyone’s view. All the requirements should be documented properly for further use and this document is called “Software Requirements Specifications”.

Test Plan :
Without a good plan, no work is a success. A successful work always contains a good plan. The testing process of software should also require good plan. Test plan document is the most important document that brings in a process – oriented approach. A test plan document should be prepared after the requirements of the project are confirmed. The test plan document must consist of the following information:
• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

Test Design :
Test Design is done based on the requirements of the project. Test has to be designed based on whether manual or automated testing is done. For automation testing, the different paths for testing are to be identified first. An end to end checklist has to be prepared covering all the features of the project.

The test design is represented pictographically. The test design involves various stages. These stages can be summarized as follows:
• The different modules of the software are identified first.
• Next, the paths connecting all the modules are identified.

Then the design is drawn. The test design is the most critical one, which decides the test case preparation. So the test design assesses the quality of testing process.

Test Cases Preparation :
Test cases should be prepared based on the following scenarios:
• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios

Design Reviews :
The software design is done in systematical manner or using the UML language. The tester can do the reviews over the design and can suggest the ideas and the modifications needed.

Code Reviews :
Code reviews are similar to unit testing. Once the code is ready for release, the tester should be ready to do unit testing for the code. He must be ready with his own unit test cases. Though a developer does the unit testing, a tester must also do it. The developers may oversee some of the minute mistakes in the code, which a tester may find out.

Test Execution and Bugs Reporting :
Once the unit testing is completed and the code is released to QA, the functional testing is done. A top-level testing is done at the beginning of the testing to find out the top-level failures. If any top-level failures occur, the bugs should be reported to the developer immediately to get the required workaround.

The test reports should be documented properly and the bugs have to be reported to the developer after the testing is completed.
Release to Production

Once the bugs are fixed, another release is given to the QA with the modified changes. Regression testing is executed. Once the QA assures the software, the software is released to production. Before releasing to production, another round of top-level testing is done.

The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus the testing process is an unending process.

Release to Production
Once the bugs are fixed, another release is given to the QA with the modified changes. Regression testing is executed. Once the QA assures the software, the software is released to production. Before releasing to production, another round of top-level testing is done.

The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus the testing process is an unending process.

Basic Test Case Concepts

2007-11-30T05:11:00.001-08:00

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

2007-11-23T07:05:00.000-08:00
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

2007-11-17T10:34:00.000-08:00
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

2007-11-17T04:43:00.000-08:00
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

Software Testing Fundamentals—Concepts, Roles, and Terminology

2007-11-17T02:25:00.000-08:00
SOFTWARE TESTING—WHAT, WHY, AND WHO

WHAT IS SOFTWARE TESTING?
Software testing is a process of verifying and validating that a software application or program
1. Meets the business and technical requirements that guided its design and development, and
2. Works as expected.

Software testing also identifies important defects, flaws, or errors in the application code that must be fixed. The modifier “important” in the previous sentence is, well, important because defects must be categorized by severity
(more on this later).

During test planning we decide what an important defect is by reviewing the requirements and design documents with an eye towards answering the question “Important to whom?” Generally speaking, an important defect is one that
from the customer’s perspective affects the usability or functionality of the application. Using colors for a traffic lighting scheme in a desktop dashboard may be a no-brainer during requirements definition and easily implemented during development but in fact may not be entirely workable if during testing we discover that the primary business sponsor is color blind. Suddenly, it becomes an important defect. (About 8% of men and .4% of women have some form of color blindness.)

The quality assurance aspect of software development—documenting the degree to which the developers followed corporate standard processes or best practices—is not addressed in this paper because assuring quality is not a responsibility of the testing team. The testing team cannot improve quality; they can only measure it, although it can be argued that doing things like designing tests before coding begins will improve quality because the coders can then use that information while thinking about their designs and during coding and debugging.

Software testing has three main purposes: verification, validation, and defect finding.
♦ The verification process confirms that the software meets its technical specifications. A “specification” is a description of a function in terms of a measurable output value given a specific input value under specific
preconditions. A simple specification may be along the line of “a SQL query retrieving data for a single account against the multi-month account-summary table must return these eight fields ordered by month within 3 seconds of submission.”
♦ The validation process confirms that the software meets the business requirements. A simple example of abusiness requirement is “After choosing a branch office name, information about the branch’s customer account managers will appear in a new window. The window will present manager identification and summary information about each manager’s customer base: .” Other requirements
provide details on how the data will be summarized, formatted and displayed.
♦ A defect is a variance between the expected and actual result. The defect’s ultimate source may be traced to a fault introduced in the specification, design, or development (coding) phases.

WHY DO SOFTWARE TESTING?

“A clever person solves a problem. A wise person avoids it." - Albert Einstein

Why test software? “To find the bugs!” is the instinctive response and many people, developers and programmers included, think that that’s what debugging during development and code reviews is for, so formal testing is redundant at best. But a “bug” is really a problem in the code; software testing is focused on finding defects in the final product.

Here are some important defects that better testing would have found.
♦ In February 2003 the U.S. Treasury Department mailed 50,000 Social Security checks without a beneficiary name. A spokesperson said that the missing names were due to a software program maintenance error.
♦ In June 1996 the first flight of the European Space Agency's Ariane 5 rocket failed shortly after launching, resulting in an uninsured loss of $500,000,000. The disaster was traced to the lack of exception handling for a floating-point error when a 64-bit integer was converted to a 16-bit signed integer.

Software testing answers questions that development testing and code reviews can’t.
♦ Does it really work as expected?
♦ Does it meet the users’ requirements?
♦ Is it what the users expect?
♦ Do the users like it?
♦ Is it compatible with our other systems?
♦ How does it perform?
♦ How does it scale when more users are added?
♦ Which areas need more work?
♦ Is it ready for release?

What can we do with the answers to these questions?
♦ Save time and money by identifying defects early
♦ Avoid or reduce development downtime
♦ Provide better customer service by building a better application
♦ Know that we’ve satisfied our users’ requirements
♦ Build a list of desired modifications and enhancements for later versions
♦ Identify and catalog reusable modules and components
♦ Identify areas where programmers and developers need training

WHAT DO WE TEST?
First, test what’s important. Focus on the core functionality—the parts that are critical or popular—before looking at the ‘nice to have’ features. Concentrate on the application’s capabilities in common usage situations before going on
to unlikely situations. For example, if the application retrieves data and performance is important, test reasonable queries with a normal load on the server before going on to unlikely ones at peak usage times. It’s worth saying again: focus on what’s important. Good business requirements will tell you what’s important.

The value of software testing is that it goes far beyond testing the underlying code. It also examines the functional behavior of the application. Behavior is a function of the code, but it doesn’t always follow that if the behavior is “bad”
then the code is bad. It’s entirely possible that the code is solid but the requirements were inaccurately or incompletely collected and communicated. It’s entirely possible that the application can be doing exactly what we’re
telling it to do but we’re not telling it to do the right thing.

A comprehensive testing regime examines all components associated with the application. Even more, testing provides an opportunity to validate and verify things like the assumptions that went into the requirements, the appropriateness of the systems that the application is to run on, and the manuals and documentation that accompany the application. More likely though, unless your organization does true “software engineering” (think of Lockheed- Martin, IBM, or SAS Institute) the focus will be on the functionality and reliability of application itself.

Testing can involve some or all of the following factors. The more, the better.
♦ Business requirements
♦ Functional design requirements
♦ Technical design requirements
♦ Regulatory requirements
♦ Programmer code
♦ Systems administration standards and restrictions
♦ Corporate standards
♦ Professional or trade association best practices
♦ Hardware configuration
♦ Cultural issues and language differences

WHO DOES THE TESTING?
Software testing is not a one person job. It takes a team, but the team may be larger or smaller depending on the size and complexity of the application being tested. The programmer(s) who wrote the application should have a reduced role in the testing if possible. The concern here is that they’re already so intimately involved with the product and “know” that it works that they may not be able to take an unbiased look at the results of their labors.

Testers must be cautious, curious, critical but non-judgmental, and good communicators. One part of their job is to ask questions that the developers might find not be able to ask themselves or are awkward, irritating, insulting or even
threatening to the developers.

♦ How well does it work?
♦ What does it mean to you that “it works”?
♦ How do you know it works? What evidence do you have?
♦ In what ways could it seem to work but still have something wrong?
♦ In what ways could it seem to not work but really be working?
♦ What might cause it to not to work well?

A good developer does not necessarily make a good tester and vice versa, but testers and developers do share at least one major trait—they itch to get their hands on the keyboard. As laudable as this may be, being in a hurry to start can cause important design work to be glossed over and so special, subtle situations might be missed that would otherwise be identified in planning. Like code reviews, test design reviews are a good sanity check and well worth the time and effort.

Testers are the only IT people who will use the system as heavily an expert user on the business side. User testing almost invariably recruits too many novice business users because they’re available and the application must be usable by them. The problem is that novices don’t have the business experience that the expert users have and might not recognize that something is wrong. Testers from IT must find the defects that only the expert users will find because the experts may not report problems if they’ve learned that it's not worth their time or trouble.

THE V-MODEL OF SOFTWARE TESTING
Software testing is too important to leave to the end of the project, and the V-Model of testing incorporates testing into the entire software development life cycle. In a diagram of the V-Model, the V proceeds down and then up, from
left to right depicting the basic sequence of development and testing activities. The model highlights the existence of different levels of testing and depicts the way each relates to a different development phase.

Like any model, the V-Model has detractors and arguably has deficiencies and alternatives but it clearly illustrates that testing can and should start at the very beginning of the project. (See Goldsmith for a summary of the pros and cons
and an alternative. Marrik’s articles provide criticism and an alternative.) In the requirements gathering stage the business requirements can verify and validate the business case used to justify the project. The business requirements are also used to guide the user acceptance testing. The model illustrates how each subsequent phase
should verify and validate work done in the previous phase, and how work done during development is used to guide the individual testing phases. This interconnectedness lets us identify important errors, omissions, and other problems before they can do serious harm. Application testing begins with Unit Testing, and in the section titled
“Types of Tests” we will discuss each of these test phases in more detail.

THE TEST PLAN
The test plan is a mandatory document. You can’t test without one. For simple, straight-forward projects the plan doesn’t have to be elaborate but it must address certain items. As identified by the “American National Standards Institute and Institute for Electrical and Electronic Engineers Standard 829/1983 for Software Test Documentation”, the following components should be covered in a software test plan.

Items Covered by a Test Plan :

REDUCE RISK WITH A TEST PLAN
The release of a new application or an upgrade inherently carries a certain amount of risk that it will fail to do what it’s supposed to do. A good test plan goes a long way towards reducing this risk. By identifying areas that are riskier
than others we can concentrate our testing efforts there. These areas include not only the must-have features butalso areas in which the technical staff is less experienced, perhaps such as the real-time loading of a web form’s contents into a database using complex ETL logic. Because riskier areas require more certainty that they work properly, failing to correctly identify those risky areas leads to a misallocated testing effort.

How do we identify risky areas? Ask everyone for their opinion! Gather information from developers, sales and marketing staff, technical writers, customer support people, and of course any users who are available. Historical data and bug and testing reports from similar products or previous releases will identify areas to explore. Bug reports from customers are important, but also look at bugs reported by the developers themselves. These will provide insight to the technical areas they may be having trouble in.

When the problems are inevitably found, it’s important that both the IT side and the business users have previously agreed on how to respond. This includes having a method for rating the importance of defects so that repair work effort can be focused on the most important problems. It is very common to use a set of rating categories that represent decreasing relative severity in terms of business/commercial impact. In one system, '1' is the most severe
and 6' has the least impact. Keep in mind that an ordinal system doesn’t allow an average score to be calculated, but you shouldn’t need to do that anyway—a defect’s category should be pretty obvious.

1. Show Stopper – It is impossible to continue testing because of the severity of the defect.
2. Critical -- Testing can continue but the application cannot be released into production until this defect is fixed.
3. Major -- Testing can continue but this defect will result in a severe departure from the business requirements if released for production.
4. Medium -- Testing can continue and the defect will cause only minimal departure from the business requirements when in production.
5. Minor -– Testing can continue and the defect will not affect the release into production. The defect should be corrected but little or no changes to business requirements are envisaged.
6. Cosmetic -– Minor cosmetic issues like colors, fonts, and pitch size that do not affect testing or production release. If, however, these features are important business requirements then they will receive a higher severity level.

WHAT SHOULD A TEST PLAN TEST?
Testing experts generally agree that test plans are often biased towards functionaltesting during which each feature is tested alone in a unit test, and that the systems integration test is just a series of unit tests strung together. (More on test types later.) The problem that this approach causes is that if we test each feature alone and then string a bunch of these tests together, we might never find that a series of steps such as

{open a document, edit the document, print the document, save the document, edit one page, print one page, save as a new document}

doesn’t work. But a user will find out and probably quickly. Admittedly, testing every combination of keystrokes or commands is difficult at best and may well be impossible (this is where unstructured testing comes in), but we must remember that features don’t function in isolation from each other.

Users have a task orientation. To find the defects that they will find—the ones that are important to them—test plans need to exercise the application across functional areas by mimicking both typical and atypical user tasks. A test like the sequence shown above is called scenario testing, task-based testing, or use-case testing.

An incomplete test plan can result in a failure to check how the application works on different hardware and operating systems or when combined with different third-party software. This is not always needed but you will want to think about the equipment your customers use. There may be more than a few possible system combinations that need to be tested, and that can require a possibly expensive computer lab stocked with hardware and spending much time setting up tests. Configuration testing isn't cheap, but it’s worth it when you discover that the application running on your standard in-house platform which "entirely conforms to industry standards" behaves differently when it runs on the boxes your customers are using. In a 1996 incident this author was involved in, the development and testing was done on new 386-class machines and the application worked just fine. Not until customers complained about performance did we learn that they were using 286’s with slow hard drives.

A crucial test is to see how the application behaves when it’s under a normal load and then under stress. The definition of stress, of course, will be derived from your business requirements, but for a web-enabled application stress could be caused by a spike in the number of transactions, a few very large transactions at the same time, or a large number of almost identical simultaneous transactions. The goal is to see what happens when the application is pushed to substantially more than the basic requirements. Stress testing is often put off until the end of testing, after
everything else that’s going to be fixed has been. Unfortunately that leaves little time for repairs when the requirements specify 40 simultaneous users and you find that performance becomes unacceptable at 50.

Finally, Marick (1997) points out two common omissions in many test plans--the installation procedures and the documentation are ignored. Everyone has tried to follow installation instructions that were missing a key step or two, and we’ve all paged through incomprehensible documentation. Although those documents may have been written by a professional technical writer, they probably weren’t tested by a real user. Bad installation instructions immediately cause lowered expectations of what to expect from the product, and poorly organized or written documentation certainly doesn’t help a confused or irritated customer feel better. Testing installation procedures and documentation is a good way to avoid making a bad first impression or making a bad situation worse.

Test Plan Terminology

TYPES OF SOFTWARE TESTS
The V-Model of testing identifies five software testing phases, each with a certain type of test associated with it.

Each testing phase and each individual test should have specific entry criteria that must be met before testing can begin and specific exit criteria that must be met before the test or phase can be certified as successful. The entry and exit criteria are defined by the Test Coordinators and listed in the Test Plan.

UNIT TESTING
A series of stand-alone tests are conducted during Unit Testing. Each test examinesan individual component that is new or has been modified. A unit test is also called a module test because it tests the individual units of code that
comprise the application.

Each test validates a single module that, based on the technical design documents, was built to perform a certain task with the expectation that it will behave in a specific way or produce specific results. Unit tests focus on functionality
and reliability, and the entry and exit criteria can be the same for each module or specific to a particular module. Unit testing is done in a test environment prior to system integration. If a defect is discovered during a unit test, the severity of the defect will dictate whether or not it will be fixed before the module is approved.

Sample Entry and Exit Criteria for Unit Testing

SYSTEM TESTING
System Testing tests all components and modules that are new, changed, affected by a change, or needed to form the complete application. The system test may require involvement of other systems but this should be minimized as much as possible to reduce the risk of externally-induced problems. Testing the interaction with other parts of the complete system comes in Integration Testing. The emphasis in system testing is validating and verifying the functional design specification and seeing how all the modules work together. For example, the system test for a new web interface that collects user input for addition to a database doesn’t need to include the database’s ETL application—processing can stop when the data is moved to the data staging area if there is one.

The first system test is often a smoke test. This is an informal quick-and-dirty run through of the application’s major functions without bothering with details. The term comes from the hardware testing practice of turning on a new piece of equipment for the first time and considering it a success if it doesn’t start smoking or burst into flame.

System testing requires many test runs because it entails feature by feature validation of behavior using a wide range of both normal and erroneous test inputs and data. The Test Plan is critical here because it contains descriptions of
the test cases, the sequence in which the tests must be executed, and the documentation needed to be collected in each run.

When an error or defect is discovered, previously executed system tests must be rerun after the repair is made to make sure that the modifications didn’t cause other problems. This will be covered in more detail in the section on
regression testing.

Sample Entry and Exit Criteria for System Testing

SYSTEM TESTING
System Testing tests all components and modules that are new, changed, affected by a change, or needed to form the complete application. The system test may require involvement of other systems but this should be minimized as much as possible to reduce the risk of externally-induced problems. Testing the interaction with other parts of the complete system comes in Integration Testing. The emphasis in system testing is validating and verifying the functional design specification and seeing how all the modules work together. For example, the system test for a new web interface that collects user input for addition to a database doesn’t need to include the database’s ETL application—processing can stop when the data is moved to the data staging area if there is one.

The first system test is often a smoke test. This is an informal quick-and-dirty run through of the application’s major functions without bothering with details. The term comes from the hardware testing practice of turning on a new piece of equipment for the first time and considering it a success if it doesn’t start smoking or burst into flame.

System testing requires many test runs because it entails feature by feature validation of behavior using a wide range of both normal and erroneous test inputs and data. The Test Plan is critical here because it contains descriptions of
the test cases, the sequence in which the tests must be executed, and the documentation needed to be collected in each run.

When an error or defect is discovered, previously executed system tests must be rerun after the repair is made to make sure that the modifications didn’t cause other problems. This will be covered in more detail in the section on regression testing.

Sample Entry and Exit Criteria for System Testing

As part of system testing, conformance tests and reviews can be run to verify that the application conforms to corporate or industry standards in terms of portability, interoperability, and compliance with standards. For example,
to enhance application portability a corporate standard may be that SQL queries must be written so that they work against both Oracle and DB2 databases.

INTEGRATION TESTING
Integration testing examines all the components and modules that are new, changed, affected by a change, or needed to form a complete system. Where system testing tries to minimize outside factors, integration testing requires involvement of other systems and interfaces with other applications, including those owned by an outside
vendor, external partners, or the customer. For example, integration testing for a new web interface that collects user input for addition to a database must include the database’s ETL application even if the database is hosted by a vendor—the complete system must be tested end-to-end. In this example, integration testing doesn’t stop with the database load; test reads must verify that it was correctly loaded.

Integration testing also differs from system testing in that when a defect is discovered, not all previously executed tests have to be rerun after the repair is made. Only those tests with a connection to the defect must be rerun, but
retesting must start at the point of repair if it is before the point of failure. For example, the retest of a failed FTP process may use an existing data file instead of recreating it if up to that point everything else was OK.

Sample Entry and Exit Criteria for Integration Testing

Integration testing has a number of sub-types of tests that may or may not be used, depending on the application being tested or expected usage patterns.
♦ Compatibility Testing – Compatibility tests insures that the application works with differently configured systems based on what the users have or may have. When testing a web interface, this means testing for compatibility with different browsers and connection speeds.
♦ Performance Testing – Performance tests are used to evaluate and understand the application’s scalability when, for example, more users are added or the volume of data increases. This is particularly important for identifying bottlenecks in high usage applications. The basic approach is to collect timings of the critical
business processes while the test system is under a very low load (a ‘quiet box’ condition) and then collect the same timings with progressively higher loads until the maximum required load is reached. For a data retrieval application, reviewing the performance pattern may show that a change needs to be made in a stored SQL procedure or that an index should be added to the database design.
♦ Stress Testing – Stress Testing is performance testing at higher than normal simulated loads. Stressing runs the system or application beyond the limits of its specified requirements to determine the load under which it fails and how it fails. A gradual performance slow-down leading to a non-catastrophic system halt is the desired result, but if the system will suddenly crash and burn it’s important to know the point where that will happen. Catastrophic failure in production means beepers going off, people coming in after hours, system restarts, frayed tempers, and possible financial losses. This test is arguably the most important test
for mission-critical systems.
♦ Load Testing – Load tests are the opposite of stress tests. They test the capability of the application to function properly under expected normal production conditions and measure the response times for critical transactions or processes to determine if they are within limits specified in the business requirements and
design documents or that they meet Service Level Agreements. For database applications, load testing must be executed on a current production-size database. If some database tables are forecast to grow much larger in the foreseeable future then serious consideration should be given to testing against adatabase of the projected size.

Performance, stress, and load testing are all major undertakings and will require substantial input from the business sponsors and IT staff in setting up a test environment and designing test cases that can be accurately executed. Because of this, these tests are sometimes delayed and made part of the User Acceptance Testing phase. Load tests especially must be documented in detail so that the tests are repeatable in case they need to be executed several times to ensure that new releases or changes in database size do not push response times beyond
prescribed requirements and Service Level Agreements.

USER ACCEPTANCE TESTING (UAT)
User Acceptance Testing is also called Beta testing, application testing, and end-user testing. Whatever you choose to call it, it’s where testing moves from the hands of the IT department into those of the business users. Software vendors often make extensive use of Beta testing, some more formally than others, because they can get users to do it for free.

By the time UAT is ready to start, the IT staff has resolved in one way or another all the defects they identified. Regardless of their best efforts, though, they probably don’t find all the flaws in the application. A general rule of
thumb is that no matter how bulletproof an application seems when it goes into UAT, a user somewhere can still find a sequence of commands that will produce an error.

Nothing is foolproof. Fools are just too darn clever. - anonymous

To be of real use, UAT cannot be random users playing with the application. A mix of business users with varying degrees of experience and subject matter expertise need to actively participate in a controlled environment.
Representatives from the group work with Testing Coordinators to design and conduct tests that reflect activities and conditions seen in normal business usage. Business users also participate in evaluating the results. This insures that the application is tested in real-world situations and that the tests cover the full range of business usage. The goal of UAT is to simulate realistic business activity and processes in the test environment.

A phase of UAT called “Unstructured Testing” will be conducted whether or not it’s in the Test Plan. Also known as guerilla testing, this is when business users bash away at the keyboard to find the weakest parts of the application. In effect, they try to break it. Although it’s a free-form test, it’s important that users who participate understand that they have to be able to reproduce the steps that led to any errors they find. Otherwise it’s of no use.

A common occurrence in UAT is that once the business users start working with the application they find that it doesn’t do exactly what they want it to do or that it does something that, although correct, is not quite optimal. Investigation finds that the root cause is in the Business Requirements, so the users will ask for a change. During UAT is when change control must be most seriously enforced, but change control is beyond the scope of this paper. Suffice to say that scope creep is especially dangerous in this late phase and must be avoided.

Sample Entry and Exit Criteria for User Acceptance Testing

PRODUCTION VERIFICATION TESTING
Production verification testing is a final opportunity to determine if the software is ready for release. Its purpose is to simulate the production cutover as closely as possible and for a period of time simulate real business activity. As a sort of full dress rehearsal, it should identify anomalies or unexpected changes to existing processes introduced by the new application. For mission critical applications the importance of this testing cannot be overstated.

The application should be completely removed from the test environment and then completely reinstalled exactly as it will be in the production implementation. Then mock production runs will verify that the existing business process flows, interfaces, and batch processes continue to run correctly. Unlike parallel testing in which the old and new
systems are run side-by-side, mock processing may not provide accurate data handling results due to limitations of the testing database or the source data.

Sample Entry and Exit Criteria for Production Verification Testing

REGRESSION TESTING

Bugs will appear in one part of a working program immediately
after an 'unrelated' part of the program is modified -
Murphy

Regression testing is also known as validation testing and provides a consistent, repeatable validation of each change to an application under development or being modified. Each time a defect is fixed, the potential exists to inadvertently introduce new errors, problems, and defects. An element of uncertainty is introduced about ability of the application to repeat everything that went right up to the point of failure. Regression testing is the probably selective retesting of an application or system that has been modified to insure that no previously working components, functions, or features fail as a result of the repairs.

Regression testing is conducted in parallel with other tests and can be viewed as a quality control tool to ensure that the newly modified code still complies with its specified requirements and that unmodified code has not been affected by the change. It is important to understand that regression testing doesn’t test that a specific defect has been fixed. Regression testing tests that the rest of the application up to the point or repair was not adversely affected by the fix.

Sample Entry and Exit Criteria for Regression Testing

ISEB/ISTQB Foundation Documents

2007-11-08T07:51:00.001-08:00
ISEB/ISTQB Foundation Documents.

Below are some of the documents which can be referred for your ISEB/ISTQB foundation in software testing.Click on the link to download the file.

Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6

All The Best

ISTQB TEST 7

2007-11-07T09:55:00.000-08:00
ISTQB Foundation Level Mock Test 2

Duration: 1 hour

Instructions:
1. Pass criteria will be 60%
2. No negative marking

1. COTS is known as
A. Commercial off the shelf software
B. Compliance of the software
C. Change control of the software
D. Capable off the shelf software

2. From the below given choices, which one is the ‘Confidence testing’
A. Sanity testing
B. System testing
C. Smoke testing
D. Regression testing

3. ‘Defect Density’ calculated in terms of
A. The number of defects identified in a component or system divided by the size of the component or the system
B. The number of defects found by a test phase divided by the number found by that test phase and any other means after wards
C. The number of defects identified in the component or system divided by the number of defects found by a test phase
D. The number of defects found by a test phase divided by the number found by the size of the system

4. ‘Be bugging’ is known as
A. Preventing the defects by inspection
B. Fixing the defects by debugging
C. Adding known defects by seeding
D. A process of fixing the defects by tester

5. An expert based test estimation is also known as
A. Narrow band Delphi
B. Wide band Delphi
C. Bespoke Delphi
D. Robust Delphi

6. When testing a grade calculation system, a tester determines that all scores from 90 to 100 will yield a grade of A, but scores below 90 will not. This analysis is known as:

A. Equivalence partitioning
B. Boundary value analysis
C. Decision table
D. Hybrid analysis

7. All of the following might be done during unit testing except

A. Desk check
B. Manual support testing
C. Walkthrough
D. Compiler based testing

9. Which of the following characteristics is primarily associated with software reusability?

A. The extent to which the software can be used in other applications
B. The extent to which the software can be used by many different users
C. The capability of the software to be moved to a different platform
D. The capability of one system to be coupled with another system

10. Which of the following software change management activities is most vital to assessing the impact of proposed software modifications?
A. Baseline identification B. Configuration auditing
C. Change control D. Version control

11. Which of the following statements is true about a software verification and validation program?

I. It strives to ensure that quality is built into software.
II. It provides management with insights into the state of a software project.
III. It ensures that alpha, beta, and system tests are performed.
IV. It is executed in parallel with software development activities.

A. I, II&III B.II, III&IV C.I, II&IV D.I, III&IV

12. Which of the following is a requirement of an effective software environment?

I. Ease of use
II. Capacity for incremental implementation
III. Capability of evolving with the needs of a project
IV. Inclusion of advanced tools

A.I, II &III B.I, II &IV C.II, III&IV D.I, III&IV

13. A test manager wants to use the resources available for the automated testing of a web application. The best choice is

A. Test automater, web specialist, DBA, test lead
B. Tester, test automater, web specialist, DBA
C. Tester, test lead, test automater, DBA
D. Tester, web specialist, test lead, test automater

14. A project manager has been transferred to a major software development project that is in the implementation phase. The highest priority for this project manager should be to
B. Establish a relationship with the customer
C. Learn the project objectives and the existing project plan
D. Modify the project’ s organizational structure to meet the manager’ s management style
E. Ensure that the project proceeds at its current pace

15. Change X requires a higher level of authority than Change Y in which of the following pairs?

Change X Change Y
A. Code in development Code in production
B. Specifications during requirements analysis Specifications during systems test
C. Documents requested by the technical development group Documents requested by customers
D. A product distributed to several sites A product with a single user

16. Which of the following functions is typically supported by a software quality information system?
I. Record keeping
II. System design
III. Evaluation scheduling
IV. Error reporting

A.I, II&III B.II, III &IV C.I, III &IV D.I, II & IV

17. During the testing of a module tester ‘X’ finds a bug and assigned it to developer. But developer rejects the same, saying that it’s not a bug. What ‘X’ should do?

A. Report the issue to the test manager and try to settle with the developer.
B. Retest the module and confirm the bug
C. Assign the same bug to another developer
D. Send to the detailed information of the bug encountered and check the reproducibility

18. The primary goal of comparing a user manual with the actual behavior of the running program during system testing is to

A. Find bugs in the program
B. Check the technical accuracy of the document
C. Ensure the ease of use of the document
D. Ensure that the program is the latest version

19. A type of integration testing in which software elements, hardware elements, or both are combined all at once into a component or an overall system, rather than in stages.
A. System Testing B. Big-Bang Testing
C. Integration Testing D. Unit Testing

20. In practice, which Life Cycle model may have more, fewer or different levels of development and testing, depending on the project and the software product. For example, there may be component integration testing after component testing, and system integration testing after system testing.

A. Water Fall Model B.V-Model
C. Spiral Model D. RAD Model

21. Which technique can be used to achieve input and output coverage? It can be applied to human input, input via interfaces to a system, or interface parameters in integration testing.
A. Error Guessing B. Boundary Value Analysis
C. Decision Table testing D. Equivalence partitioning

22. There is one application, which runs on a single terminal. There is another application that works on multiple terminals. What are the test techniques you will use on the second application that you would not do on the first application?

A. Integrity, Response time B. Concurrency test, Scalability
C. Update & Rollback, Response time D. Concurrency test, Integrity

23. You are the test manager and you are about the start the system testing. The developer team says that due to change in requirements they will be able to deliver the system to you for testing 5 working days after the due date. You can not change the resources(work hours, test tools, etc.) What steps you will take to be able to finish the testing in time. (

A. Tell to the development team to deliver the system in time so that testing activity will be finish in time.
B. Extend the testing plan, so that you can accommodate the slip going to occur
C. Rank the functionality as per risk and concentrate more on critical functionality testing
D. Add more resources so that the slippage should be avoided

24. Item transmittal report is also known as

A. Incident report B. Release note
C. Review report D. Audit report

25. Testing of software used to convert data from existing systems for use in replacement systems
A. Data driven testing B. Migration testing
C. Configuration testing D. Back to back testing

26. Big bang approach is related to

A. Regression testing B. Inter system testing
C. Re-testing D. Integration testing

27. Cause effect graphing is related to the standard

A. BS7799 B. BS 7925/2 C. ISO/IEC 926/1 D. ISO/IEC 2382/1

28. “The tracing of requirements for a test level through the layers of a test documentation” done by

A. Horizontal tracebility B. Depth tracebility
C. Vertical tracebility D. Horizontal & Vertical tracebilities

29. A test harness is a
A. A high level document describing the principles, approach and major objectives of the organization regarding testing
B. A distance set of test activities collected into a manageable phase of a project
C. A test environment comprised of stubs and drives needed to conduct a test
D. A set of several test cases for a component or system under test

30. You are a tester for testing a large system. The system data model is very large with many attributes and there are a lot of inter dependencies with in the fields. What steps would you use to test the system and also what are the efforts of the test you have taken on the test plan

A. Improve super vision, More reviews of artifacts or program means stage containment of the defects.
B. Extend the test plan so that you can test all the inter dependencies
C. Divide the large system in to small modules and test the functionality
D. Test the interdependencies first, after that check the system as a whole

31. Change request should be submitted through development or program management. A change request must be written and should include the following criteria.
I. Definition of the change
II. Documentation to be updated
III. Name of the tester or developer
IV. Dependencies of the change request.

A. I, III and IV B. I, II and III C. II, III and IV D. I, II and IV

32. ‘Entry criteria’ should address questions such as

I. Are the necessary documentation, design and requirements information available that will allow testers to operate the system and judge correct behavior.
II. Is the test environment-lab, hardware, software and system administration support ready?
III. Those conditions and situations that must prevail in the testing process to allow testing to continue effectively and efficiently.
IV. Are the supporting utilities, accessories and prerequisites available in forms that testers can use

A. I, II and IV B. I, II and III C. I, II, III and IV D. II, III and IV.

33. “This life cycle model is basically driven by schedule and budget risks” This statement is best suited for
A. Water fall model B. Spiral model
C. Incremental model D. V-Model

34. The bug tracking system will need to capture these phases for each bug.

I. Phase injected
II. Phase detected
III. Phase fixed
IV. Phase removed

A. I, II and III B. I, II and IV C. II, III and IV D. I, III and IV

35. One of the more daunting challenges of managing a test project is that so many dependencies converge at test execution. One missing configuration file or hard ware device can render all your test results meaning less. You can end up with an entire platoon of testers sitting around for days.
Who is responsible for this incident?

A. Test managers faults only
B. Test lead faults only
C. Test manager and project manager faults
D. Testers faults only

36. System test can begin when?

I. The test team competes a three day smoke test and reports on the results to the system test phase entry meeting
II. The development team provides software to the test team 3 business days prior to starting of the system testing
III. All components are under formal, automated configuration and release management control

A. I and II only B. II and III only C. I and III only D. I, II and III

37. Test charters are used in ________ testing

A. Exploratory testing B. Usability testing
C. Component testing D. Maintainability testing

All The Best

ISTQB Foundation Level Mock Test 2 Key

Q.No Answer Q.No Answer
1 (A) 20 (B)
2 (C) 21 (D)
3 (A) 22 (C)
4 (C) 23 (C)
5 (B) 24 (B)
6 (A) 25 (B)
7 (B) 26 (D)
8 (B) 27 (B)
9 (A) 28 (A)
10 (C) 29 (C)
11 (C) 30 (A)
12 (A) 31 (D)
13 (B) 32 (A)
14 (B) 33 (D)
15 (D) 34 (B)
16 (C) 35 (A)
17 (D) 36 (D)
18 (B) 37 (A)
19 (B)

ISTQB TEST 6

2007-11-07T09:53:00.000-08:00
ISTQB Foundation Level Mock Test 1

Duration: 1 hour

Instructions:

1. Pass criteria will be 60% ,
2. No negative marking

1. ___________ Testing will be performed by the people at client own locations (1M)

A. Alpha testing B. Field testing C. Performance testing D. System testing

2. System testing should investigate (2M)
A. Non-functional requirements only not Functional requirements
B. Functional requirements only not non-functional requirements
C. Non-functional requirements and Functional requirements
D. Non-functional requirements or Functional requirements

3. Which is the non-functional testing (1M)

A. Performance testing B. Unit testing
C. Regression testing D. Sanity testing

4. Who is responsible for document all the issues, problems and open point that were identified during the review meeting (2M)

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

5. What is the main purpose of Informal review (2M)

A. Inexpensive way to get some benefit
B. Find defects
C. Learning, gaining understanding, effect finding
D. Discuss, make decisions, solve technical problems

6. Purpose of test design technique is (1M)

A. Identifying test conditions only, not Identifying test cases
B. Not Identifying test conditions, Identifying test cases only
C. Identifying test conditions and Identifying test cases
D. Identifying test conditions or Identifying test cases
7. ___________ technique can be used to achieve input and output coverage (1M)

A. Boundary value analysis B. Equivalence partitioning
C. Decision table testing D. State transition testing

8. Use cases can be performed to test (2M)

A. Performance testing B. Unit testing
C. Business scenarios D. Static testing

9. ________________ testing is performed at the developing organization’s site (1M)

A. Unit testing B. Regression testing
C. Alpha testing D. Integration testing

10. The purpose of exit criteria is (2M)

A. Define when to stop testing
B. End of test level
C. When a set of tests has achieved a specific pre condition
D. All of the above

11. Which is not the project risks (2M)

A. Supplier issues B. Organization factors
C. Technical issues D. Error-prone software delivered

12. Poor software characteristics are (3M)

A. Only Project risks
B. Only Product risks
C. Project risks and Product risks
D. Project risks or Product risks
13. ________ and ________ are used within individual workbenches to produce the right output products. (2M)

A. Tools and techniques B. Procedures and standards
C. Processes and walkthroughs D. Reviews and update

14. The software engineer's role in tool selection is (3M)

A. To identify, evaluate, and rank tools, and recommend tools to management
B. To determine what kind of tool is needed, then find it and buy it
C. To initiate the tool search and present a case to management
D. To identify, evaluate and select the tools

15. A _____ is the step-by-step method followed to ensure that standards are met (2M)

A. SDLC B. Project Plan C. Policy D. Procedure

16. Which of the following is the standard for the Software product quality (1M)

A. ISO 1926 B. ISO 829 C. ISO 1012 D. ISO 1028

17. Which is not the testing objectives (1M)

A. Finding defects
B. Gaining confidence about the level of quality and providing information
C. Preventing defects.
D. Debugging defects

18. Bug life cycle (1M)

A. Open, Assigned, Fixed, Closed
B. Open, Fixed, Assigned, Closed
C. Assigned, Open, Closed, Fixed
D. Assigned, Open, Fixed, Closed

19. Which is not the software characteristics (1M)

A. Reliability B. Usability C. Scalability D. Maintainability

20. Which is not a testing principle (2M)

A. Early testing B. Defect clustering
C. Pesticide paradox D. Exhaustive testing

21. ‘X’ has given a data on a person age, which should be between 1 to 99. Using BVA which is the appropriate one (3M)

A. 0,1,2,99 B. 1, 99, 100, 98 C. 0, 1, 99, 100 D. –1, 0, 1, 99

22. Which is not the fundamental test process (1M)

A. Planning and control B. Test closure activities
C. Analysis and design D. None

23. Which is not a Component testing (2M)

A. Check the memory leaks B. Check the robustness
C. Check the branch coverage D. Check the decision tables

24. PDCA is known as (1M)

A. Plan, Do, Check, Act B. Plan, Do, Correct, Act
C. Plan, Debug, Check, Act D. Plan, Do, Check, Accept

25. Contract and regulation testing is a part of (2M)

A. System testing B. Acceptance testing
C. Integration testing D. Smoke testing

26. Which is not a black box testing technique (1M)

A. Equivalence partition B. Decision tables
C. Transaction diagrams D. Decision testing

27. Arc testing is known as (2M)

A. Branch testing B. Agile testing
C. Beta testing D. Ad-hoc testing

28. A software model that can’t be used in functional testing (2M)

A. Process flow model B. State transaction model
C. Menu structure model D. Plain language specification model

29. Find the mismatch (2M)

A. Test data preparation tools – Manipulate Data bases
B. Test design tools – Generate test inputs
C. Requirement management tools – Enables individual tests to be traceable
D. Configuration management tools – Check for consistence

30. The principle of Cyclomatic complexity, considering L as edges or links, N as nodes, P as independent paths (2M)

A. L-N +2P
B. N-L +2P
C. N-L +P
D. N-L +P

31. FPA is used to (2M)

A. To measure the functional requirements of the project
B. To measure the size of the functionality of an Information system
C. To measure the functional testing effort
D. To measure the functional flow

32. Which is not a test Oracle (2M)

A. The existing system (For a bench mark)
B. The code
C. Individual’s knowledge
D. User manual

33. Find the correct flow of the phases of a formal review (3M)

A. Planning, Review meeting, Rework, Kick off
B. Planning, Individual preparation, Kick off, Rework
C. Planning, Review meeting, Rework, Follow up
D. Planning, Individual preparation, Follow up, Kick off

34. Stochastic testing using statistical information or operational profiles uses the following method (3M)

A. Heuristic testing approach
B. Methodical testing approach
C. Model based testing approach
D. Process or standard compliant testing approach

35. A project that is in the implementation phase is six weeks behind schedule. The delivery date for the product is four months away. The project is not allowed to slip the delivery date or compromise on the quality standards established for this product. Which of the following actions would bring this project back on schedule? (3M)

A. Eliminate some of the requirements that have not yet been implemented.
B. Add more engineers to the project to make up for lost work.
C. Ask the current developers to work overtime until the lost work is recovered.
D. Hire more software quality assurance personnel.

36. One person has been dominating the current software process improvement meeting. Which of the following techniques should the facilitator use to bring other team members into the discussion? (3M)

A. Confront the person and ask that other team members be allowed to express their opinions.
B. Wait for the person to pause, acknowledge the person’ s opinion, and ask for someone else’ s opinion.
C. Switch the topic to an issue about which the person does not have a strong opinion.
D. Express an opinion that differs from the person’ s opinion in order to encourage others to express their ideas.

37. Maintenance releases and technical assistance centers are examples of which of the following costs of quality? (3M)

A. External failure
B. Internal failure
C. Appraisal
D. Prevention

All the best

ISTQB Foundation Level Mock Test 1 Key

Q.No Answer Q.No Answer
1 B 20 D
2 C 21 C
3 A 22 D
4 B 23 D
5 A 24 A
6 C 25 B
7 B 26 D
8 C 27 A
9 C 28 C
10 D 29 D
11 D 30 A
12 B 31 B
13 B 32 B
14 A 33 C
15 D 34 C
16 A 35 A
17 D 36 B
18 A 37 A
19 C

ISTQB TEST 5

2007-11-07T09:49:00.000-08:00
Foundation Certificate In Software Testing Practice Exam

Time allowed: 1 hour

40 QUESTIONS

Question
NOTE: Only one answer per question

1 We split testing into distinct stages primarily because:
a) Each test stage has a different purpose.
b) It is easier to manage testing in stages.
c) We can run different tests in different environments.
d) The more stages we have, the better the testing.

2 Which of the following is likely to benefit most from the use of test tools providing test capture and replay facilities?
a) Regression testing
b) Integration testing
c) System testing
d) User acceptance testing

3 Which of the following statements is NOT correct?
a) A minimal test set that achieves 100% LCSAJ coverage will also achieve 100% branch coverage.
b) A minimal test set that achieves 100% path coverage will also achieve 100% statement coverage.
c) A minimal test set that achieves 100% path coverage will generally detect more faults than one that achieves 100% statement coverage.
d) A minimal test set that achieves 100% statement coverage will generally detect more faults than one that achieves 100% branch coverage.

4 Which of the following requirements is testable?
a) The system shall be user friendly.
b) The safety-critical parts of the system shall contain 0 faults.
c) The response time shall be less than one second for the specified design load.
d) The system shall be built to be portable.

5 Analyse the following highly simplified procedure:
Ask: “What type of ticket do you require, single or return?”
IF the customer wants ‘return’
Ask: “What rate, Standard or Cheap-day?”
IF the customer replies ‘Cheap-day’
Say: “That will be £11:20”
ELSE
Say: “That will be £19:50”
ENDIF
ELSE
Say: “That will be £9:75”
ENDIF
Now decide the minimum number of tests that are needed to ensure that all
the questions have been asked, all combinations have occurred and all
replies given.
a) 3
b) 4
c) 5d) 6

6 Error guessing:
a) supplements formal test design techniques.
b) can only be used in component, integration and system testing.
c) is only performed in user acceptance testing.
d) is not repeatable and should not be used.

7 Which of the following is NOT true of test coverage criteria?
a) Test coverage criteria can be measured in terms of items exercised by a test suite.
b) A measure of test coverage criteria is the percentage of user requirements covered.
c) A measure of test coverage criteria is the percentage of faults found.
d) Test coverage criteria are often used when specifying test completion criteria.

8 In prioritising what to test, the most important objective is to:
a) find as many faults as possible.
b) test high risk areas.
c) obtain good test coverage.
d) test whatever is easiest to test.

9 Given the following sets of test management terms (v-z), and activity descriptions (1-5), which one of the following best pairs the two sets?
v – test control
w – test monitoring
x - test estimation
y - incident management
z - configuration control

1 - calculation of required test resources
2 - maintenance of record of test results
3 - re-allocation of resources when tests overrun
4 - report on deviation from test plan
5 - tracking of anomalous test results

a) v-3,w-2,x-1,y-5,z-4
b) v-2,w-5,x-1,y-4,z-3
c) v-3,w-4,x-1,y-5,z-2
d) v-2,w-1,x-4,y-3,z-5

10 Which one of the following statements about system testing is NOT true?
a) System tests are often performed by independent teams.
b) Functional testing is used more than structural testing.
c) Faults found during system tests can be very expensive to fix.
d) End-users should be involved in system tests.

11 Which of the following is false?
a) Incidents should always be fixed.
b) An incident occurs when expected and actual results differ.
c) Incidents can be analysed to assist in test process improvement.
d) An incident can be raised against documentation.

12 Enough testing has been performed when:
a) time runs out.
b) the required level of confidence has been achieved.
c) no more faults are found.
d) the users won’t find any serious faults.

13 Which of the following is NOT true of incidents?
a) Incident resolution is the responsibility of the author of the software under test.
b) Incidents may be raised against user requirements.
c) Incidents require investigation and/or correction.
d) Incidents are raised when expected and actual results differ.

14 Which of the following is not described in a unit test standard?
a) syntax testing
b) equivalence partitioning
c) stress testing
d) modified condition/decision coverage

15 Which of the following is false?
a) In a system two different failures may have different severities.
b) A system is necessarily more reliable after debugging for the removal of a fault.
c) A fault need not affect the reliability of a system.
d) Undetected errors may lead to faults and eventually to incorrect behaviour.

16 Which one of the following statements, about capture-replay tools, is NOT correct?
a) They are used to support multi-user testing.
b) They are used to capture and animate user requirements.
c) They are the most frequently purchased types of CAST tool.
d) They capture aspects of user behaviour.

17 How would you estimate the amount of re-testing likely to be required?
a) Metrics from previous similar projects
b) Discussions with the development team
c) Time allocated for regression testing
d) a & b

18 Which of the following is true of the V-model?
a) It states that modules are tested against user requirements.
b) It only models the testing phase.
c) It specifies the test techniques to be used.
d) It includes the verification of designs.

19 The oracle assumption:
a) is that there is some existing system against which test output may be checked.
b) is that the tester can routinely identify the correct outcome of a test.
c) is that the tester knows everything about the software under test.
d) is that the tests are reviewed by experienced testers.

20 Which of the following characterises the cost of faults?
a) They are cheapest to find in the early development phases and the most expensive to fix in the latest test phases.
b) They are easiest to find during system testing but the most expensive to fix then.
c) Faults are cheapest to find in the early development phases but the most expensive to fix then.
d) Although faults are most expensive to find during early development phases, they are cheapest to fix then.

21 Which of the following should NOT normally be an objective for a test?
a) To find faults in the software.
b) To assess whether the software is ready for release.
c) To demonstrate that the software doesn’t work.
d) To prove that the software is correct.

22 Which of the following is a form of functional testing?
a) Boundary value analysis
b) Usability testing
c) Performance testing
d) Security testing

23 Which of the following would NOT normally form part of a test plan?
a) Features to be tested
b) Incident reports
c) Risks
d) Schedule

24 Which of these activities provides the biggest potential cost saving from the use of CAST?
a) Test management
b) Test design
c) Test execution
d) Test planning

25 Which of the following is NOT a white box technique?
a) Statement testing
b) Path testing
c) Data flow testing
d) State transition testing

26 Data flow analysis studies:
a) possible communications bottlenecks in a program.
b) the rate of change of data values as a program executes.
c) the use of data on paths through the code.
d) the intrinsic complexity of the code.

27 In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10%
The next £28000 is taxed at 22%
Any further amount is taxed at 40%
To the nearest whole pound, which of these is a valid Boundary Value Analysis test case?
a) £1500
b) £32001
c) £33501
d) £28000

28 An important benefit of code inspections is that they:
a) enable the code to be tested before the execution environment is ready.
b) can be performed by the person who wrote the code.
c) can be performed by inexperienced staff.
d) are cheap to perform.

29 Which of the following is the best source of Expected Outcomes for User Acceptance Test scripts?
a) Actual results
b) Program specification
c) User requirements
d) System specification

30 What is the main difference between a walkthrough and an inspection?
a) An inspection is lead by the author, whilst a walkthrough is lead by a trained moderator.
b) An inspection has a trained leader, whilst a walkthrough has no leader.
c) Authors are not present during inspections, whilst they are during walkthroughs.
d) A walkthrough is lead by the author, whilst an inspection is lead by a trained moderator.

31 Which one of the following describes the major benefit of verification early in the life cycle?
a) It allows the identification of changes in user requirements.
b) It facilitates timely set up of the test environment.
c) It reduces defect multiplication.
d) It allows testers to become involved early in the project.

32 Integration testing in the small:
a) tests the individual components that have been developed.
b) tests interactions between modules or subsystems.
c) only uses components that form part of the live system.
d) tests interfaces to other systems.

33 Static analysis is best described as:
a) the analysis of batch programs.
b) the reviewing of test plans.
c) the analysis of program code.
d) the use of black box testing.

34 Alpha testing is:
a) post-release testing by end user representatives at the developer’s site.
b) the first testing that is performed.
c) pre-release testing by end user representatives at the developer’s site.
d) pre-release testing by end user representatives at their sites.

35 A failure is:
a) found in the software; the result of an error.
b) departure from specified behaviour.
c) an incorrect step, process or data definition in a computer program.
d) a human action that produces an incorrect result.

36 In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10%
The next £28000 is taxed at 22%
Any further amount is taxed at 40%
Which of these groups of numbers would fall into the same equivalence class?
a) £4800; £14000; £28000
b) £5200; £5500; £28000
c) £28001; £32000; £35000
d) £5800; £28000; £32000

37 The most important thing about early test design is that it:
a) makes test preparation easier.
b) means inspections are not required.
c) can prevent fault multiplication.
d) will find all faults.

38 Which of the following statements about reviews is true?
a) Reviews cannot be performed on user requirements specifications.
b) Reviews are the least effective way of testing code.
c) Reviews are unlikely to find faults in test plans.
d) Reviews should be performed on specifications, code, and test plans.

39 Test cases are designed during:
a) test recording.
b) test planning.
c) test configuration.
d) test specification.

40 A configuration management system would NOT normally provide:
a) linkage of customer requirements to version numbers.
b) facilities to compare test results with expected results.
c) the precise differences in versions of software component source code.
d) restricted access to the source code library.

Question number Correct answer
1 A
2 A
3 D
4 C
5 A
6 A
7 C
8 B
9 C
10 D
11 A
12 B
13 A
14 C
15 B
16 B
17 D
18 D
19 B
20 A
21 D
22 A
23 B
24 C
25 D
26 C
27 C
28 A
29 C
30 D
31 C
32 B
33 C
34 C
35 B
36 D
37 C
38 D
39 D
40 B

Istqb - Normative References

2007-11-05T02:48:00.000-08:00
ISTQB - Normative references

At the time of publication, the edition indicated was valid. All standards are subject to revision, and parties to agreements based upon this Standard are encouraged to investigate the possibility of applying the most recent edition of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.

- BS 7925-2:1998. Software Component Testing.
- DO-178B:1992. Software Considerations in Airborne Systems and Equipment
Certification, Requirements and Technical Concepts for Aviation (RTCA SC167).
- IEEE 610.12:1990. Standard Glossary of Software Engineering Terminology.
- IEEE 829:1998. Standard for Software Test Documentation.
- IEEE 1008:1993. Standard for Software Unit Testing.
- IEEE 1012:1986. Standard for Verification and Validation Plans
- IEEE 1028:1997. Standard for Software Reviews and Audits.
- IEEE 1044:1993. Standard Classification for Software Anomalies.
- IEEE 1219:1998. Software Maintenance.
- ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 1: Fundamental terms.

- ISO 9000:2000. Quality Management Systems – Fundamentals and Vocabulary.
- ISO/IEC 9126-1:2001. Software Engineering – Software Product Quality – Part 1:
Quality characteristis and sub-characteristics.
- ISO/IEC 12207:1995. Information Technology – Software Life Cycle Processes.
- ISO/IEC 14598-1:1996. Information Technology – Software Product Evaluation - Part 1:
General Overview.

About ISTQB examination

2007-10-29T11:33:00.001-07:00
I saw people asking lots of questions regarding testing examination.

ISTQB is the foundation level exam
CSTE is the advanced exam

Exam contains 40 question and should be completed in 1 hour.
Very tricky questions are asked.

Please click here. You will find old and new syllabus of the examination along with the Standard Glossary. Also you can book your exam.

Check out the dates available in India click here.

Click the link below to take a sample Mock test along with some information click here.

ISTQB syllabus and glossary.

Click here to download the latest copies.

The changes made in the syllabus include numbering the learning objectives, rephrasing certain terms, and removing repetitive terms. The following new terms were introduced: fault attack, incident management, retesting, error guessing, independence, iterative-incremental development model, static testing, and static technique. ISTQB also removed the following terms: software, testing, development (of software), test basis, independent testing, contractual acceptance testing, retirement, modification, migration, kick-off, review meeting, and review process.

Source: Click here

In the glossary, the following terms were added: action word driven testing, bug tracking tool, coverage measurement tools, modelling tool, monkey testing, scripted testing, specification-based technique, stress testing tool, structure-based technique, unit test framework, and white box technique. If you are preparing for the exam, keep an eye on the following changed terms: basic block, control flow graph, defect management tool, independence of testing, project risk, risk-based testing, test comparator, and test process.

Source: Glossary

Software Testing

2007-10-29T10:47:00.000-07:00
Software Testing

Software testing is any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Although crucial to software quality and widely deployed by programmers and testers, software testing still remains an art, due to limited understanding of the principles of software.

The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity. Testing is more than just debugging. The purpose of testing can be quality assurance, verification and validation, or reliability estimation.

Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality.

Software testing is not a "silver bullet'' that can guarantee the production of high quality software systems. While a "correct'' correctness proof demonstrates that a software system (which exactly meets its specification) will always operate in a given manner, software testing that is not fully exhaustive can only suggest the presence of flaws and cannot prove their absence.

Software Engineering

Software :
* Software is Computer programs that when executed provide function and performance
* Data structures that enable the programs to adequately manipulate the information.
* Documents that describe the operation and use of programs.
* Software Engineering: It is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently and effectively on real machines.
* System engineering defines the role of software in an enterprise to boost the growth and better functionalities in a business.
* System Engineering is a way of solving problems taking long-term needs into consideration.
* System engineering defines the real world problem and allocates functions to computer based system elements such as

* Software
* Hardware
* People
* Database
* Documentation

* When system engineering focuses on a business enterprise to define the context for software, it is called Information engineering.
* When system engineering focuses on building a product to cater the needs of some of common business functions across enterprise , it is treated as product engineering.

* There are three phases in software engineering in general

* Definition phase
* Development phase
* Maintenance phase

* Definition phase of software engineering focuses on what to build? or what is a problem ?

* System/Information Engineering
* Requirement Analysis
* Software Project Planning

* Development phase focuses on how to build a product or how to implement functionality

* Software Program Design
* Software Program Implementation
* Software Testing

* Maintenance focuses on change management. The changes are
* Correction
* Adaptation
* Enhancement
* Prevention

* Corrective maintenance is done when the end users report some bugs in the shipped product.

* Adaptation is needed when the external entities of software such as operation system or database etc. have undergone changes.

* Enhancements are done when the existing software needs additional functionalities because of the changed business needs.

* Preventive maintenance is similar to the business process reengineering which concentrates defining the some or all the functionality of the software to avoid further corrections, adaptations and enhancements.

Black-box Testing

Black-box Testing treats the system as a "black-box", so it doesn't use knowledge of the internal structure explicitly. It is usually described as focusing on testing functional requirements. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box.Black Box Testing is testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but has no idea how the program actually arrives at those outputs.

It is because of this that black box testing can be considered testing with respect to the specifications, no other knowledge of the program is necessary. For this reason, the tester and the programmer can be independent of one another, avoiding programmer bias toward his own work.

The so-called ``functionality testing'' is central to most testing exercises. Its primary objective is to assess whether the program does what it is supposed to do, i.e. it should meet user specified requirements. There are different approaches to functionality testing. One is the testing of each program feature or function in sequence. The other is to test module by module, i.e. each function where it is called first.

Advantages:

* More effective on larger units of code than glass box testing
* Tester needs no knowledge of implementation, including specific programming languages
* Tester and programmer are independent of each other
* Tests are done from a user's point of view

* Test cases can be designed as soon as the specifications are complete

Disadvantages

* Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever
* Without clear and concise specifications, test cases are hard to design
* There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried

* May leave many program paths untested

* Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone)

* Most testing related research has been directed toward glass box testing

1) Techniques in BlackBox

Black box testing attempts to derive sets of inputs that will fully exercise all the functional requirements of a system. It is not an alternative to white box testing. This type of testing attempts to find errors in the following categories:

* incorrect or missing functions,
* interface errors,
* errors in data structures or external database access,
* performance errors, and
* initialization and termination errors.

Tests are designed to answer the following questions:

* How is the function's validity tested?
* What classes of input will make good test cases?
* Is the system particularly sensitive to certain input values?
* How are the boundaries of a data class isolated?
* What data rates and data volume can the system tolerate?
* What effect will specific combinations of data have on system operation?

White box testing should be performed early in the testing process, while black box testing tends to be applied during later stages. Test cases should be derived which

* reduce the number of additional test cases that must be designed to achieve reasonable testing, and
* tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

Equivalence Partitioning

This method divides the input domain of a program into classes of data from which test cases can be derived. Equivalence partitioning strives to define a test case that uncovers classes of errors and thereby reduces the number of test cases needed. It is based on an evaluation of equivalence classes for an input condition. An equivalence class represents a set of valid or invalid states for input conditions.

Equivalence classes may be defined according to the following guidelines:

* If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
* If an input condition requires a specific value, then one valid and two invalid equivalence classes are defined.
* If an input condition specifies a member of a set, then one valid and one invalid equivalence class are defined.
* If an input condition is boolean, then one valid and one invalid equivalence class are defined.

Boundary Value Analysis

This method leads to a selection of test cases that exercise boundary values. It complements equivalence partitioning since it selects test cases at the edges of a class. Rather than focusing on input conditions solely, BVA derives test cases from the output domain also. BVA guidelines include:

* For input ranges bounded by a and b, test cases should include values a and b and just above and just below a and b respectively.
* If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits.
* Apply guidelines 1 and 2 to the output.
* If internal data structures have prescribed boundaries, a test case should be designed to exercise the data structure at its boundary.

Cause-Effect Graphing Techniques

Cause-effect graphing is a technique that provides a concise representation of logical conditions and corresponding actions. There are four steps:

* Causes (input conditions) and effects (actions) are listed for a module and an identifier is assigned to each.
* A cause-effect graph is developed.
* The graph is converted to a decision table.
* Decision table rules are converted to test cases.

2) Manual Testing :

BlackBox Manual Testing

SQA team members upon receipt of the Development builds, walk through the GUI and either update existing hard copy of the product Roadmaps, or create new hard copy. This is then passed on to the Tools engineer to automate for new builds and regression testing. Defects are entered into the bugs tracking database, for investigation and resolution.

Features & Functions - SQA test engineers, swearing on the team definition, exercise the product features and functions accordingly. Defects in feature/function capability are entered into the defect tracking system and are communicated to the team. Features are expected to perform as expected and their functionality should be oriented toward ease of use and clarity of objective.

Tests are planned around new features and regression tests are exercised to validate

existing features and functions are enabled and performing in a manner consistent with prior releases. SQA using the exploratory testing method manually tests and then plans more exhaustive testing and automation. Regression tests are exercised which consist of using developed test cases against the product to validate field input, boundary conditions and so on... Automated tests developed for prior releases are also used for regression testing.

Installation - Product is installed on each of the supported operating systems in either default, flat file configuration, or with one of the supported databases. Every operating system and database, supported by the product, are tested, though not in all possible combinations. SQA is committed to executing, during the development life cycle, the combinations most frequently used by the customers. Clean and upgrade installations are the minimum requirements.

Documentation - All documentation, which is reviewed by Development prior to Alpha is reviewed by the SQA

team prior to Beta. SQA not only verifies technical accuracy, clarity and completeness, they also provide editorial input on consistency, style and typographical errors.

1) Functionality Testing

Functional testing is validating an application or web site, conforms to its specifications and correctly performs all its required functions.

This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, database management, security, installation, networking, etc.

The purpose of functionality testing is to reveal issues concerning the product’s functionality and conformance to user requirement.

The first step in functionality testing is to become familiar with the program itself, and with the program’s desired behavior. For this the tester should have clear idea about the documentation such as the program’s functional specification or user manual. Once a program’s expected functionality has been defined, test cases or test procedures can be created that exercise the program in order to test actual behavior against expected behavior. Testing the program’s functionality then involves the execution of any test cases that have been created. Certain portions of a functionality testing effort can also be automated, depends on several factors, and should be discussed with a qualified engineer.

1. Range checking- minimum and maximum values should not be exceeded (invalid values should not be accepted)
2. Check whether numeric fields accept only numeric values
3. Check ‘online Help’ feature (including buttons to open Help feature)
4. Check ‘Print’ feature
5. Check ‘Open file’ feature (must open correct file extensions and incorrect file type should give error messages)
6. Check ‘Graph’ features
7. If there are logins, enter invalid login information for each field
8. Check for error messages for clarity and whether they come up when they are supposed to.
9. In the presence of a database, check all connections through application are valid when accessing data (error messages like “could not connect to database” should not appear.
10. Modify data files (like add extra special characters) to make sure the application gives correct error messages
11. For administrative features make sure only administrators of application may access the features
12. Check by adding duplicate records
13. Delete all records to check whether such an action does not crash the application
14. Check for compatibility using MS Office application (like copy and paste)
15. Click all buttons to make sure all of them are functioning appropriately
16. Click ‘save’ feature (should not be able to overwrite existing file without permission), should save to correct directory, must create correct extension)
17. Check options/settings
18. Check international units are converted correctly
19. Make sure no spellings are incorrect
20. Check for valid date formats
21. Make sure windows are properly minimized, maximized and resized
22. Check whether keyboard shortcuts are working properly
23. Check that right mouse clicks show correct pop up menus
24. If hardware/software keys are present check if the application works as intended with and without execution of keys

2) Compatability Testing

A Testing to ensure compatibility of an application or Web site with different browsers, OS and hardware platforms. Different versions, configurations, display resolutions, and Internet connect speeds all can impact the behavior of the product and introduce costly and embarrassing bugs. We test for compatibility using real test environments. That is testing how will the system performs in the particular software, hardware or network environment. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.

The purpose of compatibility testing is to reveal issues related to the product’s interaction with other software as well as hardware. The product compatibility is evaluated by first identifying the hardware/software/browser components that the product is designed to support. Then a hardware/software/browser matrix is designed that indicates the configurations on which the product will be tested. Then, with input from the client, a testing script is designed that will be sufficient to evaluate compatibility between the product and the hardware/software/browser matrix. Finally, the script is executed against the matrix, and any anomalies are investigated to determine exactly where the incompatibility lies.

Some typical compatibility tests include testing your application:

* On various client hardware configurations
* Using different memory sizes and hard drive space
* On various Operating Systems
* In different network environments
* With different printers and peripherals (i.e. zip drives, USB’s, etc.)

3) Regression Testing

Regression testing is testing the module in which a bug was identified earlier along with the impacted areas to ensure that this fix has not introduced any further defects.

The purpose of regression testing is to ensure that previously detected and fixed issues really are fixed, they do not reappear, and new issues are not introduced into the program as a result of the changes made to fix the issues.

Regression testing also referred to as verification testing, is initiated after a programmer has attempted to fix a recognized problem or has added source code to a program that may have inadvertently introduced errors. It is a quality control measure to ensure that the newly modified code still complies with its specified requirements and that unmodified code has not been affected by the maintenance activity.

Regression Testing is in general a black box testing strategy where test case execution of previously written test cases, that has exposed bugs, is done to check whether previously fixed faults have reemerged. In a test suite, all the tests that has caused bug are written and are re-tested whenever changes are made to the program to fix any bug. But this is a tedious process as after every compilation it is difficult to go through the process of retesting all the test cases repeatedly. To make this process simpler regression testing is automated using some testing tools.

Typically regression testing should be performed on a daily basis. Once an issue in the defect

tracking database has been fixed it is reassigned back for final resolution. Now it can be either reopens the issue, if it has not been satisfactorily addressed, or close the issue if it has, indeed, been fixed.

4) Performance Testing

Performance testing is a rigorous usability evaluation of a working system under realistic conditions to identify usability problems and to compare measures such as success rate, task time and user satisfaction with requirements.

The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing.

To conduct performance testing is to engage in a carefully controlled process of measurement and analysis. Ideally, the software under test is already stable enough so that this process can proceed smoothly.

A clearly defined set of expectations is essential for meaningful performance testing.

For example, for a Web application, you need to know at least two things:

* expected load in terms of concurrent users or HTTP connections

* acceptable response time

Load testing:

Load testing is usually defined as the process of exercising the system under test by feeding it the largest tasks it can operate with. Load testing is sometimes called volume testing, or longevity/endurance testing

Examples of volume testing:

* testing a word processor by editing a very large document
* testing a printer by sending it a very large job
* testing a mail server with thousands of users mailboxes

Examples of longevity/endurance testing:

* testing a client-server application by running the client in a loop against the server over an extended period of time

Goals of load testing:

* expose bugs that do not surface in cursory testing, such as memory management bugs, memory leaks, buffer overflows, etc.

* ensure that the application meets the performance baseline established during performance testing. This is done by running regression tests against the application at a specified maximum load.

Although performance testing and load testing can seen similar, their goals are different. On one hand, performance testing uses load testing techniques and tools for measurement and benchmarking purposes and uses various load levels whereas load testing operates at a predefined load level, the highest load that the system can accept while still functioning properly.

Stress testing:

Stress testing is a form of testing that is used to determine the stability of a given system or entity. This is designed to test the software with abnormal situations. Stress testing attempts to find the limits at which the system will fail through abnormal quantity or frequency of inputs.

Stress testing tries to break the system under test by overwhelming its resources or by taking resources away from it (in which case it is sometimes called negative testing). The main purpose behind this madness is to make sure that the system fails and recovers gracefully -- this quality is known as recoverability.

Stress testing does not break the system but instead it allows observing how the system reacts to failure. Stress testing observes for the following.

* Does it save its state or does it crash suddenly?
* Does it just hang and freeze or does it fail gracefully?
* Is it able to recover from the last good state on restart? Etc.

Web Testing

During testing the websites the following scenarios should be considered.

*
Functionality
*
Performance
*
Usability
*
Server side interface
*
Client side compatibility
*
Security

Functionality:

In testing the functionality of the web sites the following should be tested.

* Links

+ Internal links
+ External links
+ Mail links
+ Broken links

* Forms

+ Field validation
+ Functional chart
+ Error message for wrong input
+ Optional and mandatory fields

* Database

+ Testing will be done on the database integrity.

* Cookies

+ Testing will be done on the client system side, on the temporary internet files.

Performance:

Performance testing can be applied to understand the web site's scalability, or to benchmark the performance in the environment of third party products such as servers and middleware for potential purchase.

* Connection speed:

o Tested over various Networks like Dial up, ISDN etc

* Load

o What is the no. of users per time?
o Check for peak loads & how system behaves.
o Large amount of data accessed by user.

* Stress

o Continuous load
o Performance of memory, cpu, file handling etc.

Usability :

Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.

Usability can be defined as the degree to which a given piece of software assists the person sitting at the keyboard to accomplish a task, as opposed to becoming an additional impediment to such accomplishment. The broad goal of usable systems is often assessed using several criteria:

* Ease of learning
* Navigation
* Subjective user satisfaction
* General appearance

Server side interface:

In web testing the server side interface should be tested. This is done by

Verify that communication is done properly.

Compatibility of server with software, hardware, network and database should be tested.

The client side compatibility is also tested in various platforms, using various browsers etc.

Security:

The primary reason for testing the security of an web is to identify potential vulnerabilities and subsequently repair them.

The following types of testing are described in this section:

* Network Scanning
* Vulnerability Scanning
* Password Cracking
* Log Review
* Integrity Checkers
* Virus Detection

3) Testing Skills

BlackBox Testing Skills

Essential Testing Skills needed for Testers:

Test Planning : Analyzing a project to determine the kinds of testing needed, the kinds of people needed, the scope of testing needed, the kinds of people needed, the scope of testing (including what should and should not be tested), the time available for testing activities, the initiation criteria for testing, the completion criteria and the critical success factors of testing.

Test Tool Usage : Knowing which tools are most appropriate in a given testing situation, how to apply the tools to solve testing problems effectively, how to organize automated testing, and how to integrate test tools into an organization

Test Execution : Performing various kinds of tests, such as unit testing, system testing, UAT, stress testing and regression testing. This can also include how to determine which conditions to test and how to evaluate whether the system under test passes or fails. Test execution can often be dependent on your unique environment and project needs, although basic testing principles can be adopted to test most projects

Defect Management : Understanding the nature of defects, how to report defects, how to track defects and how to use the information gained from defects to improve the development and testing processes

Risk analysis: Understanding the nature of risk, how to assess project and software risks, how to use the results of a risk assessment to prioritize and plan testing, and how to use risk analysis to prevent defects and project failure.

Test Measurement: Knowing what to measure during a test, how to use the measurements to reach meaningful conclusions and how to use measurements to improve the testing and development processes

4) Test Approach

BlackBox Test Approach

Design Validation

Statements regarding coverage of the feature design - including both specification and development documents. Will testing review design? Is design an issue on this release? How much concern does testing have regarding design, etc. etc..

Data Validation
What types of data will require validation? What parts of the feature will use what types of data? What are the data types that test cases will address? Etc.

API Testing
What level of API testing will be performed? What is justification for taking this approach (only if none is being taken)?

Content Testing
Is your area/feature/product content based? What is the nature of the content? What strategies will be employed in your feature/area to address content related issues?

Low-Resource Testing
What resources does your feature use? Which are used most, and are most likely to cause problems? What tools/methods will be used in testing to cover low resource (memory, disk, etc.) issues?

Setup Testing
How is your feature affected by setup? What are the necessary requirements for a successful setup of your feature? What is the testing approach that will be employed to confirm valid setup of the feature?

Modes and Runtime Options
What are the different run time modes the program can be in? Are there views that can be turned off and on? Controls that toggle visibility states? Are there options a user can set which will affect the run of the program? List here the different run time states and options the program has available. It may be worthwhile to indicate here which ones demonstrate a need for more testing focus.

Interoperability
How will this product interact with other products? What level of knowledge does it need to have about other programs -- “good neighbor”, program cognizant, program interaction, fundamental system changes? What methods will be used to verify these capabilities?

Integration Testing
Go through each area in the product and determine how it might interact with other aspects of the project. Start with the ones that are obviously connected, but try every area to some degree. There may be subtle connections you do not think about until you start using the features together. The test cases created with this approach may duplicate the modes and objects approaches, but there are some areas which do not fit in those categories and might be missed if you do not check each area.

Compatibility: Clients
Is your feature a server based component that interacts with clients? Is there a standard protocol that many clients are expected to use? How many and which clients are expected to use your feature? How will you approach testing client compatibility? Is your server suited to handle ill-behaved clients? Are there subtleties in the interpretation of standard protocols that might cause incompatibilities? Are there non-standard, but widely practiced use of your protocols that might cause incompatibilities?

Compatibility: Servers
Is your feature a client based component that interacts with servers? Is there a standard protocol supported by many servers that your client speaks? How many different servers will your client program need to support? How will you approach testing server compatibility? Is your client suited to handle ill-behaved or non-standard servers? Are there subtleties in the interpretation of standard protocols that might cause incompatibilities? Are there non-standard, but widely practiced use of protocols that might cause incompatibilities?

Beta Testing
What is the beta schedule? What is the distribution scale of the beta? What is the entry criteria for beta? How is testing planning on utilizing the beta for feedback on this feature? What problems do you anticipate discovering in the beta? Who is coordinating the beta, and how?

Environment/System - General
Are there issues regarding the environment, system, or platform that should get special attention in the test plan? What are the run time modes and options in the environment that may cause difference in the feature? List the components of critical concern here. Are there platform or system specific compliance issues that must be maintained?

Configuration
Are there configuration issues regarding hardware and software in the environment that may get special attention in the test plan? Some of the classical issues are machine and bios types, printers, modems, video cards and drivers, special or popular TSR’s, memory managers, networks, etc. List those types of configurations that will need special attention.

User Interface
List the items in the feature that explicitly require a user interface. Is the user interface designed such that a user will be able to use the feature satisfactorally? Which part of the user interface is most likely to have bugs? How will the interface testing be approached?

Performance & Capacity Testing
How fast and how much can the feature do? Does it do enough fast enough? What testing methodology will be used to determine this information? What criterion will be used to indicate acceptable performance? If modifications of an existing product, what are the current metrics? What are the expected major bottlenecks and performance problem areas on this feature?

Scalability
Is the ability to scale and expand this feature a major requirement? What parts of the feature are most likely to have scalability problems? What approach will testing use to define the scalability issues in the feature?

Stress Testing
How does the feature do when pushed beyond its performance and capacity limits? How is its recovery? What is its breakpoint? What is the user experience when this occurs? What is the expected behavior when the client reaches stress levels? What testing methodology will be used to determine this information? What area is expected to have the most stress related problems?

Volume Testing
Volume testing differs from performance and stress testing in so much as it focuses on doing volumes of work in realistic environments, durations, and configurations. Run the software as expected user will - with certain other components running, or for so many hours, or with data sets of a certain size, or with certain expected number of repetitions.

International Issues
Confirm localized functionality, that strings are localized and that code pages are mapped properly. Assure program works properly on localized builds, and that international settings in the program and environment do not break functionality. How is localization and internationalization being done on this project? List those parts of the feature that are most likely to be affected by localization. State methodology used to verify International sufficiency and localization.

Robustness
How stable is the code base? Does it break easily? Are there memory leaks? Are there portions of code prone to crash, save failure, or data corruption? How good is the program’s recovery when these problems occur? How is the user affected when the program behaves incorrectly? What is the testing approach to find these problem areas? What is the overall robustness goal and criteria?

Error Testing
How does the program handle error conditions? List the possible error conditions. What testing methodology will be used to evoke and determine proper behavior for error conditions? What feedback mechanism is being given to the user, and is it sufficient? What criteria will be used to define sufficient error recovery?

Usability
What are the major usability issues on the feature? What is testing’s approach to discover more problems? What sorts of usability tests and studies have been performed, or will be performed? What is the usability goal and criteria for this feature?

Accessibility
Is the feature designed in compliance with accessibility guidelines? Could a user with special accessibility requirements still be able to utilize this feature? What is the criteria for acceptance on accessibility issues on this feature? What is the testing approach to discover problems and issues? Are there particular parts of the feature that are more problematic than others?

User Scenarios
What real world user activities are you going to try to mimic? What classes of users (i.e. secretaries, artist, writers, animators, construction worker, airline pilot, shoemaker, etc.) are expected to use this program, and doing which activities? How will you attempt to mimic these key scenarios? Are there special niche markets that your product is aimed at (intentionally or unintentionally) where mimic real user scenarios is critical?

Boundaries and Limits
Are there particular boundaries and limits inherent in the feature or area that deserve special mention here? What is the testing methodology to discover problems handling these boundaries and limits?

Operational Issues
If your program is being deployed in a data center, or as part of a customer's operational facility, then testing must, in the very least, mimic the user scenario of performing basic operational tasks with the software.

Backup
Identify all files representing data and machine state, and indicate how those will be backed up. If it is imperative that service remain running, determine whether or not it is possible to backup the data and still keep services or code running.

Recovery
If the program goes down, or must be shut down, are there steps and procedures that will restore program state and get the program or service operational again? Are there holes in this process that may make a service or state deficient? Are there holes that could provide loss of data. Mimic as many states of loss of services that are likely to happen, and go through the process of successfully restoring service.

Archiving
Archival is different from backup. Backup is when data is saved in order to restore service or program state. Archive is when data is saved for retrieval later. Most archival and backup systems piggy-back on each other's processes.
Is archival of data going to be considered a crucial operational issue on your feature? If so, is it possible to archive the data without taking the service down? Is the data, once archived, readily accessible?

Monitoring
Does the service have adequate monitoring messages to indicate status, performance, or error conditions? When something goes wrong, are messages sufficient for operational staff to know what to do to restore proper functionality? Are the "hearbeat" counters that indicate whether or not the program or service is working? Attempt to mimic the scenario of an operational staff trying to keep a service up and running.

Upgrade
Does the customer likely have a previous version of your software, or some other software? Will they be performing an upgrade? Can the upgrade take place without interrupting service? Will anything be lost (functionality, state, data) in the upgrade? Does it take unreasonably long to upgrade the service?

Migration
Is there data, script, code or other artifacts from previous versions that will need to be migrated to a new version? Testing should create an example of installation with an old version, and migrate that example to the new version, moving all data and scripts into the new format.
List here all data files, formats, or code that would be affected by migration, the solution for migration, and how testing will approach each.

Special Code Profiling and Other Metrics
How much focus will be placed on code coverage? What tools and methods will be used to measure the degree to which testing coverage is sufficiently addressing all of the code?

5) Test Metrics

BlackBox Test Metrics

A Metric is a quantitative measure of the degree to which a system, component or process possesses a given attribute. Software metrics are measures that are used to quantify the software, software development resources and software development process. A metric is defined to be the name of a mathematical function used to measure some attribute of a product or process. The actual numerical value produced by a metric is a measure. For example, cyclomatic complexity is a metric; when applied to program code, the number yielded by the formula is the cyclomatic complexity measure.

Two general classes of metrics include the following:

* Management metrics , which assist in the management of the software development process.
* Quality metrics , which are predictors or indicators of the product qualities.

Metrics related to software error detection ("Testing") in the broad sense, grouped into the following categories:

General metrics that may be captured and analysed throughout the product life cycle

Software Requirements metrics , which may give early warning of quality problems in requirements specifications

Software Design metrics , which may be used to assess the status of software designs;

Code metrics reveal properties of the program source code;

Test metrics can be used to control the testing process, to assess its effectiveness, and to set improvement targets;

Software Installation metrics, which are applicable during the installation process;

Software Operation and Maintenance metrics , including those used in providing software product support.

Test Metrics

The following are the metrics collected in the testing process.

1.Defect age .
Defect age is the time from when a defect is introduced to when it is detected (or fixed). Assign the numbers 1 through 6 to each of the software development activities from software requirements to software operation and maintenance. The defect age is computed as shown.

(Activity Detected - Activity Introduced)

Average Defect Age = –——————————————————

Number of Defects
2. Defect response time .
This measure is the time between when a defect is detected to when it is fixed or closed.

3. Defect cost ($ d )
The cost of a defect may be computed as:

$ d = ( cost to analyse the defect) + (cost to fix it)
+ (cost of failures already incurred due to it)
4. Defect removal efficiency (DRE) .
The DRE is the percentage of defects that have been removed during an activity, computed with the equation below. The DRE can also be computed for each software development activity and plotted on a bar graph to show the relative defect removal efficiencies for each activity. Or, the DRE may be computed for a specific task or technique (e.g., design inspection, code walkthrough, unit test, 6 month operation, etc.). [SQE]

Number Defects Removed
DRE = –—————————————————— * 100
Number Defects At Start Of Process

5 Mean time to failure (MTTF) .
Gives an estimate of the mean time to the next failure, by accurately recording failure times t i , the elapsed time between the ith and the (i-1)st failures, and computing the average of all the failure times. This metric is the basic parameter required by most software reliability models. High values imply good reliability.

MMTF should be corrected by a weighted scheme similar to that used for computing Fault density (see under Test Metrics).

6 . Fault density (FD) .
This measure is computed by dividing the number of faults by the size (usually in

KLOC, thousands of lines of code).

6) Test Plan

BlackBox Test Plan

Test planning is one of the keys to successful software testing. Test plan can be defined as a document that describes the scope, approach, resources and schedule of intended test activities. The main purpose of preparing test plan is that every one concerned with the project are in synchronized with regards to scope, deliverables, deadlines and response for the project.

The complete document will help the people outside the test group understand the “WHY” and “HOW” of the product validation.

Test planning can and should occur at several levels. The first plan to consider is the Master Test Plan. The purpose of the Master Test Plan is to orchestrate testing at all levels (unit, integration, system, acceptance, beta, etc.). The Master Test Plan is to testing what the Project Plan is to the entire development effort.

The goal of test planning is not to create a long list of test cases, but rather to deal with the important issues of testing strategy, resource utilization, responsibilities, risks, and priorities.

Contents of test plan:

Purpose:

This section should contain the purpose of preparing the test plan.

Scope:

This section should talk about the areas of the application which are to be tested by the QA team and specify those areas which are definitely out of the scope.

Test approach :

This would contain details on how the testing is to performed and whether any specific strategy is to be followed.

Entry criteria:

This section explains the various steps to be performed before the start of test (i.e) pre-requisites.

E.g. Environment setup, starting web server/ application server, successful implementation of latest build etc.

Resources:

This list out the people who would be involved in the project and their designation etc

Tasks and responsibilities:

This talk about the tasks to be performed and the responsibilities assigned to the various members in the project.

Exit criteria:

This contains tasks like bringing down the system or server, restoring system to pre-test environment, database, refresh etc.

Schedules/ Milestones :

This section deals with the final delivery date and the various milestone dates to be met in the course of project.

Hardware/ software requirements :

This section contains the details of system/server required to install the application or perform the testing, specific s/w that needs to be installed on the system to get the application running or to connect to the database, connectivity related issues etc.

Risks and mitigation process :

This section should list out all the possible risks that can arise during the testing and mitigation plans that the QA team plans to implement incase the risk actually turns into a reality.

Tools to be used :

This would list out the testing tools or utilities that are to be used in the project.

E.g. Winrunner, QTP, Test Director PCOM etc.

Deliverables :

This section contains various deliverables that are due to the client at various points of time. i.e. daily, weekly, start of project, end of project etc. these could include test plans, test procedures, test matrices, status reports, test scripts etc. templates for all these also be attached.

Annexure :

This section contains the embedded documents or links to document which have been/will be used in the course of testing. E.g. Templates used for reports, test cases etc. reference documents can also be attached here.

Sign off :

This section contains the mutual agreement between the client and QA team with both leads/ managers signing off their agreement on the test plan.

7) Types of Testing

SOFTWARE TESTING TYPES:

Acceptance Testing:

Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.

Accessibility Testing:

Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).

Ad Hoc Testing :

Ad-hoc testing is the interactive testing process where developers invoke application units explicitly,

and individually compare execution results to expected results.

Agile Testing :

Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.

Alpha Testing: Early testing of a software product conducted by selected customers.

Automated Testing :

• Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.

• The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.

Basis Path Testing:

A white box test case design technique that uses the algorithmic flow of the program to design tests.

Beta Testing:

Testing of a re-release of a software product conducted by customers.

Binary Portability Testing:

Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.

Black Box Testing:

Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.

Bottom Up Testing:

An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

Boundary Testing:

Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).

Branch Testing:

Testing in which all branches in the program source code are tested at least once.

Breadth Testing:

A test suite that exercises the full functionality of a product but does not test features in detail.

Compatibility Testing:

Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.

Concurrency Testing:

Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single thread code and locking semaphores.

Conversion Testing:

Testing of programs or procedures used to convert data from existing systems for use in replacement systems.

Data Driven Testing :

Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.

Dependency Testing :

Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.

Depth Testing :

A test that exercises a feature of a product in full detail.

Dynamic Testing :

Testing software through executing it. See also Static Testing.

Endurance Testing :

Checks for memory leaks or other problems that may occur with prolonged execution.

End-to-End testing :

Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Exhaustive Testing :

Testing which covers all combinations of input values and preconditions for an element of the software under test.

Gorilla Testing :

Testing one particular module, functionality heavily.

Gray Box Testing :

A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings.

Integration Testing :

Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.

Installation Testing :

Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

Localization Testing :

This term refers to making software specifically designed for a specific locality.

Loop Testing :

A white box testing technique that exercises program loops.

Monkey Testing :

Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.

Negative Testing :

Testing aimed at showing software does not work. Also known as "test to fail".

N+1 Testing :

A variation of Regression Testing. Testing conducted with multiple cycles in which errors found in test cycle N are resolved and the solution is retested in test cycle N+1. The cycles are typically repeated until the solution reaches a steady state and there are no errors.

Path Testing :

Testing in which all paths in the program source code are tested at least once.

Performance Testing :

Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".

Positive Testing :

Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.

Recovery Testing :

Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

Regression Testing :

Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.

Sanity Testing :

Brief test of major functional elements of a piece of software to determine if its basically operational.

Scalability Testing :

Performance testing focused on ensuring the application under test gracefully handles increases in work load.

Security Testing :

Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.

Smoke Testing :

A quick-and-dirty test that the major functions of a piece of software work.

Soak Testing :

Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.

Static Testing :

Analysis of a program carried out without executing the program.

Storage Testing :

Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.

Stress Testing :

Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

Structural Testing :

Testing based on an analysis of internal workings and structure of a piece of software.

System Testing :

Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.

Thread Testing:

A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.

Top Down Testing:

An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.

Usability Testing:

Testing the ease with which users can learn and use a product.

User Acceptance Testing:

A formal product evaluation performed by a customer as a condition of purchase.

Unit Testing:

The testing done to show whether a unit satisfies its functional specification or its implemented structure matches the intended design structure.

Volume Testing:

Testing which confirms that any values that may become large over time can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.

White Box Testing:

Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing .

Workflow Testing:

Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by the end-user.

8) Auto Tools

BlackBox Auto Tools

Nowadays automated testing tools more often used than ever before to ensure that their applications are working properly prior to deployment. That's particularly important today, because more applications are written for use on the Web—the most public of venues. If a browser-based application crashes or performs improperly, it can cause more problems than a smaller, local application. But for many IT and quality assurance managers, the decision of which testing tools to use can cause confusion.

The first decision is which category of tool to use— one that tests specific units of code before the application is fully combined, one that tests how well the code is working as envisioned, or one that tests how well the application performs under stress. And once that decision is made, the team must wade through a variety of choices in each category to determine which tool best meets its needs.

Functional-Testing Tools
Automated Testing is automating the manual testing process currently in use. The real use and purpose of automated test tools is to automate regression testing . This means that you must have or must develop a database of detailed test cases that are repeatable , and this suite of tests is run every time there is a change to the application to ensure that the change does not produce unintended consequences.

At a functional level, they provide record/playback capabilities, which allow developers to record an existing application and modify scripts to meet changes in an upcoming release. Tools in this category include:

WinRunner provides a relatively simple way to design tests and build reusable scripts without extensive programming knowledge. WinRunner captures, verifies, and replays user interactions automatically, so you can identify defects and ensure that business processes work flawlessly upon deployment and remain reliable. WinRunner supports more than 30 environments, including Web, Java, and Visual Basic. It also provides solutions for leading ERP and Customer Relationship Management (CRM) applications.

Astra Quick Test: This functional-testing tool is built specifically to test Web-based applications. It helps ensure that objects, images, and text on Web pages function properly and can test multiple browsers. Astra QuickText provides record and playback support for every ActiveX control in a Web browser and uses checkpoints to verify specific information during a test run.

Silk Test tool is specifically designed for doing regression and FUNCTIONALITY testing. This tool tests both mainframe and client/server applications. This is the leading functional testing product foe e-business applications. It also provides facilities for rapid test customization and automated infrastructure development.

Rational Suite TestStudio is a full suite of testing tools. Its functional-testing component, called Rational Robot uses automated regression as the first step in the functional testing process. The tool records and replays test scripts that recognize objects through point-and-click processes. The tool also tracks, reports, and charts information about the developer's quality assurance testing process and can view and edit test scripts during the recording process. It also enables the developer to use the same script to test an application in multiple platforms without modifications.

QACenter is a full suite of testing tools. One functional tool considered part of QACenter is QARun, which automates the creation and execution of test scripts, verifies tests, and analyzes test results. A second functional tool under the QACenter is TestPartner, which uses visual scripting and automatic wizards to help test applications based on Microsoft, Java, and Web-based technologies. TestPartner offers fast record and playback of application test scripts, and provides facilities for testers without much programming experience to create and execute tests.

1) Load Runner

LOAD RUNNER

Mercury LoadRunner is the performance testing tool for predicting system behavior and performance. Load runner emulates an envioronment in which thousands of users work with client/server system concurrently. For this load runner replaces the human user with virtual user(Vusers). Using limited hardware resources, LoadRunner emulates hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads.

Vugen:

VuGen is also known as Vuser generator that enables to develop Vuser script for a variety of application types and communication. VuGen creates the script by recording the activity between the client and the server. It monitors the client end of the database and traces all the requests sent to, and received from, the database server.

Vusers:

LoadRunner replaces the human users with virtual users or Vusers. The load on the system can be increased by increasing the number of Vusers.

Load testing process:

Step 1: Planning the test.

A clearly defined test plan ensures the test scenarios developed to accomplish load-testing objectives.

Step 2: Creating Vusers.

Vuser scripts are that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and tasks measured as transactions

Step 3: Define the scenario.

A scenario describes the events that occur during a testing session. It includes a list of machines, scripts, and Vusers that run during the scenario. We create scenarios using LoadRunner Controller. We can create manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers, the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner automatically builds a scenario for us.

Step 4: Running the scenario.

We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or individual Vusers.

Step 5: Monitoring the scenario.

We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.

Step 6: Analyzing test results.

During scenario execution, LoadRunner records the performance of the application under different loads. We use LoadRunner’s graphs and reports to analyze the application’s performance.

A scenario defines the events that occur during each testing session. The action that a Vuser performs during the scenario is described in Vuser Script. The Vuser scripts include functions that measure and record the performance of your application’s components.

A controller reads a single scenario to co-ordinate several host machines which specify the use of different run time setings, running different Vuser script and storing results in different locations.

Vuser types:

The vuser types are divided into the following categories:

E-business: For Web (HTTP,HTML), COM/DCOM, Corba-Java,

General-Java, Java(GUI), Jolt, LDAP, POP3, and FTP protocols.

Middleware: For Jolt, and Tuxedo(6.0, 6.3) protocols.

ERP: For SAP, Baan, Oracle NCA, and Peoplesoft (Tuxedo or Web) protocols.

Client/Server: For Informix, MSSQLServer, ODBC, Oracle (2-tier), Sybase Ctlib, Sybase Dblib, and Windows Sockets protocols.

Legacy: For APPC and Terminal Emulation (RTE).

General: For C template, Java template, and Windows Sockets type scripts.

Creating the Vuser Scripts

Step-1: Record a basic Vuser script

Step-2: Enhance/edit the Vuser script

Step-3: Configure Run-Time settings

Step-4: Run the Vuser script in stand- alone mode

Step-5: Incorporate the Vuser script into a LoadRunner scenario

The process was started by developing a Vuser script by recording a basic script. LoadRunner provides number of tools for recording Vuser scripts. Then enhancement in the basic script is done by adding control-flow structures, and by inserting transactions and rendezvous points into the script. Then configure the run-time settings. The run-time settings include iteration, log, and timing information, and define how the Vuser will behave when it executes the Vuser script. To verify that the script runs correctly, run it in stand-alone mode. When script runs correctly, incorporate it into a LoadRunner scenario.

Vuser Script Sections

Each Vuser script contains at least three sections: vuser_init, one or more Actions, and vuser_end. Before and during recording, you can select the section of the script into which VuGen will insert the recorded functions.

The following table shows what to record into each section, and when each section is executed.

Script Section ...... Used when recording... Is executed when...

vuser_init A login to a server The Vuser is initialized (loaded)

Actions Client activity The Vuser is in “Running” status

vuser_end A logoff procedure The Vuser finishes or is stopped

When you run multiple iterations of a Vuser script, only the Actions sections of the script are repeated—the vuser_init and vuser_end sections are not repeated.

LoadRunner Controller

The controller window has four tabs, correspond to four views.

Script view – Displays a list of all the Vuser scripts that assigned to Vusers.

Host view – Displays the list of machines that can execute Vuser script during the scenario.

Vuser view – Displays the Vuser assigned to the scenario

Online monitor view – Displays online monitor graph showing transactions and server resource information.

Vuser View is the default view and contains the information about the Vuser in the scenario. The tab is divided into 2 sections.

* Summary information.
* Detailed information.

Summary information:

The Status field of each Vuser group displays the current state of each Vuser in the group. The following table describes the possible Vuser states during a scenario.

Status .............. Description

DOWN The Vuser is down.

PENDING The Vuser is ready to be initialized and is
waiting for an available load generator, or is
transferring files to the load generator. The
Vuser will run when the conditions set in its

Scheduling attributes are met.

INITIALIZING The Vuser is being initialized on the remote machine.

READY The Vuser already performed the init section of the
script and is ready to run.

RUNNING The Vuser is running. The Vuser script is being
executed on a load generator.

RENDEZVOUS The Vuser has arrived at the rendezvous and is waiting
to be released by LoadRunner.

DONE . PASSED The Vuser has finished running. The script passed.

DONE . FAILED The Vuser has finished running. The script failed.

ERROR A problem occurred with the Vuser. Check the Status
field on the Vuser dialog box or the output window
for a complete explanation of the error.

GRADUAL EXITING The Vuser is completing the iteration or action it
is running (as defined in Tools > Options > Run-
Time Settings) before exiting.

EXITING The Vuser has finished running or has been
stopped, and is now exiting.

STOPPED The Vuser stopped when the Stop command was
invoked.
Detailed information:
This section provides the following information.

* ID: The Vuser ID
* Status : The current Vuser status
* Script: The script being executed by the Vuser.
* Host : The Vuser host.
* Elapsed : The Time that elapsed from when the Vuser began executing the script.

Transactions:

Transactions are insert into a Web Vuser script to enable the Controller to measure the performance of the Web server under various load conditions. Each transaction measures the time that it takes for the server to respond to one or more tasks submitted by Vusers. LoadRunner allows to create transactions to measure simple tasks, such as accessing a URL, or complex processes, such as submitting several queries and waiting for a response.

To define a transaction, just insert a Start Transaction and End Transaction icon into the Vuser script.

During a scenario execution, the Controller measures the time it takes to perform each transaction. After a scenario run, LoadRunner’s graphs and reports can be used to analyze the server’s performance.

To mark the start of a transaction while recording:

1. Click the Start Transaction button on the VuGen toolbar. The Start Transaction dialog box opens.

2. Type a transaction name in the Transaction Name box.

3. Click OK to accept the transaction name. VuGen inserts an "lr_start_transaction " statement in the Vuser script.

Example.

lr_start_transaction(" transample");

To mark the end of a transaction while recording:

1. Click the End Transaction button on the VuGen toolbar. The End Transaction dialog box opens.

2. Click the arrow in the Transaction Name box to display a list of open transactions. Select the transaction to close.

3. Select the transaction status from the Transaction Status list. You can manually set the status of the transaction, or you can allow LoadRunner to detect it automatically.

* To manually set the status, you perform a manual check within the code of your script, evaluating the return code of a function. For the "succeed" return code, set the status to LR_PASS. For the "fail" return code, set the status to LR_FAIL.

* To instruct LoadRunner to automatically detect the status, specify LR_AUTO. LoadRunner returns the detected status to the Controller.

4. Click OK to accept the transaction name and status. VuGen inserts an

"lr_end_ transaction "statement in the Vuser script.

Rendezvous Points

A rendezvous point creates intense user load on the server and enables LoadRunner to measure server performance under load. Suppose if there is a need to measure how a web-based banking system performs when ten Vusers simultaneously check account information. In order to emulate the required user load on the server, all the Vusers are instruct to check account information at exactly the same time.

Ensure that multiple Vusers act simultaneously by creating a rendezvous point. When a Vuser arrives at a rendezvous point, it is held there by the Controller. The Controller releases the Vusers from the rendezvous either when the required number of Vusers arrives, or when a specified amount of time has passed.

To Insert Rendezvous Point

1. While recording a Vuser script, click the Rendezvous button on the recording toolbar. The Rendezvous Dialog Box opens

2. Type a name for the rendezvous point in the rendezvous name box.

Click OK to accept the rendezvous name. VuGen inserts an lr_rendezvous statement into the Vuser script.

Using Rendezvous Point

Using the Controller, the level of server load can be influenced by selecting- which of the rendezvous points will be active during the scenario how many Vusers will take part in each rendezvous.

Setting the Rendezvous Attributes

The following rendezvous attributes can be set from the Rendezvous Information dialog box :

• Timeout

• Rendezvous Policy

• Enabling and Disabling Rendezvous

• Enabling and Disabling Vusers

In addition, the dialog box displays general information about the rendezvous point: which script is associated with the rendezvous and release history.

Setting Timeout Behavior Attribute

The timeout determines the maximum time (in seconds) that LoadRunner waits for each Vuser to arrive at a rendezvous. After each Vuser arrives at the rendezvous, LoadRunner waits up to timeout seconds for the next Vuser to arrive. If the nest Vuser does not arrive within the timeout period, then the Controller releases all the Vusers from the rendezvous. Each time a new Vuser arrives, the timer is reset to zero. The default timeout is thirty seconds.

Setting the Release Policy Attribute

The policy attribute determines how the Controller releases Vusers from the rendezvous. For each rendezvous the following Policies can be set:

All Arrived Instructs the Controller to release the Vusers from the rendezvous only when all die Vusers included in the rendezvous arrive. All the Vusers are released simultaneously.

The default policy is All Arrived

Quota Sets the number of Vusers that must arrive at a rendezvous point before the Controller releases the Vusers. For instance, suppose that you are testing a scenario of fifty Vusers and that you want a particular operation to be executed simultaneously by ten Vusers. You can designate the entire scenario as participants in the Rendezvous and set a quota of ten Vusers. Every time ten Vusers arrive at the rendezvous, they are released .

Disabling and Enabling Rendezvous Points

It is possible to temporarily disable a rendezvous and exclude it from the scenario. By disabling and enabling a rendezvous, you influence the level of server load. The Disable and Enable buttons on the Rendezvous Information dialog box, are used to change the status of a rendezvous.

Disabling and Enabling Vusers at Rendezvous Points

In addition to disabling a rendezvous for all Vusers in a scenario. LoadRunner lets to disable it for specific Vusers. By disabling Vusers at a rendezvous, they are temporarily excluded from participating in the rendezvous. Enabling disabled Vusers returns them to the rendezvous. Use the Disable and Enable commands to specify which Vusers will take part in a rendezvous.

Monitoring a Scenario

We can monitor scenario execution using the LoadRunner online transaction and server resource monitors.

About online monitoring

Loadrunner provides the following online monitors:

Server resource

Vuser Status

Transaction

Web

The server resource monitor gauges the system resources used during a scenario. It is capable of measuring NT, UNIX, TUXEDO and SNMP resources gathered by custom monitors.

Setting monitor options

Before running scenario, set appropriate monitor options. The options available are

* Sample rate

The sample rate is the period of time (in seconds) between consecutive samples.

* Error handling

Indicate how loadrunner should behave when monitor error occurs...................

* Debug
* Transaction monitor

LoadRunner Analysis:

After running a scenario, the graphs and reports can be used to analyze the performance of the client/server system.

The results can be viewed in several ways.

* Vuser output file
* Controller output window
* Analysis graphs and reports
* Spreadsheet and raw data

9) Download links

WinRunner

Mercury WinRunner is an automated regression testing tool that allows a user to record and play back test scripts. Mercury WinRunner captures, verifies, and replays user interactions automatically. Winrunner facilitates easy test creation by recording our work on the application. As we point and click the GUI object in the application, Winrunner generates a test script in the c like test script language(TSL).

WinRunner provides checkpoints for text, GUI, bitmaps, URL links and the database, allowing testers to compare expected and actual outcomes and identify potential problems with numerous GUI objects and their functionality.

Download winrunner7.6 here

http://www.mercury.com/us/products/quality-center/functional-testing/winrunner

LoadRunner

LoadRunner enables you to test your system under controlled and peak load conditions. To generate load, LoadRunner runs thousands of Virtual Users that are distributed over a network. Using a minimum of hardware resources, these Virtual Users provide consistent, repeatable, and measurable load to exercise your application just as real users would.

LoadRunner’s in-depth reports and graphs provide the information that you need to evaluate the performance of your application.

The advantage of LoadRunner is it reduces the personnel requirements by replacing human users with virtual users or Vusers. These Vusers emulate the behavior of real users— operating real applications.

LoadRunner automatically records the performance of the application during a test. Because LoadRunner tests are fully automated, we can easily repeat them as often as you need.

http://downloads.mercury.com/cgi-bin/portal/download/index.jsp

Download web performance testing tool

http://www.adventnet.com/products/qengine/web-performance-testing.html

Download web application testing tool

http://www.adventnet.com/products/qengine/web-application-testing.html

Quick Test Professional

Mercury QuickTest Professional provides solution for functional test and regression test automation - addressing every major software application and environment.

QuickTest Professional provides an interactive, visual environment for test development. We can create a test script by simply pressing a Record button and using an application to perform a typical business process.

QuickTest Professional is significantly easier for a non-technical person to adapt to and create working test cases

Download QTP

http://downloads.mercury.com/cgi-bin/portal/download/index.jsp

WhiteBox Testing

WhiteBox Testing

A Software testing approach that examine the program structure and derive test data from the program logic. White-box testing strategies include designing tests such that every line of source code is executed at least once, or requiring every function to be individually tested.

Test coverage is an important component of white-box testing. The goal is to try to execute (that is, test) all lines in an application at least once.

Because white-box testing tools can individually or collectively instrument source lines, it is straightforward to determine which lines in a host program have or have not been executed without modifying source.

Synonyms for white box testing:

* Glass Box testing
* Structural testing
* Clear Box testing
* Open Box Testing

The purpose of white box testing :

Build quality throughout the life cycle of a software product or service.

Provide a complementary function to black box testing.

Perform complete coverage at the component level.

Improve quality by optimizing performance.

Code Coverage Analysis:

Basis Path Testing

A testing mechanism that derive a logical complexity measure of a procedural design and use this as a guide for defining a basic set of execution paths. These are test cases that exercise basic set will execute every statement at least once.

Flow Graph Notation : A notation for representing control flow similar to flow charts

and UML activity diagrams.

Cyclomatic Complexity: The Cyclomatic complexity gives a quantitative measure of

4the logical complexity. This value gives the number of independent paths in the

basis set, and an upper bound for the number of tests to ensure that each statement

is executed at least once. An independent path is any path through a program that

introduces at least one new set of processing statements or a new condition.

Cyclomatic complexity provides upper bound for number of tests required

to guarantee coverage of all program statements

Control Structure testing:

Conditions Testing

Condition testing aims to exercise all logical conditions in a program module. They

may define:

Relational expression: (E1 op E2), where E1 and E2 are arithmetic expressions.

Simple condition: Boolean variable or relational expression, possibly proceeded by a

NOT operator.

Compound condition: composed of two or more simple conditions, Boolean operators

and parentheses.

Boolean expression: Condition without Relational expressions.

Data Flow Testing

Selects test paths according to the location of definitions and use of variables

Loop Testing

Loops fundamental to many algorithms. Can define loops as simple, concatenated,

nested, and unstructured.

Advantages of White Box Testing

* Forces test developer to reason carefully about implementation
* Approximate the partitioning done by execution equivalence
* Reveals errors in "hidden" code
* Beneficent side-effects

Disadvantages of White Box Testing

* Expensive
* Cases omitted in the code could be missed out.

Learning objectives / Levels of knowledge for ISEB Foundation Exam

2007-10-26T05:54:00.000-07:00
Learning objectives / levels of knowledge

The following learning objectives are defined as applying to this syllabus. Each topic in the syllabus will be examined according to the learning objective for it.

Level 1: Remember (K1)
The candidate will recognise, remember and recall a term or concept.

Example
Can recognise the definition of "failure" as:
* "non-delivery of service to an end user or any other stakeholder" or
* "actual deviation of the component or system from its expected delivery,
service or result".

Level 2: Understand (K2)
The candidate can select the reasons or explanations for statements related to the topic, and can summarise, compare, classify and give examples for the testing concept.

Examples
Can explain the reason why tests should be designed as early as possible:
* To find defects when they are cheaper to remove.
* To find the most important defects first.

Can explain the similarities and differences between integration and system testing:
* Similarities:
Testing more than one component, and can test non-functional aspects.
* Differences:
Integration testing concentrates on interfaces and interactions, and system testing concentrates on whole-system aspects, such as end to end processing.

Level 3: Apply (K3)
The candidate can select the correct application of a concept or technique and apply it to a given context.

Examples
* Can identify boundary values for valid and invalid partitions.
* Can select test cases from a given state transition diagram in order to cover all transactions.

Level 4: Analyse (K4)
The candidate can separate information related to a concept or technique into its constituent parts for better understanding, and can distinguish between facts and inferences.

Examples
* Can understand the various options available for risk identification.
* Can describe which portions of an incident report are factual and which are inferref from results.

Level 5: Synthesise (K5)
The candidate can identify and build patterns in facts and information related to a concept or technique, and can create new meaning or structure from parts of a concept.

Examples
* Can design a quality risk analysis rocess that includes both rigorous and informal elements.
* Can create a blended test strategy that uses a dynamic strategy to balance an analytical strategy.
* Can combine aspects of different review processes to form an effective process for their organisation.

Level 6: Evaluate (K6)
The candidate can judge the value of information and decide on its applicability in a given situation.

Examples
* Can determine the relative effectiveness and efficiency of different review processes or different testing techniques.
* Can determine the type of information that should be gathered for an incident report.

Automation Testing versus Manual Testing

2007-09-26T04:41:00.000-07:00
Automation Testing versus Manual Testing Guidelines

Collected this info from a blog I read !!
I met with my team’s automation experts a few weeks back to get their input on when to automate and when to manually test. The general rule of thumb has always been to use common sense. If you’re only going to run the test one or two times or the test is really expensive to automation, it is most likely a manual test. But then again, what good is saying “use common sense” when you need to come up with deterministic set of guidelines on how and when to automate?

Pros of Automation

* If you have to run a set of tests repeatedly, automation is a huge win for you
* It gives you the ability to run automation against code that frequently changes to catch regressions in a timely manner
* It gives you the ability to run automation in mainstream scenarios to catch regressions in a timely manner (see What is a Nighlty)
* Aids in testing a large test matrix (different languages on different OS platforms). Automated tests can be run at the same time on different machines, whereas the manual tests would have to be run sequentially.

Cons of Automation

* It costs more to automate. Writing the test cases and writing or configuring the automate framework you’re using costs more initially than running the test manually.
* Can’t automate visual references, for example, if you can’t tell the font color via code or the automation tool, it is a manual test.

Pros of Manual

* If the test case only runs twice a coding milestone, it most likely should be a manual test. Less cost than automating it.
* It allows the tester to perform more ad-hoc (random testing). In my experiences, more bugs are found via ad-hoc than via automation. And, the more time a tester spends playing with the feature, the greater the odds of finding real user bugs.

Cons of Manual

* Running tests manually can be very time consuming
* Each time there is a new build, the tester must rerun all required tests - which after a while would become very mundane and tiresome.

Other deciding factors

* What you automate depends on the tools you use. If the tools have any limitations, those tests are manual.
* Is the return on investment worth automating? Is what you get out of automation worth the cost of setting up and supporting the test cases, the automation framework, and the system that runs the test cases?

Criteria for automating

There are two sets of questions to determine whether automation is right for your test case:

Is this test scenario automatable?

1. Yes, and it will cost a little
2. Yes, but it will cost a lot
3. No, it is no possible to automate

How important is this test scenario?

1. I must absolutely test this scenario whenever possible
2. I need to test this scenario regularly
3. I only need to test this scenario once in a while

If you answered #1 to both questions – definitely automate that test

If you answered #1 or #2 to both questions – you should automate that test

If you answered #2 to both questions – you need to consider if it is really worth the investment to automate

What happens if you can’t automate?

Let’s say that you have a test that you absolutely need to run whenever possible, but it isn’t possible to automate. Your options are

* Reevaluate – do I really need to run this test this often?
* What’s the cost of doing this test manually?
* Look for new testing tools
* Consider test hooks

Software Testing Types.

2007-09-26T04:37:00.000-07:00
Software Testing Glossary

Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.

Accessibility Testing: Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).

Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.

Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.

Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.

Application Programming Interface (API): A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.

Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve software quality.

Automated Testing:

* Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.
* The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.

B

Backus-Naur Form: A metalanguage used to formally describe the syntax of a language.

Basic Block: A sequence of one or more consecutive, executable statements containing no branches.

Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to design tests.

Basis Set: The set of tests derived using basis path testing.

Baseline: The point at which some deliverable produced during the software engineering process is put under formal change control.

Benchmark Testing: Tests that use representative sets of programs and data designed to evaluate the performance of computer hardware and software in a given configuration.

Beta Testing: Testing of a rerelease of a software product conducted by customers.

Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.

Black Box Testing: Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.

Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

Boundary Testing: Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).

Boundary Value Analysis: In boundary value analysis, test cases are generated using the extremes of the input domaini, e.g. maximum, minimum, just inside/outside boundaries, typical values, and error values. BVA is similar to Equivalence Partitioning but focuses on "corner cases".

Branch Testing: Testing in which all branches in the program source code are tested at least once.

Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail.

Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner.

C

CAST: Computer Aided Software Testing.

Capture/Replay Tool: A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.

CMM: The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.

Cause Effect Graph: A graphical representation of inputs and the associated outputs effects which can be used to design test cases.

Code Complete: Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.

Code Coverage: An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.

Code Inspection: A formal testing technique where the programmer reviews source code with a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.

Code Walkthrough: A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.

Coding: The generation of source code.

Compatibility Testing: Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.

Component: A minimal software item for which a separate specification is available.

Component Testing: See Unit Testing.

Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.

Conformance Testing: The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.

Context Driven Testing: The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.
>>> As said by Cem Kaner Context Driven Testing is

Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in replacement systems.

Cyclomatic Complexity: A measure of the logical complexity of an algorithm, used in white-box testing.

D

Data Dictionary: A database that contains definitions of all data items defined during analysis.

Data Flow Diagram: A modeling notation that represents a functional decomposition of a system.

Data Driven Testing: Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.

Debugging: The process of finding and removing the causes of software failures.

Defect: Nonconformance to requirements or functional / program specification

Dependency Testing: Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.

Depth Testing: A test that exercises a feature of a product in full detail.

Dynamic Testing: Testing software through executing it. See also Static Testing.

E
Emulator: A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.

Endurance Testing: Checks for memory leaks or other problems that may occur with prolonged execution.

End-to-End testing: Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Equivalence Class: A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.

Equivalence Partitioning: A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.

Exhaustive Testing: Testing which covers all combinations of input values and preconditions for an element of the software under test.

F

Functional Decomposition: A technique used during planning, analysis and design; creates a functional hierarchy for the software.

Functional Specification: A document that describes in detail the characteristics of the product with regard to its intended features.

Functional Testing: See also Black Box Testing.

* Testing the features and operational behavior of a product to ensure they correspond to its specifications.
* Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.

G

Glass Box Testing: A synonym for White Box Testing.

Gorilla Testing: Testing one particular module,functionality heavily.

Gray Box Testing: A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings.

H

High Order Tests: Black-box tests conducted once the software has been integrated.

I
Independent Test Group (ITG): A group of people whose primary responsibility is software testing,

Inspection: A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).

Integration Testing: Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.

Installation Testing: Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

J

K

L

Load Testing: See Performance Testing.

Localization Testing: This term refers to making software specifically designed for a specific locality.

Loop Testing: A white box testing technique that exercises program loops.

M

Metric: A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.

Monkey Testing: Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.

Mutation Testing: Testing done on the application where bugs are purposely added to it.

N

Negative Testing: Testing aimed at showing software does not work. Also known as "test to fail". See also Positive Testing.

N+1 Testing: A variation of Regression Testing. Testing conducted with multiple cycles in which errors found in test cycle N are resolved and the solution is retested in test cycle N+1. The cycles are typically repeated until the solution reaches a steady state and there are no errors. See also Regression Testing.

O

P

Path Testing: Testing in which all paths in the program source code are tested at least once.

Performance Testing: Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".

Positive Testing: Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.

Q

Quality Assurance: All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer.

Quality Audit: A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.

Quality Circle: A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.

Quality Control: The operational techniques and the activities used to fulfill and verify requirements of quality.

Quality Management: That aspect of the overall management function that determines and implements the quality policy.

Quality Policy: The overall intentions and direction of an organization as regards quality as formally expressed by top management.

Quality System: The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.

R

Race Condition: A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.

Ramp Testing: Continuously raising an input signal until the system breaks down.

Recovery Testing: Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.

Regression Testing: Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.

Release Candidate: A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).

S (return to top of page)

Sanity Testing: Brief test of major functional elements of a piece of software to determine if its basically operational. See also Smoke Testing.

Scalability Testing: Performance testing focused on ensuring the application under test gracefully handles increases in work load.

Security Testing: Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.

Smoke Testing: A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

Soak Testing: Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.

Software Requirements Specification: A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software/

Software Testing: A set of activities conducted with the intent of finding errors in software.

Static Analysis: Analysis of a program carried out without executing the program.

Static Analyzer: A tool that carries out static analysis.

Static Testing: Analysis of a program carried out without executing the program.

Storage Testing: Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.

Stress Testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

Structural Testing: Testing based on an analysis of internal workings and structure of a piece of software. See also White Box Testing.

System Testing: Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.

T

Testability: The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.

Testing:

* The process of exercising software to verify that it satisfies specified requirements and to detect errors.
* The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829).
* The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.

Test Automation: See Automated Testing.

Test Bed: An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.

Test Case:

* Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc.
* A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

Test Driven Development: Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.

Test Driver: A program or test tool used to execute a tests. Also known as a Test Harness.

Test Environment: The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.

Test First Design: Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires that programmers do not write any production code until they have first written a unit test.

Test Harness: A program or test tool used to execute a tests. Also known as a Test Driver.

Test Plan: A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. Ref IEEE Std 829.

Test Procedure: A document providing detailed instructions for the execution of one or more test cases.

Test Scenario: Definition of a set of test cases or test scripts and the sequence in which they are to be executed.

Test Script: Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool.

Test Specification: A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.

Test Suite: A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by what they are intended to test.

Test Tools: Computer programs used in the testing of a system, a component of the system, or its documentation.

Thread Testing: A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.

Top Down Testing: An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.

Total Quality Management: A company commitment to develop a process that achieves high quality product and customer satisfaction.

Traceability Matrix: A document showing the relationship between Test Requirements and Test Cases.

U

Usability Testing: Testing the ease with which users can learn and use a product.

Use Case: The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.

User Acceptance Testing: A formal product evaluation performed by a customer as a condition of purchase.

Unit Testing: Testing of individual software components.

V

Validation: The process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation is testing, inspection and reviewing.

Verification: The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.

Volume Testing: Testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.

W
Walkthrough: A review of requirements, designs or code characterized by the author of the material under review guiding the progression of the review.

White Box Testing: Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing. Contrast with Black Box Testing.

Workflow Testing: Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by the end-user.

X

Y

Z

Software Testing Types

COMPATIBILITY TESTING. Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.

CONFORMANCE TESTING. Verifying implementation conformance to industry standards. Producing tests for the behavior of an implementation to be sure it provides the portability, interoperability, and/or compatibility a standard defines.

FUNCTIONAL TESTING. Validating an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, APIs, database management, security, installation, networking, etcF testing can be performed on an automated or manual basis using black box or white box methodologies.

LOAD TESTING. Load testing is a generic term covering Performance Testing and Stress Testing.

PERFORMANCE TESTING. Performance testing can be applied to understand your application or WWW site's scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase. This sort of testing is particularly useful to identify performance bottlenecks in high use applications. Performance testing generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions.

REGRESSION TESTING. Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process. Though regression testing can be performed manually an automated test suite is often used to reduce the time and resources needed to perform the required testing.

SMOKE TESTING. A quick-and-dirty test that the major functions of a piece of software work without bothering with finer details. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

STRESS TESTING. Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. A graceful degradation under load leading to non-catastrophic failure is the desired result. Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load.

UNIT TESTING. Functional and reliability testing in an Engineering environment. Producing tests for the behavior of components of a product to ensure their correct behavior prior to system integration.

Test Director

2007-09-26T04:36:00.000-07:00
Test Director: -

TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.

What is the use of Test Director software?
>>Test Director is an efficient Management tool
for having more than 2-3 years of experience in testing.
Mostly Test Lead/Quality Lead can use this Tool for managing,organizing,planning the software projects.
We can easily understand this tool

>>Using TestDirector, we can define application requirements and testing objectives, design test plans and develop test cases, create automated scripts and store them in the repository, run manual and automated tests, report execution results, enter defects, review and fix defects by logging into the database. Using application status reports we can decide whether an application is ready to be released.

>>but we do not create scripts in test director?//it is only done in winrunner ....right?

>>Test Director is a test management tool with which we can manage our entire testing process. It is a central repository where we can store our requirements, test plans, test cases and tests scripts and execute the test cases and test scripts. We can share the work with other QA testers using Test Director since it is a web based test management tool.

>>Throught TD we can genrate automated scripts either using win runner or QTP.

>>TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release. It is ued to manage test Assets. It is very useful Techinical Analysts.

>>We can store the script which is genearted by winrunner.whenever you want to run that script ,then you can use the script from test Director.

>>we can create test scripts in tet director

>>Test director software is a test management tool which helps us or a new person to know the status of the functions which are present in an application. Status of the application is nothing but: the function is pass or fail, status of defect, analyze the reports, write test case, create a subject, gather the requirements etc

>>Test Director is a test management tool where we manage the entire testing process. We can define requirements, design test plans, Test cases, Test script and execute them. We can integrate the tool with automation tools. It can be used as a defect tracking tool.

>>WinRunner Generates Automation Scripts in TSL but 'Test Scripts' is written manually and can be stored in TDs repository

>>Test direct is a test management tool.Â Usually test director design test plans, test cases, bug report.Â It is uses (BRD) bord land requirement document Getting the expected and actual results.

>>Test Director is a Mercury Interactive’s software test case management & defect tracking tool.It helps in planning & organinzing the testing process.With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.

>>Test Directot has been changed to QC by Mercury, it really is a test management tool help quality assurance personeel to plan and organize the entire software testing process. It has four modules which are requirment, test plan, run test and defect respectively.

Test Management - Intresting Questions

2007-09-26T04:35:00.001-07:00
Test Management-Interesting questionsfor new comer

1.Why test - what is Testing?
Testing is a process used to help identify the correctness, completeness and quality of developed computer software.

2. System Testing myths and legends - What are they?
Myth1: There is no need to test
Myth2: If testing must be done; two weeks at the end of the project is sufficient for testing
Myth3: Re-testing is not necessary
Myth4: Any fool can test
Myth5: The last thing you want is users involved in test
Myth6: The V-model is too complicated

3.What are the Concepts for Application Test Management?
Testing should be pro-active following the V-model
Test execution can be a manual process
Test execution can be an automated process
It is possible to plan the start date for testing
It is not possible to accurately plan the end date of testing
Ending testing is through risk assessment
A fool with a tool is still a fool
Testing is not a diagnosis process
Testing is a triage process
Testing is expensive
Not testing, can be more expensive

4. What Test Principles do you Recommend?
• Test involvement early in the lifecycle - Test Architect Signs off Requirements - Test Architect Signs off Use Cases • Fail Fast - Identify failures early via core test scripts • All Test Phases have equal value - Each Test Phase has its own value add • RACI chart everything • Testing is a pro-active activity - Plan the Test - Test the Plan • Finding defects is good - Ignorance of faults in a non-conformant system is no excuse

5.Test Analysts - What is their Value Add?
Understand the system under test
Document Assumptions
Create and execute repeatable tests
Value add through negative testing
Contribute to Impact Analysis when assessing Changes
Contribute to the risk assessment when considering to end testing

6. What do Test Analysts Need?
Education
Test Environment
Test Tools
Access Requirements Traceability -

7. What is this about?
Tracing requirements to test cases
Tracing test cases to requirements
Should be a feature of the Test Asset Management tool
Automatic on-demand process
Pie chart reporting

8. What is involved in the Application Test Lifecycle?
Unit testing
Module testing
Component testing
Component integration testing
Subsystem testing
System testing
Functional testing
Technical integration testing
System integration testing
Non-functional testing
Integration testing
Regression testing
Model Office testing
User Acceptance testing

9. How to manage Risk Mitigation?
Identify risks before the adversity affects the project
Analyse risk data for interpretation by the project team
Plan actions for probability, magnitude & consequences
Track risks and actions, maintaining a risk register
Control risk action plan, correct plan deviations

10. What should the Test Team do?
Programme Management
Strong Change Management
Strict Configuration Control
Pro Active Scope Creep Management
Inclusion in the decision making process

11. What are the Test Team Deliverables
Test Plans
Test Script Planner
Test Scripts
Test Execution Results
Defect Reports

General Interview Questions!!

2007-09-16T06:23:00.000-07:00
1. Tell me about yourself
The most often asked question in interviews. You need to have a short statement prepared in your mind. Be careful that it does not sound rehearsed. Limit it to work-related items unless instructed otherwise. Talk about things you have done and jobs you have held that relate to the position you are interviewing for. Start with the item farthest back and work up to the present.

2. Why did you leave your last job?
Stay positive regardless of the circumstances. Never refer to a major problem with management and never speak ill of supervisors, co-workers or the organization. If you do, you will be the one looking bad. Keep smiling and talk about leaving for a positive reason such as an opportunity, a chance to do something special or other forward-looking reasons.

3. What experience do you have in this field?
Speak about specifics that relate to the position you are applying for. If you do not have specific experience, get as close as you can.

4. Do you consider yourself successful?
You should always answer yes and briefly explain why. A good explanation is that you have set goals, and you have met some and are on track to achieve the others.

5. What do co-workers say about you?
Be prepared with a quote or two from co-workers. Either a specific statement or a paraphrase will work.

6. What do you know about this organization?
This question is one reason to do some research on the organization before the interview. Find out where they have been and where they are going. What are the current issues and who are the major players?

7. What have you done to improve your knowledge in the last year?
Try to include improvement activities that relate to the job. A wide variety of activities can be mentioned as positive self-improvement. Have some good ones handy to mention.

8. Are you applying for other jobs?
Be honest but do not spend a lot of time in this area. Keep the focus on this job and what you can do for this organization. Anything else is a distraction.

9. Why do you want to work for this organization?
This may take some thought and certainly, should be based on the research you have done on the organization. Sincerity is extremely important here and will easily be sensed. Relate it to your long-term career goals.

10. Do you know anyone who works for us?
Be aware of the policy on relatives working for the organization. This can affect your answer even though they asked about friends not relatives. Be careful to mention a friend only if they are well thought of.

11. What kind of salary do you need?
A loaded question. A nasty little game that you will probably lose if you answer first. So, do not answer it. Instead, say something like, That's a tough question. Can you tell me the range for this position? In most cases, the interviewer, taken off guard, will tell you. If not, say that it can depend on the details of the job. Then give a wide range.

12. Are you a team player?
You are, of course, a team player. Be sure to have examples ready. Specifics that show you often perform for the good of the team rather than for yourself are good evidence of your team attitude. Do not brag, just say it in a matter-of-fact tone. This is a key point.

13. How long would you expect to work for us if hired?
Specifics here are not good. Something like this should work: I'd like it to be a long time. Or As long as we both feel I'm doing a good job.

14. Have you ever had to fire anyone? How did you feel about that?
This is serious. Do not make light of it or in any way seem like you like to fire people. At the same time, you will do it when it is the right thing to do. When it comes to the organization versus the individual who has created a harmful situation, you will protect the organization. Remember firing is not the same as layoff or reduction in force.

15. What is your philosophy towards work?
The interviewer is not looking for a long or flowery dissertation here. Do you have strong feelings that the job gets done? Yes. That's the type of answer that works best here. Short and positive, showing a benefit to the organization.

16. If you had enough money to retire right now, would you?
Answer yes if you would. But since you need to work, this is the type of work you prefer. Do not say yes if you do not mean it.

17. Have you ever been asked to leave a position?
If you have not, say no. If you have, be honest, brief and avoid saying negative things about the people or organization involved.

18. Explain how you would be an asset to this organization
You should be anxious for this question. It gives you a chance to highlight your best points as they relate to the position being discussed. Give a little advance thought to this relationship.

19. Why should we hire you?
Point out how your assets meet what the organization needs. Do not mention any other candidates to make a comparison.

20. Tell me about a suggestion you have made
Have a good one ready. Be sure and use a suggestion that was accepted and was then considered successful. One related to the type of work applied for is a real plus.

21. What irritates you about co-workers?
This is a trap question. Think real hard but fail to come up with anything that irritates you. A short statement that you seem to get along with folks is great.

22. What is your greatest strength?
Numerous answers are good, just stay positive. A few good examples: Your ability to prioritize, Your problem-solving skills, Your ability to work under pressure, Your ability to focus on projects, Your professional expertise, Your leadership skills, Your positive attitude .

23. Tell me about your dream job.
Stay away from a specific job. You cannot win. If you say the job you are contending for is it, you strain credibility. If you say another job is it, you plant the suspicion that you will be dissatisfied with this position if hired. The best is to stay genetic and say something like: A job where I love the work, like the people, can contribute and can't wait to get to work.

24. Why do you think you would do well at this job?
Give several reasons and include skills, experience and interest.

25. What are you looking for in a job?
See answer # 23

26. What kind of person would you refuse to work with?
Do not be trivial. It would take disloyalty to the organization, violence or lawbreaking to get you to object. Minor objections will label you as a whiner.

27. What is more important to you: the money or the work?
Money is always important, but the work is the most important. There is no better answer.

28. What would your previous supervisor say your strongest point is?
There are numerous good possibilities: Loyalty, Energy, Positive attitude, Leadership, Team player, Expertise, Initiative, Patience, Hard work, Creativity, Problem solver

29. Tell me about a problem you had with a supervisor
Biggest trap of all. This is a test to see if you will speak ill of your boss. If you fall for it and tell about a problem with a former boss, you may well below the interview right there. Stay positive and develop a poor memory about any trouble with a supervisor.

30. What has disappointed you about a job?
Don't get trivial or negative. Safe areas are few but can include: Not enough of a challenge. You were laid off in a reduction Company did not win a contract, which would have given you more responsibility.

31. Tell me about your ability to work under pressure.
You may say that you thrive under certain types of pressure. Give an example that relates to the type of position applied for.

32. Do your skills match this job or another job more closely?
Probably this one. Do not give fuel to the suspicion that you may want another job more than this one.

33. What motivates you to do your best on the job?
This is a personal trait that only you can say, but good examples are: Challenge, Achievement, Recognition

34. Are you willing to work overtime? Nights? Weekends?
This is up to you. Be totally honest.

35. How would you know you were successful on this job?
Several ways are good measures: You set high standards for yourself and meet them. Your outcomes are a success.Your boss tell you that you are successful

36. Would you be willing to relocate if required?
You should be clear on this with your family prior to the interview if you think there is a chance it may come up. Do not say yes just to get the job if the real answer is no. This can create a lot of problems later on in your career. Be honest at this point and save yourself future grief.

37. Are you willing to put the interests of the organization ahead of your own?
This is a straight loyalty and dedication question. Do not worry about the deep ethical and philosophical implications. Just say yes.

38. Describe your management style.
Try to avoid labels. Some of the more common labels, like progressive, salesman or consensus, can have several meanings or descriptions depending on which management expert you listen to. The situational style is safe, because it says you will manage according to the situation, instead of one size fits all.

39. What have you learned from mistakes on the job?
Here you have to come up with something or you strain credibility. Make it small, well intentioned mistake with a positive lesson learned. An example would be working too far ahead of colleagues on a project and thus throwing coordination off.

40. Do you have any blind spots?
Trick question. If you know about blind spots, they are no longer blind spots. Do not reveal any personal areas of concern here. Let them do their own discovery on your bad points. Do not hand it to them.

41. If you were hiring a person for this job, what would you look for?
Be careful to mention traits that are needed and that you have.

42. Do you think you are overqualified for this position?
Regardless of your qualifications, state that you are very well qualified for the position.

43. How do you propose to compensate for your lack of experience?
First, if you have experience that the interviewer does not know about, bring that up: Then, point out (if true) that you are a hard working quick learner.

44. What qualities do you look for in a boss?
Be generic and positive. Safe qualities are knowledgeable, a sense of humor, fair, loyal to subordinates and holder of high standards. All bosses think they have these traits.

45. Tell me about a time when you helped resolve a dispute between others.
Pick a specific incident. Concentrate on your problem solving technique and not the dispute you settled.

46. What position do you prefer on a team working on a project?
Be honest. If you are comfortable in different roles, point that out.

47. Describe your work ethic.
Emphasize benefits to the organization. Things like, determination to get the job done and work hard but enjoy your work are good.

48. What has been your biggest professional disappointment?
Be sure that you refer to something that was beyond your control. Show acceptance and no negative feelings.

49. Tell me about the most fun you have had on the job.
Talk about having fun by accomplishing something for the organization.

50. Do you have any questions for me?
Always have some questions prepared. Questions prepared where you will be an asset to the organization are good. How soon will I be able to be productive? and What type of projects will I be able to assist on? are examples.