Some of my UX colleagues have been working with software engineers recently to test their products. It was fascinating to see the different ways that each side viewed their tests as they worked together to create a testing plan that satisfied both.
The UXers saw the engineer’s goals as a bit strange. This quote says it all.
How can we gain any insight from them if they provide such detailed instructions?
Although I was unable to speak with the software engineers, I can imagine they would have seen the same problem from the other side. How can you get any actionable information if you don’t give detailed instructions?
Here’s the deal: both test are vital in understanding how your product works (app, software or website). They simply answer different questions about how your product works.
This means that a product can work in one way and not in another. This is a common reason why products fail. They may accomplish something important but do so in a confusingly difficult manner. Let’s take a closer look at this.
Read also:
Best Automated Tools for UAT
User Acceptance Testing
The last stage of software testing is user acceptance testing (UAT). This is where a product or program is tested to determine if it is suitable for its intended purpose.
- Fulfills business needs
- End-users can use it
User Acceptance Testing is a process where people, often from the target demographic, test the software to ensure it can perform the tasks required in real-world situations.
User Acceptance Testing is a critical step in ensuring that software is ready for release to the market.
User Acceptance Test can also be called beta testing, end-user testing, or application testing. It’s the final testing after all the functional, system and regression testing are completed.
Read also
UAT plays an important role in Software Testing
Software development is not complete without user acceptance testing. According to the International Software Testing Qualification Board (ISTQB), UATs are defined as follows:
Formal testing based on user requirements and business processes. This is done to assess whether or not the system meets the acceptance criteria. It also allows customers, users, or any other authorized entity to decide whether to accept or reject the system.
This can be viewed as a machine. Let’s imagine it as a car.
We’re going assume that you have tested the car for any’showstopper defects’ before you make it available to buyers. The ignition key won’t cause the car to explode. You have brakes and your wheels can turn left and right. The engine should be able to be tuned up or down so that the wheels turn faster.
However, just because something is there, such as brakes, acceleration, steering and ignition, doesn’t mean it is available to the driver. This is the place where a user accept test is used. It is designed to ensure that the driver is satisfied with their interaction with the machine. You get the right output when you have the right input.
Read also:
User Aacceptance Testing: 7 Main Steps
A UAT confirms the following:
- The engine will start if you press the button or turn the key.
- If you turn the steering knob left, the wheels (and the car) should turn towards the left.
- The car accelerates when you press the accelerator pedal.
- The car will slow down if you put your foot on the brake pedal.
User acceptance tests must be very clear in telling you what to test. It is important to verify the functionality of each component of the car. We won’t let you sit there and try to figure it out. We’re done once you have entered the instructions into the car and it returns the correct result.
So far, so good. These are all crucial questions. These are not the important questions usability tests are designed to answer.
Usability Test
Let’s start by asking a few questions about cars before we get into the usability testing.Why???
- Why are the accelerator pedal and brake always to the left, but the accelerator pedal is always to the right? If you drive stick, the clutch is always to the left.
- What is the sound of clicking when turning indicators are turned?
These questions are a little confusing, I know. It’s how it is! This is the essence of the difference between user acceptance and usability tests.
Keep in mind what we just talked about — the user acceptance test is there to check whether the indicators and pedals work . It doesn’t matter whether the brake pedal is to the left or the right; if the car slows down and the driver presses the brake, it’s a pass.
Yet, I can guarantee you that if you build a car with the brakes on the right and the gas on your left, it will fail. Anyone who has been to driving school or driven many cars before will be able to drive this car with the following mental framework:
- The left pedal can be used to slow down.
- You can speed up by using the right pedal
This is how it might look in your car’s new reversed version.
Also, a usability testing is not really about testing. based on what your user wants and expects They will be able use the product to achieve what they had planned to do. This is a very different question than whether the product works correctly given a particular input. It now involves many fuzzy, human factors. These factors include:
- What the user is used too without thinking
- What kind of cues is the user looking for?
- The user’s view of the “correct” way to do a task
An example of how cars consider these factors is the way that a car sound. The modern car, driven mainly by electronic circuits, circuits, and the like, is very different from older models, which were mechanical. The clicking sound you hear when you turn on your turn indicators is actually caused by the spring clicking back-and-forth to turn the light on and off.
These lights are no longer controlled by springs. They probably haven’t done so in over 30 years. Why is that clicking sound still around? It’s because drivers expect it to be feedback. You might be thinking:
Are my lights dimmed or is the indicator on? What is the matter?
It might be necessary to shift your focus to the green arrows at the dashboard and take your eyes off of the road for a second. This would be disconcerting, inconvenient, and even dangerous if you drive at high speeds.
Usability tests are therefore more task-oriented. Instead of asking drivers to “step on the brake pedal to the left”, you ask them to “slow down the car”. This is how you determine if the driver has the same idea.
What if he doesn’t put his foot down properly and revs the engine? Although your car may be functional, it is not working well for you. This is going to be a problem.
Read also:
UAT Software Checklist
Working Together
These different goals determine the appearance of the tests. However, neither test can replace the other.
It is very difficult to run a usability test that covers all technical functions that a UAT needs. It would take too much time to run and would provide very fuzzy data that will not be useful for engineers.
However, the UAT itself will not provide you with the fuzzy data necessary to design a product. Although it is possible for something to work perfectly, it can also be frustrating, confusing, or even dangerous. The driver who doesn’t know if the silent turn indicator is turned on slows down and is then kissed in his rear by another car.
Read also:
UAT in Agile
Both UATs as well as Usability tests are essential for determining if a product can be used. They still have the same ultimate goal. They are done because we want to make sure that when we build something, whether it’s a car or an app, it makes life easier for our most important customers. The user.