Hello fellow dev.to-ians! I know of three types of software testing. Unit, integration and end-to-end. But I've just recently heard about Acceptance testing. Anyone willing to explain to me what it is?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (3)
It can depend on the context, but I think about it a particular way in regards to building software for a client. Another way to say acceptance testing is UAT or user acceptance testing.
Let's say your client is a child. They want you to build them a toy. Specifically, they want you to build them a ball.
In the requirements, they want the ball to bounce. In more detail, they want the ball to bounce up to their head when they drop it.
You get to work on building the ball. Once you're finally ready to deliver the project, you give the ball to the child for them to run through their acceptance test. If the ball only bounces to their knees, the acceptance test fails and they'll tell you to get back to work.
The value of UAT is after the acceptance test passes or in our case, the child says the ball is great. At this point, the project is considered done since the acceptance test passed. If the child comes back a month later complaining about something, you can point back to the passed acceptance test and ask them for more money to fix it.
Awesome explanation. Answered all my questions. Thanks a lot for this. :)
Adding on to the example, the child's parents may also be part of the acceptance test to check for things like toxicity of the ball (safety/legal/compliance review) or to make sure the ball is durable (operational review.) The child may just want a ball that bounces high, but other parties involved (the parents) want a safe ball that will last.
In an ideal world, all requirements are captured up front, but in the real world many things like this (legal, operational review) are done as part of UAT.