Jenkins Dashboard View plugin support Allure reports

Dashboard View Plugin is based on JUnit XML reports.

But the JUnit plugin which generates test report XML files has a limitation - it does not support the rerun mechanism, so it's unable to merge different XML files of rerun cycles into a single file (as result we have a single file with the latest cycle run), and as result could not provide valid numbers of test statistics on Jenkins Dashboard.

The official repository was forked -

 

and updated with corresponding improvements -

Inspect code with Cucumber plugin 'unused' in dry run mode

 Problem: During long work with the Automation test framework we collect multiple cases and even greater number of test steps. And we had no automatic mechanism to validate/check if all the steps: 

1. are still used (maybe some are obsolete/redundant/deprecated)

2. are valid in test cases ('missing step definition')

Solution: To do some garbage clean with found implemented plugin - add a special test class with dryRun option and plugin unused:

Improved Allure-report-plugin in Jenkins pipeline to display Graph trend

The problem was, that when in Jenkins build no pass (green) builds presented, the trend was not displayed and the Allure report menu item was missed (as result Dashboards iFrames based on Allure report were missing too).

Root problem: Miscommunication between Jenkins statuses and handle of those statuses.

Allure-report-plugin builds are expected to be finished not in Failed status but in Unstable.

Add formatted SQL to Allure report

 To add more details to our test report, we could attach SQL requests to it.


Logging RestAssured requests in Allure

 To fulfill our test reports we could add more details to them - by adding the rest API requests to the steps.

For this, we will need to extend our RestAssured filter.



Allure @skip annotation

 For some reason, we need sometimes to skip test cases (due to found known bugs, temp environment issues, etc.), but still, have them in our statistics.

And moreover, somehow get informed if the bug is fixed or the condition changed and the test case is ready to get back into our regression scope.

How to do this - implement smart @skip annotation


ISTQB Section 5 (Test Management)

   (back to Introduction article with links to all parts) 

---------- Section 5 ------------

Test Management

Product risks (unreliable architecture, code not performing intended functions, performance issues, user experience feedback)  

VS 

Project risks (delays, inaccurate estimates, late changes)

ISTQB Section 4 (Test design techniques)

  (back to Introduction article with links to all parts) 

---------- Section 4 ------------

 The purpose of a test design technique is - to identify test conditions, test cases, and test data.

ISTQB Section 3 (Static testing )

  (back to Introduction article with links to all parts) 

---------- Section 3 ------------

Static testing (one of the testing techniques) VS Dynamic testing 

Process of work:

Documents => Static Testing (by Reviews or Static Analysis) => Defects