Home » Software testing types
Volume Testing !!!


Volume Testing
*****************

The purpose of Volume Testing is to find weaknesses in the system with respect to its handling of large amounts of data during short time periods. For example, this kind of testing ensures that the system will process data across physical and logical boundaries such as across servers and across disk partitions on one server.

Usability Testing !!!

Usability:
***********
Correctness is whether the information is truthful or contains misinformation. The accuracy of the information is whether it is without grammatical or spelling errors .Remove relevant information from your site. This may cause misunderstanding or confusion

General appearance:
* Page appearance
* Color, font and size
* Frames
* Consistent design.


Black Box Testing !!!

Black Box Testing:

Testing of a function without knowing internal structure of the program.
Black box testing that is also known as functional or behavioral testing. This is testing a pre- release or release version of the program and trying various inputs looking for incorrect outputs or program crashes. It is one of the best ways to diagnose bugs before users discover them. Given the complexity of many software packages, much thought must be devoted to optimizing the testing process. Ideally only one test will be performed for each possible set of software conditions. Of all possible sets of software conditions there are groupings of conditions that if all tested would be testing the same code and reveal the same bugs (or hopefully the lack of bugs). These groups of conditions are considered an equivalent class or each is called an equivalent class partition.


Equivalence Partitioning:
A subset of data that is representation of a large class.
Ex: A program which exits credit limits with in a given range. (10000 – 15000)
Would have three equivalent classes.
• Less than 10000 (invalid)
• Between 10000 and 15000 ( valid)
• Above 15000. ( invalid)

Boundary Analysis:
Technique that consists of developing test cases and data that focus on the input and output boundaries of the given function.
• Low Boundary plus or minus one ( 9999 or 10001)
• On the boundary ( 10000 and 15000)
• Upper boundary plus or minus (14999 and 15001)

Error guessing
Based on the theory the test cases developed based on the experience of the Test engineer.
Ex : If one of the input is date, a test engineer must try Feb 29,2000 or 9/9/99.

Advantages of Black Box Testing
- Tester can be non-technical.
- This testing is most likely to find those bugs as the user would find.
- Testing helps to identify the vagueness and contradiction in functional specifications.
- Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing
- Chances of having repetition of tests that are already done by programmer.
- The test inputs needs to be from large sample space.
- It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
Chances of having unidentified paths during this testing

White Box Testing !!!

Testing of a function with knowing internal structure of the program.

White box testing involves looking at the structure of the code. When you know the internal structure of a product, tests can be conducted to ensure that the internal operations performed according to the specification. And all internal components have been adequately exercised. In other word WBT tends to involve the coverage of the specification in the code.

Code coverage is defined in six types as listed below.

• Segment coverage – Each segment of code b/w control structure is executed at least once.
• Branch Coverage or Node Testing – Each branch in the code is taken in each possible direction at least once.
• Compound Condition Coverage – When there are multiple conditions, you must test not only each direction but also each possible combinations of conditions, which is usually done by using a ‘Truth Table’
• Basis Path Testing – Each independent path through the code is taken in a pre-determined order. This point will further be discussed in other section.
• Data Flow Testing (DFT) – In this approach you track the specific variables through each possible calculation, thus defining the set of intermediate paths through the code i.e., those based on each piece of code chosen to be tracked. Even though the paths are considered independent, dependencies across multiple paths are not really tested for by this approach. DFT tends to reflect dependencies but it is mainly through sequences of data manipulation. This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.
• Path Testing – Path testing is where all possible paths through the code are defined and covered. This testing is extremely laborious and time consuming.
• Loop Testing – In addition top above measures, there are testing strategies based on loop testing. These strategies relate to testing single loops, concatenated loops, and nested loops. Loops are fairly simple to test unless dependencies exist among the loop or b/w a loop and the code it contains.

In WBT, we use the control structure of the procedural design to derive test cases. Using WBT methods a tester can derive the test cases that
• Guarantee that all independent paths within a module have been exercised at least once.
• Exercise all logical decisions on their true and false values.
• Execute all loops at their boundaries and within their operational bounds
• Exercise internal data structures to ensure their validity.

White box testing (WBT) is also called Structural or Glass box testing.

We do WBT because Black box testing is unlikely to uncover numerous sorts of defects in the program. These defects can be of the following nature:

• Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. Error tend to creep into our work when we design and implement functions, conditions or controls that are out of the program
• The logical flow of the program is sometimes counterintuitive, meaning that our unconscious assumptions about flow of control and data may lead to design errors that are uncovered only when path testing starts.
• Typographical errors are random, some of which will be uncovered by syntax checking mechanisms but others will go undetected until testing begins.

Talking theoretically, all we need to do in WBT is to define all logical paths, develop test cases to exercise them and evaluate results i.e. generate test cases to exercise the program logic exhaustively.

For this we need to know the program well i.e. We should know the specification and the code to be tested; related documents should be available too us .We must be able to tell the expected status of the program versus the actual status found at any point during the testing process.

Recovery Testing !!!

Recovery testing


It is nothing but a feature built in an application for handling interruptions. Returning to the actual page in an application.

Configuration Testing !!!

Configuration Testing


This testing is performed to find out the various supporting configurations of hardware and software.

Benefits Realization Testing !!!

Benefits realization testing


It is a test or analyzes conducted after an application is moved into production. To determine whether the application is lightly to deliver the original benefits. This is conducted by the user or client group who requested the project.

Vendor Validation Testing !!!

Vendor Validation Testing


This is done by producer (Vendor) and tester jointly. This testing can be conducted jointly by software vendor and testing team.

Pilot Testing !!!


Pilot Test
For the pilot test, we will give your product a "real-world" test as well as collect data on the use of the product in the classrooms. Here are the steps we will follow for our pilot test.

1. We will recruit test-run professors and teachers who are similar to our intended audience.
The important thing here is that the test audience should, as much as possible, be like your "real" audience so you get the most accurate information.

2. Have the test-run participants use or watch your product.
It is not necessary to bring the whole group together at once. It might be better to only have one or two participant test run the product at a time.

3. Observe the test-run participants as they use/watch your product.
The important thing here is to try not to interfere. In order to get accurate information, you must not jump in to "help" as soon as you spot an apparent problem. Of course, if participants really get stuck, you do want to work with them so they can continue to test your product.

a. Make notes.
Your notes should include information about where any problems occurred, under what circumstances, and how the person attempted to resolve or actually did resolve the problem. You should include any participant reactions, both positive and negative, which you observe. Your notes should include information such as "Screen #10 - both participants clicked on the big picture of the car instead of the first small picture" or "the right arrow button on screen #3 sends user to screen #4 instead of screen #7."

b. Ask questions.
Your questions should help clarify why people are doing what they're doing (i.e., When you got to the screen with the one big and several small pictures of cars, why did you click on the big picture first?). Your questions should also help you make changes (i.e., What would you suggest we do to make this screen, page, frame, etc. less confusing?).


4. Have the test-run participants make notes as they use/watch your product.
This is a good way for the test-run participants to capture things as they happen. You will likely get confirmation of problems you observed as well as some on-the-spot thinking which you cannot observe very easily.
This is also a useful time to collect information if you are unable to directly observe the test-run participants.

5. Have the test-run participants complete a survey.
This is a more systematic way to collect the information you are after. All test-run participants answer the same questions, and you can quickly see any trends that develop. Like the test-run participant notes, a survey is also a good way to get information if you are unable to observe the participants yourself.

6. Conduct interviews/focus group after the test-run.

Usability Testing !!!


Usability Testing

* Usability means that systems are easy and fast to learn, efficient to use, easy to remember, cause no operating errors and offer a high degree of satisfaction for the user. Usability means bringing the usage perspective into focus, the side towards the user.


It determines how well the user will be able to understand and interact with the system. This is done prior to testing levels.
In other words, Usability-testing is the measurement of how well a website aligns with the behaviors of online users, enabling them to complete their tasks efficiently, effectively, and satisfactorily.

Beta Testing !!!

Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers.

Beta Testing Objectives
* Evaluate software technical content
* Evaluate software ease of use
* Evaluate user documentation draft
* Identify errors
* Report errors/findings


Role of a Test Lead
1.Provide Test Instruction Sheet that describes items such as testing objectives, steps to follow, data to enter, functions to invoke.
2.Provide feedback forms and comments.

Role of a tester
1.Understand the software requirements and the testing objectives.
2.Carry out the test cases and Report defects

Smoke 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.

Executable Testing !!!

Executable Testing


Executable Tests interrupt and restart the program, including tests that remove selective binary or input files, looking for graceful program stops with appropriate error messages.

Executable Tests also include:

· Load tests – testing the program’s ability to handle large tasks.
· Error recovery – attempting to make the program generate as many error messages as possible.
· Compatibility – checking the functioning of the program simultaneously with other applications such as word processors, spreadsheets, day planners, etc.
· Installation – the installation program must be tested to see if it properly installs in a variety of environments.

Sensitivity Testing !!!

Sensitivity Tests


Sensitivity tests compare results to a baseline case and exhaustively test the functioning of every modeling input, including weather data for a full range of climate zones.

Range Testing !!!

Range Tests


Range tests check the operation of the code over the complete range of valid inputs. The tests will also go beyond all valid ranges to ensure that adequate error messages are generated.

Analytical and Emprical Testing !!!

Analytical Tests
Analytical testing compare results to mathematical solutions for simple cases.



Empirical Tests
Empirical testing compare results to experimental data. In many respects, these have proven to be the most difficult type of tests to do. It is important that high-quality data be used as the basis for comparison along with complete and accurate information for developing a simulation model that represents the test building or module as closely as possible.

Conformance Testing !!!

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.

Compatability Testing !!!

COMPATIBILITY TESTING

Testing to ensure compatibility of an application or Web site with different browsers, OS, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.

Automation Testing !!!




Automated testing requires a knowledge base of valid outcomes for various runs of simulation. This knowledge base is created by domain experts of the simulation system being tested. The data collected in various test runs is compared against this knowledge base to automatically validate the system under test. An advantage of this kind of testing is that the system can continually be regression tested as it is being developed.


The above process of testing is called Regression testing.

Manual Testing !!!