17

What kinds of software testing do you know? I've heard about Test-Driven Development, Unit tests etc, but can't understand their importance and difference. For example, why are we using regression tests or acceptance tests. What advantage they provide?

3
  • 8
    What part of this was confusing or incomplete? en.wikipedia.org/wiki/Software_testing
    – S.Lott
    Jul 15, 2011 at 19:41
  • 2
    YOu can skip the regression tests if you don;t care if you break existing functionality and you can skip the acceptance test if you don't care whether the people actually using the software or paying for it think it does what they expect it to do. Professional programmers care about both those things.
    – HLGEM
    Jul 15, 2011 at 20:19
  • I am voting to reopen this question since it is the only one I could find giving a good overview about the different kinds of test categories. Maybe someone has a good idea how to reword the question to make it a better fit for this site?
    – Doc Brown
    Jan 4, 2016 at 13:11

2 Answers 2

39

Broad categories to my mind would be:

Black box testing. You don't get to see the code and are just testing blindly to some extent as what is in the application or system is hidden from you. Thus in this case people don't know all the error cases and have to guess with various boundary conditions that may or may not be obvious to find all the cases.

White box testing. You do get to see the code and can verify what code pathways are being used so that code coverage could be used as a metric to ensure that all the logic is being used in the system. The idea here is to know what the code looks like to help guide the tests so that it isn't quite as mysterious as black box testing.

Gray box testing is a hybrid of the previous two.

Boundary cases tend to be something that one can see in white box testing as there are various conditions to see in the code that one writes tests to hit,e.g. if you had a program that asks for a number and someone enters X how this is handled should be seen somewhere in the code.

General classifications of testing would be:

Unit tests. These are generally the smallest tests that test something rather specific,e.g. does this method handle this boundary case? Note that dependency injection may be used here for cases involving mock objects to reduce any dependencies for the tests.

Integration tests. These are tests where a couple of components are connected and tests are run to ensure that the components do work together well. Note that while the unit tests may work independently, this is where the test of how well do things come together is done as there may be miscommunication between layers that cause these tests to be useful in catching various gotchas. The term End-to-End tests is used for integration tests where a full chain of components is tested from "one endpoint of the application to another" (whatever that means).

Regression tests. These would be tests done in the past that are done again to ensure that what was fixed is staying fixed and bugs aren't being re-introduced to the code.

Usability tests. These would be tests done to see how well can end users work with the software to complete various tasks. Where could something be automated to make something quicker or adjusting the UI so that something is easier to use.

User acceptance tests. These would be tests done by end users so that they can see first hand how something works and agree that the software does meet the business need that requested it in the first place.

Functional tests are all kind of tests based on the functional specification of the software under test. These are always black box tests.

Performance tests. These would be tests done to ensure a system can handle a certain amount of load without getting too slow. For example, testing out a new web farm of servers could handle 100 users hitting a site all at the same time would be an example of a performance test. These may also be called "load tests" or "stress tests" as generally the idea here is to either push the system to its limit or verify that the system can handle some projection from another department. The rationale for these tests is that often there are numerous configuration settings to optimize that can take more than a little work to discover bottlenecks and address issues with this. The bottleneck here could be memory, I/O, CPU or network bandwidth that causes the system to not be as responsive as expected. This generally requires tools on both simulating the load as well as monitoring the system to identify the bottlenecks.

Test Driven Development is a methodology and doesn't refer to a specific kind of test but rather that tests are written before the code so that the tests are what drives the development rather than behavior, domain, or feature being some other examples in terms of process.

Continuous Integration is a practice of running some tests such as unit, integration and regression tests regularly so that if a change breaks a test this is caught as early as possible.

6
  • 5
    +1... and unfortunately, there are still manual tests even after all of that. Jul 15, 2011 at 19:50
  • 2
    and Stres Test - all possible sessions testing the same mask in same time and continiously throught testing scenario, somewhere included as part of UAT, btw +1
    – mKorbel
    Jul 15, 2011 at 20:20
  • 1
    Aren't you missing coverage/branch coverage testing? Also, running under some kind of memory watching system, like "Electric Fence" malloc, or Valgrind? Jul 15, 2011 at 22:09
  • 1
    @Bruce Ediger: coverage is a statistic for white box testing, not a method of testing itself and the tools you describe are for perf testing. Jul 16, 2011 at 1:09
  • I have to differ on the "tools ... are for perf testing". In some languages (C or C++) running a whole lot of unit tests in valgrind will find bugs that none of the other kinds of testing listed above will find. Valgrind is certainly a debugging tool, but running tests in a valgrinded program is very necessary. Jul 16, 2011 at 1:39
4

Regression testing is performed to ensure that new changes to a system didn't break any existing functionality that was not supposed to have been affected by the changes.

Acceptance testing is usually done by the customer/client/business users, it's often more high-level than other forms of testing and it's performed so that the people who requested the changes are happy with them and will allow you to promote the changes into your production system.

1
  • 1
    And what's most important so that they agree they got what they had wanted to get and can pay you now.
    – Mchl
    Jul 15, 2011 at 20:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.