Learn Software Testing

Welcome to LST !!!

2009-12-02T09:39:00.018+05:30

Welcome to the world of software testing. Here you will get to know everything you wanted to know about Software Testing. Most importantly, you will get to know this information from the practitioners, from the people working in the field, from people like you and me. So lets start learning this art; this science or just Software Testing and start with its definition.

What is Software Testing?

According to the classic definition of Myers "Software Testing is the process of executing a program or system with the intent of finding errors."

To learn the testing tutorial completely from the basics, go to the link below
Testing Tutorial

Requirements Traceability Matrix !!!

2007-12-26T06:13:00.001+05:30

Ideally each software developed must satisfy the set of requirements completely. So, right from design, each requirement must be addressed in every single document in the software process. The documents include the HLD, LLD, source codes, unit test cases, integration test cases and the system test cases. Refer the following sample table which describes Requirements Traceability Matrix process. In this matrix, the rows will have the requirements. For every document {HLD, LLD etc}, there will be a separate column. So, in every cell, we need to state, what section in HLD addresses a particular requirement. Ideally, if every requirement is addressed in every single document, all the individual cells must have valid section ids or names filled in. Then we know that every requirement is addressed. In case of any missing of requirement, we need to go back to the document and correct it, so that it addressed the requirement.

For testing at each level, we may have to address the requirements. One integration and the system test case may address multiple requirements.

Installation Testing !!!

2007-12-25T06:01:00.001+05:30

Installation testing is often the most under tested area in testing. This type of testing is performed to ensure that all Installed features and options function properly. It is also performed to verify that all necessary components of the application are, indeed, installed.

Installation testing should take care of the following points: -
1.To check if while installing product checks for the dependent software / patches say Service pack3.
2.The product should check for the version of the same product on the target machine, say the previous version should not be over installed on the newer version.
3.Installer should give a default installation path say “C:\programs\.”
4.Installer should allow user to install at location other then the default installation path.
5.Check if the product can be installed “Over the Network”
6.Installation should start automatically when the CD is inserted.
7.Installer should give the remove / Repair options.
8.When uninstalling, check that all the registry keys, files, Dll, shortcuts, active X components are removed from the system.
9.Try to install the software without administrative privileges (login as guest).
10.Try installing on different operating system.
11.Try installing on system having non-compliant configuration such as less memory / RAM / HDD.

Content Management Testing !!!

2007-12-24T05:51:00.001+05:30

‘Content Management’ has gained a predominant importance after the Web applications took a major part of our lives. What is Content Management? As the name denotes, it is managing the content. How do they work? Let us take a common example. You are in China and you wanted to open the Yahoo! Chinese version. When you choose Chinese version on the main page of Yahoo! You get to see the entire content in Chinese. Yahoo! Would strategically plan and have various servers for various languages. When you choose a particular version of the page, the request is redirected to the server which manages the Chinese content page. The Content Management systems help is placing content for various purposes and also help in displaying when the request comes in.

Content Management Testing involves:
1. Testing the distribution of the content.
2. Request, Response Time’s.
3. Content display on various browsers and operating systems.
4. Load distribution on the servers.

In fact all the performance related testing should be performed for each version of the web application which uses the content management servers.

Unit Test Cases !!!

2007-12-23T05:37:00.001+05:30

It must be clear by now that preparing Unit Test Cases document (referred to as UTC hereafter) is an important task in Unit Testing activity. Having an UTC, which is complete with every possible test case, leads to complete Unit Testing and thus gives an assurance of defect-free Unit at the end of Unit Testing stage.

Think of following aspects while preparing Unit Test Cases:

* Expected Functionality
Write test cases against each functionality that is expected to be provided from the Unit being developed.

* Input values
Write test cases for each of the inputs accepted by the Unit.

* Output values
Write test cases to generate scenarios, which will produce all types of output values that are expected from the Unit.

* Screen / Report Layout
Screen Layout or web page layout and Report layout must be tested against the requirements. It should not happen that the screen or the report looks beautiful and perfect, but user wanted something entirely different! It should ensure that pages and screens are consistent.

* Path coverage
A Unit may have conditional processing which results in various paths the control can traverse through. Test case must be written for each of these paths.

* Assumptions
A Unit may assume certain things for it to function. For example, a Unit may need a database to be open. Then test case must be written to check that the Unit reports error if such assumptions are not met.

* Transactions:
In case of database applications, it is important to make sure that transactions are properly designed and no way inconsistent data gets saved in the database.

* Abnormal terminations:
Behavior of the Unit in case of abnormal termination should be tested.

* Error messages
Error messages should be short, precise and self-explanatory. They should be properly phrased and should be free of grammatical mistakes.

UTC Document Format

Defect Recording !!!

2007-12-22T05:24:00.001+05:30

* Defect Recording can be done on the same document of UTC, in the column of ‘Expected Results’. This column can be duplicated for the next iterations of Unit Testing.

* Defect Recording can also be done using some tools like Bugzilla, in which defects are stored in the database.

* Defect Recording needs to be done with care. It should be able to indicate the problem in clear, unambiguous manner, and reproducing of the defects should be easily possible from the defect information.

Comparison Testing !!!

2007-12-21T05:18:00.001+05:30

There are situations where independent versions of software be developed for critical applications, even when only a single version will be used in the delivered computer based system. It is these independent versions which form the basis of a black box testing technique called Comparison testing or back-to-back testing.

Equivalence Partitioning !!!

2007-12-20T05:13:00.001+05:30

Equivalence partitioning is a black box testing method that divides the input domain of a program into classes of data from which test cases can be derived.

Equivalence Partitioning can be defined according to the following guidelines:
1. If an input condition specifies a range, one valid and one two invalid classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined.
4. If an input condition is Boolean, one valid and one invalid class is defined.

Boundary Value Analysis !!!

2007-12-19T16:58:00.001+05:30

Boundary Value Analysis (BVA) is a test data selection technique (Functional Testing technique) where the extreme values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The hope is that, if a system works correctly for these special values then it will work correctly for all values in between.

* Extends equivalence partitioning
* Test both sides of each boundary
* Look at output boundaries for test cases too
* Test min, min-1, max, max+1, typical values

* BVA focuses on the boundary of the input space to identify test cases
* Rational is that errors tend to occur near the extreme values of an input variable

There are two ways to generalize the BVA techniques:

1. By the number of variables
For n variables: BVA yields 4n + 1 test cases.

2. By the kinds of ranges
Generalizing ranges depends on the nature or type of variables

* NextDate has a variable Month and the range could be defined as {Jan, Feb, …Dec}
* Min = Jan, Min +1 = Feb, etc.
* Triangle had a declared range of {1, 20,000}
* Boolean variables have extreme values True and False but there is no clear choice for the remaining three values

Advantages of Boundary Value Analysis
1. Robustness Testing - Boundary Value Analysis plus values that go beyond the limits
2. Min - 1, Min, Min +1, Nom, Max -1, Max, Max +1
3. Forces attention to exception handling
4. For strongly typed languages robust testing results in run-time errors that abort normal execution

Limitations of Boundary Value Analysis
BVA works best when the program is a function of several independent variables that represent bounded physical quantities

1. Independent Variables
NextDate test cases derived from BVA would be inadequate: focusing on the boundary would not leave emphasis on February or leap years
Dependencies exist with NextDate's Day, Month and Year
Test cases derived without consideration of the function

2. Physical Quantities
An example of physical variables being tested, telephone numbers - what faults might be revealed by numbers of 000-0000, 000-0001, 555-5555, 999-9998, 999-9999?

Loop Testing !!!

2007-12-18T16:53:00.002+05:30

Loop Testing is a white box testing technique that focuses exclusively on the validity of loop constructs. Four classes of loops can be defined: Simple loops, Concatenated loops, nested loops, and unstructured loops.

Simple Loops
The following sets of tests can be applied to simple loops, where ‘n’ is the maximum number of allowable passes through the loop.
1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
4. ‘m’ passes through the loop where m
5. n-1, n, n+1 passes through the loop.

Nested Loops
If we extend the test approach from simple loops to nested loops, the number of possible tests would grow geometrically as the level of nesting increases.
1. Start at the innermost loop. Set all other loops to minimum values.
2. Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values. Add other tests for out-of-range or exclude values.
3. Work outward, conducting tests for the next loop, but keep all other outer loops at minimum values and other nested loops to “typical” values.
4. Continue until all loops have been tested.

Concatenated Loops
Concatenated loops can be tested using the approach defined for simple loops, if each of the loops is independent of the other. However, if two loops are concatenated and the loop counter for loop 1 is used as the initial value for loop 2, then the loops are not independent.

Unstructured Loops
Whenever possible, this class of loops should be redesigned to reflect the use of the structured programming constructs.

Control Structure Testing !!!

2007-12-17T16:51:00.001+05:30

Described below are some of the variations of Control Structure Testing.

Condition Testing
Condition testing is a test case design method that exercises the logical conditions contained in a program module.

Data Flow Testing
The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program.

Code Review !!!

2007-12-16T14:38:00.002+05:30

A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.

QA team member (In case the QA Team is only involved in Black Box Testing, then the Development team lead chairs the review team) leads code review. Members from development team and QA team participate in the review.

Input Criteria
The Coding Standards Document and the Source file are the essential documents for the review. A checklist can be used for the review.

Exit Criteria
Exit criteria include the filled & completed checklist with the reviewers’ comments & suggestions and the re-verification whether they are incorporated in the documents.

Design Review !!!

2007-12-15T14:35:00.001+05:30

A process or meeting during which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include critical design review, preliminary design review, and system design review.

QA team member leads design review. Members from development team and QA team participate in the review.

Input Criteria
Design document is the essential document for the review. A checklist can be used for the review.

Exit Criteria
Exit criteria include the filled & completed checklist with the reviewers’ comments & suggestions and the re-verification whether they are incorporated in the documents.

Requirement Review !!!

2007-12-14T14:33:00.001+05:30

A process or meeting during which the requirements for a system, hardware item, or software item are presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include system requirements review, software requirements review.

Product management leads Requirement Review. Members from every affected department participates in the review

Input Criteria
Software requirement specification is the essential document for the review. A checklist can be used for the review.

Exit Criteria
Exit criteria include the filled & completed checklist with the reviewers’ comments & suggestions and the re-verification whether they are incorporated in the documents.

Technical Reviews !!!

2007-12-13T14:31:00.001+05:30

Technical reviews confirm that product Conforms to specifications, adheres to regulations, standards, guidelines, plans, changes are properly implemented, changes affect only those system areas identified by the change specification.

The main objectives of Technical Reviews can be categorized as follows:
• Ensure that the software confirms to the organization standards.
• Ensure that any changes in the development procedures (design, coding, testing) are implemented per the organization pre-defined standards.
In technical reviews, the following Software products are reviewed
• Software requirements specification
• Software design description
• Software test documentation
• Software user documentation
• Installation procedure
• Release notes

The participants of the review play the roles of Decision-maker, Review leader, Recorder, Technical staff.

Management Reviews !!!

2007-12-12T14:28:00.001+05:30

Management reviews are performed by those directly responsible for the system in order to monitor progress, determine status of plans and schedules, confirm requirements and their system allocation.

Therefore the main objectives of Management Reviews can be categorized as follows:
• Validate from a management perspective that the project is making progress according to the project plan.
• Ensure that deliverables are ready for management approvals.
• Resolve issues that require management’s attention.
• Identify any project bottlenecks.
• Keeping project in Control.

Support decisions made during such reviews include Corrective actions, Changes in the allocation of resources or changes to the scope of the project

In management reviews the following Software products are reviewed:
Audit Reports
Contingency plans
Installation plans
Risk management plans
Software Q/A

The participants of the review play the roles of Decision-Maker, Review Leader, Recorder, Management Staff, and Technical Staff.

Review !!!

2007-12-11T14:23:00.001+05:30

A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.
The main goal of reviews is to find defects. Reviews are a good compliment to testing to help assure quality. A few purposes’ of SQA reviews can be as follows:

• Assure the quality of deliverable before the project moves to the next stage.
• Once a deliverable has been reviewed, revised as required, and approved, it can be used as a basis for the next stage in the life cycle.

Types of reviews

* Management Reviews
* Technical Reviews
* Inspections
* Walkthroughs and Audits.

Objective Testing !!!

2007-12-10T18:46:00.002+05:30

Objective testing is mainly used in systems where the data can be recorded while the simulation is running. This testing technique relies on the application of statistical and automated methods to the data collected.

Statistical methods are used to provide an insight into the accuracy of the simulation. These methods include hypothesis testing, data plots, principle component analysis and cluster analysis.
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.

Walkthrough !!!

2007-12-09T14:41:00.001+05:30

A static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a segment of documentation or code, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems.

The objectives of Walkthrough can be summarized as follows:
• Detect errors early.
• Ensure (re)established standards are followed:
• Train and exchange technical information among project teams which participate in the walkthrough.
• Increase the quality of the project, thereby improving morale of the team members.

The participants in Walkthroughs assume one or more of the following roles:
a) Walk-through leader
b) Recorder
c) Author
d) Team member

To consider a review as a systematic walk-through, a team of at least two members shall be assembled. Roles may be shared among the team members. The walk-through leader or the author may serve as the recorder. The walk-through leader may be the author.
Individuals holding management positions over any member of the walk-through team shall not participate in the walk-through.

Input to the walk-through shall include the following:
a) A statement of objectives for the walk-through
b) The software product being examined
c) Standards that are in effect for the acquisition, supply, development, operation, and/or maintenance of the software product
Input to the walk-through may also include the following:
d) Any regulations, standards, guidelines, plans, and procedures against which the software product is to be inspected
e) Anomaly categories

The walk-through shall be considered complete when
a) The entire software product has been examined
b) Recommendations and required actions have been recorded
c) The walk-through output has been completed

When Should Testing stop?

2007-12-08T14:20:00.001+05:30

"When to stop testing" is one of the most difficult questions to a test engineer.
The following are few of the common Test Stop criteria:

1. All the high priority bugs are fixed.
2. The rate at which bugs are found is too small.
3. The testing budget is exhausted.
4. The project duration is completed.
5. The risk in the project is under acceptable limit.

Practically, we feel that the decision of stopping testing is based on the level of the risk acceptable to the management. As testing is a never ending process we can never assume that 100 % testing has been done, we can only minimize the risk of shipping the product to client with X testing done. The risk can be measured by Risk analysis but for small duration / low budget / low resources project, risk can be deduced by simply: -

• Measuring Test Coverage.
• Number of test cycles.
• Number of high priority bugs.

Methods of Software Testing !!!

2007-12-07T14:12:00.001+05:30

Testability

Software testability is how easily, completely and conveniently a computer program can be tested.
Software engineers design a computer product, system or program keeping in mind the product testability. Good programmers are willing to do things that will help the testing process and a checklist of possible design points, features and so on can be useful in negotiating with them.
Here are the two main heuristics of software testing.
1. Visibility
2. Control

Visibility

Visibility is our ability to observe the states and outputs of the software under test. Features to improve the visibility are

• Access to Code
Developers must provide full access (source code, infrastructure, etc) to testers. The Code, change records and design documents should be provided to the testing team. The testing team should read and understand the code.

• Event logging
The events to log include User events, System milestones, Error handling and completed transactions. The logs may be stored in files, ring buffers in memory, and/or serial ports. Things to be logged include description of event, timestamp, subsystem, resource usage and severity of event. Logging should be adjusted by subsystem and type. Log file report internal errors, help in isolating defects, and give useful information about context, tests, customer usage and test coverage.

The more readable the Log Reports are, the easier it becomes to identify the defect cause and work towards corrective measures.

• Error detection mechanisms
Data integrity checking and System level error detection (e.g. Microsoft Appviewer) are useful here. In addition, Assertions and probes with the following features are really helpful
* Code is added to detect internal errors.
* Assertions abort on error.
* Probes log errors.
* Design by Contract theory---This technique requires that assertions be defined for functions. Preconditions apply to input and violations implicate calling functions while post-conditions apply to outputs and violations implicate called functions. This effectively solves the oracle problem for testing.

• Resource Monitoring
Memory usage should be monitored to find memory leaks. States of running methods, threads or processes should be watched (Profiling interfaces may be used for this.). In addition, the configuration values should be dumped. Resource monitoring is of particular concern in applications where the load on the application in real time is estimated to be considerable.

Control
Control refers to our ability to provide inputs and reach states in the software under test.
The features to improve controllability are:

• Test Points
Allow data to be inspected, inserted or modified at points in the software. It is especially useful for dataflow applications. In addition, a pipe and filters architecture provides many opportunities for test points.

• Custom User Interface controls
Custom UI controls often raise serious testability problems with GUI test drivers. Ensuring testability usually requires:
* Adding methods to report necessary information
* Customizing test tools to make use of these methods
* Getting a tool expert to advise developers on testability and to build the required support.
* Asking third party control vendors regarding support by test tools.

• Test Interfaces
Interfaces may be provided specifically for testing e.g. Excel and Xconq etc.
Existing interfaces may be able to support significant testing e.g. InstallSheild, AutoCAD, Tivoli, etc.

• Fault injection
Error seeding---instrumenting low level I/O code to simulate errors---makes it much easier to test error handling. It can be handled at both system and application level, Tivoli, etc.

• Installation and setup
Testers should be notified when installation has completed successfully. They should be able to verify installation, programmatically create sample records and run multiple clients, daemons or servers on a single machine.

Life Cycle of a Defect !!!

2007-12-06T06:26:00.001+05:30

The following self explanatory figure explains the life cycle of a defect:

Defect Taxonomies !!!

2007-11-30T18:31:00.001+05:30

Categories of Defects:

All software defects can be broadly categorized into the below mentioned types:

• Errors of commission: something wrong is done
• Errors of omission: something left out by accident
• Errors of clarity and ambiguity: different interpretations
• Errors of speed and capacity

However, the above is a broad categorization; below we have for you a host of varied types of defects that can be identified in different software applications:

1. Conceptual bugs / Design bugs
2. Coding bugs
3. Integration bugs
4. User Interface Errors
5. Functionality
6. Communication
7. Command Structure
8. Missing Commands
9. Performance
10. Output
11. Error Handling Errors
12. Boundary-Related Errors
13. Calculation Errors
14. Initial and Later States
15. Control Flow Errors
16. Errors in Handling Data
17. Race Conditions Errors
18. Load Conditions Errors
19. Hardware Errors
20. Source and Version Control Errors
21. Documentation Errors
22. Testing Errors

Defect !!!

2007-11-28T18:51:00.001+05:30

Defect Management

Defects determine the effectiveness of the Testing what we do. If there are no defects, it directly implies that we don’t have our job. There are two points worth considering here, either the developer is so strong that there are no defects arising out, or the test engineer is weak. In many situations, the second is proving correct. This implies that we lack the knack. In this section, let us understand Defects.

What is a Defect?
For a test engineer, a defect is following: -
• Any deviation from specification
• Anything that causes user dissatisfaction
• Incorrect output
• Software does not do what it intended to do.

Bug / Defect / Error: -
• Software is said to have bug if it features deviates from specifications.
• Software is said to have defect if it has unwanted side effects.
• Software is said to have Error if it gives incorrect output.

But as for a test engineer all are same as the above definition is only for the purpose of documentation or indicative.

Rapid Testing Practice !!!

2007-11-14T15:01:00.001+05:30

THE RAPID TESTING PRACTICE

It would help us if we scrutinize each phase of a development process to see how the efficiency, speed and quality of testing can be improved, bearing in mind the following factors:

• Actions that the test team can take to prevent defects from escaping. For example, practices like extreme programming and exploratory testing.
• Actions that the test team can take to manage risk to the development schedule.
• The information that can be obtained from each phase so that the test team can speed up the activities.

If a test process is designed around the answers to these questions, both the speed of testing and the quality of the final product should be enhanced.

Some of the aspects that can be used while rapid testing are given below:
1. Test for link integrity
2. Test for disabled accessibility
3. Test the default settings
4. Check the navigation’s
5. Check for input constraints by injecting special characters at the sources of data
6. Run Multiple instances
7. Check for interdependencies and stress them
8. Test for consistency of design
9. Test for compatibility
10. Test for usability
11. Check for the possible variability’s and attack them
12. Go for possible stress and load tests
13. And our favorite – banging the keyboard

Rapid Testing

2007-11-05T13:13:00.002+05:30

Rapid testing is the testing software faster than usual, without compromising on the standards of quality. It is the technique to test as thorough as reasonable within the constraints. This technique looks at testing as a process of heuristic inquiry and logically speaking it should be based on exploratory testing techniques.

Although most projects undergo continuous testing, it does not usually produce the information required to deal with the situations where it is necessary to make an instantaneous assessment of the product's quality at a particular moment. In most cases the testing is scheduled for just prior to launch and conventional testing techniques often cannot be applied to software that is incomplete or subject to constant change. At times like these Rapid Testing can be used.

It can be said that rapid testing has a structure that is built on a foundation of four components namely,
• People
• Integrated test process
• Static Testing and
• Dynamic Testing
There is a need for people who can handle the pressure of tight schedules. They need to be productive contributors even through the early phases of the development life cycle. According to James Bach, a core skill is the ability to think critically.

It should also be noted that dynamic testing lies at the heart of the software testing process, and the planning, design, development, and execution of dynamic tests should be performed well for any testing process to be efficient.

Subjective Testing !!!

2007-10-30T15:17:00.001+05:30

Subjective testing mainly depends on an expert's opinion. An expert is a person who is proficient and experienced in the system under test. Conducting the test involves test runs of the simulation by the expert and then the expert evaluates and validates the results based on some criteria.

One advantage of this approach over objective testing is that it can test those conditions which cannot be tested objectively. For example, an expert can determine whether the joystick handling of the flight feels "right".

One disadvantage is that the evaluation of the system is based on the "expert's" opinion, which may differ from expert to expert. Also, if the system is very large then it is bound to have many experts. Each expert may view it differently and can give conflicting opinions. This makes it difficult to determine the validity of the system. Despite all these disadvantages, subjective testing is necessary for testing systems with human interaction.

System Test cases !!!

2007-10-26T17:58:00.001+05:30

The system test cases meant to test the system as per the requirements; end-to end. This is basically to make sure that the application works as per SRS. In system test cases, (generally in system testing itself), the testers are supposed to act as an end user. So, system test cases normally do concentrate on the functionality of the system, inputs are fed through the system and each and every check is performed using the system itself. Normally, the verifications done by checking the database tables directly or running programs manually are not encouraged in the system test.
The system test must focus on functional groups, rather than identifying the program units. When it comes to system testing, it is assume that the interfaces between the modules are working fine (integration passed).

Ideally the test cases are nothing but a union of the functionalities tested in the unit testing and the integration testing. Instead of testing the system inputs outputs through database or external programs, everything is tested through the system itself. For example, in a online shopping application, the catalog and administration screens (program units) would have been independently unit tested and the test results would be verified through the database. In system testing, the tester will mimic as an end user and hence checks the application through its output.
There are occasions, where some/many of the integration and unit test cases are repeated in system testing also; especially when the units are tested with test stubs before and not actually tested with other real modules, during system testing those cases will be performed again with real modules/data in

Integration Test cases !!!

2007-10-22T15:13:00.002+05:30

Before designing the integration test cases the testers should go through the Integration test plan. It will give complete idea of how to write integration test cases. The main aim of integration test cases is that it tests the multiple modules together. By executing these test cases the user can find out the errors in the interfaces between the Modules.
For example, in online shopping, there will be Catalog and Administration module. In catalog section the customer can track the list of products and can buy the products online. In administration module the admin can enter the product name and information related to it.

Integration Test cases

The tester has to execute above unit and Integration test cases after coding. And He/She has to fill the actual results and Pass/fail columns. If the test cases fail then defect report should be prepared.

Unit Test Cases !!!

2007-10-16T16:48:00.001+05:30

These are very specific to a particular unit. The basic functionality of the unit is to be understood based on the requirements and the design documents. Generally, Design document will provide a lot of information about the functionality of a unit. The Design document has to be referred before UTC is written, because it provides the actual functionality of how the system must behave, for given inputs.
For example, In the Online shopping application, If the user enters valid Email id and Username values, let us assume that Design document says, that the system must display a product details and should insert the Email id and Username in database table. If user enters invalid values the system will display appropriate error message and will not store it in database.

Login Screen
Test Conditions for the fields in the Login screen

Email-It should be in this format (For Eg clickme@yahoo.com).
Username – It should accept only alphabets not greater than 6.Numerics and special type of characters are not allowed.

Test Prerequisite: The user should have access to Customer Login screen form screen

Negative Test Case:
*********************

Positive Test Case:
********************

Test Case Format !!!

2007-10-13T12:50:00.001+05:30

The test cases will have a generic format as below.

Test case ID - The test case id must be unique across the application
Test case description - The test case description must be very brief.
Test prerequisite - The test pre-requisite clearly describes what should be present in the system, before the test can be executes.
Test Inputs - The test input is nothing but the test data that is prepared to be fed to the system.
Test steps - The test steps are the step-by-step instructions on how to carry out the test.

Expected Results - The expected results are the ones that say what the system must give as output or how the system must react based on the test steps.
Actual Results – The actual results are the ones that say outputs of the action for the given inputs or how the system reacts for the given inputs.
Pass/Fail - If the Expected and Actual results are same then test is Pass otherwise Fail.

The test cases are classified into positive and negative test cases. Positive test cases are designed to prove that the system accepts the valid inputs and then process them correctly. Suitable techniques to design the positive test cases are Specification derived tests, Equivalence partitioning and State-transition testing. The negative test cases are designed to prove that the system rejects invalid inputs and does not process them. Suitable techniques to design the negative test cases are Error guessing, Boundary value analysis, internal boundary value testing and State-transition testing. The test cases details must be very clearly specified, so that a new person can go through the test cases step and step and is able to execute it. The test cases will be explained with specific examples in the following section.

Test Case !!!

2007-10-11T18:53:00.001+05:30

“A test case specifies the pretest state of the IUT (Integration Unit Testing) and its environment, the test inputs or conditions, and the expected result. The expected result specifies what the IUT should produce from the test inputs. This specification includes messages generated by the IUT, exceptions, returned values, and resultant state of the IUT and its environment. Test cases may also specify initial and resulting conditions for other objects that constitute the IUT and its environment.”

In software engineering, the most common definition of a test case is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. It may take many test cases to determine that a requirement is fully satisfied. In order to fully test that all the requirements of an application are met, there must be at least one test case for each requirement unless a requirement has sub requirements.

* Test cases help us discover information. Different types of tests are more effective for different classes of information.
* Test cases can be “good” in a variety of ways. No test case will be good in all of them.
* People tend to create test cases according to certain testing styles, such as domain testing or risk-based testing. Good domain tests are different from good risk-based tests.

Effective Bug Reporting !!!

2007-10-05T20:45:00.001+05:30

Keep bug reporting simple:
Don't make bug reporting complicated by requiring entry of more data than is really necessary

Describe how to reproduce bugs:
A bug report should include a step-by-step description on how to reproduce the bug (or replication information)

Record how bugs are detected:
Report all the facts-Allow them to reproduce the bug

Write bug reports immediately :
the longer you wait between finding the problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten.

Writing a one-line report summary :
Writing the Bug's report title is an art. You must master it (the same should be related to bug you are reporting)

Don't use the same summary:
For two different reports, even if they are similar don’t use similar summary

Consult your peer member:
Before writing a bug consult your peer team member (if the same has already been reported).

Bug Life Cycle - Resolutions !!!

2007-10-04T18:04:00.001+05:30

Fixed - The Bug has been fixed
Invalid - The problem described is not a bug
WontFix - The bug will never be fixed
Later - The bug will not fixed in this version

Remind - The bug probably wont be fixed in this version
Duplicate - This is a duplicate of an existing bug
Worksforme - the bug could not be reproduced
Moved - The bug has been moved to another database

Bug Life Cycle !!!

2007-10-01T07:09:00.001+05:30

Life cycle of a BUG:
*********************
As defects move through the system they are given various states. At each state there are a number of possible transitions to other states
The following figure is the life cycle of a bug

NEW Recently added
to ASSIGNED by acceptance
to RESOLVED by analysis and maybe fixing
to NEW by reassignment
ASSIGNED The owner, i.e. the person referenced by Assigned-To has accepted this bug as something they need to work on
to NEW by reassignment
to RESOLVED by analysis and maybe fixing

REOPENED Was once resolved but has been reopened
to NEW by reassignment
to ASSIGNED by acceptance
to RESOLVED by analysis and maybe fixing
RESOLVED Has been resolved (e.g. fixed, deemed unfixable, etc. See "resolution" column)
to REOPENED by reopening
to VERIFIED by verification
to CLOSED by closing
VERIFIED The resolution has been approved by QA
to CLOSED when the product ships
to REOPENED by reopening
CLOSED Over and done with
to REOPENED by reopening

Priority in Bug Tracking !!!

2007-09-28T18:33:00.001+05:30

Priority is used to organize the work.This field describes the importance and order in which a bug should be fixed.

The field only takes meaning when owner of the bug

P1 - Fix in next build
P2 - Fix as soon as possible
P3 - Fix before next release
P4 - Fix if time allows
P5 - Unlikely to be fixed

Default priority for new defects is set at P3.

Severity in Bug tracking !!!

2007-09-27T16:47:00.001+05:30

This field describes the impact of a bug. The submitter of the bug should consider carefully their view of the bug severity, i.e. the impact to them as the end user.

Blocker - Blocks development and/or testing work
Critical - crashes, loss of data, severe memory leak
Major - major loss of function

Normal - Minor loss of function.Unfriendly behavior that is hindering, but workable, for the user or service
Minor - Minor loss of function.Unfriendly behavior that is merely annoying to the user
Trivial - cosmetic problem like misspelled words or misaligned text
Enhancement - Request for enhancement

Note : The default severity is Normal.

Bugs in software testing !!!

2007-09-22T13:49:00.001+05:30

Bug:
An Error found in the development environment before the product is shipped to the customer.

Bug Reporting :
A person who uses a product Reports a Bug/Malfunctioning ..etc to a person who developed the product

Bug Tracking :
Managing and Reviewing a bug and its status

Bug Tracking System :
This is a system designed especially to manage software problems, enhancement, change request during software development life cycle.

Application Binary Interface !!!

2007-09-20T19:24:00.001+05:30

A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.

It describes the low-level interface between an application program and the operating system, between an application and its libraries, or between component parts of the application.

Process in Agile Testing !!!

2007-09-19T17:15:00.001+05:30

Process in Agile testing:
***************************
1) Conversational test creation
2) Coaching tests
3) Providing test interfaces
4) Exploratory learning

Conversational test creation
*****************************
* Who should write tests
* Defining test is a key activity that should include programmers and customer representatives.
* Don't do it alone.

Cooaching Tests
*******************
* A way of thinking about acceptance tests
* turn user stories in to tests
* Tests provide
1) Goals and guidance
2) Instant feedback
3) progress measurement
* Tests are specified in a format:
1) That is clear enough that users/customers can understand.
2) That is specific enough that it can be executed.
* specification by example

Providing test interfaces
**************************
Developer are responsible for providing the fixtures that automate coaching tests.
2) In most cases XP teams are adding test interfaces to their products,rather than using external test tools.

Test Interaction model
**************************

Exploratory learning
************************
Plan to explore the product with each iteration
Look for bugs , missing features and opportunities for improvement.
we don't understand software until we have used it.

Agile testing !!!

2007-09-18T17:14:00.001+05:30

Agile Testing
***************

* Testing practice that follows the agile manifesto, treating development as the customer of testing
* Testing practice for projects using agile methodologies.

Test case for Database testing !!!

2007-09-17T16:02:00.001+05:30

Steps to writing test cases for database testing
***********************************************
1) Learn the functional requirement of the application (SRS) completely

2) Find out the back end tables used, joined used between the tables, cursors used (if any), triggers used(if any), stored procedures used (if any), input parameter used and output parameters used for developing that requirement.

3) By knowing all these things write the test case with different input values for checking and comparing the actual results with the expected results for the application.

Note : For writing test cases for back end operations, the tester must know the white box testing.

Stages in Database testing !!!

2007-09-15T15:57:00.001+05:30

Stages in Database Testing
****************************
1) Testing the data in the database with respect to frontend transactions.

2) Testing the constraints (primary key,forien key ....).

3) Testing the performance of the procedures.

4) Testing the triggrs (execution of triggers).

4) Testing the transactions (begin,commit,rollback).

Database testing !!!

2007-09-14T15:47:00.001+05:30

Database testing
*****************

This is the process of testing the input data collected by the clients side with the inbuilt database activities. For example, testing that the datas to be save are going correctly to the database or not, correct datas to the database types are entering or not etc.

It includes the following process
******************************
1) Data validity testing using SQL queries
2) Data Integrity testing by knowing the referential integrity and different constraint.
3) Performance related to data base. ( considering the table structure and design )
4) Testing the Procedure,triggers and functions.

Ad hoc Testing !!!

2007-09-13T19:18:00.001+05:30

Ad hoc testing
***************

It is performed without planning and documentation. The tests are intended to be run only once, unless a defect is discovered. Ad hoc testing is a part of exploratory testing, being the least formal of test approach. In this view, ad hoc testing has been criticized because it isn't structured, but this can also be a strength: important things can be found quickly. It is performed with improvisation, the tester seeks to find bugs with any means that seem appropriate. It contrasts to regression testing that looks for a specific issue with detailed reproduction steps, and a clear expected result. Ad hoc testing is most often used as a complement to other types of testing.

Exploratory testing !!!

2007-09-12T19:06:00.001+05:30

Exploratory Testing
*********************
Exploratory testing is an approach in software testing with simultaneous learning, test design and test execution. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run.

Exploratory testing has been performed for a long time, and has similarities to ad hoc testing.

When performing exploratory testing, there are no exact expected results; it is the tester that decides what will be verified, critically investigating the correctness of the result.

Advantage of Exploratory Testing
***********************************
1. The main advantage of exploratory testing is that less preparation is needed, important bugs are found fast, and is more intellectually stimulating than scripted testing.
2. Exploratory testing is extra suitable if requirements and specifications are incomplete, or if there is lack of time. The method can also be used to verify that previous testing has found the most important defects.
3. It is common to perform a combination of exploratory and scripted testing where the choice is based on risk.

Disadvantage of Exploratory Testing
**************************************
The tests can't be reviewed in advance (and by that prevent errors in code and test cases), and that it can be difficult to show exactly which tests have been run.

Tips for Bug Tracking !!!

2007-09-11T18:21:00.001+05:30

1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.

2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed.

3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not repro, duplicate, or by design.

4. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.

5. You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn't have to retest the bug on a version of the software where it wasn't even supposed to be fixed.

6. If you're a programmer, and you're having trouble getting testers to use the bug database, just don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "please put this in the bug database. I can't keep track of emails."

7. If you're a tester, and you're having trouble getting programmers to use the bug database, just don't tell them about bugs - put them in the database and let the database email them.

8. If you're a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they'll get the hint.

9. If you're a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great "unimplemented feature" database, too.

10. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database.

Bug Tracking !!!

2007-09-10T18:56:00.001+05:30

A bug tracking system is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work.

Many bug-tracking systems, such as those used by most open source software projects, allow users to enter bug reports directly. Having a bug tracking system is extremely valuable in software development, and they are used extensively by companies developing software products.

A major component of a bug tracking system is a database that records facts about known bugs.Facts may include the time a bug was reported, its severity, the erroneous program behavior, and details on how to reproduce the bug; as well as the identity of the person who reported it and any programmers who may be working on fixing it.

Typical bug tracking systems support the concept of the life cycle for a bug which is tracked through status assigned to the bug.A bug tracking system should allow administrators to configure permissions based on status, move the bug to another status, or delete the bug.

In a corporate environment, a bug-tracking system may be used to generate reports on the productivity of programmers at fixing bugs. The severity of a bug may not be directly related to the complexity of fixing the bug. There may be different opinions among the managers, architects and the developers about the relative ease of fixing bugs.

Local bug trackers are usually a Computer Program used by a team of application support professionals (often a help desk) to keep track of issues communicated to software developers.

Volume Testing !!!

2007-08-06T06:20:00.001+05:30

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 !!!

2007-08-05T06:19:00.003+05:30

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.

Performance and security !!!

2007-08-04T06:09:00.001+05:30

Performance
**************
* Connection speed:
1. try with connection speed: 14.4, 28.8, ISDN, Cable, DSL, T1, T#.
2. Time out occurrence.

* Load:
Check or measure the following
a. What is the estimated number of users per time period and how will it be divided over the period?
b. Will there be peak loads and how will be the system reacts.
c. Can your site handle a large amount of users requesting contain page?
d. Large amount of data from users.

* Stress:
Check for the following things.
a. Typical areas to test are forms, logins or other information transaction components.
b. Performance of memory, CPU, file handling etc..
c. Error in hardware, software, memory errors (leakage overwrite or printers)

Security
*********
• Valid and Invalid login.
• Limit defined for the number of tries.
• Verify log files are maintained to store the information for traceability.
• Verify encryption is done correctly if SSL is used.
• No access to edit scripts on the server without authorize

Security Testing
******************
* If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorized internal or external access.

Client side compatibility !!!

2007-08-03T06:07:00.001+05:30

Client side compatibility:
***************************
* platform
Check for the responsibility of
a. Windows (95, 98, 2000 etc)
b. Unix (different sets)
c. Maintosh (if applicable)
d. Linux
e. Solaris

* Browsers
Check for various combinations
a. Internet explorer (3.x, 4.x, 5.x)
b. Netscape navigator (3.x, 4.x, 5.x)
c. AOL
d. Browser settings (security settings, graphics, java etc)
e. Frames and cascade style sheets
f. Applets, ActiveX controls, DHTML, Client side scripting, HTML specification.

* Printing
Despite the paperless society the web was to introduce, printing is done more than ever considerations on.
a. Text and image alignment.
b. Colors of text, foreground and background
c. Scalability to fit paper size
d. Tables and borders.

Server side Interfaces !!!

2007-08-02T06:06:00.001+05:30

Server side interfaces:
************************
Server interface:
• verify that the communication is done correctly web server, application server, and database server and vice versa
• Compatibility OS server software, hardware, network connections.

• Database compatibility.

Functionality Testing !!!

2007-08-01T06:04:00.001+05:30

Functionality testing:
************************
It is classified as Links, Forms, Cookies, Database

Links
Internal link, external link, mailto link, Broken link

Forms
* Field level validation
Check for lenth, special characters, numerical charts etc

* Final checks
Checking whether the Create, modify, view and delete are working or not.
* Error handling
Check whether appropriate error messages to be displayed.
* Optional and mandatory fields
Mandatory Field should not be left blank and optional field should allow the user to skip the field.

Cookies
Check whether cookies are enable or not. Websites use cookies to simulate a continuous connection to that site.

Database
Should not contain wrong or missing data.

Web Testing !!!

2007-07-30T15:19:00.001+05:30

Web Testing:

Testing a web application such as functionality, usability, server side interface, client side compatibility, security.

There are generally three layers in web application. They are
1. Presentation layer
2. Business layer
3. Database

Testing Software Metrics !!!

2007-07-29T15:48:00.001+05:30

Testing metrics:
*****************
* User participation:
To find the involvement of the tester = User participation / (test time vs total time)

* Path tested:
Extent of testing = No. of path tested / Total no. of paths.

* Acceptance criteria tested
Extent of testing = Acceptance criteria vs. Total acceptance criteria.

* Test Cost:
Resources consumed in testing = Total cost vs. Total system cost.
This metric identifies the amount of resources used in the testing process.

* Cost to locate defect:
Resources consumed in the testing = Total cost / No. of defects located in testing.
This metric shows the cost to locate a defect.

* Detected production defect:
Effectiveness of testing = No. of defects detected in production / Application system size.

* Test automation
Effectiveness of testing = cost of manual test / test cost.

Types of Software Metrics !!!

2007-07-29T15:46:00.001+05:30

Types
******
Process metrics and Product metrics

Process metric:
A metric used to measure the characteristic of the methods techniques and tools employed in developing, maintaining and implementing the software system.
Product metric:
A metric used to measure the characteristic of the documentation and code.

Software Metrics !!!

2007-07-29T15:04:00.001+05:30

Software Metrics
*******************

A metric quantifies a characteristic of a process or product. Metrics can be directly observable quantities or can be derived from one or more directly observable quantities. Examples of raw metrics include the number of source lines of code, number of documentation pages, number of staff-hours, number of tests, number of requirements, etc. Examples of derived metrics include source lines of code per staff-hour, defects per thousand lines of code, or a cost performance index.

Software metrics are numerical data related to software development. Metrics strongly support software project management activities. They relate to the four functions of management as follows:

1. Planning - Metrics serve as a basis of cost estimating, training planning, resource planning, scheduling, and budgeting.

2. Organizing - Size and schedule metrics influence a project's organization.

3. Controlling - Metrics are used to status and track software development activities for compliance to plans.

4. Improving - Metrics are used as a tool for process improvement and to identify where improvement efforts should be concentrated and measure the effects of process improvement efforts.

The term indicator is used to denote a representation of metric data that provides insight into an ongoing software development project or process improvement activity. Indicators are metrics in a form suitable for assessing project behavior or process improvement. For example, an indicator may be the behavior of a metric over time or the ratio of two metrics. Indicators may include the comparison of actual values versus the plan, project stability metrics, or quality metrics. Examples of indicators used on a project include actual versus planned task completions, actual versus planned staffing, number of trouble reports written and resolved over time, and number of requirements changes over time.

Indicators are used in conjunction with one another to provide a more complete picture of project or organization behavior. For example, a progress indicator is related to requirements and size indicators. All three indicators should be used and interpreted together.

Test Plan !!!

2007-07-28T15:54:00.001+05:30

The Following are the test plan outlines:

1. BACKGROUND
2. INTRODUCTION
3. ASSUMPTIONS
4. TEST ITEMS
List each of the items (programs) to be tested.
5. FEATURES TO BE TESTED
List each of the features (functions or requirements) which will be tested or demonstrated by the test.
6. FEATURES NOT TO BE TESTED
Explicitly lists each feature, function, or requirement which won't be tested and why not.
7. APPROACH
Describe the data flows and test philosophy.
Simulation or Live execution, Etc.
8. ITEM PASS/FAIL CRITERIA Blanket statement
Itemized list of expected output and tolerances
9. SUSPENSION/RESUMPTION CRITERIA
Must the test run from start to completion?
Under what circumstances may it be resumed in the middle?
Establish check-points in long tests.
10.TEST DELIVERABLE
What, besides software, will be delivered?

Test report
Test software
11. TESTING TASKS Functional tasks (e.g., equipment set up)
Administrative tasks
12. ENVIRONMENTAL NEEDS
Security clearance
Office space & equipment
Hardware/software requirements
13. RESPONSIBILITIES
Who does the tasks in Section 10?
What does the user do?
14. STAFFING & TRAINING
15. SCHEDULE
16. RESOURCES
17. RISKS & CONTINGENCIES
18. APPROVALS

Test Plan Preparation !!!

2007-07-28T14:34:00.001+05:30

The following concepts are present in the Test plan preparation:

Test Objective
A Test Objective is simply a testing "goal". It is a statement of what a tester is expected to perform during testing activity.

Test Strategy
It contains the following datas
1.Technology that are going to be used during the testing.
2.What types of tests must be conducted.
3.what stage of testing are required. (eg. Unit Testing)

Test Risk analysis
A risk is a condition that can result in a loss. The risk that may occur during analysis of the testing. The probability that the negative event will occur.

Risk identify and mitigation
This plan contains the unavailability of resources (eg. hardware and software ). And what are the ways to overcome.

Scheduled and resources

Roles and Responsibilities
Test Manager - Prepares the test plan
Test Leader - Review the test case, take decision.
Test engineer - Prepare the test cases.

Communication approach
The communication during the project will be informed through this communication approach.

Test Environment
What are the environment that the person needed to develop and testing.
(eg. Tools that are needed and Hardware & software requirements)

Automated Test tools:
Identify which tool is used for each individual test and should know the test level criteria.

Testing Life Cycle (TLC) !!!

2007-07-27T14:15:00.001+05:30

Testing Life Cycle:

Steps involved in testing an application:

Test Plan preparation
It is a document that defines over all testing approach.

Test case design
Documents that defines what is selected to test and describes its expected results

Test Execution
Executing the test cases.

Test Log Preaparation
Pass and fail information will be stored in test log.

Defect cracking
All the fail items will come under defect tracking.

Test reports
Reports are generated during the final test summary report.

Verification and Validation !!!

2007-07-27T12:27:00.001+05:30

Verification:
It is the process of confirming that software meets its specifications.It is used to identify the defects in the product early in the life cycle.

Classification:
1. Based on time
2.Based on classes.

1. Based on Time:
• In process review
* During the specific period of the development cycle. Ex : Design phase
* Used to find the defects in the work product and the work process.
* Catches defects early where they are less costly to correct.
* It may occur at any time.

• Phase end/ decision making review/ milestone review
* Review of product or process near the completion of each phase of development.
* Decisions for proceeding with development or based on the cost, schedule, risk, progress, readiness for the next phase.
* Also referred to a milestone review

• Post implementation/ post mortem review
* Review or evaluation of the product that includes planned Vs actual development results and compliance with requirements.
* Used for process improvement of software development.
* Can be held upto 3 to 6 months after implementation.

2. Based on classes:

• Informal (peer reviews)
* Generally one to one meeting.
* No agenda
* Results are not formally reported
* Occur as needed throughout each phase.

• Semiformal
* Facilitated by author(tester).
* Reports are distributed to the participants.
* Possible solutions for defects not discussed.
* Occurs one or more times during a phase.

• Formal

* Facilated by moderator
* Assisted by recorder
* Meeting are planned in advance.
* Directly dependent on the preparation of participants.
* Held at any time.

Validation:
Its is the process confirming that it meets the users requirement.

Thread Testing !!!

2007-07-25T16:10:00.001+05:30

* Thread Testing

1. Its a technique that often used during in the early integration testing.
2. Demonstrates key functional capabilities by testing a string of units that accomplishes a specific function in the application.

Incremental Testing !!!

2007-07-24T16:11:00.001+05:30

* Incremental Testing
A disciple method of testing the interfaces between unit tested programs as well as between system components.

Types:
1. Top down Testing
2. Bottom up testing

1. Top Down
Begin testing from the top of the module hieracrchy and works down to the bottom using interior stubs to stimulate the lower interfacing modules or program.

It tests the program of LLD. If LLD is not ready means it uses a dummy module called STUB.
LLD - Low Level Design

2. Bottom up
* Begin testing from the bottom of the hierarchy and works up to the top.
* It requires the development of driver module which provide the test input call the module or program being testing and display the test output.

It tests the program of HLD. If it is not ready means it uses a dummy module called DRIVER.
HLD - High Level Design

If both dummy variables STUB and DRIVER are presented in the testing process then it is known as Sandwich Incremental Testing.

Black Box Testing !!!

2007-07-23T16:18:00.001+05:30

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

Tools for Black box testing !!!

2007-07-23T14:59:00.001+05:30

Many tool vendors have been producing tools for automated black box and automated white box testing for several years. The basic functional or regression testing tools capture the results of black box tests in a script format. Once captured, these scripts can be executed against future builds of an application to verify that new functionality hasn't disabled previous functionality.

Automation Testing tools used for Black box testing such as

* Rational Robot
* Silk Test
* OpenSTA
* QTP
* WinRunner
* LoadRunner

White Box Testing !!!

2007-07-22T16:22:00.001+05:30

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.

Tools for white box testing !!!

2007-07-22T14:51:00.001+05:30

Few Test automation tool vendors offer white box testing tools which:

1) Provide run-time error and memory leak detection;
2) Record the exact amount of time the application spends in any given block of code for the purpose of finding inefficient code bottlenecks; and
3) Pinpoint areas of the application that have and have not been executed.

Testing Techniques !!!

2007-07-21T19:14:00.001+05:30

Testing Techniques

There are four types of testing techniques. They are
• White Box Testing
• Black Box Testing
• Incremental Testing
• Thread Testing

Comparision between Testing Levels and techniques:

V Model !!!

2007-07-20T19:37:00.000+05:30

CHAPTER 9

Diagramatic Representation of V Model:

In Brief:

There are two phases in the V model development. They are
1. Verification
2. Validation.

Verification Phases

Requirements analysis

In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface,
performance, data, security requirements etc as expected by the user.The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests(UAT) are designed in this phase.

System Design

System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements is not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold examples business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

Architecture Design

This phase can also be called as high-level design (HLD). The baseline in selecting the architecture is that it should realize all the requirements within the given time, cost and resources. Software architecture is commonly represented as two-tier, three-tier or multi-tier models which typically comprises of the database layer, user-interface layer and the application layer. The modules and components representing each layer, their inter-relationships, subsystems, operating environment and interfaces are laid out in detail.The output of this phase is the high-level design document which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried
out in this phase.

Module Design

This phase can also be called as low-level design (LLD). The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error
message listings- complete input and outputs for a module. The unit test design is developed in this stage.

Coding

It is the process of writing, testing, and maintaining the source code of computer programs. The source code is written in a programming language.

Validation Phases

Unit Testing

In the V-model of software development, unit testing implies the first stage of dynamic testing process.It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software testers, software developers or both.

Integration Testing

In integration testing the separate modules will be tested together expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors. It is done using the integration test design prepared during the architecture design phase. Integration testing is generally conducted by software testers.

System Testing

System testing will compare the system specifications against the actual system. The system test design derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. once all the modules are integrated several erros may rise.Testing done at this stage is called system test.

User Acceptance Testing

Acceptance Testing checks the system against the requirements of the user. It uses black box testing using real data, real people and real documents to ensure ease of use and functionality of systems. Users who understand the business functions run the tests as given in the acceptance test plans, including installation and Online help. Hardcopies of user documentation are also being reviewed for usability and accuracy. The testers formally document the results of each test, and provide error reports, correction requests to the developers.

User Acceptance Testing !!!

2007-07-19T16:38:00.001+05:30

* User Acceptance Testing (UAT)

A range of simple buildings should be simulated with the building simulation program undergoing testing automatically prior to all other tests. These should be considered an acceptance test intended to weed out unstable versions of the software that would not be fruitful to use for further debugging. Acceptance tests are often automated and may be provided to the programmers as a way to reduce the number of versions submitted for testing.

1. Building the confidence of the client and the users is the role of acceptance test
Phase.
2. It is depend on the Business Scenario.

System Testing !!!

2007-07-18T16:36:00.001+05:30

* System Testing: (For SRS)

* A system is the big component.
* System testing is aimed at revealing bugs that cannot be attributed to a component as such, to inconsistencies between components or planned interactions between components.
* Concern: issues, behaviors that can only be exposed by testing the entire integrated system (e.g., performance, security, recovery).

1. Testing the entire application.
2. It’s a Black box testing.

SRS - Software Requirement Specifications

Integration testing !!!

2007-07-17T16:34:00.001+05:30

Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure that has been dictated by design.

Usually, the following methods of Integration testing are followed:
1. Top-down Integration approach.
2. Bottom-up Integration approach.

1. Top-Down Integration
Top-down integration testing is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module. Modules subordinate to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.

1. The Integration process is performed in a series of five steps:
2. The main control module is used as a test driver and stubs are substituted for all components directly subordinate to the main control module.
3. Depending on the integration approach selected subordinate stubs are replaced one at a time with actual components.
4. Tests are conducted as each component is integrated.
5. On completion of each set of tests, stub is replaced with the real component.
6. Regression testing may be conducted to ensure that new errors have not been introduced.

2.Bottom-Up Integration
Bottom-up integration testing begins construction and testing with atomic modules (i.e. components at the lowest levels in the program structure). Because components are integrated from the bottom up, processing required for components subordinate to a given level is always available and the need for stubs is eliminated.

1. A Bottom-up integration strategy may be implemented with the following steps:
2. Low level components are combined into clusters that perform a specific software sub function.
3. A driver is written to coordinate test case input and output.
4. The cluster is tested.
Drivers are removed and clusters are combined moving upward in the program structure.

Unit Testing !!!

2007-07-16T16:32:00.001+05:30

This is a typical scenario of Manual Unit Testing activity-
A Unit is allocated to a Programmer for programming. Programmer has to use ‘Functional Specifications’ document as input for his work. Programmer prepares ‘Program Specifications’ for his Unit from the Functional Specifications. Program Specifications describe the programming approach, coding tips for the Unit’s coding.
Using these ‘Program specifications’ as input, Programmer prepares ‘Unit Test Cases’ document for that particular Unit. A ‘Unit Test Cases Checklist’ may be used to check the completeness of Unit Test Cases document.
‘Program Specifications’ and ‘Unit Test Cases’ are reviewed and approved by Quality Assurance Analyst or by peer programmer.

The programmer implements some functionality for the system to be developed. The same is tested by referring the unit test cases. While testing that functionality if any defects have been found, they are recorded using the defect logging tool whichever is applicable. The programmer fixes the bugs found and tests the same for any errors.

Stubs and Drivers

A software application is made up of a number of ‘Units’, where output of one ‘Unit’ goes as an ‘Input’ of another Unit. e.g. A ‘Sales Order Printing’ program takes a ‘Sales Order’ as an input, which is actually an output of ‘Sales Order Creation’ program.
Due to such interfaces, independent testing of a Unit becomes impossible. But that is what we want to do; we want to test a Unit in isolation! So here we use ‘Stub’ and ‘Driver.

A ‘Driver’ is a piece of software that drives (invokes) the Unit being tested. A driver creates necessary ‘Inputs’ required for the Unit and then invokes the Unit.

A Unit may reference another Unit in its logic. A ‘Stub’ takes place of such subordinate unit during the Unit Testing. A ‘Stub’ is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual unit. A Stub works as a ‘Stand-in’ for the subordinate unit and provides the minimum required behavior for that unit.
Programmer needs to create such ‘Drivers’ and ‘Stubs’ for carrying out Unit Testing.
Both the Driver and the Stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the Unit in question.

Example - For Unit Testing of ‘Sales Order Printing’ program, a ‘Driver’ program will have the code which will create Sales Order records using hard coded data and then call ‘Sales Order Printing’ program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a ‘Stub’, which will simply return fix discount data.

Testing Levels !!!

2007-07-15T18:35:00.001+05:30

Testing Levels:

• Unit Testing.
• Integration Testing
• System Testing
• User Acceptance Testing

Management in Testing !!!

2007-07-14T18:07:00.001+05:30

There are various Management types in testing. They are

Project Management
**********************

It is nothing but organizing, planning, scheduling, costing, monitoring review, report writing and presentation of the software project.
• Manual – Contains records of Name, requirements, schedule, cost etc.
• Automation – MPP – Microsoft Project Planner.

Requirement Management
****************************

It is managing changes in evolving software in a cost effective manner.

Manual tools

SRS HLD LLD Code Testing
S1 HL1 LL1 C1
S2 * * C2 (if changes)

SRS - Software Requirements Specification
HLD - High Level Design
LLD - Low Level Design

Automation tools

Requistic pro – Rational operation product
TBI Caliber – Technology Builder Incorporation - Organis
QSS Doors – Quality System Software - Actions

Configuration Management
*****************************
CM is standards and procedures for managing changes in an evolving software product.
• Version control
• Changes in Progress.

Manual Tools

CR ------------> CCB ---------> CI =======>

CR – Change request CCB – Change Control Board CI – Change Information

CM System

Version 1.0

Version 2.0

Shared

Version 3.0

Version 4.0

Draft

Managed File

Automation

VSS – Visual Source Safe (Microsoft Product)
RCC – Rational Clear Case (Rational corporation product)
CVS – Concurrent Vision System.

SDLC (Sotware Development Life Cycle) !!!

2007-07-14T10:41:00.000+05:30

SDLC:
********
Software Development Life Cycle

SDLC Process Diagram
*************************

SDLC Flow chart
******************

Steps involving in SDLC
************************

* Feasibility Study
Economical feasibility
Technical feasibility

*Planning
*Requirements Analysis

* Design
High Level design
Low Level design

*Development (Coding/Implementation)
*Testing
*Unit testing

*Integration testing
1 Top-down testing
2 Bottom-up testing
3 Regression testing
4 Smoke testing

* Validation testing
1 Alpha testing
2 Beta testing

* System testing
1 Recovery testing
2 Security testing
3 Stress testing
4 Performance testing

*Installation (Release/Delivery of product)
*Maintenance
1 Corrective maintenance - To fix errors
2 Adaptive maintenance - To add new capability and enhancements
3 Perfective maintenance - To improve efficiency

Steps in Brief
*****************

* Project planning, feasibility study:
Establishes a high-level view of the intended project and determines its goals.

* Systems analysis, requirements definition:
Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

* Systems design:
Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.

* Implementation: The real code is written here.

* Integration and testing:
Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

* Acceptance, installation, deployment:
The final stage of initial development, where the software is put into production and runs actual business.

* Maintenance:
What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

SDLC Models:
1. Waterfall models.
2. Spiral models.
3. Iterative models.
4. JDA ( Joint Development Application )
5. RDA ( Rapid Development Application )

Standard Certifications !!!

2007-07-13T02:08:00.001+05:30

These are the standard certifications which is given to the software companies

ISO – International Organizations for standards.
SEI – CMM – Software Engineering Institute – Capability Maturity Model.

CMM level 5 – Optimizing.
CMM level 4 – Managed – (no defects)
CMM level 3 – Defined – (More than two applications)
CMM level 2 – Repeatable – (Two applications)
CMM level 1 – Initial – (beginning)
these levels are classified by considering the Kpa values.
Kpa - Key process area

PCMM – People Capability Maturity Model.
SIX SIGMA

Software process !!!

2007-07-12T10:32:00.001+05:30

Process:

A particular method of doing something generally involved in number of steps and operations.

Software Process:

The process that deals with technical and management issues of software development is called software process.

Steps involved in software process:

PLAN – defines the objective and determines the strategy and methods required

to achieve that objective.

DO – Executing the plan. Create the conditions and perform the necessity

training to execute the plan.

CHECK – Check the results. Check to determine whether the work is processing

according to the plan and whether the results are obtain.

ACTION – Take the necessary action if your check reveals that the work is not

being perform according the plan or that results are not what was

expected device measures for appropriate action.

Quality Control !!!

2007-07-10T16:53:00.001+05:30

Quality Control

It is the process by which product quality is combined with applicable standards and the action taken when non conformance is defected. It is product oriented and defect detection based.

Verifies the resources.
Tester is the participant.
Defect detection based.
Product Oriented.

Quality Assurance !!!

2007-07-09T16:51:00.001+05:30

Quality Assurance:

It is a planned and systematic activity necessity to provide adequatic confidence that products and services will conform to specified requirements and meet user need. It is a process oriented and defect prevention based.

Building confidence in customers.
Gather the customers requirements.
It involves with testers and developers.
Defect prevention team will be there. Process Oriented deal.

Quality !!!

2007-07-09T10:25:00.001+05:30

Quality:

Quality is defined as meeting the customer’s requirements for the first time and every time. Quality is much more than absence of defects which allows as to meet customer’s expectations

Attributes of Quality:

Zero defect.
Effectiveness – ( Performance and cost )
Reliability – ( Build confidence in customers)
Durability.
Usability.

How to Achieve Quality?
By Quality Assurance and Quality control.

Factors influencing the testing project:

Quality ( always increase )
Schedule ( increase or decrease ) – ( time spent for prevention and detecting the defects)
Cost ( increase or decrease ) – ( prevention cost, appraisal cost and failure cost)

Recovery Testing !!!

2007-07-07T17:01:00.001+05:30

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 !!!

2007-07-07T17:00:00.001+05:30

Configuration Testing

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

Benefits Realization Testing !!!

2007-07-07T16:59:00.001+05:30

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 !!!

2007-07-07T16:57:00.001+05:30

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 !!!

2007-07-06T17:03:00.001+05:30

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 !!!

2007-07-06T17:02:00.002+05:30

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 behaviours of online users, enabling them to complete their tasks efficiently, effectively, and satisfactorily.

Beta Testing !!!

2007-07-05T17:06:00.001+05:30

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

Alpha Testing !!!

2007-07-05T17:05:00.001+05:30

Testing of an application when development is nearing completion minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

Aim
* is to identify any serious errors
* to judge if the indented functionalities are implemented
* to provide to the customer the feel of the software

A through understanding of the product is done now. During this phase, the test plan and test cases for the beta phase (the next stage) is created. The errors reported are documented internally for the testers and developers reference. No issues are usually reported and recorded in any of the defect management/bug trackers

Role of test lead
1. Understand the system requirements completely.
2. Initiate the preparation of test plan for the beta phase.

Role of the tester
1. To provide input while there is still time to make significant changes as the design evolves.
2. Report errors to developers

Smoke Testing !!!

2007-07-04T17:13:00.001+05:30

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 !!!

2007-07-04T17:12:00.001+05:30

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 !!!

2007-07-04T17:11:00.001+05:30

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 !!!

2007-07-04T17:10:00.001+05:30

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 !!!

2007-07-04T17:07:00.001+05:30

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 !!!

2007-07-03T17:16:00.001+05:30

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 !!!

2007-07-03T17:14:00.001+05:30

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 !!!

2007-07-02T17:32:00.001+05:30

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 !!!

2007-07-02T17:27:00.001+05:30

Regression Testing !!!

2007-07-02T17:24:00.001+05:30

To ensure that the code changes have not had an adverse affect to the other modules or on existing functions.

It is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists.

Regression testing as the name suggests is used to test / check the effect of changes made in the code.

Regression Testing is retesting unchanged segments of application. It involves rerunning tests that have been previously executed to ensure that the same results can be achieved currently as were achieved when the segment was last tested.
The selective retesting of a software system that has been modified to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of the reparations and that newly added features have not created problems with previous versions of the software. Also referred to as verification testing, regression 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.

Purpose of Regression Testing:
* Rerunning of previously conducted tests
* Reviewing previously prepared manual procedures
* Comparing the current test results with the previously executed test results