How does it work — We need the following infrastructure in place:

1. GitLab Repository — you need something to store the code. We have chosen GitLab as the repository for this example.

2. CI/CD Pipeline — We will configure GitLab CI/CD pipeline to automate the build and deployment.

3. Load Balancer — This is required to switch between the blue and green environments. We will use any open-source tool for this. We will be using NGINX as the Load Balancer which will direct traffic to the blue environment by default. This ensures that users continue to access the stable version while you deploy and test the new version in the green environment.

The IP addresses for blue and green environment will need to be updated in the NGINX configuration file. At the same time, your DNS settings need to point the domain to NGINX server’s IP address.

4. Two Production Environments — Lastly, we need two environments which will be known as the blue and green environment.

Here is a flow to explain how it works in detail:

Stage 1 & 2

Stage 1 — At this stage, the two environments are set up with same version of code. Either of them can be used for same experience but all user traffic is directed to Blue environment at this point as in the picture at the left.

Stage 2 — This is when a new deployment happens. We will release the new version 1.1 into the Green environment to ensure user experience is not disturbed. Load balancer will still continue to direct all traffic to Blue as in the picture at the right.

We can configure GitLab CI/CD pipeline to build, test, and deploy your application. Use the .gitlab-ci.yml file to define the pipeline stages and jobs. Normally, we have to define the deployment stages in this file like build, test, deploy etc. Every step will have its own jobs and scrips to execute related actions automatically.

Stage 3 & 4

Stage 3 — At this stage load balancer will start directing some of the user traffic to Green. This will serve the purpose of beta testing also and entire traffic can be quickly diverted to Blue in case there is any problem with the new release. In the picture for Stage 3, we can see 40% of users have been moved to Green environment while 60% of them are still in Blue environment.

Stage 4 — At this stage the Load Balancer has completely moved all users into Green environment which is working as the active production environment. Blue can continue to have release 1.0 even at this stage.

Stage 5 & 6

Stage 5- At this stage a new release comes along. Version 1.2 which also contains updates code base for the previous version 1.1 is deployed into Blue environment using CI/CD pipeline. All users still continue to be using Green environment.

Stage 6- The load balancer once again starts directing users to the new production environment, which is Blue with the latest version 1.2. Eventually, 100% users move to Blue and the same cycle keeps repeating with every release.

Benefits

There are many benefits of using this blue green deployment strategy in this way.

Zero Downtime: Blue-green deployment allows updates to be rolled out without causing any downtime for users. While one environment (let’s say “blue”) is serving live traffic, the other environment (green) can be updated or modified. Once the changes are made and the green environment is ready, traffic can be seamlessly switched from the blue to the green environment.

Risk Reduction: By maintaining two identical environments, one serving live traffic and the other being updated, we are reducing the risk associated with deploying changes significantly. If any issues arise during deployment in the green environment, it can be easily rolled back by directing traffic back to the blue environment and vice versa. This rollback process can be performed quickly and with minimal impact on users.

Testing in Production-Like Environment: Blue-green deployment allows for thorough testing of updates in a production-like environment before they are made live. Users can be gradually directed to allow for Beta testing. This ensures that any potential issues or bugs are identified and addressed before the changes are exposed to all users.

Quick Rollback: If any issues are detected after deploying changes to the green environment, it’s straightforward to revert to the blue environment, which would still be running the previous stable version of the application. This rollback process can be automated as well in the CI/CD pipeline.

There are many ways to come up with a stable Blue Green environment set up. Some of the cloud providers like AWS come with sophisticated packages as well. Once integrated in the CI/CD pipeline this allows for automated and frequent deployments of updates to the application. Rolling deployments increase productivity of the team and also allow for quick fixes of bugs bringing in tremendous value to both quality and quantity of delivery.

Difference with Traditional Testing: In traditional testing, the testing phase is positioned towards the “Right” of the software development life cycle (SDLC). This means that requirement understanding, test case creation, execution, and defect detection occur after development is complete. This approach poses risks, such as delays and missed project timelines due to late bug detection and increased rework. To address these issues, the Shift-Left approach moves many testing steps to earlier phases of the project. It promotes collaboration between developers and testers, fostering shared responsibility for quality.

How Shift-Left Helps:

1. Early Bug Detection: By testing early, Shift-Left testing catches defects in their early stages, reducing the risk of critical issues going unnoticed. This minimizes the cost and effort required for defect fixing, avoiding setbacks.

2. Improved Communication and Collaboration: Continuous feedback from testers enhances code quality and increases efficiency. Testers gain a clear understanding of requirements from the beginning, resulting in better collaboration.

3. Faster Time to Market: Shift-Left testing accelerates the development cycle by reducing rework, optimizing test cycles, and streamlining defect resolution. This enables organizations to gain a competitive edge by delivering software solutions faster.

4. Test Driven Development (TDD): The Shift-Left approach aligns well with Agile continuous testing and TDD methodologies. Features are tested from the initial draft code and continuously throughout the development process. By the time formal testing begins, a significant portion of the testing steps has already been completed, reducing inefficiencies.

In a Shift-Left approach, testing activities are not delayed until a dedicated testing phase. Instead, they occur concurrently with development. The following steps exemplify this approach:

• Requirements understanding from testers’ perspective

• Test planning

• Test design

• Test environment setup

• Code quality reviews

• Partial test execution

• Early defect identification and management

Types of Testing In-Scope

While not all testing types can be executed before development is complete, the following can be shifted at least partially to the left.

• Unit Testing: In Scope. Developers conduct unit testing during development once logical functionalities are complete.

• Integration Testing: In Scope. Testers can test the integration between various modules early and continuously.

• Regression Testing: In Scope. If regression test cases are automated, they can be executed during development, providing early feedback. Manual testing may have limited success in shifting regression testing to the left.

• Performance Testing: Partially in-scope. Proper performance testing requires complete deployment, making early results less accurate and beneficial.

• System Testing: Partially in-scope. By definition, system testing involves testing the software as a whole and is typically executed after development completion. However, preparatory steps, such as test creation, can occur earlier.

• Security Testing: Partially in-scope. Similar to performance testing, comprehensive security testing is advisable after development completion.

Implementing the Shift-Left approach requires a cultural shift and additional training for testers. Despite the challenges, it offers significant advantages to Agile teams and organizations requiring rapid development and testing. While the concept of Shift-Left testing has existed for some time, it has gained additional traction in recent years, helping organizations stay competitive in the ever-evolving software development landscape.

In this article, I will compare Playwright and Puppeteer, highlighting their similarities, differences, strengths, and weaknesses. The goal is to equip you with the essential insights to make an informed decision on which tool best aligns with your project requirements and development needs.

Overview of Playwright and Puppeteer

Playwright is an open-source Node.js library developed by Microsoft that enables developers to automate browser actions and interactions for testing and scraping purposes. It supports multiple browser engines, including Chromium, Firefox and WebKit, allowing for seamless cross-browser testing. Playwright provides an easy-to-use API and a robust set of features, making it a go-to choice for many developers.

On the other hand, Puppeteer is a Node.js library created by the Chrome team at Google. Like Playwright, Puppeteer is designed for automating browser actions and interactions, but it primarily focuses on the Chromium browser engine. Puppeteer boasts a user-friendly API and a strong feature set, making it a popular choice for web automation and testing tasks since the time it came out in 2017.

Similarities

Playwright is written and maintained by people who had earlier worked in Puppeteer and then moved to Microsoft so there are obvious similarities.

Both tools provide a comprehensive API for automating browser interactions, such as clicking buttons, filling out forms, and navigating pages. There is also headless browser support, allowing developers to run tests and automate tasks without the need for a visible browser window. Both tools can capture screenshots of web pages or generate PDF files, making it easy to save visual representations of a site’s content. In both Puppeteer and Playwright, developers can intercept and modify network requests and responses, providing greater control over the testing environment. Both allow execution of JavaScript within the context of the web page as well, enabling developers to interact with and modify the DOM as needed.

Differences Between Playwright and Puppeteer

Despite their obvious similarities and similar goals, Playwright and Puppeteer have some key differences that set them apart:

Browser Support: One of the most significant differences between the two tools is their browser support. Playwright provides out-of-the-box support for Chromium, Firefox, and WebKit, facilitating cross-browser testing. In contrast, Puppeteer primarily focuses on the Chromium browser engine, with limited support for Firefox and no native support for WebKit.

Selector Engine: Playwright offers a more advanced selector engine compared to Puppeteer. It supports a variety of selector types, including CSS, XPath, and text-based selectors, while Puppeteer mainly relies on CSS and XPath selectors. This can make it easier to target specific elements on a web page with Playwright.

Multiple Contexts and Pages: Playwright allows developers to work with multiple browser contexts and pages simultaneously, enabling more complex testing scenarios. Puppeteer, on the other hand, has limited support for managing multiple contexts and pages, making it more challenging to handle intricate test cases.

Auto-Waiting Mechanism: Playwright features an advanced auto-waiting mechanism that automatically waits for elements to become available before performing actions. This can help to reduce the need for manual timeouts and improve the stability of tests. Puppeteer lacks this advanced auto-waiting functionality, requiring developers to rely more on manual timeouts and workarounds.

Accessibility Testing: Playwright has built-in support for accessibility testing, allowing developers to verify that their web applications meet accessibility standards. Puppeteer does not have native support for accessibility testing, requiring additional tools or libraries to perform such tests.

When to select Playwright:

➕ You need to test across multiple browsers, as Playwright offers out-of-the-box support for Chromium, Firefox, and WebKit.
➕ You have complex testing scenarios that involve multiple browser contexts or pages, which Playwright handles more effectively.
➕ You prefer advanced element selection capabilities, as Playwright provides a versatile selector engine.
➕ You value stability and automatic waiting mechanisms, which are built into Playwright and help reduce flakiness in tests.
➕ Accessibility testing is a priority, as Playwright offers built-in support for this feature.

When to Choose Puppeteer:

Puppeteer might be the better solution if:

➕ You mainly target the Chromium browser engine and don’t require extensive cross-browser testing.
➕ You or your team have prior experience with Puppeteer or an existing codebase that leverages it, making it more efficient to continue using the tool.
➕ You have simpler test cases that don’t require managing multiple browser contexts or pages, which Puppeteer handles with some limitations.
➕ Your project relies on Chrome-specific features or APIs, as Puppeteer’s close integration with the Chromium browser engine ensures better compatibility and support.

Test Driven Development (TDD)

This is perhaps the oldest of the method here and was developed in the late 1990s. This method puts testing at the core of development and everything else revolves around it.

Unit Testing is the driving force here. Rather than writing the code and then testing, first it is tested. This will obviously fail and then code will be written and tested again. This process will keep repeating till the test is successful.

Test cases are typically automated in same language as the implementation language.

The steps involve –

· Writing unit test cases in collaboration between developers and testers

· Executing test cases

· Coding to address issues

· Executing test cases again and so on..

· Testers can do integration tests once Unit test is successful.

Behavior Driven Development (BDD)

This method started getting popular in the early 2000s and acceptance testing is the focus here. This is driven from the purpose of focusing on the expected behavior so that both technical and non-technical people are on the same ground. Typically implemented using many available tools in the market like Cucumber, Quantum, SpecFlow, JBehave etc.

Typically the test cases would be written in a language called Gherkin which follows a Given, When, Then format of specifying anything. Tests are written at scenario level and clearly maintained in feature files.

The end goal is to have a test case in natural language yet in a standard format. This can be understood and implemented by everyone working in the team and ensures end goal is met.

The steps involve -

· Identify the scenario for BDD

· Write the feature file in Given, When, Then format

· Run the feature file in appropriate language

· Check the test results of the run and fix the errors.

· Redo the process

Acceptance Test Driven Development (ATDD)

This also came into focus in the early 2000s. Acceptance testing is again the focus here as the name suggests but the purpose is clear capture of the requirements. This is also usually written in Gherkin and typically the tools used in BDD can be used here also. This brings customers to the testing table even before development has begun.

There are few situations where ATDD can do wonders. As the end goal is very clear to everyone, estimate are more accurate and collaboration improves in the team. It can help when technical debt is high in the project.

ATDD can be effective in reducing rework also due to clarity and save time. It reduces many problems Agile teams typically face.

The steps involve –

· Train the stakeholders on objectives and expectations

· Write the acceptance test cases

· Implement iterative learning

Domain Driven Development (DDD)

Understand the big picture and end goal. Once that is clear, decompose it into smaller deliveries and follow usual SDLC for the smaller pieces. This is the gist of domain driven development which came after all the other methods. This is not replacing any of the above methods but working in tandem with them to improve the process.

Summary

So do these methods exist separately? Is it a choice to pick one of them or all together?

It depends on the project but for a reasonably big one, all of them can be used together. In fact for best results, it may be good to combine some of them together and not just pick one.

· Start with the big picture by doing DDD

· Once decomposed into smaller pieces, go with BDD or ATDD or both as required

· Once further decomposed into unit level, developers need to work with TDD

There may be training period for the team to get accustomed to this but once there, the development process can improve and reduce issues as well.