Approval of the Product Integration indicates an understanding of the purpose and content described in this deliverable. By signing this document, each individual agrees on the proposed subsystem roles, business logic responsibilities, and confirms that test planning and detailed design activities can be initiated as described in the Project Charter.
-
-
-
## Document Revision History
-
-
| Version | Date | Change Description | Author | Approver |
7. Continuous integration Process to Improve Software Quality and Reduce Risk.
+
_(Approval of this Product Integration document signifies a comprehensive understanding of the purpose and content described within this deliverable. By signing this document, each individual acknowledges and agrees to the defined subsystem roles, responsibilities, and business logic assigned to them. Upon approval, Test Planning and Detailed Design activities should be initiated for the project, and all necessary resources must be allocated as outlined in the Project Charter.)_
---
-
## 1. Introduction
+
## **1. Introduction**
The Product Integration process consists of a set of procedures used to combine software components into subsystems and final systems. Integration enables early visibility into the product’s functionality, quality, and performance. For software systems, this is the first stage where the complete product behavior can be evaluated, making integration a critical phase of the development lifecycle.
@@ 40,13 15,13 @@
---
-
## 2. Integration Guideline
+
## **2. Integration Guideline**
Effective integration requires a strong understanding of the product design, controlled changes, and coordinated execution across teams.
---
-
### 2.1. Understanding the Product Design
+
### **2.1. Understanding the Product Design**
- Understanding full functional design of the product can help avoid problem in the future.
- Architectural decisions are done without considering the full system, leading to problems at integration time
@@ 57,14 32,14 @@
---
-
### 2.2. Integration Strategy
+
### **2.2. Integration Strategy**
The strategy for software integration provides a road map that describes the steps to be conducted as part of the implementation of software to start integration activities. When a strategy is planned, then resources are required. This strategy should be flexible and promote an approach that could show change. Sometimes, planning by senior, program and project managers need to track program and project progress and require the following characteristics:
- Conduct effective technical reviews
- Show different integration techniques and software approaches
- Software designers are required to be involved from the start to the finish
-
#### Approach to Software Integration
+
#### **Approach to Software Integration**
* Integration activities are planned early
* Lower-level integration verifies correctness of individual components
@@ 73,7 48,7 @@
---
-
### 2.3. Environment
+
### **2.3. Environment**
- Problems appear as tests for the components are not run in the same type of environment as the integration test system. Different versions of hardware and test platform are used
- The build environment is not prepared for new builds, e.g. results from earlier builds are not removed before a new generation of the system is started
@@ 81,11 56,11 @@
---
-
### 2.4. Verification and Validation
+
### **2.4. Verification and Validation**
-
#### Software Integration Testing
+
#### **Software Integration Testing**
-
**What is Software Integration Testing? **
+
**What is Software Integration Testing?**
The concept for testing software is to uncover errors, troubleshoot, and fix problems that occur during test. Test plans and procedures are developed to test systems and if required, rerun integration tests that are to being witnessed by quality or customers.
**Integration Test:** The integration test is performed to understand how effectively the component can be integrated into the selected component architecture. Components that are found suitable are candidates for inclusion in a library of reusable components.
@@ 96,7 71,7 @@
The techniques for developing and the construction of the software architecture goals take unit-tested components and build program structures established by design. The "Bam Theory" approach is to attempt non-scheduled software integration and testing. This approach is performed in the following four steps:
-
- Planning and schedules are in place
+
- **Planning and schedules are in place**
- Software test plans, procedures, or internal work instructions are ready to support integration
- Software Integration is ready for testing to be conducted and performed by all notified team members
- Stay in control between multiple tests running at the same time. Out of control can cause chaos.
@@ 104,7 79,7 @@
---
-
## 3. Continuous Integration Process
+
## 3. **Continuous Integration Process**
**Continuous integration (CI) **is the real meat behind the CD process and is the reason that makes Continuous Delivery possible.
@@ 122,13 97,34 @@
Tests are run immediately to catch any errors each time a code check-in happens thereby setting up the necessary feedback loop for a Continuous Delivery.
-
### 3.1. Continuous Integration Process
+
### **3.1. Continuous Integration Process**
Let’s retrace back to the CD pipeline diagram discussed previously. The red circle will be our focus in this article in order to understand the CI process.
_Even though the CI process may seem very development centric, it’s vital for QA engineers to get an overall picture and adapt accordingly._
-
+
```mermaid
+
graph LR
+
%% Define Nodes
+
Start([New code checkin]) --> SCS[Source Control System]
+
SCS --> CI{C. I Engine <br/> <i>Sanity check on build</i>}
+
+
CI --> QC[Quality Check]
+
QC --> Decision{Passed Tests?}
+
+
%% Feedback Loops
+
Decision -- No --> CI
+
CI -.-> SCS
+
SCS -.-> Start
+
+
%% Final Path
+
Decision -- Yes --> PD[(Production Deployment)]
+
+
%% Styling
+
style CI fill:#f9d5a7,stroke:#e67e22,stroke-width:2px
Before we proceed any further, the following terminology is important to know:
@@ 139,7 135,7 @@
Say there are two or three development engineers working on a feature and are using Continuous Integration.
-
### This is how the sequence of events would appear:
+
**This is how the sequence of events would appear:**
1. On the local copy, the developer builds his code for the new feature.
2. After coding is done, he might write the required automated unit tests to test his code.
@@ 152,7 148,7 @@
9. After commit, another build pertaining to the source code (mainline) is run on an integration system.
10. This now is ready to be consumed by the next stages.
-
#### 3.2. Continuous Integration Tools
+
#### **3.2. Continuous Integration Tools**
It is dependent on each organization on what kind of CI tools they use.
While some of the tools like Hudson, CruiseControl, Jenkins are popular choices, there are many other tools that provide similar capabilities in addition to their own unique features.
@@ 163,7 159,7 @@
=> [Here is the complete list of CI tools with features](https://www.softwaretestinghelp.com/tools/24-best-continuous-integration-tool/)
-
#### 3.3. CI Benefits
+
#### **3.3. CI Benefits**
1. **Errors detected early:** If it is an error in the local copy or code checked indirectly without being synching to the mainline, a build failure will occur at the appropriate stage. It forces the developer to fix the bug before proceeding further. QA teams will also be benefited from this as they will mostly be working on stable builds.
2. **Decreases bug accumulation**: Bugs are inevitable; however with the use of CI the piling of bugs is reduced greatly. Based on how effective the automation is, the bugs are easy to find early and fix, greatly reducing risks.
@@ 171,7 167,7 @@
4. **Increased transparency**: CI brings in a greater level of transparency into the overall development and QA processes. There is, at all times, a clear indication of what tests are failing, causes for failure, defects, etc. enabling you to make factual decisions on where and how to improve efficiency.
5. **Cost-effectiveness**: Based on the above points of early error detection, less bug accumulation, more automation and clarity in the overall system, it is
-
#### 3.4 CI In QA – A Point Of View
+
#### **3.4 CI In QA – A Point Of View**
1. **Initial tests:** We left off at a point where we now have a good build after a code commit. The code commit should trigger some automated tests – smoke or sanity checks certifying that the build is now ready for QA.
2. **Automation Framework:** To stay true to CI, every QA team should invest in building a test automation framework that automatically triggers tests that uncover not only feature specific shortcomings but also identify framework enhancement requirements (for current and new tests).
@@ 179,7 175,7 @@
4. **Automation across different types of testing:** Continuing the previous point, automated test coverage should include different types of testing – functional and non-functional tests – such as stress, load, performance, regression, database, acceptance, etc.
5. **Bugs:** This is particularly interesting because even the logging of bugs can be automated with a CI system! You can poll for certain kinds of errors coming up in the logs and on encountering them, a bug is automatically logged. A typical example of this situation is auto-logging bugs for nullPointerExceptions observed in a server trace log.
-
#### 3.5. CI Implementation And Best Practices
+
#### **3.5. CI Implementation And Best Practices**
Continuous Integration aims to have a drastic drop in the degree of errors during software development through feedback mechanisms, automation, and quick bug fix turnaround.
Although it may seem too ambitious for a process to achieve all of this, it can certainly be a reality with some of the continuous integration best practices described below:
@@ 210,7 206,7 @@
-
## Conclusion
+
## **Conclusion**
Application of CI in test organizations proves to be invaluable for its automation scope.
As we’ve seen above CI reduces testing effort with a promise of greater accuracy. This is much needed for the Continuous Delivery process as a whole.