In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

 In this post, I’ll be discussing my thoughts on an article I found on the Ministry of Testing website titled “An introduction to Continuous Integration (CI) and Continuous Delivery (CD) pipelines for software testers.” This piece really stood out to me because it highlighted the importance of integrating testing into the continuous integration and continuous delivery (CI/CD) pipeline. I’ve been learning about automated testing and CI/CD practices, and this article helped me better understand how testing can be embedded into each phase of the development cycle to ensure high-quality software and faster release times.

One key point that really resonated with me was the idea of shifting left, which means testing early in the development process. The author explained that integrating tests into the CI/CD pipeline allows teams to detect bugs and issues earlier, rather than waiting until the end of the development cycle. This makes perfect sense to me because I’ve seen firsthand in my career how much more efficient the development process becomes when tests are automated and run continuously. Instead of waiting for a bug to be discovered during a manual testing phase late in the process, CI/CD testing enables teams to catch those issues as they happen, significantly reducing the risk of production bugs and minimizing the effort needed to fix them. When things build up, business units accrue a lot of technical debt, and I end up having to hound them to fix 20 different things at the same time, instead of them being able to handle them as they appear, which CI/CD pipeline testing may help them with.

By incorporating automated tests into the pipeline, I can quickly get feedback about the code I’ve written, allowing me to catch mistakes early. However, I also realized that the article pointed out a very important note that I agree with: not all tests can be fully automated. There are still areas, such as user experience or complex edge cases, that may require more manual or exploratory testing. This balance of automated and manual testing within CI/CD pipelines is something I’ve experienced while developing a public facing status page, where it is not just functionality that needs to be tested, but also human elements, like how the page looks.

The article also discussed how testing within the CI/CD pipeline encourages a mindset of continuous improvement. Each time a test fails or catches an issue, it provides an opportunity to address potential gaps in the process and refine both the tests and the code. I think this aligns perfectly with the idea of being a “Software Apprentice,” always looking for ways to improve and enhance the quality of the product, no matter how far along in the development cycle it may be. Overall, this article reinforced the idea that CI/CD testing is not just about speeding up development—it’s about focusing on quality, where testing is an integral part of every stage.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

This reading presents an insightful perspective on software craftsmanship, emphasizing apprenticeship, perpetual learning, and skill mastery. The concept of learning through mentorship and practical experience, as illustrated in Dave’s story, was particularly interesting. It highlights the importance of hands-on work, exposure to real-world challenges, and the necessity of a growth mindset in becoming a great developer. The reading has influenced my perspective on professional growth. It reinforces the idea that mastering something comes from deliberate practice, seeking out mentors, and embracing failure as a learning opportunity. I believe this is what makes a good developer. One point I disagree is the romanticization of craftsmanship. While the focus on individual skill development is inspiring, modern software development requires collaboration with teams. Balancing skilled craftsmanship with effective teamwork is important. In chapter 2, I find the story of the Zen master and the young philosopher was provoking. It talks about the importance of maintaining a beginner’s mindset, or “emptying your cup,” to fully absorb new knowledge. I think this is important in apprenticeship. The idea that experience can sometimes be a barrier to learning is interesting and that applies to many fields, including software development.

Dave’s realization that true mastery comes not from credentials but from continuous learning and engagement with a community of experts is highly relevant. The story also highlights the importance of humility in learning. Even the most skilled developers acknowledge that they are still learning, which serves as both an inspiration and a challenge to those just starting out. The idea that learning is a lifelong journey rather than a destination is a valuable takeaway. I resonate a lot with this point because I often feel like this is a lifelong journey of continuously learning and adapting to new technologies. In terms of how I work, the idea that certifications and formal training are only steppingstones, not the final proof of competence is true. I’ve learnt that while training can provide foundational knowledge, real expertise comes from practice, engagement with peers, and continuous learning. One thing that I found interesting was the analogy of “the big fish in a small pond”. It is a powerful way to describe the risk of complacency for those who learn quickly. It’s a reminder that achieving success in a limited environment may feel rewarding, but true growth comes from recognizing the wideness of the field and challenging yourself to bigger things. I’ve learnt that it’s important to stay challenged and continuously learn. It’s easy to become comfortable in an environment where your highly competent, but it’s important to seek out mentors that can further challenge you to be even better than you already are.

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.