A Quick Review of Playwright Framework's Robust Features

1. Supported Languages 
• Playwright supports JavaScript, TypeScript, Python, and C# for writing tests.
2. Playwright Supported Browsers
• Playwright supports Chromium, Firefox, Microsoft Edge, and WebKit, covering most major browsers.
3. Playwright Test Generator [Record & Playback]
• This is the most cool feature, enabling the introduction of Playwright to manual QA engineers without any trouble, transitioning them to hybrid QA roles. The Playwright Test Generator helps create test scripts by recording user interactions with a web page. It generates code snippets that can be directly used in test files, making it easier to write tests by capturing the exact sequence of actions performed during manual testing.
4. Locators
• Playwright comes with multiple built-in locators such as page.getByText(), page.getByLabel(), page.getByTestId(), and page.getByTitle(). Additionally, you can use locators by CSS or XPath, making it easy to identify and interact with elements on a web page.
5. Assertions
• Assertions in Playwright verify that a web application behaves as expected during testing. By default, failed assertions terminate test execution. Playwright also supports soft assertions, where failed soft assertions do not terminate test execution but mark the test as failed.
6. Reports
• Reports in Playwright provide detailed information about test execution, including passed and failed tests, errors, and logs. Playwright offers built-in reporters and supports third-party reporters like Allure for more comprehensive and visually appealing reports, aiding in efficient test result analysis.
7. Hooks
• Hooks are functions that run at specific points in the test lifecycle, such as before or after each test or suite of tests. Playwright supports various hooks, including beforeAll, beforeEach, afterAll, and afterEach, allowing developers to set up or clean up resources, configure test environments, and perform other tasks.
8. Groups
• Groups in Playwright allow organizing tests into logical collections or suites, aiding in better structuring and management of tests. This is useful for executing related tests together, such as smoke testing and regression test cases. Grouping can also help run specific sets of tests based on tags, configurations, or test requirements.
9. Re-use State & Re-use Authentication
• Re-using state and authentication in Playwright tests involves preserving and sharing session information across multiple tests. This technique reduces the need to repeatedly log in or set up the state for each test, improving test speed and efficiency by maintaining a consistent test environment.
10. Global Setup and Teardown
• Global setup and teardown functions in Playwright run once before and after the entire test suite, respectively. These functions are used to perform tasks such as initializing test environments, starting servers, or cleaning up resources, ensuring a consistent and isolated environment for all tests.
11. Sharding
• Sharding in Playwright involves splitting test execution across multiple parallel processes or machines to reduce total test run time. This technique improves efficiency and speed by distributing the test load, making it possible to run large test suites quickly and effectively.
12. Fixtures
• Fixtures in Playwright are reusable components or data that can be set up and used across multiple tests. They help in preparing the test environment, such as initializing databases, setting up test data, or configuring application states, ensuring consistency and reducing redundant setup code.
13. API Support For The Frontend Automation
• Playwright provides API support for testing frontend applications by simulating user interactions, capturing network requests, and inspecting the DOM. This allows for end-to-end testing of web applications, ensuring that frontend components work correctly and interact as expected with backend services.
14. Design Pattern - Page Object Model
• The Page Object Model (POM) is a design pattern used in Playwright to create reusable and maintainable test code. It involves creating separate classes for different pages or components of the application, encapsulating the interactions and elements within these classes. POM promotes code reuse and reduces duplication.
15. Trace Viewer
• The Trace Viewer is a tool in Playwright that provides detailed traces of test execution, including network activity, DOM snapshots, and action logs. It helps in debugging by allowing developers to step through the test and inspect the state of the application at each step, identifying issues and understanding test behavior.
16. Screenshots, Videos
• Playwright can capture screenshots and videos during test execution to visually document the state of the application. These artifacts help in debugging and understanding test failures by providing a visual record of what happened during the test. Screenshots can be taken at specific points, while videos can record the entire test session.
17. Emulation
• Emulation in Playwright refers to simulating different devices, screen sizes, and user agents to test how a web application behaves across various environments. This includes mobile device emulation, geolocation, and network conditions, enabling comprehensive testing of responsive and adaptive designs.
18. Data Set
• Data sets in Playwright refer to collections of test data used to drive tests with different inputs and scenarios. Using data sets allows for parameterized testing, where the same test logic is executed with various data combinations, ensuring thorough coverage and validation of application behavior.

Understanding What Agile Testing Is: Key for Beginners

 

What is Agile Testing..

1. Definition

2. Differences between Traditional Testing and Agile Testing

3. Key attributes of Agile Testing

4. Principles of Agile Testing

5. Agile Testing Methods

6. Agile Testing Quadrants 

1. Definition

Agile testing is basically a software testing process that follows the principles of agile software development. Agile testing is a part of Agile Software Development in which the development and the testing process go side by side.

2. Differences between Traditional Testing and Agile Testing

There are traditional development approaches like Waterfall and V Model. The most common one is the waterfall approach, which is a sequential development process that flows like a waterfall. It encompasses all phases of a project, including requirement gathering, designing, development, testing, and deployment. In the waterfall approach, there is no overlap between the phases, and the final outcome is generated at the end. This approach is considered suitable for projects with clearly defined requirements and a stable environment.

The Agile methodology is a more flexible and iterative approach that emphasizes rapid development, delivery, collaboration, and communication within the team. This methodology is employed in situations where requirements evolve over time. Unlike a linear and sequential process, the Agile methodology adopts an iterative approach, where requirements and solutions evolve through the collective effort of the team. The Agile methodology encompasses various methods such as Scrum, Kanban, Extreme Programming, Lean, and Crystal, with Scrum and Kanban being the most commonly used approaches. The primary focus of Agile is to deliver small increments within short timeframes and gather feedback from stakeholders. This iterative approach leads to cumulative outcomes.

Waterfall Testing	Agile Testing
Testing is a separate phase	Testing is NOT a separate phase
Testing is carried out only after the completion of development	Testing is performed alongside development
The development team and testing team often work separately	The development and testing teams work together
Acceptance testing is carried out only at the end	Acceptance testing is carried out after every iteration
Regression testing is carried out at the end	Regression testing is carried out after every iteration

Testing is a separate phase in the waterfall approach because it follows a linear sequential flow, where each phase must be completed before moving onto the next phase. In the waterfall approach, testing is considered as a separate phase to ensure that the product meets the requirements with high quality before it is delivered to the customer. However, in an agile approach, testing is considered as an integral part of each development cycle and not a separate phase. This approach helps to ensure that the bugs are caught early and that the features are delivered with high quality.

In the waterfall approach, testing is carried out only after the completion of development because each phase of the process must be completed before moving on to the next one. In this approach, development needs to be finished before testing can begin since testing requires a complete software product. Any bugs or defects discovered during testing cannot be addressed until the next phase, potentially leading to time-consuming and costly rework in the design or implementation stages. On the other hand, in an agile approach, testing is performed alongside development as it follows an interactive and incremental model of software development. Unlike the waterfall approach, agile allows for flexibility and adaptability throughout the development process. Testing is an ongoing process in agile, conducted continuously throughout the development cycle. The development team collaborates closely with the testing team to ensure timely testing of each feature implementation. This early bug identification reduces the risk of rework in later development stages. Agile methodology incorporates stakeholder feedback through regular retrospectives and sprint reviews, ensuring that the product meets user needs and aligns with business goals. One advantage of agile testing is its ability to facilitate a more flexible and responsive development process.

In the waterfall approach, the development team and testing team often work separately because of the sequential and linear model. In this approach, the development team focuses on the design and implementation of the software, while the testing team focuses on verifying that the software meets the requirements and specifications. The two teams work separately to ensure that their respective tasks are completed efficiently and effectively. One disadvantage of this approach is that it can lead to a lack of collaboration between the development and testing teams, as well as a lack of understanding of the testing process by the development team, which can result in defects being introduced into the software that could have been prevented if the development and testing had worked together more closely. The development and testing teams work together in an Agile approach because it emphasizes collaboration and communication between all the members who are involved in the project. By having the development and testing teams work closely together, they can catch and fix the defects earlier in the development process, which saves time and reduces the cost of fixing issues later on.

In the waterfall approach, acceptance testing is carried out only at the end because the acceptance testing phase comes after the system has been fully developed and integrated, and all lower-level testing has been completed. By waiting until the end of the development process to conduct acceptance testing, the testers can verify that the system meets the requirements and specifications that were established at the beginning of the project. This allows them to sign off on the project, indicating that they are satisfied with the end result and the project is ready for release. In the agile approach, acceptance testing is carried out after every iteration to ensure that the software meets the needs and expectations of the stakeholders. Agile development encourages frequent feedback, so it is important to validate the progress of the project after each iteration to make sure it is on track. By conducting acceptance testing after each iteration, the stakeholders can verify that the software meets their requirements and can provide feedback on any changes that they would like to see. This helps to ensure that the project is aligned with the stakeholders' goals, and if there are any deviations from the original plan, they can be corrected early in the development process. Conducting acceptance testing after each iteration provides a sense of accomplishment and helps the development team to validate that their work is on track. It helps to prioritize features and functionalities so that the most important items are completed first.

In the waterfall approach, regression testing is carried out at the end of the development process for a couple of reasons. One reason is the sequence of stages. Regression testing is considered to be a part of the final testing phase, so it is conducted after all other testing has been completed. Another reason is the limited change management. The waterfall approach is based on a more rigid and sequential development model that doesn't accommodate changes easily. As a result, there are fewer changes to the system during the development process, which reduces the need for frequent regression testing. In the agile approach, regression testing is carried out after every iteration to ensure that the changes to the system don't negatively impact the existing functionalities. Regression testing verifies that previously developed and tested functionalities still work as expected after the changes have been made to the system. In the agile approach, changes are expected and even encouraged because the goal is to respond to changing requirements. By conducting regression testing after each iteration, the development team can quickly identify and resolve any issues that may have been introduced as a result of these changes. Conducting regression testing after each iteration helps to catch the problems early in the development process, before they become more difficult and expensive to resolve. This is particularly important in Agile because the goal is to deliver to the stakeholders as quickly as possible and to minimize the risk of delays and rework. Overall, regression testing in Agile ensures that the system is always in a releasable state.

Even Though the waterfall approach has been widely used in the past, it has been criticized for its flexibility and difficulty in accommodating changes during the development process. Whereas, agile development methodologies have emerged as a more flexible and adaptive alternative that can handle the changing requirements better and allow for more frequent testing and feedback. 

3. Key attributes of Agile Testing

3.1 Communication with 3 amigos - 

This refers to the practice of having regular communication between the 3 key stakeholders involved in the project, the product owner or the BA, the development team and the QA team. This type of communication helps to ensure that everyone is aligned on the goals and requirements for the project and any issues or challenges can be identified and addressed early. In this way, everyone is able to work together to ensure the high quality of the software. This approach has more transparency and helps to break down silos, so that the BA, developers and QA team can all work together effectively. By involving the testing team from the outset, it helps to identify any trestig issues or challenges early, so that they can be addressed before they become bigger problems.

3.2 Collaboration with devs - 

Collaboration with the developers is another key attribute of Agile testing that is critical for the success of the project. In Agile testing, the testing team works closely with the development team to ensure that the software is tested effectively and efficiently. This collaboration helps to identify any issues early in the development process, and makes it easier to resolve them and maintain high quality. It’s important to know the development approach by the testing team and vice versa. 

As an example, 

1. The tester should collaborate with the developer about the development approach of a particular feature and the tester should include that to the test cases to ensure that the feature is developed and tested accordingly. 

2. Pair testing - Ex: Chaos testing, performance testing

3.3 Quality is everyone’s responsibility - 

This emphasizes the importance of shared responsibility for ensuring the software meets the desired quality standards. In Agile testing, the goal is to involve everyone in the development process to maintain the quality of the project. This means that everyone, from the BA to the developers, to the testers, is accountable for ensuring the quality standards and if any issues are identified, they should be addressed as soon as possible. Individuals are responsible for the components that they are working on. By making quality everyone’s responsibility, it helps to ensure that the project meets the needed quality standards, and everyone is working together towards this goal. 

4. Principles of Agile Testing

4.1 The 3 amigos involvement - 

The 3 amigos involvement is a principle of Agile testing that refers to the regular communication and collaboration between the 3 key stakeholders in the project. This principle is based on the idea that everyone involved in the project should be working together to ensure that the project meets the desired quality standards. By having regular 3 amigos meetings, everyone is able to stay aligned on the goals and requirements. 

1. As an example, BA will first write down the requirements and the initial acceptance criteria and they will be explained to the project team during the grooming ceremony.  Then the other 2 amigos will evaluate the requirements and the initial acceptance criteria, suggest and amend them and all 3 will finalize. 

2. Shift Left Testing approach -

In the waterfall approach, testing starts upon completing the development process. Whereas, in the Agile Methodology, testing starts as soon as the requirements are finalized. The testing team will evaluate the requirements and communicate the gaps to the BA and dev team to amend if necessary. Simply, all 3 amigos should have the same understanding about the requirements. Shift left testing is a type of static testing, finding the issues in static testing is very cheaper when compared to dynamic testing. 

4.2 Continuous testing perform by the team - 

The goal here is to test the software as early and often as possible, so that issues can be identified quickly. For example, the testers can perform automated or manual smoke tests on a regular basis, after each IR, which helps to catch issues in the basic business flow and prevents them from becoming bigger problems down the line. They can perform exploratory testing or regression testing whenever possible. 

Dev testing - 

Before the IR is deployed, the developers should test the features that they are implementing, and after the IR, they should test if the IR is deployed accurately without any major breakdowns.

Smoke testing - 

After the IR is deployed, the QA team will do a smoke test to ensure that the basic business flow is working without any blockers. 

1. Smoke tests should be done and successfully pass in each IR to accept for further feature testing. If there are any blockers and existing feature breakages, QA has to communicate to the development team. 

2. Smoke testing is a repetitive task because it should be executed in each IR. 

Regression testing - 

Once the release [expected iteration is done] is done, the testers will do a regression test.

Production Sanity -

After the Production release, the QA team will conduct a sanity test in the Prod environment.  

4.3 Continuous FEEDBACK - 

Continuous feedback means the importance of regular communication between the teams. This principle is based on the Agile philosophy that prioritizes delivering working software frequently and adapting to changing requirements. Continuous feedback in Agile testing means that testing happens throughout the development process and not just at the end. The testing team provides regular feedback to the developers on the quality of the software’s ability to meet customer requirements. This helps the development team to make necessary adjustments and improvements to the software and to deliver with a high-quality state. By encouraging continuous feedback, agile teams can identify and resolve issues early in the process and reduce the risk of delays and rework. It builds the trust between the teams and other stakeholders such as the customers or vertical leads. It is a critical principle where you encourage  and accommodate the changing requirements. 

4.4 Test Driven - 

The Test-Driven approach prioritizes writing tests before any code. The main objective is to define the behavior of the software and then start implementing to meet those expectations. Here, tests are written first to describe the expected behavior of the software. Then the developers start to implement the code to make the tests pass. This process is repeated until all tests pass and the software is complete. The tests work as a safety net, to ensure that the code continues to meet the expected behavior as it evolves over time. This approach helps to improve the quality by catching bugs early and making sure that the code is maintainable and flexible and the tests protect the code from unintended changes. 

4.5 Less Documentation -

Less documentation is based on valuing working software over comprehensive documentation. The focus in agile testing is on delivering value to the customer with high quality software that meets their needs, rather than spending a lot of time on documenting every aspect of the process. The idea behind less documentation is that documentation should only be created if it is needed to support the development process or to provide value to the customer. This approach streamlines the development process and saves time to allow teams to focus on delivering value to the customer in the form of working software. 

Ex : A traditional lengthy Test Plan is not needed, instead all the necessary details can be included in a few pages. 

Same as that the Release Note does not have to be long, it can be sent with minimal important details. 

5. Agile Testing Methods

5.1 BDD - 

Behavior-Driven Development is based on how the customer will interact with the application. BDD provides a clear understanding of the outcome and enables the team to develop software to meet the ultimate customer needs. The process starts with writing scenarios which will be discussed in the 3 amigos sessions. Along with the development the tests are executed and provide fast feedback on the system’s behavior. This helps to catch defects soon and reduce the overall cost of fixing them.

5.2 ATDD -

Acceptance Test-Driven Development is where acceptance criteria are defined before development begins, and the test cases are used to guide and validate the development process. In ATDD, all the stakeholders work together to define clear, concise and testable acceptance criteria for a feature. Then these tests are run regularly throughout the development process to ensure the feature is built to meet the acceptance criteria and to provide fast feedback. So ATDD is a key part of the agile methodology which ensures that the delivered software meets the customer expectations.

5.3 Exploratory Testing - 

Exploratory testing is where testers interact with the application to understand it and test it  and identify defects. The goal of this is to find defects quickly and identify areas of the application that may need improvements. This approach encourages the testers to be creative and think critically about the application and how it can be tested. Unlike other testing methods, this approach does not follow a strict set of test cases or a predetermined plan. Instead, it’s a dynamic, iterative process that allows the testers to react to the application as they are testing it. This allows the testers to focus on areas that need more attention and to adapt their testing approach as they learn more about the application.

Ex: Exploratory testing is one of experience based testing techniques. Experience based testing techniques have 3 types, 

1. Error guessing

2. Checklist based testing

3. Exploratory testing

6. Agile Testing Quadrants

Q1 - Automated : - Unit Tests, API Tests,  Components Tests	Q3 - Manual : - Exploratory Testing, Usability Testing , UAT Testing
Q2 - Automated & Manual : - Functional Testing,  Story Tests	Q4 - Tools : - Performance & Load Testing, Security Testing

The whole process is separated into 4 quadrants and helps to understand how agile testing is actually performed. The internal code quality is the main focus, for the first quadrant. It has test cases which are technologically driven and are implemented to support them. It includes the unit tests, API tests and component tests. This quadrant is automated. 

The quadrant 2 contains test cases that are business driven and are implemented to support the team. This quadrant focuses on the requirements. Functional testing and story tests are done in this quadrant and they can be both automated and manual. 

The Q3 provides feedback to Q1 and Q2. Many rounds of iteration reviews are carried out here which builds confidence in the product. The kind of testing done in this quadrant is the exploratory testing, usability testing and User Acceptance Testing. This quadrant is fully manual. 

Final quadrant concentrates on the non-functional requirements such as performance and load testing and security testing. With the help of this quadrant, the application is made to deliver the non-functional qualities and the expected value. 

Q4 is done by different tools that are there for different non-functional testing types.

Basic Syntax Of XPath For Beginners

 

1. Basic format of XPath

Format: //tagname[@Attribute=’Value’]

    Ex: //input[@id=’first_name’]

2. Absolute XPath starts with the root node. Single forward slash (/).

Ex: /html/body/div/div[3]/div

3. Relative XPath starts from the middle of the HTML DOM structure. Begins with double forward slash (//).

Ex: //input[@name=’user[first_name]’]

4. XPath function - “starts-with”

“starts with” function is helpful in finding dynamic web elements. 

Format: //tagname[starts-with(@Attribute,’Value’)]

Ex: //input[starts-with(@id,’last_name’)]

5. XPath function - “contains”

“contains” function is helpful in finding dynamic web elements. 

Format: //tagname[contains(@Attribute,’Value’)]

Ex: //input[contains(@name,’email’)]

6. XPath function - “text()”

“text()” method is used to find elements with exact text matches. 

Format: //tagname[text()=’ActualText’)]

Ex: //a[text()=’Terms_Of_Use’]

7. XPath function - and

Helpful if you want to use more than two attributes to find an element on the webpage.

Format: //tagname[@Attribute=’Value’ and @Attribute=’Value’]

Ex: //input[@type=’text’ and @name=’user[first_name]’]

8. XPath function - or

Helpful if you want to use more than two attributes to find an element on the webpage.

Format: //tagname[@Attribute=’Value’ or @Attribute=’Value’]

Ex: //input[@type=’text’ or @name=’user[first_name]’]

9. XPath function - parent

Selects the parent of the context (current) node.

Format: //tagname[@Attribute=’Value’]//parent::tagname

Ex: //select[@name=’user[country]’]//parent::form

10. XPath function - child

Selects all children of the current node.

Format: //tagname[@Attribute=’Value’]//child::tagname

Ex: //select[@name=’user[country]’]//child::option[1]

11. XPath function - self

Selects the current node.

Format: //tagname[@Attribute=’Value’]//self::tagname

Ex: //select[@name=’user[country]’]//self::select

12. XPath function - descendant

Selects all the descendants (children, grandchildren, etc) of context (current) node.

Format: //tagname[@Attribute=’Value’]//descendant::tagname

Ex: //div[@class=’signup_container’]//descendant::div

13. XPath function - descendant-or-self

Selects the context (current) node and all of its descendants (children, grandchildren, etc).

Format: //tagname[@Attribute=’Value’]//descendant-or-self::tagname

Ex: //div[@class=’signup_container’]//descendant-or-self::div

14. XPath function - ancestor

Selects all the ancestors (parent, grandparent, etc) of context (current) node.

Format: //tagname[@Attribute=’Value’]//ancestor::tagname

Ex: //*[@id=’errorbox’]//ancestor::div

15. XPath function - ancestor-or-self

Selects the context (current) node and all of its ancestors (parent, grandparent, etc).

Format: //tagname[@Attribute=’Value’]//ancestor-or-self::tagname

Ex: //*[@id=’errorbox’]//ancestor-or-self::div

16. XPath function - following

Selects all the nodes that appear after the context (current) node.

Format: //tagname[@Attribute=’Value’]//following::tagname

Ex: //option[@value=’Developer’]//following::option

17. XPath function - following-sibling

Selects all the nodes that have the same parent as the context (current) node and appear after the context (current) node.

Format: //tagname[@Attribute=’Value’]//following-sibling::tagname

Ex: //option[@value=’Developer’]//following-sibling::option

18. XPath function - preceding

Selects all the nodes that appear before the context (current) node.

Format: //tagname[@Attribute=’Value’]//preceding::tagname

Ex: //option[@value=’Developer’]//preceding::option

19. XPath function - preceding-sibling

Selects all the nodes that have the same parent as the context (current) node and appear before the context (current) node.

Format: //tagname[@Attribute=’Value’]//preceding-sibling::tagname

Ex: //option[@value=’Developer’]//preceding-sibling::option