Seite - 102 - in The Future of Software Quality Assurance

102 M.Mitev that have tested the software influence the acceptance testing phase toomuch.That is definitely not good if you want to prove that the system does the things it is supposed todo in theway it is supposedto do them. 4.3 Acceptance TestingPerformed by theInternalQA Team The result of doing the acceptance testing with the QA hired in your company and thatweredoing thesystem testingareas follow: • It onlyproves that theapplicationworksas shownby theprevious test stages. • The coverage is quite small and mainly UI—some even argue that this is what most of theusers see, theParetoprinciple. • They do what they do day to day as the corner cases are covered by the Functional/SystemTestingand isprovencorrect. • Acceptance testing is not supposed to find any defects—the things that do not workshall comeaschangerequests, i.e. theprimaryrequirementwasat fault. • Testers should not be involved in acceptance testing as it is a milestone for requirementsand their correctness. 4.4 WhatAre theMainReasons theAcceptance TestingPhase Often Fails? Thus, we come to the point to find out what are the main reasons the acceptance testing phase often fails. It is because there is nocollaborationand nomanagement buy-in. The other reason is the wrong focus—mostly testers focus on how and not what. Besides that, acceptance testing is often neglected; it is fully performed by different and sometimes not suitable tools. And then, when the objectives of the team are not aligned and the skill set required is underestimated, there is no possibility tohaveasuccessfulend to theacceptance testingphase. Therefore, it is quite understandable to see the fear of acceptance testing when it comes to that point in the testing process. It requires a lot of efforts, a lot of good planning and the ability to be able to adjust quite fast to the new realities. It is also not good to underestimate the requirements of the end users involved in that phase—as most of them will not be very good at IT literacy, you should be careful and patient while explaining the system and the steps for writing their test cases. Yes, that is difficult—youusea set of termswith your team and then the end user comes and is not aware of those terms—you will have to change the way you expressyourself andfind commonwords for the terms for the ordinaryworld. But, the result of that involvement should never be neglected—the ideas the end users can provide and the bugs they can find—usually the one you and your team will definitelyhavemissedout.