Project Submodules

# Dashboard

Dashboard displays the following areas of interest:

  1. Test analysis status
  2. Test execution status
  3. Help settings - if you keep instructions in e.g. Confluence article, you can enter its URL here and a new button Help will get created for users to simply be redirected to your article
  4. Project information - keeps details like author, project description and project stakeholders
  5. Project issue - a list of all created bugs in the project


# Design

Use the agile planning in your project by creating folders in which you will keep epics and stories.


For progress management you can edit your epics by linking them to a specific Schedule where you create milestones and iterations.

The new design also includes a summary of working hours estimation for all child stories, test analysis and test executions. All you have to do is add a work estimation in hours and time already spent while creating / editing the items.

To get to the screen below, click on the epic name in your folder.





The screen below shows the section which needs to be filled in. In case of a test case, don't forget to assign an epic, story and a version.


# Test Plan

Create a plan of your future tests by dividing it into test sprints and assigning test cases to specific users.


After clicking on either test plan or test sprint name, you get valuable details which you can see on the images below.



# Test Analysis

Test case creation has never been easier.

The analysis screen works based on a folder structure which should be created at the beginning.
Once you have a folder, you can start creating Test Sets and then Test Cases (in order to open the folder, use the "double arrow button" 00_Double_arrow  ).


Other options of Test case creation:

  • Bulk test case - select an existing Test Set and quickly make a bulk of new test cases
  • Import/export - you can export details about your Test Sets into Excel file for analytical work and after changes are made, you can import the file back so the changes get applied in JunoOne
  • Bulk push - this feature transfers Test Sets or Test Cases into the Storage or Projects section
  • If there is an existing Test Set, you can just click on "+" button to create a new Test Case in it
  • At the Test Case level there is an option to Clone the test case


Search and Filter sections are in place for better co-operation with a bigger amount of existing Test Sets/Cases.



# Test Execution

Users with role permission to execute test cases will choose a Test Plan and a Test Sprint to see specific Test Cases.
Those can be opened and then executed by hitting the green play Timer button at the top center side of the screen.



Should any issues occur during the execution, user can immediately create a bug by hitting the "Issue" button (with a bug icon) on the failed scenario row.


# Issues

Bugs created during a test case execution are being saved to this section.

You can always create a bug or a task here as well by using the Create Bug/Task button (use the blue switch button to switch between Bugs and Tasks).

Tasks is a helpful feature to assign any task regarding an issue to any user in JunoOne.



# Settings

These settings will configure the currently selected project.


  • General settings

  • Project roles

  • Ticketing system - connection to 3rd party software (JIRA, GIT and OTRS) for systems synchronization (these settings will configure JunoOne based on how e.g. JIRA names particular items).
    More details HERE.

  • Export - select an area which you would like to export the deep overview of

  • Settings workflow
    • Bugs - workflow for bugs where you can configure which user role can do what with the bugs

    • Bugs statuses - configure bug statuses - by clicking the Create status button, you can have as many statuses as needed.
      It is mandatory to assign the first status and final status.

    • Bugs priority - configure bug priority naming by clicking the button Add priority

    • Tasks - click on Statuses button to create or edit task statuses and manage which user role can work with which task status.
      IMPORTANT: Don't forget to set the first and final status.


    • Test case - create or edit test case statuses and manage which user role can work with which test case status

    • Custom fields - manage the required fields in the bug/task creation forms and make your own custom fields

    • Module - serves for adding gestors for specific application modules. Once a tester creates a bug or task, he can assign a specific module in them. If the tester needs a piece of information about the module, he can check who the gestor is in this section, without looking for him in the organization hierarchy.
      Components serve for filtering artefacts such as bugs and tasks which can be synchronized with JIRA. You can assign a specific component to a bug or a task.

  • Archive / Delete - you can archive or remove the current project. In case of removing, it will never be physically deleted as it will stay in our database in case you would need to revive the data.

  • Tags settings - for better data organizing it's a good idea to use tags. In this section you can edit existing ones or create completely new tags

  • Activity settings - in order for users to track their time at work, create an activity to specific users and they will be able to use it in their Operating Log section

  • Settings Jenkins - in case you have jobs created in Jenkins that you would like to remotely launch from JunoOne, fill in the log in details in this section and use the Automat section under the project menu

# Automat

Once you set up conection to your Jenkins via Settings, you can remotely run the Jenkins jobs in JunoOne.

Schedule a job to be run at your desired day and time.


Autoruns section displays all finished jobs - click on the name and see the results.



# Jenkins: High-level process description

Upstream job, which is configured as the first one, includes all tests to be run. After a build is executed by this job, a test report with results is generated and a downstream job is triggered to execute its build (upstream build URL is also being sent to the downstream job).

Downstream job takes the test report with results and according to the set parameters it writes the report’s results into the database.

# Jenkins: Detailed configuration

  1. Log in to Jenkins.

  2. Hit the arrow down of the Jenkins button at the top left corner to open a menu, hover over Manage Jenkins and in the submenu select Manage Plugins.

  3. In the tab Available use the Filter field to find Parameterized Trigger plugin and install it.

  4. Hit the top left corner Jenkins button to get back to the list of builds and click on the People menu option. After the page loads, copy your User ID and save it aside, you will need it later.

  5. Click on your User ID link and hit the Configure menu option.

  6. Hit Add new Token button, then Generate buttonCopy the token number and save it aside, you will need it later. Hit the Save button.

  7. It’s time to create a new project – this project will later write test results down from the upstream job (the job must generate the results from a plugin, where the selenium tests are configured = jUnit plugin is for tests to work properly, Bootstraped-multi-test-results-report plugin serves for displaying the test results).
    Hit the New Item menu option, add a name of your project, click on Freestyle project, click on OK and at the new page hit directly Save button.


  8. Hit the top left corner Jenkins button to get back to the list of builds.
    Click on your created project and hit the Configure menu option.

  9. At tab General select checkbox This project is parameterized. Into a newly created section add the following details:
    • Name – always enter “proj_ID
    • Default Value – project ID from JunoOne – portal menu section Projects
    • Description – it’s preferable to fill in the details in this field to describe the parameters from above fields

  10. Go to tab Build Triggers and select checkbox Trigger builds remotely (e.g. from scripts)
    This is a build trigger from console. 
    Enter the authentication token – create your own token which will be used later in JunoOne once you’ll be creating the “Job to schedule” in Projects > Automat section.



  11. Go to tab Post Steps, hit the Add post_build step button and add a new section Trigger parameterized build on other projects.

  12. The newly created section will appear under tab Build Settings. 
    Projects to build – fill in with the name of your created project
    Trigger when build is – select option Complete (always trigger)


  13. Hit Add Parameters button, select option Predefined parameters.
    Enter PRE_BUILD=${BUILD_URL} in the Parameters text field and then hit Save button.

  14. The project overview page appears and it now contains a new section Downstream Projects where your downstream project needs to be configured. Click on its link.

  15. Click on the Configure menu option. 

    In tab General select checkbox This project is parameterized and use the button Add Parameter to add two String Parameter sections (description fields can stay blank in them):
    • the first section:
      • Name – PRE_BUILD (this is the build we have configured previously in the upstream job)
    • the second section:
      • Name – proj_ID
      • Default Value – project ID which must be the same as in the upstream job previously
  16. Go to tab Build, use the button Add Build Step and select option Execute Shell in order to add it. For each client there will be specific variables created. Once provided, insert the below script into the newly created Execute Shell section. 

    You can see an example of the script below. These items will always be unique for each client:
    Jenkins_USER – User ID previously saved aside
     – generated token number previously saved
    WSO2_TOKEN – access token into API (every user has a different access token which will be provided by Denevy)
    API address - replace the current API address at the last line of the script: "Authorization: Bearer $AUTH_TOKEN" ""
    #This job is being triggered by upstream job. For a successful run it only needs
    #'$BUILD_URL' from upstream. Any number of projects can connect to this job and
    #data from all projects will get transfered to database (according to API). Test report should be the same as in Juno_automatizovane_testovanie
    echo $proj_ID
    echo $PRE_BUILD
    #automated_jobs sheet
    #these vars are required for report download

    JOB_ID=$(echo $PRE_BUILD | cut -d'/' -f 6) #it pulls out the job number from build url
    JOB_NAME=$(echo $PRE_BUILD | cut -d'/' -f 5) #it pulls out project name from build url

    promenna=$(curl -k --user $Jenkins_USER:$Jenkins_TOKEN --silent ${PRE_BUILD}api/xml) #an overview of upstream job will get downloaded into this variable
    JOB_START=$(echo $promenna | xmlstarlet sel -t -m '//timestamp' -v . -n) #from the upstream job overview we get the tag <timestamp> - the beginning of upstream project
    JOB_DURATION=$(echo $promenna | xmlstarlet sel -t -m '//duration' -v . -n) #from the upstream job overview we get the tag <duration> - duration of the whole job

    let time_en=$JOB_START+$JOB_DURATION #calculation of the upstream job end
    time_end=$(printf "%.3f\n" $(($time_en/1000))) #time conversion from miliseconds to seconds
    JOB_END=$(date +%FT%T -d @$time_end) #upstream job end time

    #from upstream job overview we get the result
    BUILD_STATUS=$(curl -k --user $Jenkins_USER:$Jenkins_TOKEN --silent ${PRE_BUILD}api/json | jq -r '.result')

    #api token
    AUTH_TOKEN=`curl -k -d "grant_type=client_credentials" -H "Authorization: Basic $WSO2_TOKEN" | awk -F'"' '{print $4}'`
    #insert to database via API and json
    curl -v -k -H "Content-Type: application/json" -H "Authorization: Bearer $AUTH_TOKEN" "" -d '{ "job_status": "'$BUILD_STATUS'", "project_ID": "'$proj_ID'", "job_name": "'$JOB_NAME'", "job_id": '$JOB_ID', "job_time_end": "'$JOB_END'", "job_build_responsible": "'$EXECUTOR_NUMBER'", "job_url": "'$PRE_BUILD'", "job_last_duration": '$JOB_DURATION' }'
    #tabulka test_results

    promenna1=$(curl -k --user $Jenkins_USER:$Jenkins_TOKEN --silent ${PRE_BUILD}testReport/api/xml) #upstream job test report will get donwloaded into this variable

    #pulling the data out of the report
    skipped=$(echo $promenna1 | xmlstarlet sel -t -m './/case/skipped' -v . -n) #from report pulling <skipped> - has the test been skipped?
    status=$(echo $promenna1 | xmlstarlet sel -t -m './/case/status' -v . -n) #from report pulling <status> - what status has the test ended with?
    duration=$(echo $promenna1 | xmlstarlet sel -t -m './/case/duration' -v . -n) #from report pulling <duration> - how long did the test take?
    name=$(echo $promenna1 | xmlstarlet sel -t -m './/case/className' -v . -n) #from report pulling <className> - test name
    test_count=$(echo $promenna1 | xmlstarlet sel -t -m '//totalCount' -v . -n) #from report pulling <totalCount> - how many test have been there in the upstream job?

    #data into array

    #api token
    AUTH_TOKEN=`curl -k -d "grant_type=client_credentials" -H "Authorization: Basic $WSO2_TOKEN" | awk -F'"' '{print $4}'`

    #insert to database via api and json
    for (( i=0; i<$test_count; i++ )); do array_name_rep=${arr_name[$i]}; array_status_rep=${arr_status[$i]}; array_duration_rep=${arr_duration[$i]}; array_skipped_rep=${arr_skipped[$i]}; curl -v -k -H "Content-Type: application/json" -H "Authorization: Bearer $AUTH_TOKEN" "" -d '{ "status": "'$array_status_rep'", "project_ID": "'$proj_ID'", "build_ID": '$JOB_ID', "test_name": "'$array_name_rep'", "duration": "'$array_duration_rep'", "skipped": "'$array_skipped_rep'", "job_name": "'$JOB_NAME'" }'; done
  17. After pasting the code, the field should look like this.

  18. Hit Save button in Jenkins.


DENEVY s.r.o
Business Centrum Ocelářská
Ocelářská 35/1354
190 00, Prague 9

phone: +420 774 494 633
ID: 02995107 VAT: CZ02995107


phone: +420 774 494 633

phone: +420 774 494 633

2020 © Copyright

page by DENEVY