FIGURE 2: CONTINUOUS DELIVERY PIPELINE DOING AUTOMATED RELEASES
FIGURE 3: SUBSYSTEMS ASSEMBLED INTO A SYSTEM
There is sometimes a confusion between integration tests and functional tests as they both require multiple components to interact with each other. The difference is that an integration test may simply verify that you can query the database while a functional test would expect to get a specific value from the database as defined by the product requirements.
End-to-end tests
Acceptance testing
Performance testing
Smoke testing
What are stories, epics, and initiatives?
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.
Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
You’re doing continuous delivery when: [1]
Here’s a concise DevOps lifecycle example using a 3-tier web application (Presentation → Application → Database):
| Step | Output | Major Tasks | Example Artifacts/Tools |
|---|---|---|---|
| Plan | Requirements, architecture, backlog | Define user stories & NFRs; choose tech stack; draft C4 diagrams; plan environments & CI/CD | Jira/Azure Boards, Confluence, C4 diagrams |
| Code | Source code in VCS | Implement frontend, backend, DB schema; follow branching; code reviews; write unit tests | GitHub/GitLab/ADO, ESLint/Prettier, Jest/pytest |
| Build | Versioned build artifacts (e.g., images) | Compile/package; resolve dependencies; create Docker images for FE/BE; generate SBOM | Docker, npm/Maven/Gradle, Make, Syft |
| Test | Automated test reports | Unit/integration/API/UI tests; security (SAST/DAST); performance & load tests; fix defects | Playwright/Cypress, Postman, OWASP ZAP, k6/JMeter |
| Release | Approved, tagged version | SemVer tagging; release notes; change control; promote artifacts to release registry | Git releases/tags, Change mgmt, Artifact registry |
| Deploy | App running in target env (stg/prod) | IaC apply; deploy to K8s/VMs; run DB migrations; blue/green or canary; rollback strategy | Terraform/Ansible, Helm/Argo CD/Flux, Liquibase |
| Operate | Stable, performant service | Incident response; scaling; patching; backups/DR; cost optimization; feature flags | SRE runbooks, Autoscaling, Backup jobs |
| Monitor | Dashboards, logs, alerts | Collect metrics/logs/traces; SLO/SLI tracking; alerting; anomaly detection; feedback to backlog | Prometheus/Grafana, ELK/Cloud Logging, OpenTelemetry |
| Environment/Tier Name | Description |
|---|---|
| Local | Developer's desktop/workstation |
| Development/Trunk | Development server acting as a sandbox where unit testing may be performed by the developer |
| Integration | CI build target, or for developer testing of side effects |
| Testing/Test/QC/Internal Acceptance | The environment where interface testing is performed. A quality control team ensures that the new code will not have any impact on the existing functionality and tests major functionalities of the system after deploying the new code in the test environment. |
| Staging/Stage/Model/Pre-production/External-Client Acceptance/Demo | Mirror of production environment |
| Production/Live | Serves end-users/clients |
Summary: “Kanban vs. scrum” is a discussion about two different strategies for implementing an agile development or project management system. Kanban methodologies are continuous and more fluid, whereas scrum is based on short, structured work sprints.
Two popular formula:
Triangular Distribution: E = (o + m + p ) / 3
where E is Estimate; o = optimistic estimate; p = pessimistic estimate; m = most likely estimate
Beta Distribution (PERT): E = (o + 4m + p ) / 6
Testing levels
Broadly speaking, there are at least three levels of testing: unit testing, integration testing, and system testing.[39][40][41][42] However, a fourth level, acceptance testing, may be included by developers. This may be in the form of operational acceptance testing or be simple end-user (beta) testing, testing to ensure the software meets functional expectations.[43][44][45] Based on the ISTQB Certified Test Foundation Level syllabus, test levels includes those four levels, and the fourth level is named acceptance testing.[46] Tests are frequently grouped into one of these levels by where they are added in the software development process, or by the level of specificity of the test.
Unit testing Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors.[47]
Integration testing Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. Software components may be integrated in an iterative way or all together ("big bang"). Normally the former is considered a better practice since it allows interface issues to be located more quickly and fixed.
System testing System testing tests a completely integrated system to verify that the system meets its requirements.[6]: 74 For example, a system test might involve testing a login interface, then creating and editing an entry, plus sending or printing results, followed by summary processing or deletion (or archiving) of entries, then logoff.
Acceptance testing Acceptance testing commonly includes the following four types:[46]
Test Report is needed to reflect testing results in a formal way, which gives an opportunity to estimate testing results quickly. It is a document that records data obtained from an evaluation experiment in an organized manner, describes the environmental or operating conditions, and shows the comparison of test results with test objectives.
Files
Source: "Introduction to OpenUP (Open Unified Process)", https://www.eclipse.org/epf/general/OpenUP.pdf
OpenUP is a minimally sufficient software development process – meaning that only fundamental content is included. Thus, it does not provide guidance on many topics that projects may deal with, such as large team sizes, compliance, contractual situations, safety or mission critical applications, technology-specific guidance, etc. However, OpenUP is complete in the sense it can be manifested as an entire process to build a system. For addressing needs that are not covered in its content, OpenUP is extensible to be used as foundation on which process content can be added or tailored as needed.
OpenUP is an agile process. Though OpenUP is lightweight, there is much more to agility than simply being light. Most recognized agile practices are intended to get a team communicating with one another providing a shared understanding of the project. Agile methods have drawn our attention back to the importance of coordinating understanding, benefiting stakeholders over unproductive deliverables and formality.
OpenUP has the essential characteristics of a lean Unified Process that applies iterative and incremental approaches within a proven structured lifecycle. OpenUP is based on use cases and scenarios, risk management, and an architecture-centric approach to drive development.
Table 1 – Mapping between OpenUP principles and Agile Manifesto
The OpenUP content addresses organization of work at personal, team and stakeholder levels, as seen in Figure 1.
Figure 1 – Organization of work and content focus in OpenUP
The essential skills needed by small and co-located teams are represented by OpenUP roles:
The OpenUP method content is focused on the following disciplines:
Other disciplines and areas of concern were omitted, such as Business Modeling, Environment, advanced Requirements Management and Configuration Management tools setup. These concerns are either considered unnecessary for a small project or are handled by other areas of the organization, outside the project team.
OpenUP applies the Unified Process phases:
When taken together, these basic building blocks are also used to address the objectives for each phase (see Table 2 for a mapping between patterns and phases objectives).
Table 2 – mapping between patterns and phases objectives
When we sequence the iteration template patterns (occurring as many times as needed), we have a delivery process – a complete and integrated approach for performing a specific project type (as seen in Figure 3). A delivery process describes a complete project lifecycle and is used as a reference for running similar projects.
Figure 2 – OpenUP delivery process
Reusable method content is created separately from its application in processes. Method content provides step-by-step explanations, describing how specific development goals are achieved independent of the placement of method elements within a development lifecycle.
Processes take these method elements and relate them into semi-ordered sequences that are customized to specific types of projects. Method elements are organized into reusable pieces of process called capability patterns, providing a consistent development approach to common project needs. These patterns are made from organizing tasks (from the method content) into activities, grouping them in a sequence that makes sense for the particular area where that pattern is applied.
Patterns can be small and focused in particular areas like iteration management, project initiation, architecture definition and so on. These are considered the basic building blocks to create larger patterns or delivery processes (defined below).
One example of basic building block in OpenUP is Develop Solution Increment pattern, as depicted in Figure 4.
This activity provides a way to perform goal-based planning and execution of work. Work is taken on by developers, and work progress is tracked based on the goals achieved using the designed, developer-tested, and integrated source code.
Figure 3 – There are activities in the workflow of Elaboration phase includes the "Develop Solution Increment"
Figure 4 – The "Develop Solution Increment" activity
A task is unit of work a role may be asked to perform. In OpenUP, there are 18 tasks that the roles perform either as primary performers (the responsible for executing the task) or additional performers (supporting and providing information used in the task execution).
The collaborative nature of OpenUP is manifested by having the primary performers work with a range of other individuals when performing a task.
An artifact is something that is produced, modified, or used by a task. Roles are responsible for creating and updating artifacts. Artifacts are subject to version control throughout the project lifecycle.
Figure 5 – The workflow of Inception phase
Figure 6 – The workflow of Elaboration phase
Figure 7 – The workflow of Construction phase
Figure 8 – The workflow of Transition phase
Youtube Playlist, https://www.youtube.com/playlist?list=PLCku-ULHIQvl2-jd91KJYuJ0Lmxt-kLTm
References
