Types of Software Testing - a Glossary
It's amusing that software testing is a conversation starter or stopper at a party when you exchange details on what you do for a living during first greetings, depending upon whether you meet a fellow ‘techie’ or not! Software testing doesn't have to be daunting; it can be fun and interesting!
Here are the most popular types of software testing, let us look at what they are and why we do them:
Accessibility Testing - this is important to ensure your software is usable by as many people as possible. It can include people who are deaf, colour-blind, partially blind, mentally disabled, physically disabled or due to old age.
Loosely refers to the first round of testing. The main aim is to find the main types of activities the users would do and run the tests to see if there are issues.
Testing automation by programming software tools to perform rapid tests. This replaces much of the manual effort and time involved from human writing, amending and executing tests. These can even run by overnight unaided.
This is database testing where data is stored - new or existing migrated records such as Oracle and SQL Server. We do this to enquire on record, check for data loss and data corruption.
Loosely refers to the second round of testing at a prominent level. It's type of user acceptance testing, used to find bugs in the software.
Black Box Testing
Black Box Testing - this is a type of functional testing commonly performed in systems testing and can apply to most levels of testing but considers functionality without looking at code structure or internal workings.
This testing looks at different environment configurations, typically web services, hardware, networks etc. Common ones are different browsers and versions, mobile vs. tablet vs. desktops, internal vs. external networks etc.
This is done after unit testing that tests multiple functionalities such as single code, to see if there are any issues when connected.
Also, often called downstream testing. This looks at compete transactional flows and connectivity from start to finish, concluding with the destinations. It also shows successful inter-system handshake, data transformation and receipting exchanges of data acknowledgement triggers and responses.
This is a fun one as it allows artistic license where the tester intuitively navigates exploring areas of the software with no pre-set script or rigid parameters.
Final Acceptance Testing
After successful installation, the final acceptance testing is run to confirm if it's fit for intended purpose – often referred to as commission testing.
This is feature testing in short, like the above. Functional testing is concerned with a single feature as opposed to a complete set of features, products and processes.
Testing application behaviour to see if interruptions disrupt the transactional flow and are managed in accordance with business expectations
This looks at performance, accessibility, reliability, response times, fail over, security to name a few. These help to support the framework of operational systems.
This is checking to see if the software and error handing can manage invalid or unexpected inputs etc. We check to see a useful meaningful and user-friendly error message is displayed.
Looks at the speed, scalability and durability of a system in diverse ways.
Types of performance testing include:
Finding pressure thresholds and bottlenecks under predicted peak user loads.
To understand system behaviour under extreme workloads. Finding the break point.
Testing to understand system behaviour when sudden extreme increases in user activity e.g, ticket sales launch for music concerts.
To show understanding to aid capacity planning and look at future potential ability to significantly increase capabilities, users, products, customers etc.
Testing to understand the system tolerance in terms of system stamina under sustained pressure.
To understand system behaviour under extreme volume. Finding the tolerance and behaviour of systems at various levels.
This testing is to look at unchanged functionality after code change to find if there have been any adverse effects.
A subset of regression and acceptance testing, this testing happens after an environment refresh or bug fix deployment to detect bugs.
This looks at how well the system is under threat from malicious attack, internal and external threats such as virus malware, data security, authorisation, authentication etc.
SoapUI is a free open-source tool which enables applications to communicate and exchange data. We use the tool sometimes for testing where the originating system is not available, to simulate web services as an example.
Site Acceptance Testing
Put simply, this evaluates the functionality and access at the user site before it’s installation to ensure there are no site-specific issues that would affect operational use.
This describes high level testing to check important level basic and common functions are working before a detailed testing phase starts.
This is reviewing documentation before testing execution to find conflict, omissions, anomalies, inaccuracies, contradictions in design which can save huge amounts of money and time when identified and resolved early.
Systems Integration Testing
This done primarily to show that data passes successfully and correctly, from one system to another and considers the movement and transition of data from end to end. The focus here is co-existence and interaction between modules, systems and connected areas or sub / downstream systems. Examples may include marketing/customer emails, financial collections/refunds, print, overnight batch data transit, interaction between mobile & tablet devices, management information and so on.
This has some degree of overlap with UX testing in that it's concerned with the design of the user interface, which directly affects the user experience. It can include how the software behaves with mouse, keyboard or other input peripheral devices attached and whether the visual elements presented are working as expected.
This is the checking that developers/programmers do in isolation on one or more units of code. Their machines reviews their own code. The purpose is to look for inaccuracies, check for consistency/standards in formatting and data integrity.
User Acceptance Testing
Also known as change acceptance testing and business acceptance testing. Mostly owned led and performed by business users. It used to show if the changes in a system behave in an acceptable way to support live business operations and that existing business can be transacted as usual without adverse effect.
This, in simple terms looks at the holistic user experiences in testing - how it looks, feels and how your system users or target audience expect the system to behave. Retail online shopping experience would be a good example for this. The focus is optimising the user experience. Research shows that the user experience drives growth.
White Box Testing
This is testing oriented around the technical structure design and coding, looking at inputs/outputs flow to improve security and usability.
Hope you've found this useful. For more helpful content, read our 'Modern Development' white paper below or alternatively check out our knowledge centre for more useful articles.