0

What is a QA Sign Off?

The ultimate goal in testing is proving that the system in question is ready and fit for purpose. The official way to do this is via a formal process called a QA Sign off.

What is a QA sign off? It’s the test team’s, or quality assurance (QA) in this instance, method for formally declaring the completion of testing. This declaration is recorded and referred to if required after testing has completed.

What is a QA sign off criteria?

To make the decision that testing is complete, obviously you’ll need some kind of criteria to make sure that you’re confident that the sign off has been completed. This criteria is the agreed exit gate definition that governs when testing is complete.

Is this usually documented in the Test Plan?

The answer is, yes. The exit criteria is typically listed as one of the main headings in the Test Plan, as well as the entry criteria.

So effectively, the QA sign off is the actual declaration of testing completion. And the criteria of this is typically documented in the Test Plan.

How does this relate to the Test Entry and Test Exit Criteria?

The Test Entry criteria is effectively the list of requirements to govern when testing can start.

For example:

• Is the test environment ready for testing?
• Are all of the prerequisites needed to test been done?
• Has the data setup been prepared?
• Has the Test Plan being formally signed off?
• Test scripts available in your test management tool of choice? (for example ALM or whatever you may be using, JIRA or whatever the case may be.)

With regards to the exit criteria, we spoke about this in greater length earlier

What is an example of a QA sign off criteria item?

Following on from what we discussed earlier, when I explained the different types of exit criteria. One other example of a QA sign off criteria item is:

are all of the priority tests being executed?

I say, “Priority,” because in some cases where you have really been time-pressed to complete a test phase, you may agree that you can perform the top priority tests and the lower priority ones.

For example it might be a test that focusses on a more cosmetic test, for example checking the labels on an e-commerce order form.

Another example is:

No P1 or P2 criteria defects are in the system at the time of completion.

And maybe another example, one that i’ve used in my experience is,

Minimum of 5 P3 defects with documented and agreed plan to fix after go-live.

This sign off criteria definitely needs to be agreed upfront. It can’t be an afterthought once you started testing. Because the worst case, there’ll be an argument about when you can actually finish testing, because one party may feel that you haven’t done enough.

So , to avoid this, it’s essential that this exit criteria is agreed upfront, and documented. And the document is signed off. Now in reality, getting the Test Plant signed off before testing starts, believe it or not, doesn’t always happen.

And sometimes there’s a battle to do this, because for some unknown reasons there’s people within a project team that are frightened, in a way, to sign off a document, because they don’t want to admit any liability in case anything goes wrong down the line.

But theoretically in testing, you’d want the sign off criteria out of the way and signed off at the beginning. The agreement of the criteria is a collaboration of team members.

Who is responsible for agreeing the QA sign off?

The responsibility is a collaboration of all interested parties. And these parties usually will be the Business Analyst (BA), the Test Manager if you were the test lead in this instance. And the Program manager or Project Manager

How Do You Actually do the Sign off?

This is subjective, depending on where you work and how your company works. But effectively the most common way is in the form of an email that is sent out.

And who this email goes to depends on your company. For example, it might go to the project manager, and it may come from the test manager.

Whoever gets it, ultimately it is basically a simple email.

How do you approach writing a sign off email?

Really and truly this doesn’t have to be War And Peace. This has to be very basic and simple, and get to the point. So a very simple email just explaining that you’re happy that the testing has met the exit criteria is fine.

It’s important that you explained the exit criteria, because you don’t want to this be a subjective statement. You want it to be based on facts. So you want to relay it and relate it to the exit criteria that was agreed.

So for example you might say, “The testing has met the exit criteria as documented in the Test Plan section. Blah, blah, blah.” And then you may relist the items in the exit criteria, and then you will just explain how you’ve met that.

For example if you had 300 test cases to run, and 200 of those test cases were priority one’s. And the agreement was that you had to at least complete the priority test cases, then you would state that 200 test cases of priority one have been done as per the exit criteria.

So it’s just listing out how you have come to the conclusion that the testing has actually complete, and keep it as simple as that.

What happens if you do not meet all of the criteria?

This happens quite a lot of time. Like for example, you may have a very strict deadline to meet. But then once you meet the deadline, you may find that you don’t actually complete all the tests.

You haven’t actually met all of the test exit criteria, and you have to make a call as to what happens next. And this is typically in a form of a conditional sign off. And a conditional sign off is effectively a way of agreeing that the testing will be accepted for completion, but with some conditions as in certain functionality will have to be tested at a later date.

Or you’d have an agreement for a workaround for a problem that you’ve discovered in testing, and therefore it will be accepted with those conditions.

So what is a checklist in testing?

A checklist is a catalog of items that are typically recorded for tracking. This list is ordered in a sequence. You may or may not be ordered in a sequence. But it’s effectively just the way to work out exactly what needs to be done for testing.

And it’s a checklist much the same as anything that could be used outside of the context of testing. But that effectively is what it is.

What is a conditional sign off?

As briefly discussed earlier, the conditional sign off is ultimately a way for you to have acceptance of exiting the testing, but with a list of agreed conditions to move forward.

Related Questions

Why do you really need a QA sign off? Why not just stop testing and then just go into production?The sign off is quite important, because it is a formal process which is recorded and can be looked back to if there are any issues in the future.

Also, it’s a way to get buy-in that everyone accepts that testing has completed in case there are any issues. And it’s the way to prove that you’ve met the actual exit criteria.

Basically its a way to cover your back and get something documented. As projects go into production and issues crop up in the future, then there may be a need to have some traceability about how things were tested. And you may be challenged on these in the future. So it’s always good to have an agreed sign off.

Is there a sign off required for UAT testing? In the same way as you have the QA sign off, UAT testing (Click here to see the difference between UAT & SIT) definitely is required to be signed off.

This is quite critical as well, because this is the acceptance from the actual stakeholders or the customers that are gonna use the software in production.

For this reason it’s important to get their buy-in. This proves that they’re actually happy with what they seen. Believe me,  this is critical. When things go into production, if things don’t go correct, if you’ve got QA sign off andUAT sign off, it makes your life a whole lot easier.

Who Signs off the UAT testing you may be asking?

So as I said before, the UAT testing it typically signed off by a nominated product owner. And this might be someone who is very skilled in that particular function of not necessarily testing, but actually uses the product day-in, day-out.

For example, if you were working on a finance system, and it was an invoice inventory system and you had someone who’s day job was to use that every day. Then they would be the perfect candidate to actually do UAT testing. This is Because they know how the system should work. After they they are informed about the new functionality, they can make a decision if it meets their criteria.