SDLC at Granicus - PD Ways of Working

Software Development Lifcycle

Start

Be sure to enable fullscreen mode!

Granicus Product Designer - Functional Onboarding

Start

Please also note that audio and animation the following slides cannot be paused, fast forwarded, or restarted. To begin a slide over, navigate away from the slide, then back to the slide to restart the audio and animation.

You will be provided with a full text version of this presentation immediately after viewing it. Sit back, relax, and absorb as much information as you can, knowing that you have full access to the information for future reference!

There is no need to take notes of the following presentation!

Attention:

5 → 6: UAT passed

4 → 5: All stories passed

3 → 4: Story passed

2 → 3: CI builds passed

1 → 2: Merge Request

Checkpoints

Software Development Lifecycle

Bugs found during FT

Bugs found during RT

1. Development&Unit Testing

6. Production (smoke tests)

5. User Acceptance Testing (smoke tests)

4. Regression Testing

3. Feature Testing

2. Continuous Integration

Continue

Software Development Lifecycle

• This is also true when making configuration changes.
• In situations where our tooling does not support automated unit test scripts, developers work in:
• Local Containers
• Virtual Machines (VMs)
• Proof-of-Concept (POC) environments

• Software Engineers write unit tests and code to satisfy the requirements of a task.
• As a feature is being built, a developer writes unit tests that verify functionality, among other things.

Continue

Development & Unit Testing

1. Development & Unit Testing

• The developer commits their change to our source code repository (git) and files a merge request to be reviewed by other members of the team.
• Merge requests serve an important purpose as a stand-in for Pair Programming and formal Code Review meetings.
• One or more team members who were not associated with the previous phase review and approve the merge request before it is accepted into the master git branch.

Merge Request

Continue

• Builds fail: messages are automatically sent to interested parties.
• Builds are passing: deploy the application to a higher environment.

• When changes are detected, the relevant portions of the CI suite (i.e. "builds") are executed.
• These builds run various sets of automated tests and report the results.

• Once a merge request has been approved and code is merged into our master branch, our Continuous Integration (CI) suite takes over.
• Runs on containers or shared VMs
• Periodically scans master branches of all deployable repositories for changes.

Continuous Integration

Continue

2. Continuous Integration

• If a bug is found at this level of testing, a ticket is created in our workflow management tool and tied to the appropriate feature request.
• A feature request does not pass this level of testing until:
• All test cases have been executed.
• All acceptance criteria met.
• Not tied to any open bugs.

• Occurs after code merge in lower environments, such as DEV, QA, or QC environments.
• Verifies that features or changes work as expected and do not contain vulnerabilities.

Feature Testing

Continue

3. Feature Testing

• Click Granicus icon below to view and bookmark the spreadsheet we use to track the test cases we execute

• If a bug is found, a ticket is created in our workflow management tool and tied to the appropriate feature request.
• If feature request cannot be easily determined, it is simply tied to the release candidate itself.
• A release candidate does not pass this level of testing until there are no open bugs tied to it.

• Full execution of a test suite through a combination of automation tests and manual tests.
• Covers existing functionality, ensures changes did not cause problems in unrelated areas of the system (regressions).

Regression Testing

Continue

4. Regression Testing

• Some products have a test environment exposed to customers, which we refer to as a Customer Demo Environment or User Acceptance Environment.

• Light (smoke) testing is done as well to ensure that the release process itself has run smoothly.

User Acceptance Testing

• Features within release candidates are tested by users to verify integration points.
• Releases may sit in this User Acceptance environment for a period of time to give users a chance to adapt their systems to the change.

Continue

5. User Acceptance Testing

• Production Release is the final stage in the release process.
• A Change Request approval is necessary from the Change Control Board (CCB) before a production change can occur.
• As is the case in User Acceptance Testing, smoke tests are executed in this environment to ensure that the release went smoothly, and the application is functioning as expected.

Production Release

Continue

6. Production Release

Granicus Product Designer - Functional Onboarding

Please exit fullscreen mode and continue below.

THANK YOU!