Software Testing World

Tutorials, Careers, eBooks, Reviews

Archive for category Software Testing Types

Stress Testing

Jul 12

Posted by admin in Stress Testing | Comments off

In Stress Testing, the application under test is tested against very heavy load, which checks for the behavior of the applications beyond load testing. The idea is to create an environment more demanding of the application than the application would experience under normal work loads. Any software is tested with increasing load and can be tested until the system breaks, and stress testing is testing of system behavior and functionalities after the highest load a system can work with. The system is repaired and the stress test is repeated until a level of stress is reached that is higher than expected to be present at a customer site. Race conditions and memory leaks are often found under stress testing.

A race condition is a conflict between at least two tests. Each test works correctly when done in isolation. When the two tests are run in parallel, one or both of the tests fail. This is usually due to an incorrectly managed lock. A memory leak happens when a test leaves allocated memory behind and does not correctly return the memory to the memory allocation scheme. The test seems to run correctly, but after being exercised several times, available memory is reduced until the system fails

Tags: ,

Load Testing

Jul 12

Posted by admin in Load Testing | Comments off

In Load Testing, the application is tested against loads or inputs such as testing of web sites in order to find out up to what load the system works correctly or at what point its behavior/performance degrades. Load

Note that load testing does not aim to break the system by overwhelming it, but instead tries to keep the system constantly humming like a well-oiled machine. In the context of load testing, extreme importance should be given of having large datasets available for testing. Bugs simply do not surface unless you deal with very large entities such thousands of users in repositories such as LDAP/ NIS/ Active Directory; thousands of mail server mailboxes, multi-gigabyte tables in databases, deep file/ directory hierarchies on file systems, etc. Testers obviously need automated tools to generate these large data sets, but fortunately any good scripting language worth its salt will do the job

Tags:

Usability Testing

Jul 12

Posted by admin in Usability Testing | Comments off

Usability Testing is also called as ‘Testing for User-Friendliness’. Usability Testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user. Usability Testing is the process of working with end-users directly and indirectly to assess how the user perceives a software package and how they interact with it. This process will uncover areas of difficulty for users as well as areas of strength. The goal of Usability Testing should be to limit and remove difficulties for users and to leverage areas of strength for maximum usability. Usability Testing should ideally involve direct user feedback, indirect feedback (observed behavior), and when possible computer supported feedback. Computer supported feedback is often (if not always) left out of this process. Computer supported feedback can be as simple as a timer on a dialog to monitor how long it takes users to use the dialog and counters to determine how often certain conditions occur (i.e. error messages, help messages, etc). Often, this involves trivial modifications to existing software, but can result in tremendous return on investment. Ultimately, Usability Testing should result in changes to the delivered product in line with the discoveries made regarding usability. These changes should be directly related to real-world usability by average users. As much as possible, documentation should be written supporting changes so that in the future, similar situations can be handled with ease.

Tags:

Recovery Testing

Jul 12

Posted by admin in Recovery Testing | Comments off

Recovery Testing is done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications. It is basically testing how well a system recovers from crashes, hardware failures, or other catastrophic problems

Tags:

Volume Testing

Jul 12

Posted by admin in Volume Testing | Comments off

In simple term, Volume Testing is the test process where the system is subjected to large volumes of data

Volume Testing is done against the efficiency of the application. Large data/database is processed through the application under testing in order to check the extreme limitations of the system

Volume Testing, as its name implies, is testing that purposely subjects a system (both hardware and software) to a series of tests where the volume of data being processed is the subject of the test. Such systems can be transactions processing systems capturing real time sales or could be database updates and or data retrieval

Volume testing will seek to verify the physical and logical limits to a system’s capacity and ascertain whether such limits are acceptable to meet the projected capacity of the organization’s business processing

Tags:

Regression Testing

Jul 12

Posted by admin in Regression Testing | Comments off

Regression Testing is a style of testing that focuses on retesting after changes are made. In traditional regression testing, we reuse the same tests (the regression tests). In risk-oriented regression testing, we test the same areas as before, but we use different (increasingly complex) tests. Traditional regression tests are often partially automated. These note focus on traditional regression

Regression testing attempts to mitigate two risks:

o A change that was intended to fix a bug failed.

o Some change had a side effect, unfixing an old bug or introducing a new bug

Regression testing approaches differ in their focus, Common examples include:

Bug regression: We retest a specific bug that has been allegedly fixed.

Old fix regression Testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)

General functional regression: We retest the product broadly, including areas that worked before, to see whether more recent changes have destabilized working code. (This is the typical scope of automated regression testing.)

Conversion or port Testing: The program is ported to a new platform and a subset of the regression test suite is run to determine whether the port was successful. (Here, the main changes of interest might be in the new platform, rather than the modified old code.)

Configuration Testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn’t been changed–only the external components that the software under test must interact with.

Localization Testing: The program is modified to present its user interface in a different language and/or following a different set of cultural rules. Localization testing may involve several old tests (some of which have been modified to take into account the new language) along with several new (non-regression) tests.

Smoke or Build Verification Testing: A relatively small suite of tests is used to qualify a new build. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn’t work. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports.

Tags: ,

Smoke Testing

Jul 12

Posted by admin in Smoke Testing | Comments off

This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.

A test of new or repaired equipment by turning it on, if it smokes… guess what… it doesn’t work! The term also refers to testing the basic functions of software. The term was originally coined in the manufacture of containers and pipes, where smoke was introduced to determine if there were any leaks. A common practice at Microsoft and some other shrink-wrap software companies is the ‘daily build and smoke test’ process. Every file is compiled, linked, and combined into an executable program every day, and the program is then put through a “smoke test,” a relatively simple check to see whether the product ‘smokes’ when it runs.

Tags: , ,

Ad-hoc Testing

Jul 12

Posted by admin in Ad-hoc Testing | Comments off

In Ad-hoc Testing, testing is done without any formal Test Plan. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing. It is the least formal method of testing.

One of the best uses of ad hoc testing is for discovery. Reading the requirements or specifications (if they exist) rarely gives you a good sense of how a program actually behaves. Even the user documentation may not capture the “look and feel” of a program.

Ad hoc testing can find holes in your test strategy and can expose relationships between subsystems that would otherwise not be apparent. In this way, it serves as a tool for checking the completeness of your testing. Missing cases can be found and added to your testing arsenal. Finding new tests in this way can also be a sign that you should perform root cause analysis. Ask yourself or your test team, “What other tests of this class should we be running?” Defects found while doing ad hoc testing are often examples of entire classes of forgotten test cases.

Tags: ,

Performance Testing

Jul 12

Posted by admin in Performance Testing | Comments off

In the current era, when you hardly have any stand alone desktop application Performance, Load and stress Testing becomes key to the success of your application. Performance testing comes under non functional testing.

Performance testing is normally used with Load testing and stress testing. Some people even use these terms interchangeably, which is not correct. Common factor among this testing type is the simulated load, but there are subtle difference in performance, load and stress testing. We will explore these in some detail and try to make the difference between these testing clear.

Performance testing is conducted after the completion of functional testing. Performance testing is normally conducted during the System Testing phase. Objective of performance testing is not to find functional defect in the system, it is assumed that functional defects have been identified and removed from the system.

Performance testing is usually conducted for web applications. Main objective of performance testing is to get information with respect to response time, throughput and utilization under a given load. In order to perform performance testing on the web application, you need to know at least these two things

Expected load it could be in terms of concurrent user or HTTP connections.

Acceptable response time:

During performance testing whole system can be optimized at various levels. It can be optimized at

  • Application Level
  • Database level
  • Operating system level
  • Network level

Performance testing can be performed as a white box or black box activity. In white box approach, system is inspected and performance tuning is performed where ever possible to improve performance of the system. In black box approach, test engineers can use tools that simulate the concurrent users/ HTTP connections and measure response time.

When the result of the performance testing indicates that performance of the system is below the acceptable level, you start tuning application and databases. You need to make sure that system runs as efficiently as possible on the given hardware/OS combination. If even after tuning application, databases and other parameters performance of application is under acceptable level, probably it is time to scale your hardware, database and web servers.

Tags: ,