Lesson 11 · Verification, build and deploy

Test cases and runs, defect tasks, ECO verification, building and deploying with GitHub Actions, Workbench tools, insights and settings.

Goal of this lessonTo prove a requirement with its work and its tests, build and deploy the software with GitHub Actions and use the Workbench's smart tools.

Requirements follow the V-model: a requirement says what is needed and its acceptance criteria; a task does it; a test case says how it is checked; a test run records on which version, by whom and with which result it was tried. The line on the requirement form always says the next step.

Step by step

  1. Link the work and the tests to a requirement

    On the requirement's Tasks tab pick the task that does it, or open one with Create Task. On the Tests tab add the test cases that prove the acceptance criteria: preconditions, steps, expected result; manual or automated (a test method or a CI job).

    A requirement's tests1234
    1. The next step: what the V-model still lacks.
    2. Tests passing / all tests.
    3. Test cases and their last results.
    4. Tasks: the tasks that do the work.

  2. Follow the product's requirements

    The Requirements tab of the product's Git Studio lists each requirement with the tasks that do it, the tests passing and the code changes; a click opens the requirement.

    The product's requirements123
    1. The tasks that do the work.
    2. The state of the tests.
    3. A click opens the requirement.

  3. See a task's software

    The task's GitHub button first sums up the task's software: did it cause development (commits, pull requests, branches), which version holds all of its code, which customers run that version, which requirement it meets and how its tests stand. The code opens from here.

    A task's software123
    1. Show the Task's Changes: the task's changes in the Workbench.
    2. The development this task caused and the version its code went into.
    3. The task's branch name.

  4. Run the test and record the result

    On the test case press Record Run: the result (passed, failed, blocked, skipped), the version tried (e.g. 2026.10.9, rev B), the environment, the duration and the evidence. A failed run opens a defect task in one click, already linked to the requirement. When every test passes, Verify from Tests on the requirement notes which test passed on which version.

    A test case and its runs1234
    1. Record Run: a new run.
    2. The requirements it verifies.
    3. Level and manual / automated.
    4. Steps, preconditions and the expected result.

  5. Build and deploy

    Builds and deployments run where the code lives, on GitHub Actions. On the repository's Build and Deploy tab press Read Workflows and give each workflow its role (build, test, deploy, release). A workflow with the workflow_dispatch trigger starts from Build or Deploy on the repository header, on a branch or a tag, with its inputs. It is a GitHub manager's act; the credential needs "Actions: Read and write". The result arrives under Builds.

    A repository's workflows1234
    1. How it works.
    2. Read Workflows: reads the workflows on GitHub.
    3. Role: the Build and Deploy buttons start it.
    4. Can be started from PORTWARE (workflow_dispatch).

  6. The Workbench's smart tools

    Ctrl+P finds a file from a few letters of its name. Outline lists the open file's functions, classes and headings; a click goes to the line. History shows every commit that changed the file and compares one with the one before. Ask Cowork prepares the question that explains the open file or the difference; sending it is up to you. ? opens every shortcut.

    Go to file and the outline123
    1. Go to file: a few letters are enough.
    2. Explorer, Commits, Outline, History.
    3. Ask Cowork: prepares the question.

  7. Search the code, go to a definition

    Ctrl+Shift+F searches all the code of the selected version; a hit opens the file at that line. Ctrl+click (or F12) on a function, class or variable goes to its definition: in the file, in the file an #include / import names, or elsewhere in the repository; a QML component is its own file. Shift+F12 lists its uses in the file, Ctrl+Shift+O the symbols. Colours tell functions, classes, parameters and constants apart.

    Searching the code123
    1. The text searched; Enter.
    2. A hit: the file and its lines.
    3. Coloured code: function, class, parameter, constant.
Insights
The product's Git Studio overview says what to look at: a failing build, open security alerts, approved requirements without evidence, failing tests, customers on an older version, pull requests waiting for a week and changes piled up since the last version.
Together with the PLM
With the PLM installed the change order (ECO) has a Verification tab: the requirements the change affects and the runs that prove them. A test run carries the change order it verifies; hardware and software use the same records.
Settings
Project › Configuration › Settings › Git Studio: tag prefixes that are not versions (backup/, archive/) and whether a comparison opens with the last two releases or the last two tags. Installations differ in settings, never in code.

Check yourself

What does an approved requirement without a test show?
A red 'Gap' and the next step: add a test case that proves the acceptance criteria.
What happens when a test fails?
The run is recorded and 'Open Defect Task' opens a task linked to the requirement; it cannot be verified.
Which workflow can be started from PORTWARE?
One that declares workflow_dispatch; starting it takes a GitHub manager.