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?
Ad Hoc Testing / Exploratory Testing
Ad hoc testing is likely the most popular form of testing done by developers. As its name implies, this is a random testing method that involves simply using the software to see what issues can be found. If a person has a good idea of the expected functionality of the solution being tested, this method of testing can help to find issues. In general, ad hoc or exploratory testing is best as a supplemental testing method and should not be used as the sole approach to testing.
If you ask developers to list testing approaches, unit testing will be on nearly every developer’s list at the top. Unit testing is a type of white box testing that focuses on testing a single unit within a solution. The testing should focus on all aspects of that unit, including the testing of methods statements, branching logic, interfaces, and more. Unit testing is often used when building automated tests.
Integration Testing including API Testing
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.
Configuration testing involves testing a solution against a variety of software and hardware platforms to confirm to confirm there are no issues. Configuration testing is also called hardware compatibility testing. This can be one of the more time-consuming testing methods, but at the same time is one of the most important due to the variety of platforms being used today.
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).
Acceptance Testing / User Acceptance Testing (UAT)
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….
Usability testing should not be confused with acceptability testing. Usability testing focuses on how easy software is to understand and use. Usability testing should watch for easy of use, it should verify software is intuitive, and it should make sure that the user is not stressed by using the software. Developers can use approaches that work for themselves, but that are not necessarily clear to the end users. Not every user will know the acronyms, icons, or other elements that often make their way into solutions!
Functional testing is a form of quality assurance in that it tests a solution against design objectives and specifications. The focus of functional testing is to confirm that the results expected are received when specific input is provided to a system.
Performance testing is focused on determining how a solution behaves in various workload situations. Performance testing can include break-point testing, configuration testing, isolation testing, load testing, soak testing, spike testing, and stress testing.
Stress Testing / Scalability Testing
Stress testing is used to determine what happens to a solution under extreme situations. Stress testing and scalability testing determine what happens if the workload increases. This can include spike testing, which tests for sudden increases or decreases in activity as well as slower scaling of use. The focus can be on making sure the system can continue to work in a reliable manner and at an acceptable performance level.
Regression testing is the retesting of a solution to make sure that features that worked previously still work as expected. This is often done when software is updated or modified. Regression testing tends to include re-running many of the other testing methods mentioned in these slides, including functional, stress, performance, and other tests.
Security testing Includes a variety of testing approaches, including penetration testing and vulnerability testing. The overall objective of security testing is to verify that the solution is safe from both internal and external threats, whether human or machine. This can include testing the security of data as well as the strength of authorization approaches. If a solution includes confidential data, security testing can include validation on the approaches to maintaining confidentiality as well.
Load testing is similar to stress testing. Its focus is to validate that the solution will work at various levels of usage. Load testing tends to look for issues that would cause the software to misbehave. This can include looking for issues such as bottlenecks and race conditions. Stress testing, soak tests, and spike tests are all related to load testing.
Alpha testing is a form of acceptance testing that is generally done by releasing a software solution to an independent test team to use. This can be potential users or customers, or it can be a test team; however, the teams should be independent of the development team. An alpha test is generally the first test released in this manner.
Beta testing has nothing to do with a Beta fish, but rather is a level of testing that occurs after alpha testing. Beta testing is also a form of user acceptance testing done by an independent group. Beta tests tend to be done after a product is considered feature complete and after other test approaches have been completed.
System testing is a high-level term that includes many subcategories of testing. The focus of system testing is on validating that the solution works on the software, hardware, and networks. This is done using functional, regression, load, stress, security, and many of the other testing methods mentioned in these slides.
Accessibility testing focuses on making sure that a solution is usable by those with disabilities. Common checks include making sure that font sizes can be adjusted for the visually impaired, that colors contrast effectively for those who are color blind, or that various input methods will work for those who cannot necessarily type.
Fuzz testing, or “fuzzing,” is the process of providing random data and inputs to a computer solution. It is the process of seeing what odd or unexpected actions do to a program. Fuzz testing can include actions such as typing random items into input fields, the removing of an expected file, the submission of a junk (or corrupted) file instead of a real file, and other unusual testing scenarios.
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.
Internationalization verifies that the solution is ready for world-wide use. Does the software support multiple languages, including different characters sets? Does it work with single- and double-byte character sets? If the user changes from one location to another, does the software adjust? These are just some of the scenarios internationalization testing should validate.
Similar to internationalization, localization testing focuses on making sure that the software adapts based on the location the user set. For example, do numbers and dates get displayed correctly based on the country that is being used? Does input for values also get changed appropriately? Are fonts updated to display the correct character sets? Are financials displayed in the correct monetary unit, such as dollars in the United States or Euros in Europe?
And so many more…
There are many other testing terms and types that have not been covered in the 21 previous sections. 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?