Automatic QA and release request - part 02

[rodrigo_paisante3]

A not too long time ago...

I had detailed in previous blog about creating a tool to analyze the source code, or the best solution, using the ATC (Abap Test Cockpit).
I mentioned about the quality and wisdom of the team of programmers that grew up.

But what's the point of having an automatic verification code? What are the gains and benefits? And the worst?

Here in the company, we allocated 2 programmers to do this activity. They were checking the code, line by line, following our standard document.
When non conformities were found it was returned by mail to the developer to proceed with the correction: Much work, numerous requests daily, many similar errors, complex routines to analyze... Add to that the worst question of all: dealing with people. Identify errors and point it in source code is like to speak ill of the mother of the programmer. The human factor was the main cause of failure in this process because not all errors will be identified and not all errors identified will be corrected or treated. Yes, It is true!

Automating these validations reduces the human factor. There are no arguments against the machine... is 0 or 1. If not corrected it will stay there. The error has to be, at least, properly argued to be considered a false positive and "accepted"  by an approver.

Important to mention that the static validation does not identify 100% of the logic and performance problems . Rather, it is almost 0. To do this validation, the tests are crucial, better doing automated tests.  But it can identify points that cause crashes, dumps into production, so with praise. And this is the focus: No dumps into production, who is allocated in support can be allocated to to improve the system.

The image above shows month by month - from March to November 2013 - how transport request was handled with automatic release.

• Green   - no problems, all right - released by request owner
• Yellow  - False positive - released by an approver
• Red      - Urgent or no time to correct releases, authorized by boss - released by an approver
  

Approvers had a lot of work but it was decreasingly month by month. We analysed yellow request to create/change our patterns or to create rules to turn it in green requests. But the main focus was to reduce the red requests number.

The developer and support teams did not accept well the solution. The big problem: change past codes. It is impossible to change old codes without test all scenarios and without automated tests. Then we adjusted the solution to skip the verification on old codes when support team creates the request and only check modified code. But the developer team must have to change old codes when they changed an old program and have to test it all. Of course, case by case was analysed to did not delay the delivery of a project.

Attention to yellow requests: it appears only once. When we registered an approval the validation don't show it anymore in the future.

Other good effect was the lower number of dumps in production.

We advanced some steps and for the next year (2014) we will do it better using ATC and others SAP standard tools.

And parallel with this initiative we started the ABAP DOJO meetings, but it will be a topic for another blog...