Manual Testing important Topics -Part I

Software Testing

Software testing is a process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine, that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects to produe quality Product.

Or)

Testing is the process of executing a program with the intent of finding errors.

(Or)

Verifying and validating the application with respect to customer requirements.

(Or)

Testing should also ensure that a quality product is delivered to the customer.

Verification and Validation

Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings. You CAN learn to do verification, with little or no outside help.

Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verification are completed.

Difference between Verification and Validation:
Verification takes place before validation, and not vice versa. Verification evaluates documents, plans, code, requirements, and specifications. Validation, on the other hand, evaluates the product itself. The inputs of verification are checklists, issues lists, walkthroughs and inspection meetings, reviews and meetings. The input of validation, on the other hand, is the actual testing of an actual product. The output of verification is a nearly perfect set of documents, plans, specifications, and requirements document. The output of validation, on the other hand, is a nearly perfect, actual product.

Verification- Are we building the product right?

Validation- Are we building the right product?

TEST DESIGN TECHNQUES

I) SPECIFICATION-BASED/BLACK-BOX TECHNIQUES

           1. Equivalence partitioning

2. Boundary value analysis
3. Decision table testing
4. State transition testing
5. Use case testing

  Equivalence Partitioning
o    Inputs to the software or system are divided in to groups that are expected to have similar behavior
o    Equivalence partitions or classes can be found for both valid data and invalid data
o    Partitions can also be identified for outputs, internal values, time related values and for interface values.
o    Equivalence partitioning is applicable all levels of testing

EP is the process of methodically reducing the huge Infinite) set of possible test cases into a much smaller, but still equally effective similar behavior set.

If one test case in the particular equivalence class reveals a bug, then the other test case based on that class probably will too reveal the same bug.(Just reverse also).

Boundary Value Analysis

o Software can operate or test on the edge or boundary for its capabilities.
o    Behavior at the edge of each equivalence partition is more likely to be incorrect. The maximum and minimum values of a partition are its boundary values.

o  Black-box technique that focuses on the boundaries of the input domain
o    Boundary value analysis can be applied at all test levels
o    It is relatively easy to apply and its defect-finding capability is high
o    This technique is often considered as an extension of equivalence partitioning.

This technique is based on testing the boundaries between the partitions for both valid boundaries and invalid boundaries.

For Example- If a Text Field allows 1 to 255 characters. Then

-Use 1 and 255 as a Valid condition (You might also try 245 as a valid condition)

-Use 0 and 256 as a Invalid condition.

Decision Table Testing('cause-effect' table.)

o    In Decision table testing test cases are designed to execute the combination of inputs
o    Decision tables are good way to capture system requirements that contain logical conditions.

o    It maybe applied to all situations when the action of the software depends on several logical decisions

oThe first task is to identify a suitable function or subsystem that has a behavior

Which reacts according to a combination of inputs or events,It is better to deal with large numbers of conditions by dividing theinto subsets and dealing with the subsets one at a time.

OA Decision Table showing combination of inputs (causes) with their output (effects),Which can be used to design test cases.

Credit card worked example

Let's look at another example. If you are a new customer opening a credit card

Account, you will get a 15% discount on all your purchases today. If you are an

Existing customer and you hold a loyalty card, you get a 10% discount. If you

have a coupon, you can get 20% off today (but it can't be used with the 'new

Customer' discount). Discount amounts are added, if applicable.

TABLE --Decision table for credit card example

In Table, the conditions and actions are listed in the left hand column.

All the other columns in the decision table each represent a separate rule,

one for each combination of conditions. We may choose to test each

Rule/combination and if there are only a few this will usually be the case.

However, if the number of rules/combinations is large we are more likely to

Sample them by selecting a rich subset for testing.

State Transition Testing

o    State transition testing is used where some aspect of the system can be

Described in what is called a 'finite state machine'. This simply means that the

System can be in a (finite) number of different states, and the transitions from

One state to another are determined by the rules of the 'machine'.

o   Ablack box test design technique in which  test cases are designed to execute valid and invalid state transitions
o    A system may exhibit a different response on current conditions or previous history. In this case, that aspect of the system can be shown as a state transition diagram.
o    State transition testing is much used in embedded software and technical automation.

A state transition model has four basic parts:

• The states that the software may occupy (open/closed or funded/insufficient

Funds);

• The transitions from one state to another (not all transitions are allowed);

• The events that cause a transition (closing a file or withdrawing money);

• The actions that result from a transition (an error message or being given

Your cash).

The state diagram shows seven states but only four possible events (Card

inserted, Enter PIN, PIN OK and PIN not OK). We have not specified all of the

possible transitions here - there would also be a time-out from 'wait for PIN'

and from the three tries which would go back to the start state after the time

had elapsed and would probably eject the card. There would also be a transition

from the 'eat card' state back to the start state. We have not specified all

the possible events either - there would be a 'cancel' option from 'wait for PIN'.

Table 4.9 lists the states in the first column and the possible inputs across the

top row. So, for example, if the system is in State 1, inserting a card will take it

to State 2. If we are in State 2, and a valid PIN is entered, we go to State 6 to

access the account. In State 2 if we enter an invalid PIN, we go to State 3. We

have put a dash in the cells that should be impossible, i.e. they represent invalid

transitions from that state.

Use Case Testing

Use case testing is a technique that helps us identify test cases that exercise the

whole system on a transaction by transaction basis from start to finish.

o    In use case testing test cases are designed to execute user scenarios

o    Use cases are a sequence of steps that describe the interactions

between the actor and the system.

o    Use cases are defined in terms of the actor, not the system, describing what

the actor does and what the actor sees rather than what inputs the system

expects and what the system ‘outputs   

o    Use cases, often referred  to as scenarios, are very useful for designing acceptance tests with customer/user participation   

 EXPERIENCE-BASED TECHNIQUES

Although testing needs to be rigorous, systematic and thorough, there are some non-systematictechniques that are based on a person's knowledge, experience, imagination and intuition. A bug hunter often is able to locate an elusive defect in the system. The two techniques, which fall under this category, they are:

o    Error guessing
o    Exploratory testing

Error Guessing

o    Error guessing is a commonly used experience-based technique
o    Generally testers anticipate defects based on experience, these defects list can be built based on experience, available defect data, and from common knowledge about why software fails.

Exploratory Testing
o    Exploratory testing is concurrent test design, test execution, test logging and learning , based on  test charter containing test objectives and carried out within time boxes
o    It is approach that is most useful where there are few or inadequate specifications and serve time pressure.

Error Guessing

It is a test design technique, where the experience of the tester is put to test, to hunt for elusive bugs, which may be a part of the component or the system, due to errors made. This technique is often used after the formal techniques have been used to test the code and has proved to be very useful. A structured approach to be used in error guessing approach is to list the possible defects, which can be a part of the system and then test cases in an attempt to reproduce them.

Exploratory Testing Techniques

Exploratory testing is also known as 'monkey testing'. It is a hands-on approach, where there is minimum planning of testing the component, but maximum testing takes place. The test design and test execution happen simultaneously without formally documenting the test conditions, test cases or test scripts. This approach is useful, when the project specifications are poor or when the time at hand is extremely limited.

There are different types of software testing estimation techniques. One of the techniques involves consulting people who will perform the testing activities and the people who have expertise on the tasks to be done. The software testing techniques to be used to test the project depends on a number of factors. The main factors are urgency of the project, severity of the project, resources in hand, etc. At the same time not all techniques of software testing will be utilized in all the projects, depending on the organizational polices techniques will be decided.

Structure Based Testing Techniques

There are two purposes of structure based testing techniques, viz. Test coverage measurement and structural test case design. They are a good way to generate additional test cases, which are different from existing test cases, derived from the specification based techniques. This is also known as white box testing strategy or white box testing techniques.

·         Test Coverage: The degree expressed as a percentage, to which a specified coverage item has been exercised by a test suite. The basic coverage measure is

Coverage  =

Number of coverage items exercised Total number of coverage items

*100%

·         There is a danger in using the coverage measure. Contrary to the belief, 100% coverage does not mean that the code is 100% tested.

·         Statement Coverage and Statement Testing:

This is the percentage of executable statements, which have been exercised by a particular test suite. It is important to note, that a statement may be on one single line or it can be spread over several lines. At the same time, one line may contain more than one statement or a part of a statement as well and not to forget statements, which contain other statement inside them. The formula to be used for statement coverage is:

Statement Coverage  =

Number of statements exercised Total number of statements

*100%

·         Decision Coverage and Decision Testing:

Decision statements are statements like 'If statements', loop statements, Case statements, etc. where there are two or more possible outcomes from the same statement. To calculate decision coverage, the formula you will use is

Decision Coverage  =

Number of decision outcomes exercised Total number of decision outcomes

*100%

·         Decision coverage is stronger than statement coverage, as 100% decision coverage always guarantees statement coverage, but the other way round is not true. While checking decision coverage, each decision needs to have both a true as well as a false outcome.

·         Other Structure based Testing Techniques:

Apart from the structure based techniques mentioned above, there are some other techniques as well. They include linear code sequence and jump (LCSAJ) coverage, multiple condition decision coverage (MCDC), path testing, etc.