Continuous delivery and defect management

[Ismail iam]

Hello,

in my project I'm doing continuous  integration using the Jenkins tool. We operate unit and functional tests using tosca tricentis. However, test analysis after execution is time-consuming. Let's say that at the first iteration the automate identify an issue that is being defected. At the second iteration, the tool discovers in addition to the already known defect 2 other anomalies for example. The trouble is that we will have in the reporting 2 colors (red for the defect, green for the passed): is there any solution (application or tool) that allow to aggregate the all test result and to distinguish the known defect, the defect identified for the first time ?

Thaks for your help

Best regards

[Thierry de Pauw]

Hello Ismail,

First of all, I’m very sorry for this late reply.

Regarding your problem about test analysis and distinguishing known defects from the new once. I’ve got this question before from customers I help in adopting continuous integration. Most of the times it comes from a misunderstanding of what continuous integration is and what it’s purpose is.

Continuous Integration is really a practice where everyone in the team integrates its work frequently with the system. Usually this integration happens at least once a day, leading to multiple integrations per day. Every integration is validated by a build that executes all automated tests. Whenever the build fails, this also means whenever an automated test fails, the build gets fixed within 10 min. The easiest way to fix a failing build is to just rollback the last commit.

The purpose of continuous integration is really to have an always working system, allowing you to perform production releases at any given moment in time. This means that at any given moment in time, tests have to always pass. In this case you don’t need to perform any test analysis to identify new defects from known defects. If a defect is reported by a test, you fix it, immediately. If you don’t, it means your defect is not important and as such your test is not important. In that case, you can just delete that test.

To resume, you in fact don’t need a tool to distinguish new from known defects. I think what is needed is a shift in mindset to work towards an always working system and keeping tests to be always green.

Cheers,

Thierry

http://thinkinglabs.io

--
You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Sent from a device without keyboard. Please excuse brevity, errors and embarrassing autocorrections.