The customer is always right

The idea for any project usually arises from the need to solve a business problem or drastically improve an existing business practice.

In other words, the system that will be developed will either replace some archaic paper driven procedure, or else improve the performance of an existing computerized system. In either case, there is always a common goal, that of providing more benefit to the business.

To fully understand and identify what the solution must do to provide the maximum possible benefit, workshops are organized. The people attending these workshops should include not only technical and management personnel, but also the end users as ultimately, it is the end user who will use the system to carry out his or her day to day tasks. If we are trying to improve a business practice, then the user must be involved from the start and in fact, constant communication with the user is imperative throughout the whole project. If this is not given its deserved attention, a project could  very easily fail. This is one such story.

The aim of the project I was working on was rather simple; provide a fully functional booking and ticketing system for a cinema. The client had a very old non-computerized system and wanted a more modern, up to date solution.

Now as you might think, this is not a very complex system. In fact, the amount of time spent on developing and testing was minimal when compared to other huge projects. There wasn’t even the need to issue incremental releases. I remember attending only one single workshop at the start of the project to break down the requirements and that was it. Off we went jolly hopping like the seven dwarves, confident and convinced that this project was a piece of cake. Little did we know.

Soon thereafter we were ready to issue our first release. A demo was set up with the client. One of the people present for the demonstration was an end user, a young lady who works at the cinema ticket booth. We had never communicated anything with her or any of her colleagues before. Not even in the initial workshop, zilch, nada. Somehow the lady’s bosses didn’t feel the need for her or anyone on her team to attend. That should have set off alarm bells as all the warning signs were there, but we just didn’t see them.

We proudly showed off the system, going through all the fancy screens. There was one particular screen that displayed the layout of the theatre with different colour coding for the seats, indicating their availability. Management looked impressed, and we were feeling good.

Then, half way through the demo, the young lady raised her hand. She asked a simple question; how long would it take to issue a ticket with this system.

We couldn’t provide a definite answer. She stood up and assertively said “Listen, I don’t really care about all the fancy colours and graphics you’ve put in the system. I’m in that ticket booth every single day and I know what goes around. You have a 150 people waiting in line, frustrated and calling you names because you’re not quick enough. If with this new system it will take more than 5 seconds to issue a ticket, then I’m sorry, but it’s completely useless to us.”

She literally threw our project out of the window with that statement. And worse still, she was perfectly right. Had we communicated with her from the start, we would have provided a solution fit for her needs. A solution that would have ultimately provided the maximum business benefit.

What would I have done differently in hindsight? Well, I’d have set up several meetings with the various stakeholders and designed prototypes to supplement the initial requirements gathering workshop. I would definitely not have been happy with just one single demo for users at the end of development. In fact, we should have demoed the solution to real users very early on, so that any concerns could have been addressed earlier for much cheaper, rather than much later for more money and time. And if I got resistance from the powers that be at the cinema, I should have simply explained the above and insisted!

On a related note, here’s how to use interviews to gather requirements – https://reqtest.com/blog/how-to-use-interviews-to-gather-requirements/ and how to use pair-testing for better acceptance testing – https://reqtest.com/blog/newsletters/use-pair-testing-for-better-acceptance-testing/

Confessions of a Tester is written by Johnny, a test leader by profession and friend of ReQtest’s. Johnny loves clean code and is suspicious of anything that seems to be completely bug free. Apart from bug tracking at his day job, Johnny plays guitar, watches action and gangster movies and is a great fan of comic books and superheroes. This blog is a chronicle of Johnny’s Software Testing Nightmares.