Unit testing involves verifying at a granular level that each "unit" of source code performs as it should. While it can sometimes be difficult to
define what a unit is, intuitively it can be thought of as the smallest testable part of an application. Unit testing is a form of "white box" testing
because it requires actually knowing how the software is built. It is important to note that unit testing merely verifies that a class or method or
other software component does what its author intended, which is why unit testing is typically done by the developers that write the code.
The most effective unit testing is done with automation tools so that the unit tests can be executed repeatedly whenever something in the software
changes. This helps to minimize cases where a developer inadvertently breaks something that was previously working. These tools have become quite
sophisticated and allow for managing test data and doing other things like "mocking" dependencies. It is common for one software component to have
a dependency on another, such that it cannot run in isolation, and therefore cannot be tested in isolation either. In such cases, mock components
are substituted in place of the real components that do just enough to satisfy the dependency, without clouding the results of the unit test.
SwitchLane's developers and comfortable with using these types of tools to ensure the quality of their code before they release it for further testing
by others.
Acceptance testing is conducted to determine if an application or a portion of it meets the agreed upon requirements. This is typically a form of
"black box" testing because it does not require knowledge of how the software is built, only how it should function. Acceptance testing is typically
done by specialized QA testers who excel at thinking of all the normal and abnormal ways in which a piece of software might get used. Another benefit
of this is that it results in independent verification of the software quality since the testing is not being done by the same person who built it.
Once the QA testers approve the software, it will often also undergo what is called User Acceptance Testing (UAT). This is where the end users
(typically working for the client) do less structured testing to make sure that the software will fulfill their needs. SwitchLane QA testers may
coordinate with members of the client's team to conduct UAT once they have verified that the system meets the documented requirements.
While acceptance testing focuses on verifying the functionality of newly built software features, regression testing focuses on ensuring that
previously accepted software has not been subsequently broken due to changes that have been made. Software applications can get very complex and often
components get re-used for multiple purposes. When there is a high degree of complexity and dependencies between different components, it can be
quite easy to introduce or re-introduce problems inadvertently.
It is difficult and expensive to do manual regression testing, as humans take a long time to do things in comparison to computers. Since regression
testing involves repetition by definition, it is an excellent candidate for automation. However, many companies cannot afford (or at least decide
not to afford) investing in automated regression testing. SwitchLane provides specialized testers who know how to automate repetitive tests for
this purpose, when a client is willing to invest.
In addition to the types of testing described on the other tabs, there are lots of other types of software testing as well. Names and definitions
tend to vary, but below is a list of other common types of testing along with definitions that we see commonly used.
-
Integration Testing: Once individual components have been unit tested, they need to be tested together to ensure that they
interact properly. This type of testing focuses on exposing defects in the interfaces and interactions between components.
-
Smoke/Sanity Testing: Smoke or sanity testing consists of a minimal set of tests to ensure that a software build seems to be
generally operational. This is typically done when a new build is produced to determine if it is worth proceeding with more detailed testing.
-
Performance Testing: Complex software can take a long time to execute and may need to be optimized to minimize this time,
especially if a user is waiting while the execution happens. Performance testing is done to verify speed of execution under varying workloads.
-
Load Testing: As more workload (number of users, amount of data to be processed, etc) is put on a system, it may not only slow
down but stop functioning correctly. Load testing is primarily concerned with verifying whether a system can continue to operate under certain
workloads.
-
Security Testing: In today's world, software security is more important than ever. Security testing focuses on exposing
vulnerabilities in a system that could be maliciously exploited by hackers, so that the vulnerabilities can be fixed or minimized.