Testing involves operation of a system or application under controlled conditions and evaluating the results. The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection'.
The U.S. Commerce Department has estimated that buggy software costs nearly $60 billion annually, and that at least $22.2 billion worth of those bugs could have been prevented with more thorough testing.
And although you might like to think that your newly coded application is virtually bug-free, we all know by now that it just ain't so. Note that there's simply no such thing as an error-free application. There is no software that is perfect.
Defect can be caused by a flaw in the application software or by a flaw in the application specification. For example, unexpected (incorrect) results can be from errors made during the construction phase, or from an algorithm incorrectly defined in the specification. Testing is commonly assumed to mean executing software and finding errors. This type of testing is known as dynamic testing, and while valid, it is not the most effective way of testing. Static testing, the review, inspection and validation of development requirements, is the most effective and cost efficient way of testing. A structured approach to testing should use both dynamic and static testing techniques.
There are many, many different ways to test software, but most tend to fall into two broad categories: functional testing and performance testing.
The functional testing focuses on the program's functionality against the specification.
Functional testing covers how well the system executes the functions it is supposed to execute—including user commands, data manipulation, searches and business processes, user screens, and integrations.
Although functional testing is often done toward the end of the development cycle, it can—and should, say experts—be started much earlier. Individual components and processes can be tested early on, even before it's possible to do functional testing on the entire system.
This term is often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans. Performance testing is perhaps the biggest area of testing.
Performance testing can be defined as the testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users.
The different types of performance testing that can be done are:
- Classic performance testing, which measures response times and transaction rates
- Load testing, which measures the system's ability to handle varied workloads
- Stress testing, which looks for errors produced by low resources or competition for resources
- Volume testing, which subjects the software to larger and larger amounts of data to determine its point of failure
Key Objectives of Performance Testing
- Plan Approach - What is it that you are trying to measure and why? You need to understand your motive of performance testing your application
- Create a plan and a model - After planning your approach, invest time and effort into creating your capacity and performance model. The approach should include the key inputs , key items to measure and how you plan to measure.
- Implement Approach - Roll out your performance testing approach, including your measurement, profiling and benchmarking tools and processes, to start feeding your capcity model. At this point of your testing, you will most likely iterate for a defined period, inputting the data from profiling and benchmarking into your performance testing model.