Types of Testing

There are many ways a site or application can be tested. I am going to explain a few of the most common types.

“Black Box” and “White Box” Testing

Black Box Testing is a way of Software Testing that examines the functionality of a website or application, without looking at any of the website’s code. The tester knows what the website or application should do, but doesn’t know how it does it. An example of this is: A tester without any knowledge of a website’s code, tests webpages using a browser, inputting data, clicking buttons and checking the actual outcome against the expected outcome.

White Box Testing is the opposite to Black Box. This is where the internal’s or code is tested. A Tester or Developer could carry out this type of testing, as an example, a developer could study the code of a particular field of a form on a webpage. They could then determine all valid and invalid inputs and check the outcome against the expected outcome.


TDD (Test Driven Development)

Test Driven Development is a type of testing that is written before any Development has taken place. This will fail the test. The developer will then write just enough code to make the test pass. This type of testing follows a particular cycle:

Create a Test > Run Test > Fail > Write Code > Run Test > Pass > Develop Code > Repeat.

TDD can allow a Developer to take small steps by following the process of code > test > repeat if required. It allows them to focus on the task as the main focus is to make the test pass. A test case can be a User Story.


BDD (Behaviour Driven Development)

Behaviour Driven Development, similar to TDD is written before any Development has taken place. The Project Manager or Client would explain particular behaviours they want the site to carry out. The Developer would then code or build the site, just enough to make the particular behaviour occur. Validation tests often occur to test whether the Website or application carries out the expected behaviour.


Unit Testing

Unit Testing is creating several Test Cases all independent from each other. This type of testing is commonly automated but it can also be manual. The purpose of Unit testing is to isolate a component or a piece of code and see if it works as expected. It is usually carried out by a Developer in the Development phase of the website.


Smoke Tests

Smoke Tests are quick tests that are done throughout the development of the site. This type of test checks that there are no critical bugs that would stop functioning of the site. It is done as minimal as possible as bigger tests will occur in later stages.


Load/Stress Testing

This type of testing is a way of seeing how much capacity the website or application can handle. Load/Stress testing, tests whether the website or application can handle the expected capacity, then keeps adding until the site breaks, so Developers can see what the limit is. The amount of users or inputs can be tested with this. The performance can also be tested as more capacity is added to the site.


UAT (User Acceptance Testing)

User Acceptance Testing is gathering users who match the Target Audience to test the site for problems in Navigation, Text or Visuals. In some cases, the testers will be given particular tasks on the site so you can see how difficult they found it and if anything can be changed or improved. UAT Testing can also take place from the designs, or paper sketches. But it most commonly takes place on Prototypes or Development sites.


Regression Testing

Regression Testing is testing the whole Website or Application after an update or change has taken place. This is useful to find bugs in unexpected places. In some cases, the process involves screenshotting a page before the change, then screenshotting after the change and comparing the two. This can happen throughout any stage of the Website or Application Process.


Alpha, Beta and Release Candidate

Alpha Testing is when a site is 60-80% complete, and happens just after the initial QA testing. It is a way of finding bugs and asking: Does the Website or Application work? Participants of this type of testing will include users who match the target audience. Alpha Testing is complete when the website or application meets the design criteria and there are no longer any critical bugs.

Beta Testing happens after Alpha, when the site is 80-90% complete. It is a way of seeing how far away the site is from being ready for release. It also answers the question: Do customers like the product? Beta Testing is complete when users who match the target audience have tested the site, and are happy with the experience and features of the Website or Application.

Release Candidate happens after Beta. This type of testing occurs when the website or application is almost complete and essentially ready for use. This type of testing answers the question: Is the site ready? This type of testing acts as a final test before the site is deployed, to find any bugs or problems missed from previous tests. There should be no difference in the Final Build and the latest Release candidate.


Continuous Integration

Continuous Integration is a type of automated testing. This type of testing can occur after particular triggers or at set times – usually at the end of the day or overnight when no one is working. This test can also be set to run everytime a change has been made to the site, to ensure the site is still running as expected.



Behat is a type of BDD Tool, meaning it tests whether a particular behaviour takes place. It is all automated, reliable, human-readable and typically written in the Command Line. Behat testing can happen at anytime throughout the Website or Application Development. Behat Testing follows this template:

Scenario: Some description of the scenario
  Given [some context]
  When [some event]
  Then [outcome]

In my project I decided to test a Contact Form. I carried out 2 separate tests that checked validation. So mine looked like:

Scenario: Filling in a webform with all required fields
  Given: I am an anonymous user 
  And: I am on "/contact"
  And: I fill in the following
  | name    | test name     |
  | email   | test@test.com |
  | number  | 07070707070   |
  | message | Test Message  |
  When: I click submit
  Then: I should see "Message Sent"
Scenario: Filling in a webform without all required fields
  Given: I am an anonymous user 
  And: I am on "/contact"
  And: I fill in the following
  | name    | test name     |
  | number  | 07070707070   |
  | message | Test Message  |
  When: I click submit
  Then: I should not see "Message Sent"

On the second test, I didn’t enter an email which is a required field on the form. Therefore I should not see “Message Sent”. You can also see I used ‘And:”, this can be used as many times as required to add more context to the test.