Explain like I'm 5: What is ISO 9001 and what would it mean for me as a (currently) solo tester?

Questions
#1

My employer is considering using ISO 9001 (we provide metering and billing for energy providers). I’ve taken a look at the ISO website but it’s very corporate and I struggle a lot with understanding things that I’m not immediately “interested” in.

My employer also hired me in March to introduce testing to the company (I started testing in 2012) and I’m a little concerned at the checklists ISO 9001 mentions. It looks like it might step on my toes.

Edit: I’d also like to add that my line manager hasn’t outright said we’re using it, just that we’re considering using it. He also mentioned that because I’m good at process and sticking to it, I could be a good candidate for being the one who whips people into shape about sticking to the ISO requirements, but it will not be forced upon me if we do go down that route.

#2

ISO9001 explained to someone who is five:
Kid: “I’ve cleaned up the room.”
Parent: “Can you show me the puzzle you were playing with?”
Kid: [Opens the puzzle box.] “It is in the box.”
Parent: “Where are the markers?”
Kid: [Opens the drawer.] “Here they are.”
Parent: “Well done.”

Around 2000 I worked with ISO9001 for a test consultancy firm. It basically meant that all consultants follow the same processes. A lot of customers required a quality system and ISO9001 fitted the bill.

The most important process was how I would do my job at the customer’s site. There were checkpoints to assure that this was the case. E.g. my resource manager would visit me at regularly to talk about the progress and any challenges. He would write a small report about it. This was a proof.

In the years afterwards I saw other standards like ISO27001, a standard for information security management. There were a lot of similarities with ISO9001: process flows and documentation ared needed as proof that the process was followed. Auditors would check my test artifacts every year.

Some things I learned:

  • management should communicate regularily about the quality system in a few sentences. “We have an order from an important customer. That is because we use ISO9001. Please stick to the coding standards.”
  • every manager is responsible for the adherence to the process of his or her team. This basically meant that I would not control the work of another team.
  • a quality system is a team responsibility. If a programmer codes, then he/she should follow the process as described. This is not the work of a tester. Of course I can mention some gaps looking at the Definition of Done.
  • checklists can become outdated, if the process is described in too much detail. E.g. we try to work in a more agile work. So there is no detailed functional specification document any more.
  • processes should be described at a high level. For testing I used the Deming cycle as a basis: Plan Do Check Act. This can be used in waterfall and agile situations.
  • It is recommended to do an elaborate check twice a year. This way missing or incomplete documents and problem tickets can be updated in a timely matter.
  • Processes should be made with the parties involved. E.g. Is an “automated test” needed in this particular case? Is the word test enough? You could automate it, when needed.
  • if I had to check the documentation for an audit, I asked help in a casual way. In an Agile team I could make separate ticket for the sprint.
2 Likes
#3

ISO in general provides high level frameworks/requirements. ISO 9001 is a standard for quality management systems. In practical terms, satisfying the ISO requirements generally involves building a lot of formal processes.

#4

Is helping maintain ISO 9001 a full-time job? I don’t want to agree to be on the team that enforces it if I’m not going to have enough time to do my normal testing work - I only work 4 days a week as it is, so I don’t want any risk of doing more hours.

Do the formal processes mean that some aspects of testing change?

How come in your instance, Han, got rid of functional specifications? I’ve spent a long time getting one together for my employer to help improve process and understanding for the team and don’t want that all to be for nothing, or abandoned, especially as I personally don’t work in sprints.

1 Like
#5

Worked at a place where we considered 9001 qualification. It requires hiring one in every 50 people just to look after the process full time. Which is where that bi-annual review of all processes comes in. We ditched, but we did learn a lot. I would happily work for a company that was required to follow a standard, I love traceability. But, all I can say, is, don’t ask for more process, the 9001 manager in the company might (will) take that as an invitation to offload work.

There are plenty of short cuts to be found in any standards process, the biggest one for me, was to never document anything, that is arguably implicit.

3 Likes
#6

The things have to be done for ISO9001:

  • set up processes.
  • stick to the processes.
  • prove that you sticked to the processes.
  • adjust the processes.

The most additional time is spent writing good processes. It is possible to leave this to other people. There is a risk that testing might be described in undesirable way. Input and review should not cost more than 1 working day, unless there is a long process compliant with the way of working of the customer.

My suggestion for processes is Keep it simple.

Sticking to the processes takes a small additional time in an Agile environment. For a Waterfall environment it is hard to determine. It is important to add time for ISO9001 in the planning.

Proving that you sticked to the test processes can take 1 day. If the administration is not uptodate, then it will take more days.

Adjusting the processes does not happen often. Also in this case Input and review should not cost more than 1 working day, unless there is a long process compliant with the way of working of the customer.

The formal processes should impact testing in an achievable and helpful way. I would describe the current process and add some small improvements after talking with other people.

ISO9001 is not a full time job. If this is the case, then things have to be fixed. It is important to determine your scope of work for ISO9001.

“E.g. we try to work in a more agile work. So there is no detailed functional specification document any more.”
In this example I wanted to highlight the use of detailed names for documents.

Let me project this to your situation.
Suppose my firm uses a detailed functional specification document as stated in the process. After a while this document is replaced by a high level functional document and a technical document, because the customer did not like all the technical terms.

At this moment my firm does not adhere to the process: the wrong documents are used. It is better to use a more abstract term like design documentations in the process description.

1 Like