|
Acceptance TestBy Uzi Shuri |
|
This article is presenting two acceptance test approaches. The article presents the two acceptance test phases. In addition the article is emphasizing the acceptance test importance main goal of being the last quality gate before implementing the software in real live environment.
Acceptance test activity is a list of defined tests which allow the customer accepting and approving working software functionality.
In a project life cycle the acceptance test activity is starting right after system test is completed. When acceptance test is finished the software is actually approved and the functionality will be implemented in real live environment. Acceptance test is the last gate before going live.
There are two phases to acceptance test activity.
The first phase is short and fast, some people call this part sanity tests. There are three reasons to perform it.
1. Customer location - Running the system on customer physical location using his machines, servers, connections, third parties etc.
2. Financial value – Usually one of the payments is being paid after software delivered to acceptance test phase.
3. A declaration that a new phase of the whole project is stared.
Second phase of acceptance test is the real highlight. The main goal of acceptance test is approving software with no high and critical defects. As mentioned above after acceptance tests the software will be implemented in real live environment, which means there is no room for having mistakes, there is zero tolerance for mistakes.
Acceptance test testers must be very talented and very professional, otherwise defects will not be fully detected during the tests. I was experiencing two types of acceptance test methods or approaches, the goal was the same, but the way for reaching it was completely different regarding the test resources tasks and allocations.
Acceptance test first approach – Each tester will specialize only with one area.
Each tester will be specialist only in one area. An area can be one application, module, external interfaces, infrastructure etc. The tester will understand completely all elements of his defined area. Since applications and interfaces are integrated, acceptance test team will work like a chain work, one test output which produced by first tester will be used as input for second tester and so on.
For instance, Software with GUI application which contains 50 different functions and few of them are producing extract files for second application. One tester use the GUI function and produce those extract files and second tester will load and test the results of the files on the second application.
For the good and for the bad this approch is working fine, but I prefer the second approch, see below and decide.
Acceptance test second approach – Vertical testers
Each tester in acceptance test team will have cross application knowledge and will be able to test vertical scenarios. Meaning that end to end test scenarios will be completed by one tester only. It sounds better than the first approach, isn’t it? The catch with this approach, the second one, is budget. The effort of finding, training and keeping testers with wide knowledge is high, much higher than the first approach.
This approach is perfectly working. There are less dependences or misunderstandings and more quality or satiability.
Few tips for acceptance test
1. Vendor should not perform acceptance test. The customer should.
2. Perform knowledge transfer between system and acceptance test teams.
3. Allocate few free lancer testers to acceptance test team.
4. The whole project should be focused during acceptance test period.
5. IT department should back up acceptance test requirements. |
|
|
|
|
About the Author |
| My name is Uzi Shuri. I am a professional testing adviser. My profession and experience is all related to testing of software. From being a tester to managing big groups of testers, I was experienced all roles and responsibilities of testing in software life cycle. Now, I would like to share it with you. |
|
|
|
|
|
|