Here’s a real-life story that shows the importance of End User Acceptance testing and what happens if this is skipped.

———————-

Just doing an upgrade

I was a systems analyst in a project for a client once that involved an upgrade for an Enterprise Search application. The application allowed users to locate documents that were scattered across different locations and was one of the important tools that the users relied on to do their job.

The tech guy who was doing the upgrade had worked many, many hours.

The job was not complex, but the server on which the application was installed was also used for other things and so, there were starts and stops as others demanded their own slice of time to do maintenance on other apps running on the system.

Time to test

Finally, Techguy had finished the upgrade. He made sure that all the settings were still correct and that the software was still able to give the logged-in users access only to the documents that they were allowed to see.

Techguy ran the software and checked that there were no errors.

Everything looked fine. The documents were being returned OK.

He did further testing, by physically eyeballing a document in the system, checking the content, and then doing searches on various metadata, as well as content searching. Yep, system worked well.

Techguy even performed Regression Testing, following a scripted Regression Test that he had written. It went through the whole process of creating a document, sending in for review, getting it approved, changing the status of the document, etc.

Everything checked out beautifully. Techguy proudly confirmed that the system was working fine.

Then the errors started

Then the users were allowed back onto the system. Within hours, tickets issues were being lodged. It seemed that the documents that were being returned in a Search were not opening. The user would click on a search result, and get greeted with a page not found error.

Techguy was called back in. He started looking at the system. Everything looked OK. He was told to look harder. After much scratching of head, and flicking back and forth between various screens Techguy looked up sheepishly. “He had forgotten to add one critical setting – the address of the computer that would allow a document to be displayed.

It turns out that all the Search application could talk with most of the computers involved, but when it came to doing the indexing, but when a request was made to open a document from the search results, a different mechanism was used. If the address of another server is not correctly entered, then a big fat nothing happens when a user clicks on a search result.

End User Acceptance testing – Test as a user, not as a techie …

Techguy was just that – a tech guy. When he did the upgrade he was a tech guy, and when he did the testing he was a tech guy. And

When he did the upgrade he was a tech guy, and when he did the testing he was a tech guy. And as a tech guy, he had focused on the technical side. He had made sure that all the main knobs had been turned, he had made sure that the process of indexing was working fine. He had even made sure that the system was returning search results as expected. The one thing that he hadn’t done was to try and open one of the documents that was returned!

 

Techguy’s oversight raised a very important point.

As well as technical guys doing technical testing, end users are also required to do end-user testing.

Why? Because the end user does stupid things that the technical people never expect…they actually use the system. And, even if there is a Standard Operating Procedure in place, users tend to use systems in ways that the technical guy would never think of.

---

Recommended Resources 

[Important Disclosure]