What systems approval techniques are available?

Question

What technique can I use to approve software?

Is there some kind of form, standard, technique or procedure to validate if a system meets the requirements?

Is there any standard document to formalize this approval?

Answer 1

Homologation, in the common sense used in companies, it only means getting a confirmation from the user, an "acceptance", that the software meets what he needs.

There is no standard rule or process here, although you probably find some templates around.

There are some process frameworks such as RUP or ITIL that talk about approval, sometimes using terms such as acceptance testing or even others. Behold this article, for example.

However, although they suggest good practices, they do not prescribe all actions and practices, it is up to you to understand what the method proposes and apply this according to your needs.

To perform approval testing, you follow general principles of system testing, but there is no specific rule and it varies depending on the type of system.

To document you use the tool you have at hand. It can be an internal system like Bugzilla or Jira, a text document or even a spreadsheet. Test-related documents may also appear in checklist format, requiring you to check certain items specifically.

If you buy a consultancy for some process they will provide templates and help you customize according to your needs.

However, making a counterpoint to the other answer, it is very important that you differentiate legal aspects from pragmatic aspects that involve customer satisfaction, in relation to the problem that involves delivering something that may contain hidden defects.

Regarding legal aspects, seek an expert lawyer, ask for emails, signatures, etc.

Now, think on the other side. When you require the customer to sign a statement that the system "works" in practice, you are disclaiming the responsibility of testing it properly and providing warranty. What’s the point of throwing a signed document in the customer’s face when he finds obvious errors in the system?

The first step in reaching a reasonable approval process is to have the requirements and objectives of the system clear.

The second thing is to establish a customer communication that allows flexibility in changing requirements within the same budget and make clear the cost for larger changes.

In addition, it is important to differentiate non-adherence to requirements (for example, using simple interest when the requirement says it should be composed) from implementation errors (for example, the calculation of interest returns incorrect values in certain cases).

The system warranty generally applies to errors only and you should make this clear.

The approval, from the customer’s point of view, should be a general check that the system is doing what it actually asked for, but it is not a certificate that there are no errors.

Whoever writes the software is primarily responsible for performing the tests and also training users and demonstrating the system to them. The client is not the expert.

Think of an automobile. Ever wondered if the manufacturer asked you to sign a document that there is no problem in the vehicle after a test drive? Maybe you argue that a car is an expensive item. Well, software that isn’t worth the cost of its own quality and maintenance might not even have been made.

Answer 2

Look, I believe your question is for teaching purposes, and I wanted to apply all the knowledge that the faculty gave me to answer that question with pleasure. But honestly, I think it’s better to have a crazy response by sharing some experiences, than one emanating from a theoretical text about system approval, documentation, which doesn’t make much sense to see in practice. I expect a better answer to your question, but I really wanted to see more experiences from the other shared users here too.

Text messages, connection and e-mail is not valid as approval... it is obvious!

The first system I did (at the time I was rebellious and didn’t listen to what I saw in college), was a business system adapted to a small company, I decided not to do homologation documentation. Soon, I worked for a couple of months (after the effective delivery of the system without homologation), making small adaptations, because as the turnover of employees in the company was large, so each new entry, there were "suggestions" to give in the system, I very attentive attended them, made sure to ask everyone to send the improvements and sometimes corrections by email, because I thought "I will have all this in the email, I will be able to charge later" and, well, if I thought to receive an email saying "dear, the control works, but you can put an extra button in the corner?" or "is working, but I wanted you to make an exception, may be", "computer guy, it’s beautiful this, a wonder, works until when my computer is off, comes here for a coffee" And I was skeptical that I would print all these emails and verify that the system is operational (so that in my head meant it was already approved) and still charge for the extra service. Well, I lost my pay for my service in those eight months of "improvement correction" there, "correction of the correction of an exception opening here", then I learned that this would not be a good form of homologation, because in the head of the owner of the company, everything I was doing after the delivery of the system, was correction or improvement of something already ordered by them.

Approving everything in form does not solve 100% and gives caca

In the second system, I learned the lesson (which I quoted above and was no longer rebellious in college, so I embraced the teachings) and I started making forms (even on paper) throughout the development of the system. The form was simple, it was a field around "tested and is sure that xzy functionality is working: ( ) yes ( ) no" reflecting the initial scope of the project and so on, well described functionality by functionality. Well, there came a point that I was doing approval on top of another approval form already done once or more by myself or by the other team members. I soon realized, that the analysis that my team and I did a few months, had no weight at the time of the homologation, why, the company owner describing a feature is one thing, user describing and asking a functionality is something else, user testing/using it seems that it goes to another dimension that is inverse to the dimension that the owner of the company was when he described/requested the functionalities.

Now I homologo system causing the user to make a written statement, with witnesses and with firm recognition (including I wanted to have videos, photos, audio recordings and biometric reading at this instant rsrs)

For starters, it’s serious. Every step of the development, I take the user to exhaustion forcing to complete the process, declaring for the proper purpose... who carried out the system test on a given date in a given place with the presence of witnesses, certifying that the functionality is as expected, that there were no errors during the process, and what improvements and suggestions should be sent after the delivery of the system is effective (as it should and always should be). I do this not because I want to, but because I don’t want the company I work for to lose money and so little that the customer I serve is dissatisfied. Personally, I would prefer to do everything the user asks, receiving or not, it is a pleasure to make things happen, but this is a heartbreak for the company that pays my salary.

But, a homologation is indeed so and has to be so always

Dear, It keeps the whole system running, alone! Get out of the room, go have a coffee bouncing by the company, make a beautiful form, fill a lot of sausage in it, a no, thousands... At the end of the approval process, take a photo with the V of the victory of you and who was in this process, put on the face, thumblr, twitter with the hashtags #homolog highfive with everyone, dance with the cleaning aunt, open a smile like that, the customer will see your happy face and you will infect everyone, and that harmony.... ah that harmony, that happiness that will take care of the department, that yes it is a lot of a well done homologation, the process in the end that is worth it is that !

Joking aside, I wish you good luck when you get to that point.