In my work as a tester I was asked to find a solution to validate the quality of Cobol code. For that I was asked to investigate Jenkins, Sonarqube/SonarLint and Rational/Topaz.

Starting point - I have no knowledge of these concepts, or the Cobol language.

So far in my research I got the following results:

  • Jenkins - continuous integration tool.
  • Continuous Integration - Practice that developers integrate the code in a repository often generating builds and running the tests. It allows instant feedback (via email, for example, indicating the errors and commit the same cause). The developer can then correct the problem as quickly as possible.
  • Sonarqube - validate the quality of the code being developed. It can be configured to store all the code information in a database so that you can also follow up the evolution of code quality.
  • Integration with Jenkins Sonarqube - to automate the generation of these assessment reports of code quality. Faster knowledge about technical debt team and take the necessary actions to correct the problem.

Right now I'm a bit lost ... What should be the next step?

The next step is to create a proof of concept.

  1. Setup cobol code repository
    • Create example cobol code to test jenkins/sonarqube features
    • Create cobol unit-tests
  2. Setup Jenkins
    • Create job to pull cobol code
    • Run any tests and generate code-coverage
    • Push data to SonarQube
  3. Analyze results
    • Manual: Analyze trends and set targets
    • Automated: SonarQube can give feedback/alerts

I think the best is to just start trying and see what you run into, this could lead to better less broad questions.

Try to setup a (automated) flow / process that uses these tools and see if they give you value.

Niels van Reijmersdal already pointed the next steps out. Such tools make sense if their results are understood and accepted by the developers. You wrote you have only little to no understanding of these concepts, tools and COBOL. So it would be best to get aid from an experienced developer or accepted software architect to interpret the results, make the right conclusions and convince the developers. Especially in case of COBOL, which is a quite old language, the developers might be long-time practitioners who do it 'like we always did' and defend their methods from the 1970s against this new stuff of modern times. In my work I heard the fanciest arguments. Anyway, keep up your work - good luck.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.