|
Component Testing
Starting from the bottom the first level is “Component Testing”, sometimes referred to as “Unit Testing”. In theory an independent tester should perform the testing for this stage, but in practice this is normally
completed by the developer. The components are such a small part of the system when they are running on there own & normally only complete one specific process. The testing of these components is normally within
an isolated environment performed by the developer as they complete the development and confirm the component works. This is not the preferred practice but often the reality.
Interface Testing
As the components are constructed they can be linked together to check if they work with each other. Interface testing is not focussed on what the components are doing but on how they communicate with each other. The
Interface testing is linked to the System Design as it defines the relationship between the components. This involves stating :
1. What a component can expect from another component in terms of data format, content, size, frequency, “Service”
2. How to handle nonstandard conditions, i.e errors.
The tests are organized to complete all the interface testing, completing the data ‘flow’ from the first components interface through to the final component. Each interface test is performed and verified
independently from other interfaces.
System Testing
System testing is the first time the entire system is available to be tested as a whole. Confirming functionality and information flow of data through each part of the system. The testing must meet the “System
Specifications” and although still developer focussed the testing is completed by specialized developers known as system testers.
System Testing can involve a number of specialized types of tests to check Performance, Volume, Stress, Limit and Documentation.
Performance - Are the performance criteria’s met?
Volume - Can the larges of anticipated volumes of information be handled ?
Stress - Can peak volumes of information be handled and how is the performance impacted at these times.?
Limit - Testing the system to break point, confirming when, where and how the system will break and what is required to restore it. This testing should also confirm certain disaster recovery requirements detailed
within the system specifications.
Documentation - Is the documentation useable for the system ?
Acceptance Testing ( UAT )
Acceptance testing checks the system against the “Requirements”. It is similar to the system testing in that the whole system is checked, but the important difference is the change
in focus.
System Testing checks that the system which was specified has been delivered.
Acceptance Testing checks that the system delivers what was requested.
Acceptance testing looks to confirm that the new software and system delivers and performs what the business requires. The best people to decide if the requirements have been met are
the real business users who have been using the old system on a day to day basis. This is why this phase of the testing is normally referred to as User Acceptance Testing or UAT.
UAT is known under many different names depending on the company or people you work with. During my career within testing I have heard it called “Beta testing, QA testing, Application testing, End user testing and
even Model office testing. Often users do not have the time or the understanding to complete UAT and specialized testers are employed to liaise between the users and the system specialist. This, along with system
testing has been predominately my position within many companies.
The concept of User Acceptance Testing is to use the system as the users would, including every process and functionality that the users would use. These are the easy to identify functionality’s, and the users are
best used to complete or identify these tasks. The system has been designed specifically to complete these tasks and normally a well developed system will stand up and look good with this type of testing. The
specialist areas of UAT come with performing the tasks which the users will do but the system was not designed for. These areas of defects are the ones specialist experience testers will identify and test for. A few
examples of the type of defect which are discovered may explain this clearer.
- A HR system required that a user logged in with user id and password, it was discovered that if the user entered the number 0 within the password the system allowed the user access as long as the id was correct.
- A very well known online web site which sold books as one of their main products, released software for end users which included credit card transactions. The general concept of the site was that the user
would select a book, enter the quantity of units they required and their credit card was approved and payment was made. It was discovered after the release that if a user entered a negative quantity then the
credit card would be credited rather than debited.
- A time and expense system allowed the user to give an explanation for the expense within a narrative box. The anticipated text length from the business was not specified within the design documentation, however
upon discussion it was agreed that a brief explanation consisting of less than 120 characters was what was expected. Further to UAT it was discovered that the narrative field populated an Oracle database field
which was restricted to 255 characters. If an expense was submitted with more than 255 characters not only did the expense reports crash during submission but it also froze the users machine forcing a
reboot. As a resolution to the defect code was written before release advising if the narrative box contained more than 255 characters and forced the user to remove some of the text. Within 3 months and
only half way through the system roll out, the business users requested the narrative size to be increased to a 1000 characters
Release Testing
Even if a system meets all the requirements, there is still the case to be answered that, will the new system benefit the business and meet the initial business case.
Release Testing identifies if the new or change system will work in the existing business environment. Mainly this means the technical environment and checks concerns such as :
Does the new system effect any other system
Is it compatible with other systems
These tests are normally run by the operation team within a business and their opinion to the impact of the system should have been asked during the Business Case stage. They would have identified new hardware if it
was required and ongoing costs can now be confirmed and maintenance processes finalized.
|
