How to test a fire extinguisher?

Once I asked my dad how to test a fire extinguisher. He answered:

"Very simple! It is necessary to check the expiration date, see that the seal is in place and that there is no visible damage to the case."

"Is that all? But how do you know it will work? How can you be sure?"

"I just know, that's all." - Dad answered.

This question arose for a reason. I was asked the same when I was interviewing for the position of a tester.

I still don't know the correct answer to this question, but since I was hired, I probably answered correctly.

I answered that, in fact, the production of fire extinguishers is an assembly line. At each stage, control must be carried out, moreover, not only control of the quality of materials, sizes of parts, their density, etc., but also control over the equipment used in the manufacture. Also, don't forget about people. They shouldn't get too tired, the schedule should be optimal. Periodically, you need to remove the entire batch of fire extinguishers from the conveyor and check them in the field to determine the percentage of rejects. If the number is small, then everything is in order. But if it exceeds the norm, you need to urgently diagnose all equipment, find out and fix the cause.

Sounds pretty simple in theory. In practice, it turned out differently.

The question is:

Is it possible to put a person at the end of the conveyor and give him the task of making sure that the result is ideal fire extinguishers? What can he do to achieve this goal?

Working in the company, I learned the hard way that this is impossible. We had a lot of problems:

• We did not have any requirements, but at the same time the program had to work without interruptions.
• We did not have enough testers, but we had to have time to check all-excel: the CMS itself, the work of its modules and shared sources, the work of various add-ons and extensions. All this had to work on different versions of the operating system, with 4 different database providers, in several browsers and we only had 3 people for this.
• We had to make sure that clients could use our libraries. That is, all open code could be used in any way without problems.
• Sometimes, when we (the testers) had questions about why it works like this and not otherwise, developers would answer: “Because it is written in the code”.
• The support team complained that customers have many problems and questions after each release.

And this is just a small list of the problems we encountered. We hired a few more testers, but it did not save the day much.

The CEO was unhappy and had every right to do so.

My team was doing all the best to improve:

• We had several hours per week for self-education. We learnt new technology and tool and shared knowledge between each other's.
• We tested our applications from different sides (functionality, performance, security, usability etc.). We had separate checklists and test suites for each type of testing.
• We tried to automate as much as possible (on the UI level and lower).
• We created own knowledge base and any newcomer (not only tester) could use it if he was faced with some installation or environment problems for example.
• Thanks to review procedure we became guru in testing documentation.
• Our estimations were as accurate as possible because we were gathering corresponding metrics.
• We used different templates for reports and they were useful and informative for all concerned.

Despite all this we were still at the end of the conveyor.

CEO of the company understood that it is not enough to hire a good tester, you need to be able to give him the opportunity to do this job well and once, during one of the meetings, he reminded me of how I answered the question about the fire extinguisher and suggested setting up a process not only in my team, but throughout the company.

So, he wanted me to tell developers how to write code, the Support Team how to communicate with customers, and the Sales Team how to sell. It was an overwhelming task for me. But this was not necessary.

The company had excellent specialists who knew their business and really wanted to do it better, faster, and more qualitative.

As a result, we had standards and approaches, guided by which we were going to work in the future:

• In a few words, a coding guidelines and a code review process appeared in the company.
• Our developers created recommendation on how to test security of our products.
• When new versions of the operation system were released, we certificated our products to let our clients more evidence of good work of them.
• Our support team developed new rules of their work process, so that our clients were able to receive hot-fix in 8 hours (not more).

I have not worked in this company for many years, but I always remember those times with warmth.

The Fire Extinguisher has become a symbol of excellent work for me.

From that time I always ask this question at interviews, as well as to my students who come to me for "QA Engineer" courses.

I got the most varied answers, but I only hired those who did not blurt out instantly:

"Break the seal, pull out the pin, press the lever."

Every experienced tester knows to think first. And when you think about it, it becomes clear that even if the fire extinguisher works correctly, it will no longer be possible to give it to the client and say:

"Yes, it's a good fire extinguisher. In a critical situation, it will help you."

And it is not good idea to tell him:

"We tested functionality only. Security and performance testing is not our responsibility."

Of course, not all programs need to be tested like fire extinguishers. There are such types of programs, for the testing of which it is imperative to apply formal approaches, carefully plan and document everything (programs for medicine or banking software). But there are programs for which this is not necessary.

How to decide how thoroughly a program should be tested?

Experience tells me that even the simplest handbook-program can eventually become part of a huge system that will be used on board an aircraft. If the housewife does not find how many minutes to cook potatoes, this is not a problem. But what if the pilot of a supersonic fighter cannot find ejection instructions and as a result forgets to put his feet on the seat footrests?

Each tester decides for himself how thoroughly the program should be tested, but he should always be guided by professional ethics, and not by the mood or limits of the project.

I would really like to test my programs in the same way as those people who produce fire extinguishers. So that about the programs that my company produces, people would say the same as my dad:

"I just know, that's all."

Article Photo by Matt Chesin