Project Management Methodology and Testing

Below are examples of the different types of tests involved in different phases of testing to demonstrate the objective and the different types of individual tests involved in each stage. This is of course an example only and real scripts will include many more tests (as many as you can possibly think of).

The example uses a development where an application is being made to allow input of a Name and Address into a database with Outbound and Inbound update to an external emails contacts system (e.g. interfacing with Gmail).

Note: All examples below are for demonstrating the differences between types of test only and are not necessarily the tests which would actually be present for the example given above.

Unit Test Scripts

Objective: To ensure the application being delivered from development into testing is of a high quality and is efficient and maintainable.

Note: Unit testing is generally on a component by component, method by method basis and much more detailed than described here.

Note: A mixture of internal checks to the program, and more demonstrable test.

Installation Test Scripts

Objective: Ensure the application as delivered can be installed

Operations Testing/Smoke Testing

Objective: Ensure the program is able to be accessed for Systems/Functional Testing (Nothing much worse than handing something over for testing to find the application does not run).

Functional/System Testing

Demonstrable elements of unit testing.

These tests should be documented before the unit testing scripts, as a domain expert writes the specification and these can then also be used as a basis for unit testing). They should then be again reviewed near the end of development to include any changes to specification which may have been made over the duration of the development.

Good system testers will also be able to read code/unit tests and add smart tests post the unit testing phase. It is worth spending money on getting a good system tester who will cover additionally tests from other areas as part of his/her own tests for functional test).

Back up the functional test scripts with screen prints/report layouts/wireframes to avoid any ambiguity

Functional test scripts can be split into Sense Checks (which can be repeated on future rounds of testing but where more detailed tests are required for a change but need to be supplemented with some more general testing, similar but more detailed than Operational Tests) and Full Checks which test every individual point against a specification.

Testing referenced should be cross referenced with specification points, in the specification.

End to End /Integration Test Scripts

Objective: Check that existing, already developed, systems allow data to flow seamlessly back and forth with the new application and that security is reflected correctly in the target environment. Can be started in parallel with functional system testing, and must be allowed to complete on final version.

User Acceptance Test Scripts (UAT)

Objective: Allow the end users to confirm they are happy the new system is easy to use and meets the objectives and requirements.

Note: Scripting can start immediately in-line with the functional testing scripts, but need to be revisited 80% though system testing to pick up any changes which may have been made.

Note: You should include scripted tests and then also add an additional session where the user invents some of their own tests in the same style as they have had provided, to allow them to report any issues in areas you may not have considered .

See our User Acceptance Test guidelines checklistfor more information.

Performance and Capacity Testing

Objective: Ensure the target system can handle load.

Note: Functional and end to end testing has to complete before these tests are ran, a run can be made near end of these tests to prove the scripts.