If you are a developer, you are also a tester. As a part of developing solutions, you must spend time testing what you are building to confirm that it not only works, but that it works as expected. Good developers check to see that a solution works as expected, as well as check to verify that it works in an efficient, bug-free manner that can stand up to whatever might be thrown at it.
Not all tests, however, are the same. In the world of developing solutions, how many different types of testing can you name? Better yet, how many different types of testing do you do? The following slides touch on many of the types of testing developers encounter. After going through the slides, post a comment stating how many of these you do. Do you do them all?
Regarding popularity, after unit testing, integration testing is one that developers will be mention. Whereas unit testing checks the functioning of a unit within a solution, integration testing focuses on the interaction and interfaces among those units. Integration testing is used to verify that the units are interacting appropriately. There are various forms of integration testing is generally done in a top-down or bottom-up scenario.
API Testing is a type of integration testing that focuses on the APIs used within a solution. APIs should be tested to ensure they perform as defined by the specifications that come with the APIs. Testing should be done to verify that the correct fields, types, and functionality are all happening.
Installation testing focuses on the process of installing a software solution. This can be done on its own, but is generally a part of configuration testing. In addition to including the process of installing the software, integration testing also should include checking the processes of uninstalling and upgrading.
As part of the testing, there should be a focus to make sure that dependent files exist, valid hardware is present and configured, and any connectivity that might be needed is available (or not).
User Acceptance testing is not actually done by developers, but rather by the client or end users of the software. User acceptance testing is used to confirm that the software does what the end users need it to do. For the best chance of success (and to help avoid scope creep), it is best to have acceptance test objectives documented at the beginning of a project so that developers know what the business objectives are.
Although end users do this testing, it is critical for developers to make sure it happens. If you don't, you could end up with calls from users later rather than sooner....
Interface testing focuses on the interactions between the end user and the software. With today’s varied hardware solutions, interface testing can include testing screen forms to make sure they display correctly as well as accept input appropriately.
Interface testing also can include working with input whether typed, spoken, written, or gestured. The testing must take into consideration whether a graphical user interface is being used, if a service is being used, or if the interaction is done in some other manner. When completed, interface testing should insure that not only the various input manners work, but that interaction with the user is appropriate based on the interfacing actions that occur.
There are many other testing terms and types that have not been covered in the 21 previous slides. This includes areas such as Gorilla testing, which is testing that has multiple people pound on (work on) the same testing area in an exhaustive manner. There is also Agile testing, which simply integrates the testing as part of the overall integrated process of building a solution.
There is also paired testing, which is the process of having two people work together when testing. Paired testing can be two developers, a developer and a business person, or any other combination of two people. The idea of paired testing is that two people looking and testing together can better identify issues better than one.
Black box testing focuses on testing the functionality of an area of a solution without worrying about the internals of how the unit is accomplishing a task. White box testing, on the other hand focuses on the inner workings of an application rather than the overall functionality that black box tests cover. White box testing can include testing code coverage, data flow, branching, decision trees, statements, and more. Then, there is gray box testing, which combines the black and white testing approaches.
Other testing methods not mentioned include boundary testing, sanity testing, smoke testing, and more. Many of these have similarities to what has already been covered.
Clearly, there are a lot of testing approaches as well as types of tests. Developers need to make sure they are applying the right testing to the solutions they are doing. On that note, how many of these testing strategies do you use regularly?
Advertiser Disclosure: Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.