Software Testing

Posted Date: 07 Apr 2008 Resource Type: Articles/Knowledge Sharing Category: Computer & Technology

Posted By: CONFIDENCE IS THE COMPANION OF SUCCESS Member Level: Diamond
Rating:

Points: 3

Testing is a process used to help identify the correctness, completeness and quality of developed computer software. With that in mind, testing can never completely establish the correctness of computer software.

There are many approaches to software testing, but effective testing of complex products is essentially a process of investigation, not merely a matter of creating and following rote procedure. One definition of testing is "the process of questioning a product in order to evaluate it", where the "questions" are things the tester tries to do with the product, and the product answers with its behavior in reaction to the probing of the tester. Although most of the intellectual processes of testing are nearly identical to that of review or inspection, the word testing is connoted to mean the dynamic analysis of the product—putting the product through its paces.

The quality of the application can and normally does vary widely from system to system but some of the common quality attributes include reliability, stability, portability, maintainability and usability. Refer to the ISO standard ISO 9126 for a more complete list of attributes and criteria.

Testing helps is Verifying and Validating if the Software is working as it is intended to be working. Thins involves using Static and Dynamic methodologies to Test the application.

Because of the fallibility of its human designers and its own abstract, complex nature, software development must be accompanied by quality assurance activities. It is not unusual for developers to spend 40% of the total project time on testing. For life-critical software (e.g. flight control, reactor monitoring), testing can cost 3 to 5 times as much as all other activities combined. The destructive nature of testing requires that the developer discard preconceived notions of the correctness of his/her developed software.
Software Testing Fundamentals

Testing objectives include

1. Testing is a process of executing a program with the intent of finding an error.
2. A good test case is one that has a high probability of finding an as yet undiscovered error.
3. A successful test is one that uncovers an as yet undiscovered error.

Testing should systematically uncover different classes of errors in a minimum amount of time and with a minimum amount of effort. A secondary benefit of testing is that it demonstrates that the software appears to be working as stated in the specifications. The data collected through testing can also provide an indication of the software's reliability and quality. But, testing cannot show the absence of defect -- it can only show that software defects are present.

When Testing should start:

Testing early in the life cycle reduces the errors. Test deliverables are associated with every phase of development. The goal of Software Tester is to find bugs, find them as early as possible, and make them sure they are fixed.

The number one cause of Software bugs is the Specification. There are several reasons specifications are the largest bug producer.

In many instances a Spec simply isn’t written. Other reasons may be that the spec isn’t thorough enough, its constantly changing, or it’s not communicated well to the entire team. Planning software is vitally important. If it’s not done correctly bugs will be created.

The next largest source of bugs is the Design, That’s where the programmers lay the plan for their Software. Compare it to an architect creating the blue print for the building, Bugs occur here for the same reason they occur in the specification. It’s rushed, changed, or not well communicated.

Coding errors may be more familiar to you if you are a programmer. Typically these can be traced to the Software complexity, poor documentation, schedule pressure or just plain dump mistakes. It’s important to note that many bugs that appear on the surface to be programming errors can really be traced to specification. It’s quite common to hear a programmer say, “ oh, so that’s what its supposed to do. If someone had told me that I wouldn’t have written the code that way.”

The other category is the catch-all for what is left. Some bugs can blamed for false positives, conditions that were thought to be bugs but really weren’t. There may be duplicate bugs, multiple ones that resulted from the square root cause. Some bugs can be traced to Testing errors.

Costs: The costs re logarithmic- that is, they increase tenfold as time increases. A bug found and fixed during the early stages when the specification is being written might cost next to nothing, or 10 cents in our example. The same bug, if not found until the software is coded and tested, might cost $1 to $10. If a customer finds it, the cost would easily top $100.

When to Stop Testing

This can be difficult to determine. Many modern software applications are so complex, and run in such as interdependent environment, that complete testing can never be done. "When to stop testing" is one of the most difficult questions to a test engineer. Common factors in deciding when to stop are:

* Deadlines ( release deadlines,testing deadlines.)
* Test cases completed with certain percentages passed
* Test budget depleted
* Coverage of code/functionality/requirements reaches a specified point
* The rate at which Bugs can be found is too small
* Beta or Alpha Testing period ends
* 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.
Test Strategy:

How we plan to cover the product so as to develop an adequate assessment of quality.

A good test strategy is:

Specific
Practical
Justified

The purpose of a test strategy is to clarify the major tasks and challenges of the test project.

Test Approach and Test Architecture are other terms commonly used to describe what I’m calling test strategy.

Example of a poorly stated (and probably poorly conceived) test strategy:

"We will use black box testing, cause-effect graphing, boundary testing, and white box testing to test this product against its specification."
Test Strategy: Type of Project, Type of Software, when Testing will occur, Critical Success factors, Tradeoffs

Test Plan - Why

* Identify Risks and Assumptions up front to reduce surprises later.
* Communicate objectives to all team members.
* Foundation for Test Spec, Test Cases, and ultimately the Bugs we find.
Failing to plan = planning to fail.

Test Plan - What

* Derived from Test Approach, Requirements, Project Plan, Functional Spec., and Design Spec.
* Details out project-specific Test Approach.
* Lists general (high level) Test Case areas.
* Include testing Risk Assessment.
* Include preliminary Test Schedule
* Lists Resource requirements.

Test Plan

The test strategy identifies multiple test levels, which are going to be performed for the project. Activities at each level must be planned well in advance and it has to be formally documented. Based on the individual plans only, the individual test levels are carried out.

Entry means the entry point to that phase. For example, for unit testing, the coding must be complete and then only one can start unit testing. Task is the activity that is performed. Validation is the way in which the progress and correctness and compliance are verified for that phase. Exit tells the completion criteria of that phase, after the validation is done. For example, the exit criterion for unit testing is all unit test cases must pass.
Unit Test Plan {UTP}

The unit test plan is the overall plan to carry out the unit test activities. The lead tester prepares it and it will be distributed to the individual testers, which contains the following sections.
What is to be tested?

The unit test plan must clearly specify the scope of unit testing. In this, normally the basic input/output of the units along with their basic functionality will be tested. In this case mostly the input units will be tested for the format, alignment, accuracy and the totals. The UTP will clearly give the rules of what data types are present in the system, their format and their boundary conditions. This list may not be exhaustive; but it is better to have a complete list of these details.
Sequence of Testing

The sequences of test activities that are to be carried out in this phase are to be listed in this section. This includes, whether to execute positive test cases first or negative test cases first, to execute test cases based on the priority, to execute test cases based on test groups etc. Positive test cases prove that the system performs what is supposed to do; negative test cases prove that the system does not perform what is not supposed to do. Testing the screens, files, database etc., are to be given in proper sequence.
Basic Functionality of Units

How the independent functionalities of the units are tested which excludes any communication between the unit and other units. The interface part is out of scope of this test level. Apart from the above sections, the following sections are addressed, very specific to unit testing.

* Unit Testing Tools
* Priority of Program units
* Naming convention for test cases
* Status reporting mechanism
* Regression test approach
* ETVX criteria

Integration Test Plan

The integration test plan is the overall plan for carrying out the activities in the integration test level, which contains the following sections.
What is to be tested?

This section clearly specifies the kinds of interfaces fall under the scope of testing internal, external interfaces, with request and response is to be explained. This need not go deep in terms of technical details but the general approach how the interfaces are triggered is explained.
Sequence of Integration

When there are multiple modules present in an application, the sequence in which they are to be integrated will be specified in this section. In this, the dependencies between the modules play a vital role. If a unit B has to be executed, it may need the data that is fed by unit A and unit X. In this case, the units A and X have to be integrated and then using that data, the unit B has to be tested. This has to be stated to the whole set of units in the program. Given this correctly, the testing activities will lead to the product, slowly building the product, unit by unit and then integrating them.
System Test Plan {STP}

The system test plan is the overall plan carrying out the system test level activities. In the system test, apart from testing the functional aspects of the system, there are some special testing activities carried out, such as stress testing etc. The following are the sections normally present in system test plan.
What is to be tested?

This section defines the scope of system testing, very specific to the project. Normally, the system testing is based on the requirements. All requirements are to be verified in the scope of system testing. This covers the functionality of the product. Apart from this what special testing is performed are also stated here.
Functional Groups and the Sequence

The requirements can be grouped in terms of the functionality. Based on this, there may be priorities also among the functional groups. For example, in a banking application, anything related to customer accounts can be grouped into one area, anything related to inter-branch transactions may be grouped into one area etc. Same way for the product being tested, these areas are to be mentioned here and the suggested sequences of testing of these areas, based on the priorities are to be described.
Acceptance Test Plan {ATP}

The client at their place performs the acceptance testing. It will be very similar to the system test performed by the Software Development Unit. Since the client is the one who decides the format and testing methods as part of acceptance testing, there is no specific clue on the way they will carry out the testing. But it will not differ much from the system testing. Assume that all the rules, which are applicable to system test, can be implemented to acceptance testing also.

Since this is just one level of testing done by the client for the overall product, it may include test cases including the unit and integration test level details.
A sample Test Plan Outline along with their description is as shown below:

Test Plan Outline

1. BACKGROUND – This item summarizes the functions of the application system and the tests to be performed.
2. INTRODUCTION
3. ASSUMPTIONS – Indicates any anticipated assumptions which will be made while testing the application.
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. This section also mentions all the approaches which will be followed at the various stages of the test execution.
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 it may be resumed in the middle?
Establish check-points in long tests.
10. TEST DELIVERABLES - 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

The schedule details of the various test pass such as Unit tests, Integration tests, System Tests should be clearly mentioned along with the estimated efforts.

Risk Analysis:

A risk is a potential for loss or damage to an Organization from materialized threats. Risk Analysis attempts to identify all the risks and then quantify the severity of the risks.A threat as we have seen is a possible damaging event. If it occurs, it exploits vulnerability in the security of a computer based system.
Risk Identification:

1. Software Risks: Knowledge of the most common risks associated with Software development, and the platform you are working on.

2. Business Risks: Most common risks associated with the business using the Software

3. Testing Risks: Knowledge of the most common risks associated with Software Testing for the platform you are working on, tools being used, and test methods being applied.

4. Premature Release Risk: Ability to determine the risk associated with releasing unsatisfactory or untested Software Prodicts.

5. Risk Methods: Strategies and approaches for identifying risks or problems associated with implementing and operating information technology, products and process; assessing their likelihood, and initiating strategies to test those risks.

Traceability means that you would like to be able to trace back and forth how and where any workproduct fulfills the directions of the preceeding (source-) product. The matrix deals with the where, while the how you have to do yourself, once you know the where.

Take e.g. the Requirement of UserFriendliness (UF). Since UF is a complex concept, it is not solved by just one design-solution and it is not solved by one line of code. Many partial design-solutions may contribute to this Requirement and many groups of lines of code may contribute to it.

A Requirements-Design Traceability Matrix puts on one side (e.g. left) the sub-requirements that together are supposed to solve the UF requirement, along with other (sub-)requirements. On the other side (e.g. top) you specify all design solutions. Now you can connect on the crosspoints of the matrix, which design solutions solve (more, or less) any requirement. If a design solution does not solve any requirement, it should be deleted, as it is of no value.

Having this matrix, you can check whether any requirement has at least one design solution and by checking the solution(s) you may see whether the requirement is sufficiently solved by this (or the set of) connected design(s).

If you have to change any requirement, you can see which designs are affected. And if you change any design, you can check which requirements may be affected and see what the impact is.

In a Design-Code Traceability Matrix you can do the same to keep trace of how and which code solves a particular design and how changes in design or code affect each other.
Demonstrates that the implemented system meets the user requirements.

Serves as a single source for tracking purposes.

Identifies gaps in the design and testing.

Prevents delays in the project timeline, which can be brought about by having to backtrack to fill the gaps
Software Testing Life Cycle:

The test development life cycle contains the following components:

Requirements
Use Case Document
Test Plan
Test Case
Test Case execution
Report Analysis
Bug Analysis
Bug Reporting

Typical interaction scenario from a user's perspective for system requirements studies or testing. In other words, "an actual or realistic example scenario". A use case describes the use of a system from start to finish. Use cases focus attention on aspects of a system useful to people outside of the system itself.

* Users of a program are called users or clients.
* Users of an enterprise are called customers, suppliers, etc.

Use Case:

A collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system's declared responsibilities, showing how the primary actor's goal might be delivered or might fail.

Use cases are goals (use cases and goals are used interchangeably) that are made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal, each step in a scenario is a sub (or mini) goal of the use case. As such each sub goal represents either another use case (subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition.

This hierarchical relationship is needed to properly model the requirements of a system being developed. A complete use case analysis requires several levels. In addition the level at which the use case is operating at it is important to understand the scope it is addressing. The level and scope are important to assure that the language and granularity of scenario steps remain consistent within the use case.

There are two scopes that use cases are written from: Strategic and System. There are also three levels: Summary, User and Sub-function.
Scopes: Strategic and System

Strategic Scope:

The goal (Use Case) is a strategic goal with respect to the system. These goals are goals of value to the organization. The use case shows how the system is used to benefit the organization.,/p> These strategic use cases will eventually use some of the same lower level (subordinate) use cases.

System Scope:

Use cases at system scope are bounded by the system under development. The goals represent specific functionality required of the system. The majority of the use cases are at system scope. These use cases are often steps in strategic level use cases
Levels: Summary Goal , User Goal and Sub-function.

Sub-function Level Use Case:

A sub goal or step is below the main level of interest to the user. Examples are "logging in" and "locate a device in a DB". Always at System Scope.
User Level Use Case:

This is the level of greatest interest. It represents a user task or elementary business process. A user level goal addresses the question "Does your job performance depend on how many of these you do in a day". For example "Create Site View" or "Create New Device" would be user level goals but "Log In to System" would not. Always at System Scope.
Summary Level Use Case:

Written for either strategic or system scope. They represent collections of User Level Goals. For example summary goal "Configure Data Base" might include as a step, user level goal "Add Device to database". Either at System of Strategic Scope.
Test Documentation

Test documentation is a required tool for managing and maintaining the testing process. Documents produced by testers should answer the following questions:

* What to test? Test Plan
* How to test? Test Specification
* What are the results? Test Results Analysis Report

1. Why test - what is Testing? Top
Testing is a process used to help identify the correctness, completeness and quality of developed computer software.
2. System Testing myths and legends - What are they?
Myth1: There is no need to test
Myth2: If testing must be done; two weeks at the end of the project is sufficient for testing
Myth3: Re-testing is not necessary
Myth4: Any fool can test
Myth5: The last thing you want is users involved in test
Myth6: The V-model is too complicated
3. What are the Concepts for Application Test Management?

* Testing should be pro-active following the V-model
* Test execution can be a manual process
* Test execution can be an automated process
* It is possible to plan the start date for testing
* It is not possible to accurately plan the end date of testing
* Ending testing is through risk assessment
* A fool with a tool is still a fool
* Testing is not a diagnosis process
* Testing is a triage process
* Testing is expensive
* Not testing, can be more expensive

4. What Test Principles do you Recommend?
• Test involvement early in the lifecycle - Test Architect Signs off Requirements - Test Architect Signs off Use Cases
• Fail Fast - Identify failures early via core test scripts
• All Test Phases have equal value - Each Test Phase has its own value add
• RACI chart everything
• Testing is a pro-active activity - Plan the Test - Test the Plan
• Finding defects is good - Ignorance of faults in a non-conformant system is no excuse

5. Test Analysts - What is their Value Add?

* Understand the system under test
* Document Assumptions
* Create and execute repeatable tests
* Value add through negative testing
* Contribute to Impact Analysis when assessing Changes
* Contribute to the risk assessment when considering to end testing

6. What do Test Analysts Need?

* Education
* Test Environment
* Test Tools
* Access

7. Requirements Traceability - What is this about?

* Tracing requirements to test cases
* Tracing test cases to requirements
* Should be a feature of the Test Asset Management tool
* Automatic on-demand process
* Pie chart reporting

8. What is involved in the Application Test Lifecycle? Top

* Unit testing
* Module testing
* Component testing
* Component integration testing
* Subsystem testing
* System testing
* Functional testing
* Technical integration testing
* System integration testing
* Non-functional testing
* Integration testing
* Regression testing
* Model Office testing
* User Acceptance testing

9. How to manage Risk Mitigation?

* Identify risks before the adversity affects the project
* Analyse risk data for interpretation by the project team
* Plan actions for probability, magnitude & consequences
* Track risks and actions, maintaining a risk register
* Control risk action plan, correct plan deviations

10. What should the Test Team do?

* Programme Management
* Strong Change Management
* Strict Configuration Control
* Pro Active Scope Creep Management
* Inclusion in the decision making process

11. What are the Test Team Deliverables

* Test Plans
* Test Script Planner
* Test Scripts
* Test Execution Results
* Defect Reports
Software Testing Types

# Static Testing
# Dynamic Testing
# Blackbox Testing
# Whitebox Testing.
# Unit Testing.
# Requirements Testing.
# Regression Testing.
# Error Handling Testing.
# Manual support Testing.
# Intersystem Testing.
# Control Testing.
# Parallel Testing.
# Volume Testing.
# Stress Testing.
# Performance Testing.

One Stop Testing has been developed to give all the information on Software Testing in one place. This site contains the information on the following:

* Static Testing: This section covers - Static Testing, Static material Testing, Static Testing Machine, Static Materials Testing, Software Testing Static Analysis, Static Control Testing, Static Testing Techniques, Static Pressure Testing

* Dynamic Testing: This section covers - Dynamic Tribology Oscillation Testing, Dynamic Testing, Dynamic Testing Machine, Dynamic Material & Tear, Wall, Load Testing

* Blackbox Testing: This section covers - What is blackbox testing, difference between blackbox testing and whitebox testing, Blackbox Testing plans, unbiased blackbox testing

* Whitebox Testing: This section has notes on Whitebox Testing (QA)

* Unit Testing: This section covers - Software Unit Testing, tools, research topics, toolkits, extreme programming unit testing

* Requirements Testing: This section covers - (half face) Respirator fit testing requirements, GFCI, NCLEX testing requirements, CNA testing in Georgia Requirements

* Regression Testing: Software Regression Testing, Network Regression Testing (Software), Automated Regression Testing, Dod regression standard testing, Regression Testing Tools, Web Regression Testing
*Error Handling Testing

Usage:

* It determines the ability of applications system to process the incorrect transactions properly
* Errors encompass all unexpected conditions.

* In some system approx. 50% of programming effort will be devoted to handling error condition.

Objective:

* Determine Application system recognizes all expected error conditions
* Determine Accountability of processing errors has been assigned and procedures provide a high probability that errors will be properly corrected
* Determine During correction process reasonable control is maintained over errors.
How to Use

* A group of knowledgeable people is required to anticipate what can go wrong in the application system.
* It is needed that all the application knowledgeable people assemble to integrate their knowledge of user area, auditing and error tracking.
* Then logical test error conditions should be created based on this assimilated information.

When to Use

* Throughout SDLC.
* Impact from errors should be identified and should be corrected to reduce the errors to acceptable level.
* Used to assist in error management process of system development and maintenance.

Example

* Create a set of erroneous transactions and enter them into the application system then find out whether the system is able to identify the problems..
* Using iterative testing enters transactions and trap errors. Correct them. Then enter transactions with errors, which were not present in the system earlier.
*Manual Support Testing:

Usage:

* It involves testing of all the functions performed by the people while preparing the data and using these data from automated system.

Objective:

* Verify manual support documents and procedures are correct.
* Determine Manual support responsibility is correct
* Determine Manual support people are adequately trained.
* Determine Manual support and automated segment are properly interfaced.

How to Use

* Process evaluated in all segments of SDLC.
* Execution of the can be done in conjunction with normal system testing.
* Instead of preparing, execution and entering actual test transactions the clerical and supervisory personnel can use the results of processing from application system.
* To test people it requires testing the interface between the people and application system.

When to Use

* Verification that manual systems function properly should be conducted throughout the SDLC.
* Should not be done at later stages of SDLC.
* Best done at installation stage so that the clerical people do not get used to the actual system just before system goes to production.

Example

* Provide input personnel with the type of information they would normally receive from their customers and then have them transcribe that information and enter it in the computer.
* Users can be provided a series of test conditions and then asked to respond to those conditions. Conducted in this manner, manual support testing is like an examination in which the users are asked to obtain the answer from the procedures and manuals available to them.

Intersystem Testing

Usage:

* To ensure interconnection between application functions correctly.

Objective:

* Determine Proper parameters and data are correctly passed between the applications
* Documentation for involved system is correct and accurate.
* Ensure Proper timing and coordination of functions exists between the application system.

How to Use

* Operations of multiple systems are tested.
* Multiple systems are run from one another to check that they are acceptable and processed properly.

When to Use

* When there is change in parameters in application system
* The parameters, which are erroneous then risk associated to such parameters, would decide the extent of testing and type of testing.
* Intersystem parameters would be checked / verified after the change or new application is placed in the production.

Example

* Develop test transaction set in one application and passing to another system to verify the processing.
* Entering test transactions in live production environment and then using integrated test facility to check the processing from one system to another.
* Verifying new changes of the parameters in the system, which are being tested, are corrected in the document.

Disadvantage

* Time consuming and tedious if test automation not done
* Cost may be expensive if system is run several times iteratively

Control Testing

Usage:

* Control is a management tool to ensure that processing is performed in accordance to what management desire or intents of management.

Objective:

* Accurate and complete data
* Authorized transactions
* Maintenance of adequate audit trail of information.
* Efficient, effective and economical process.
* Process meeting the needs of the user.

How to Use

* To test controls risks must be identified.
* Testers should have negative approach i.e. should determine or anticipate what can go wrong in the application system.
* Develop risk matrix, which identifies the risks, controls; segment within application system in which control resides.

When to Use

* Should be tested with other system tests.

Example

* file reconciliation procedures work
* Manual controls in place.
Parallel Testing

Usage:

* To ensure that the processing of new application (new version) is consistent with respect to the processing of previous application version.

Objective:

* Conducting redundant processing to ensure that the new version or application performs correctly.
* Demonstrating consistency and inconsistency between 2 versions of the application.

How to Use

* Same input data should be run through 2 versions of same application system.
* Parallel testing can be done with whole system or part of system (segment).

When to Use

* When there is uncertainty regarding correctness of processing of new application where the new and old version are similar.
* In financial applications like banking where there are many similar applications the processing can be verified for old and new version through parallel testing

Example

* Operating new and old version of a payroll system to determine that the paychecks from both systems are reconcilable.
* Running old version of application to ensure that the functions of old system are working fine with respect to the problems encountered in the new system.

Volume Testing

Whichever title you choose (for us volume test) here we are talking about realistically exercising an application in order to measure the service delivered to users at different levels of usage. We are particularly interested in its behavior when the maximum number of users are concurrently active and when the database contains the greatest data volume.

The creation of a volume test environment requires considerable effort. It is essential that the correct level of complexity exists in terms of the data within the database and the range of transactions and data used by the scripted users, if the tests are to reliably reflect the to be production environment. Once the test environment is built it must be fully utilised. Volume tests offer much more than simple service delivery measurement. The exercise should seek to answer the following questions:
What service level can be guaranteed. How can it be specified and monitored?

Are changes in user behaviour likely? What impact will such changes have on resource consumption and service delivery?

Which transactions/processes are resource hungry in relation to their tasks?

What are the resource bottlenecks? Can they be addressed?

How much spare capacity is there?

The purpose of volume testing is to find weaknesses in the system with respect to its handling of large amount of data during extended time periods .

Stress Testing

The purpose of stress testing is to find defects of the system capacity of handling large numbers of transactions during peak periods. For example, a script might require users to login and proceed with their daily activities while, at the same time, requiring that a series of workstations emulating a large number of other systems are running recorded scripts that add, update, or delete from the database.
Performance Testing

System performance is generally assessed in terms of response time and throughput rates under differing processing and configuration conditions. To attack the performance problems, there are several questions should be asked first:

# How much application logic should be remotely executed?
# How much updating should be done to the database server over the network from the client workstation?
# How much data should be sent to each in each transaction?

According to Hamilton [10], the performance problems are most often the result of the client or server being configured inappropriately.

The best strategy for improving client-sever performance is a three-step process [11]. First, execute controlled performance tests that collect the data about volume, stress, and loading tests. Second, analyze the collected data. Third, examine and tune the database queries and, if necessary, provide temporary data storage on the client while the application is executing.

Responses

Author: lall 07 Apr 2008

Member Level: Bronze Points : 1

Good

Author: lall 07 Apr 2008

Member Level: Bronze Points : 1

Can u sent notes about Software Requirements

Author: lall 07 Apr 2008

Member Level: Bronze Points : 1

really good

Author: diyaa 08 Apr 2008

Member Level: Bronze Points : 1

Can u send detail description about white box testing

Author: Olufemi 08 Apr 2008

Member Level: Gold Points : 2

This is my area of responsibility and this article is highly exhaustive and has been bookmarked for further reference. Well done for posting this software developer's companion.
Olufemi

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 09 Apr 2008

Member Level: Diamond Points : 1

thnks for all

Author: Shreshtha 11 Apr 2008

Member Level: Diamond Points : 5

Hi Archana,

Would like to add few point here -

You missed to put Test Apporoach & Dependecies in your Test Plan.

Test Approach - What approach you are going to follow to test your application whether Automation or Manual. What phases of testing would be involved in your project.

Dependencies - Mention all the dependencies related to your testing. e.g. if you need any other software to test it or any test data from other team in case of system integration testing.

In Test Deliverables, we need to prepare a sign off report which represents the closure of your testing. Mention your open issues here and send it to all the stakeholders of your project. It is the final documentation.

Test Scenario document - It covers all the high level scenarios of your requirement. Through which you can trace out your scenarios.

Regards
Shrestha

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 16 Apr 2008

Member Level: Diamond Points : 1

thnk u shresta

Author: lall 16 Apr 2008

Member Level: Bronze Points : 1

i need software Requirement ..tis is good

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 16 Apr 2008

Member Level: Diamond Points : 1

actually i upload tht one but my source get deleted

Author: Vinothkumar K 18 Apr 2008

Member Level: Gold Points : 5

Almost u touch all the important things in testing..
especially i like most are(How to manage Risk Mitigation?

* Identify risks before the adversity affects the project
* Analyse risk data for interpretation by the project team
* Plan actions for probability, magnitude & consequences
* Track risks and actions, maintaining a risk register
* Control risk action plan, correct plan deviations

Volume Testing

Whichever title you choose (for us volume test) here we are talking about realistically exercising an application in order to measure the service delivered to users at different levels of usage. We are particularly interested in its behavior when the maximum number of users are concurrently active and when the database contains the greatest data volume.)

Author: Vinothkumar K 18 Apr 2008

Member Level: Gold Points : 5

Author: Vinothkumar K 18 Apr 2008

Member Level: Gold Points : 5

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 18 Apr 2008

Member Level: Diamond Points : 2

Actually i need Software Requirements
Also i got details about tht.
I sent REsource related to tht.
But the resource get deleted.
I dont know the reason
ok thnks for ur resource

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 18 Apr 2008

Member Level: Diamond Points : 5

Test Approach - What approach you are going to follow to test your application whether Automation or Manual. What phases of testing would be involved in your project.

Dependencies - Mention all the dependencies related to your testing. e.g. if you need any other software to test it or any test data from other team in case of system integration testing.

In Test Deliverables, we need to prepare a sign off report which represents the closure of your testing. Mention your open issues here and send it to all the stakeholders of your project. It is the final documentation.

Test Scenario document - It covers all the high level scenarios of your requirement. Through which you can trace out your scenarios.

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 18 Apr 2008

Member Level: Diamond Points : 5

I missed the following Details
So plz c to tht

Test Approach - What approach you are going to follow to test your application whether Automation or Manual. What phases of testing would be involved in your project.

Dependencies - Mention all the dependencies related to your testing. e.g. if you need any other software to test it or any test data from other team in case of system integration testing.

In Test Deliverables, we need to prepare a sign off report which represents the closure of your testing. Mention your open issues here and send it to all the stakeholders of your project. It is the final documentation.

Test Scenario document - It covers all the high level scenarios of your requirement. Through which you can trace out your scenarios.

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 18 Apr 2008

Member Level: Diamond Points : 5

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 18 Apr 2008

Member Level: Diamond Points : 1

thnks shretha

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 18 Apr 2008

Member Level: Diamond Points : 1

thnks vinoth...

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 18 Apr 2008

Member Level: Diamond Points : 1

thnks for all

Author: Raghav 19 Apr 2008

Member Level: Gold Points : 2

Thank you archana
you have given a very exhaustive article on software testing. Can u give some articles on something like software life cycle.

raghav

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 1

ya ok /....

I will try

thnks for response

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 5

A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. Typically, a life cycle model addresses the phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance. Much of the motivation behind utilizing a life cycle model is to provide structure to avoid the problems of the "undisciplined hacker" or corporate IT bureaucrat (which is probably ten times dangerous then undisciplined hacker). As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.

Software life cycle models describe the interrelationships between software development phases. The common life cycle models are:

* Waterfall model. The least flexible of the life cycle models. Still it is well suited to projects which have a well defined architecture and established user interface and performance requirements. The waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development (Those are the ones most likely to be outsourced overseas ;-)

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 5

#
# Extreme programming(XP) is the latest incarnation of Waterfall model and is the most recent software fad. Most postulates of Extreme programming are pure fantasy. It has been well known for a long time that big bang or waterfall models don't work well on projects with complex or shifting requirements. The same is true for XP. Too many shops implement XP as an excuse for not understanding the user requirements. XP try improve classic waterfall model by trying to start coding as early as possible but without creating a full-fledged prototype as the first stage. In this sense it can be considered to be variant of evolutionary prototyping (see below). Often catch phase "Emergent design" is used instead of evolutionary prototyping.

It also introduces a very questionable idea of pair programming as an attempt to improve extremely poor communication between developers typical for large projects. While communication in large projects is really critical and attempts to improve it usually pay well, "pair programming" is a questionable strategy. There are two main problems here:

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 5

# In a way it can be classified as a hidden attempt to create one good programmer out of two mediocre. But in reality it is creating one mediocre programmer from two or one good. No senior developer is going to put up with some jerk sitting on his lap asking questions about every line. It just prevents the level of concentration needed for high quality coding. Microsoft's idea of having a tester for each programmer is more realistic: one developer writes tests while the other one develops the actual code to be tested. This forces each of them to communicate and because tester has different priorities then developer such communication brings the developer a new and different perspective on his code, which really improves quality. This combination of different perspectives is a really neat idea as you can see from the stream of Microsoft Office products and operating systems (look for example on the quality of components in Office 2003, especially front page and Excel).
# You can also think about pair programming as a perverse way to enforce code reviews (if code reviews are good, do them all the time and for a change remove computer from one guy, so that he can concentrate on reviewed the code written by a lucky one who has the computer

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 5

# Throwaway prototyping model. It was advocated by Brooks. Useful in "proof of concept" or situations where requirements and user's needs are unclear or poorly specified. The approach is to construct a quick and dirty partial implementation of the system during or before the requirements phase. Typical implementation language is scripting language and Unix shell (due to availability huge amount of components that can be used for construction of the prototype).

# Spiral model. The spiral model is a variant of "dialectical spiral" and as such provides useful insights into the life cycle of the system. Can be considered as a generalization of the prototyping model. That why it is usually implemented as a variant of prototyping model with the first iteration being a prototype.

# Evolutionary prototyping model. This is kind of mix of Waterfall model and prototyping. Presuppose gradual refinement of the prototype until a usable product emerge. Might be suitable in projects where the main problem is user interface requirements, but internal architecture is relatively well established and static. Can help to cope with organizational sclerosis. One variant involves so called "binary" software implementation model using a scripting language plus statically typed language. In this case system first is coded in a scripting language and then gradually critical components are rewritten in the lower language. This new development paradigm was pioneered by Ousterhout with TCL but also possible with Python, various scripting language that use JVM (Jython +Java, etc) or Microsoft .NET framework (for example Iron Python + C++). Lately a perverse form of evolutionary prototyping was advocated as the optimal OSS development model

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 5

* OSS development model is the latest variant of evolutionary prototype model. See also OSS development model

The "waterfall model" was probably the first published model and as a specific model for military it was not as naive as some proponents of other models suggest. The model was developed to help cope with the increasing complexity of aerospace products. The waterfall model followed a documentation driven paradigm.

Prototyping model was probably the first realistic of early models because many aspects of the syst4m are unclear until a working prototype is developed. It was advocated by Brooks in early 60th.

A better model, the "spiral model" was suggested by Boehm in 1985. The spiral model is a variant of "dialectical spiral" and as such provides useful insights into the life cycle of the system. But it also presuppose unlimited resources for the project. No organization can perform more then a couple iterations during the initial development of the system. the first iteration is usually called prototype.

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 5

Prototype based development requires more talented managers and good planning while waterfall model works (or does not work) with bad or stupid managers works just fine as the success in this model is more determined by the nature of the task in hand then any organizational circumstances.

Like always humans are flexible and programmer in waterfall model can use guerilla methods of enforcing a sound architecture as manager is actually a hostage of the model and cannot afford to look back and re-implement anything substantial.

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 5

Because the life cycle steps are described in very general terms, the models are adaptable and their implementation details will vary among different organizations. The spiral model is the most general. Most life cycle models can in fact be derived as special instances of the spiral model. Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities.

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 20 Apr 2008

Member Level: Diamond Points : 3

there is nothing wrong about using waterfall model for some components of the complex project that are relatively well understood and straightforward. But mixing and matching definitely needs a certain level of software management talent.

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 26 Apr 2008

Member Level: Diamond Points : 5

1.4. Cost Estimation
1.4.1. Definition
Cost estimation is the process of predicting the amount of effort required to build a software system (or) it is to determine how many resources are needed to complete the project. It is in programmer-months (PM).

1.4.2. Measurement of software size

• Lines of code (LOC) - measure of source code program length.
NCLOC is used to represent a non-commented source line of code. Therefore, NCLOC is a measure of the uncommented length. CLOC is used to represent a commented source line of code.

total length (LOC) =[ NCLOC + CLOC] (in terms of KLOC)

KLOC is used to denote thousands of lines of code.

• Function points
Function points (FP) measure size in terms of the amount of functionality in a system. Function points are computed by first calculating an unadjusted function point count (UFC).

Counts are made for the following categories:
1. External inputs – those items provided by the user that describe distinct application-oriented data (such as file names and menu selections)
2. External outputs – those items provided to the user that generate distinct application-oriented data (such as reports and messages, rather than the individual components of these)
3. External inquiries – interactive inputs requiring a response
4. External files – machine-readable interfaces to other systems
5. Internal files – logical master files in the system
i) Unadjusted Function Point Count
The individual function point items are identified and then classified as simple, average, or complex. The weights from Table 1.2a are then assigned to each item and the total is summed. This total is called the unadjusted function points.
Table 1.2a Function point weights.
Weighting Factor
Item Simple Average Complex
External inputs 3 4 6
External outputs 4 5 7
External inquiries 3 4 6
External files 7 10 15
Internal files 5 7 10

Adjusted function point count (FP) = UFC * [ a technical complexity factor (TCF)]

Components of the TCF are listed in Table 1.2b.

Table 1.2b.Components of the technical complexity factor.

F1 Reliable back-up and recovery F2 Data communications
F3 Distributed functions F4 Performance
F5 Heavily used configuration F6 Online data entry
F7 Operational ease F8 Online update
F9 Complex interface F10 Complex processing
F11 Reusability F12 Installation ease

Each component is rated from 0 to 5, where 0 means the component has no influence on the system and 5 means the component is essential. The TCF can then be calculated as:
TCF = 0.65 + 0.01(SUM(Fi))

The factor varies from 0.65 (if each Fi is set to 0) to 1.35 (if each Fi is set to 5). The final function point calculation is:

FP = UFC x TCF

1.4.3. Models
Models are used to estimate cost. It can be categorized as either cost models or constraint models. COCOMO is an example of a cost model and SLIM is an example of a constraint model.
i) Constructive Cost Model (COCOMO)
Boehm derived a cost model called COCOMO (Constructive Cost Model) using data from a large set of projects. The original COCOMO is a collection of three models:
1. a Basic model that is applied early in the project
2. an Intermediate model that is applied after requirements are specified
3. an Advanced model that is applied after design is complete. All three models take the form:
E = aS^b x EAF
where E is effort in person months, S is size measured in thousands of lines of code (KLOC), and EAF is an effort adjustment factor (equal to 1 in the Basic model) (Fenton, 1997). The factors a and b depend on the development mode.

Boehm has defined three development modes:
1. Organic mode – relatively simple projects in which small teams work to a set of informal requirements (ie. thermal transfer program developed for a heat transfer group).
2. Semi-detached mode – an intermediate project in which mixed teams must work to a set of rigid and less than rigid requirements (ie. a transaction processing system with fixed requirements for terminal hardware and software).
3. Embedded mode – a project that must operate within a tight set of constraints (ie. flight control software for aircraft).
1) Basic
The Basic COCOMO model computes effort as a function of program size. The Basic COCOMO equation is:
E = aKLOC^b

The factors a and b for the Basic COCOMO model are shown in Table 1.2c.

Table 1.2c. Effort for three modes of Basic COCOMO.

Mode a b
Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20

2) Intermediate
The Intermediate COCOMO model computes effort as a function of program size and a set of cost drivers. The Intermediate COCOMO equation is:

E = aKLOC^b x EAF

The factors a and b for the Intermediate COCOMO model are shown in Table 1.3d.

Table 1.3d. Effort parameters for three modes of Intermediate COCOMO.

Mode a b
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20

The effort adjustment factor (EAF) is calculated using 15 cost drivers. The cost drivers are grouped into four categories: product, computer, personnel, and project. Each cost driver is rated on a six-point ordinal scale ranging from low to high importance. Based on the rating, an effort multiplier is determined using Table 1.3e. The product of all effort multipliers is the EAF.

Table 1.3e. Software Development Effort Multipliers.

Cost Driver Description Rating
Very Low Low Nominal High Very High Extra High
Product
RELY Required software reliability 0.75 0.88 1.00 1.15 1.40 -
DATA Database size - 0.94 1.00 1.08 1.16 -
CPLX Product complexity 0.70 0.85 1.00 1.15 1.30 1.65
Computer
TIME Execution time constraint - - 1.00 1.11 1.30 1.66
STOR Main storage constraint - - 1.00 1.06 1.21 1.56
VIRT Virtual machine volatility - 0.87 1.00 1.15 1.30 -
TURN Computer turnaround time - 0.87 1.00 1.07 1.15 -
Personnel
ACAP Analyst capability 1.46 1.19 1.00 0.86 0.71 -
AEXP Applications experience 1.29 1.13 1.00 0.91 0.82 -
PCAP Programmer capability 1.42 1.17 1.00 0.86 0.70 -
VEXP Virtual machine experience 1.21 1.10 1.00 0.90 - -
LEXP Language experience 1.14 1.07 1.00 0.95 - -
Project
MODP Modern programming practices 1.24 1.10 1.00 0.91 0.82 -
TOOL Software Tools 1.24 1.10 1.00 0.91 0.83 -
SCED Development Schedule 1.23 1.08 1.00 1.04 1.10 -

3) Advanced
The Advanced COCOMO model computes effort as a function of program size and a set of cost drivers weighted according to each phase of the software lifecycle. The Advanced model applies the Intermediate model at the component level, and then a phase-based approach is used to consolidate the estimate.

The four phases used in the detailed COCOMO model are: requirements planning and product design (RPD), detailed design (DD), code and unit test (CUT), and integration and test (IT). Each cost driver is broken down by phase as in the example shown in Table 1.3f.

Table 1.3f. Analyst capability effort multiplier for Detailed COCOMO.

Cost Driver Rating RPD DD CUT IT
ACAP Very Low 1.80 1.35 1.35 1.50
Low 0.85 0.85 0.85 1.20
Nominal 1.00 1.00 1.00 1.00
High 0.75 0.90 0.90 0.85
Very High 0.55 0.75 0.75 0.70

Estimates made for each module are combined into subsystems and eventually an overall project estimate. Using the detailed cost drivers, an estimate is determined for each phase of the lifecycle.

ii) SLIM

Putnam developed a constraint model called SLIM to be applied to projects exceeding 70,000 lines of code. Putnam’s model assumes that effort for software projects is distributed similarly to a collection of Rayleigh curves. Putnam suggests that staffing rises smoothly during the project and then drops sharply during acceptance testing. The SLIM model is expressed as two equations describing relation between the development effort and the schedule. The first equation, called the software equation, states that development effort is proportional to the cube of the size and inversely proportional to the fourth power of the development time. The second equation, the manpower-buildup equation, states that the effort is proportional to the cube of the development time.

1) The Norden-Rayleigh Curve

The Norden-Rayleigh curve represents manpower as a function of time. SLIM uses separate Rayleigh curves for design and code, test and validation, maintenance, and management. A Rayleigh curve is shown in Figure 1.11.

Figure 1.11. A Rayleigh curve.

2) The Software Equation
Putnam used some empirical observations about productivity levels to derive the software equation from the basic Rayleigh curve formula. The software equation is expressed as:
Size = CE^1/3( t^4/3)

where C is a technology factor, E is the total project effort in person years, and t is the elapsed time to delivery in years.

3) The Manpower-Buildup Equation

To allow effort estimation, Putnam introduced the manpower-buildup equation:
D = E / t^3

Where D is a constant called manpower acceleration, E is the total project effort in years, and t is the elapsed time to delivery in years.

1.4.4. Automated Tools

Many models are available as automated tools. These tools allow the planner to estimate cost and effort and to perform what if analyses for important project variables.

1) Costar
Costar is an estimation tool developed by Softstar Systems. Costar will produce estimates of a project's duration, staffing levels, effort, and cost based on the original COCOMO or COCOMO II models. Planners can adjust the estimate to arrive at an optimal project plan. The main screen is shown in Figure 1.12.

Figure 1.12. Costar main screen.

2) SLIM
Putnam has extended the SLIM model to include an automated tool. The SLIM tool was developed by Quantitative Software Management. SLIM produces the chart shown in Figure 1.13.

Figure 1.13. SLIM manpower distribution.

3) Checkpoint
Checkpoint is a tool developed by Software Productivity Research. Checkpoint predicts effort at four levels: project, phases, activity, and task. Checkpoint facilitates the comparison of actual and estimated performance to various industry standards included in an internal estimation knowledge base.

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 26 Apr 2008

Member Level: Diamond Points : 5

Software testing is the process used to assess the quality of computer software. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test[1] , with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs. Quality is not an absolute; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behavior of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of Software Quality Assurance (S.Q.A.), which encompasses all business process areas, not just testing.[citation needed]

Over its existence, computer software has continued to grow in complexity and size. Every software product has a target audience. For example, a video game software has its audience completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it presumably must assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment.

Software testing may be viewed as an important part of the software quality assurance (SQA) process.[citation needed] In SQA, software process specialists and auditors take a broader view on software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in defect rate. What constitutes an acceptable defect rate depends on the nature of the software. An arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than software used to control an actual airliner. Although there are close links with SQA testing departments often exist independently, and there may be no SQA areas in some companies.

The software faults occur through the following process. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure.[3] Not all defects will necessarily result in failures. For example, defects in a dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new hardware platform, alterations in source data or interacting with different software.[3]

A problem with software testing is that testing all combinations of inputs and preconditions is not feasible when testing anything other than a simple product.[4] This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, parafunctional dimensions of quality--for example, usability, scalability, performance, compatibility, reliability--can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another.

There are many approaches to software testing. Reviews, walkthroughs or inspections are considered as static testing, whereas actually running the program with a given set of test cases in a given development stage is referred to as dynamic testing.

Software testing is used in association with verification and validation:[5]

* Verification: Have we built the software right (i.e., does it match the specification)?
* Validation: Have we built the right software (i.e., is this what the customer wants)?

Software testing can be done by software testers. Until the 1950s the term software tester was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing[6] there have been established different roles: test lead/manager, tester, test designer, test automater/automation developer, and test administrator.

Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements.[14] Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix etc.

White box testing, however, is when the tester has access to the internal data structures, code, and algorithms. White box testing methods include creating tests to satisfy some code coverage criteria. For example, the test designer can create tests to cause all statements in the program to be executed at least once. Other examples of white box testing are mutation testing and fault injection methods. White box testing includes all static testing.

White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.[15] Two common forms of code coverage are function coverage, which reports on functions executed and statement coverage, which reports on the number of lines executed to complete the test. They both return a coverage metric, measured as a percentage.

In recent years the term grey box testing has come into common usage. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey-box because the input and output are clearly outside of the black-box we are calling the software under test. This is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. Grey box testing may also include reverse engineering to determine, for instance, boundary values.

Special methods exist to test non-functional aspects of software. Performance testing checks to see if the software can handle large quantities of data or users. Usability testing is needed to check if the user interface is easy to use and understand. Security testing is essential for software which processes confidential data and to prevent system intrusion by hackers. To test internationalization and localization aspects of software a pseudolocalization method can be used.

Author: Avdhut Sonpethkar 27 Apr 2008

Member Level: Gold Points : 2

Well software testing is nothing but to find out what programmers have done wrong and try to correct it by making it more complicated.

Author: Raghav 28 Apr 2008

Member Level: Gold Points : 2

Really a lot of information and abundant information about software testing.

raghav

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 29 Apr 2008

Member Level: Diamond Points : 2

thnks for ur response Avdhut Sonpethkar

Regards

Confidence

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 29 Apr 2008

Member Level: Diamond Points : 2

thnks for ur response raghav

Regards

Confidence

Author: Raghav 30 Apr 2008

Member Level: Gold Points : 2

OK. it is alright Confidence

raghav

Author: SRINIVAS VANKAYALA 01 May 2008

Member Level: Silver Points : 2

this very useful information for me regarding testing

Author: pournami 02 May 2008

Member Level: Gold Points : 2

Great job....

Author: CONFIDENCE IS THE COMPANION OF SUCCESS 12 May 2008

Member Level: Diamond Points : 2

thnks for all

Feedbacks

Popular Tags

What are tags ?

Search Tags

(No tags found.)

Post Feedback

This is a strictly moderated forum. Only approved messages will appear in the site. Please use 'Spell Check' in Google toolbar before you submit.
You must Sign In to post a response.

	Next Resource: New internet that’s 10,000 times faster
	Previous Resource: keyboardevent
	Return to Discussion Resource Index
	Post New Resource
	Category: Computer & Technology

Post resources and earn money!

Related Resources

Fresher Jobs

Resources

Colleges

Software Testing

Responses

Post Feedback