Forem: Mikeharris52

The Role of Continuous Testing in Delivering Quality Digital Experiences

Mikeharris52 — Tue, 13 Jun 2023 06:53:56 +0000

Testing strategy to achieve a quality experience for each of the agents.

Shift-Left and Shift-Right Testing in Continuous Testing Strategy

Continuous testing includes shift-left and shift-right testing and it is a strategy that the team should consider using in order to deliver a good quality digital experience. Development can be visualized as a timeline where writing the specification is positioned on the left-hand side of the line and production is represented on the right-hand side of the line. Continuous testing encompasses both leftward and rightward shifts along the timeline. It involves conducting testing as early as possible in the development process (leftward shift) and also performing testing in the production environment after code deployment (rightward shift).

Testing as early as possible in the development process can be described as shift-left testing, however, traditionally, testing takes place once the code is ‘ready for testing’. Once the code has been tested and bugs have been fixed the code is deployed to production. Advocates of lean processes have argued that if testing is left until the code is ‘ready for testing’ then the product’s quality is already there and testing will have little impact on improving it. Lean aims to reduce waste and lean testing would mean starting to test as early as possible in the development process. Testing in this way reduces waste because if a bug is found in the specification, it is much cheaper to fix than a bug found in the code when the code is ‘ready to test’.

Shift-left testing, as a component of continuous testing, plays a crucial role in delivering quality digital experiences. By conducting testing activities earlier in the development process, shift-left testing enables the identification of bugs and issues at an early stage. As a result, it reduces the likelihood of encountering last-minute bugs just before the release. It will be less likely that the product will be delivered late because bugs will have been found early in the process. Bugs that are found early in the process are cheaper to fix because, for example, it is cheaper to fix a fault in a specification than it is to fix a bug in production. There will be higher customer satisfaction because the code is delivered on time. If testing starts as early as possible and continues throughout the development process there will not be a testing phase and this will help deliver features earlier.

There are many types of testing that can be done as a part of shift left testing. The specification can be tested before development has started. One such type is testing the specification itself before the actual development begins. This critical examination of the specification aims to identify any errors or inconsistencies. An effective approach to testing the specification is through a collaborative “three amigos” session, where a tester, developer, and product owner work together to review the specification from their respective perspectives. This collaborative effort helps ensure a comprehensive and well-rounded evaluation of the specification, minimizing the chances of errors and enhancing overall quality.

Get started with this complete Selenium automation testing tutorial. Learn what Selenium is, its architecture, advantages and more for automated cross browser testing.

Implementing Continuous Integration, Automated Testing, and Code Quality Enhancement

Implementing a Continuous Integration (CI) system is crucial for the development team to ensure the smooth building, testing, and integration of the product with every code merge. When a developer’s code passes the automated tests in CI gives the developer reassurance that their code changes have not broken the product.

An automated test strategy should be created by the development team. The strategy should include unit testing, API testing, and integration testing. The automated tests should be executed in CI.

Linting and static analysis are important ways of improving code quality. Developers should use linters and static analysis locally when they are developing the code because they will find issues in the code as it is being written. Additionally, the CI system should incorporate linting processes, providing the team with an added layer of confidence in the codebase. Linting in both local development and the CI system helps ensure that coding standards are followed, potential bugs are caught early, and the overall code quality is improved.

WebDriver is a remote programming interface that can be used to control, or drive, a browser either locally or on a remote machine. Learn more in this complete Selenium WebDriver Tutorial.

Incorporating Shift-Left and Shift-Right Testing for Enhanced Quality and User Experience

As part of shift-left testing, the tester should execute tests to ensure that the new feature being developed delivers a quality experience for each user or stakeholder of the product. These tests should cover various scenarios and validate that the feature meets the requirements and expectations of different agents, such as end-users, administrators, or any other relevant parties. This further helps the team to proactively address any issues, improve the feature’s quality, and enhance the overall user experience.

The availability of various types of shift-left testing provides a development team with a valuable opportunity to incorporate quality into the product from the early stages. By leveraging different testing techniques, such as unit testing, integration testing, security testing, etc, the team can identify and address potential issues and vulnerabilities before they escalate.

While shift-left testing moves testing earlier in the development process, shift-right testing moves testing later in the development process. With shift-right testing, we test to the right on the timeline in production. Testing in production enables us to learn how the application is performing and enables you to find any production issues quickly. We can gain information that enables the team to know what errors are occurring in production by monitoring the application for errors. It is useful to run non-functional tests in production, such as performance tests, to find what performance issues customers are experiencing. The team will also want to perform security testing to check that the application is secure.

Shift-right testing helps to deliver quality digital experiences in several ways. It reduces the risk of releasing software because faults in the software are discovered quickly. This means that new features and fixes can be deployed to production more quickly. Test coverage can be expanded by automating tests that run regularly in production to cover user test cases. Different ways of deploying code can be used such as a/b testing in order to gain information from customers about how best the product can be designed.

As a part of shift-right testing, the tester should consider the needs of every agent involved in the product. needs of each of the agents for the product and design automated tests that can be run in production to test whether a quality experience is being delivered for that agent.

A complete tutorial on retesting that sheds light on its features, importance, pros and cons, and how to perform it.

Unlocking Code Confidence with Continuous Testing

The development team will gain confidence in their code when continuous testing is adopted as a testing strategy. This is because the code is tested from the earliest stage of development right through to production. This confidence can enable the development team to release their code more quickly. This can be done by using continuous delivery which means that the code and infrastructure are kept in “a deployable state, and that all code checked into trunk can be safely be deployed to production”[2]. It can also be done using continuous deployment, which means that in addition to continuous delivery, developers are “deploying good builds into production on a regular basis through self-service” [3]. Releasing code more quickly improves the quality of the customer’s experience because the customers can benefit from new features and fixes more quickly.

Some definitions of continuous testing define continuous testing as only covering automated testing. If this is the case then a number of testing activities that would give the development team confidence in their code are excluded. It would help the team if it includes code reviews, exploratory testing and considered testability.

Selenium WebdriverIO is Javascript based test automation framework built over nodeJs. Learn with this guide how to use webdriverIO to perform web automation testing.

Code reviews should be included in shift-left testing as they are a powerful way of sharing knowledge across the team and finding issues with the code.

The development team can do exploratory testing on feature branches, or by using feature flags. This will enable the development team to explore and test the new features as these are being developed.

The team ought to also consider how testable the code is, and endeavor to make it testable. If the code is hard to test it will be hard to deliver a quality experience for the customer. An example of how to make the code more testable would be to improve error logging.

There is a lot of discussion about continuous testing. The adjective ‘continuous’ is added to testing to show that testing is happening all the time. Continuous means that testing is happening without a break, replicating the behavior typically associated with the machines Testing, though, is a human activity that involves analyzing the test results, gaining insights and applying this knowledge to inform the next piece of work. For instance, continuous integration and continuous deployment have mechanical aspects and emphasize the seamless and uninterrupted nature of these specific processes. These processes will also include running automated tests.

However, testing should contain breaks when the testers and development team wait for test results or analyze them. Further, testing will also contain breaks when the development team and testers are learning something related to their development activities. Testing is better described as ‘continual’ rather than continuous because continual describes a process where there are plateaus and periodic breaks in testing to facilitate learning. It is better to adopt a strategy of continual testing, rather than continuous testing because continual testing will include breaks in testing when the team is studying the results of tests and learning.

The adjective continual is widely used to describe an activity that requires pauses and breaks. Last year, I was fortunate to have a conversation with Kevin Cahill, who is W. Edwards Deming’s grandson. While talking to him I used the phrase continuous learning. He told me that he had once said the words continuous learning while talking to his grandfather. His grandfather told him that he should say continual learning and that he should look up the definitions of continuous and continual in the dictionary. Since then I have noticed that books such as The DevOps Handbook contain sections about continual learning and experimentation[4]. DevOps owes a great deal to Deming [5] and continuous testing relates to DevOps. Testing is better described as continual rather than continuous because it is done by humans we need the plateaus and breaks to reflect and learn.

Continual testing should use a plan-do-study-act-cycle because it is a way of working that facilitates learning. This means that once a piece of testing is planned and implemented, the next step is to analyze the test results and incorporate the insights gained into the next testing phase. If the team works in this way, they will continually be learning from their testing, and their testing will improve.

Online Selenium Grid to run your browser automation testing scripts on cloud infrastructure containing 3000+ desktop and mobile browser environments.

Conclusion

The role of continuous testing is a valuable testing strategy that helps to deliver quality digital experiences because it enables quicker delivery of features to customers through continuous delivery and continuous deployment. This is because it finds issues with the software early in development, and gives confidence in the development process. Continual testing has the same benefits as continuous testing and it also gives the development team space to learn from their work.

iOS simulator by LambdaTest allows you to seamlessly test your websites and webapp on latest to legacy devices, OS versions and browsers. You can also test your iOS app online on 200+ device and iOS environmets. Sign up for free!

Managing for Quality with Dr Joseph Juran

Mikeharris52 — Wed, 31 May 2023 08:55:47 +0000

The Juran Trilogy: Empowering Management, Testers, and Development Teams for Quality Planning

We can plan for quality. Dr Joseph Juran showed many companies how to do this. The Juran Trilogy helps management plan for quality, and it can also be used by testers and development teams to do the same.

Joseph Juran was born in Romania and moved to the USA. He worked with Walter Shewhart at Bell Telephones and he later taught quality control at New York University. After World War Two he helped to rebuild the Japanese economy where his techniques became part of the management culture. He went on to work with many others including Steve Jobs [1]. The Emperor of Japan and the President of the USA gave Juran honours.

Check out this tutorial to learn what is Regression testing, its importance, types, and how to perform it.

Fitness for Purpose: Juran’s Definition of Quality and Its Significance

Juran wrote that one of the first tasks is to define quality[2]. People will disagree in their views of what quality is, thus there needs to be an agreement among those working on a project as to what quality is. He suggests using “fitness for purpose” as a definition of quality because it shows that quality is more than “conformance to requirements”. Juran also recommended understanding the distinctions between these two definitions of quality:

Quality consists of features that meet customer needs
Quality consists of freedom from deficiencies

He says that by adopting these two definitions a company can create a systematic approach to managing quality.

If the first definition of quality is used then new features and configuration options will be added to the product to enable the customer to use the product according to their preferences . This helps organisations to increase customer satisfaction, meet competition, provide sales income, and secure premium prices. Improving quality using the first definition will, however, increase the costs of developing the product because new features and options will be added to the product.

If the second definition is used the team will focus on reducing software bugs and enhancing product attributes like performance and reliability. This enables the company to reduce error rates, minimize rework, reduce customer dissatisfaction, reduce the number of errors customers encounter., As a result, it enables faster release of new features. Moreover, improving quality based on this definition reduces development costs since less time is spent on bug fixing and addressing customer complaints.

Inspect web elements to help developers and testers to debug UI flaws or make modifications in HTML or CSS files. Learn how to inspect on MacBook.

Applying Juran’s Methods: Managing for Quality in any Organization

Juran observed a disagreement between two managers discussing whether higher quality means higher costs. The two managers disagreed because one manager was referring to the first definition of quality and the other manager believed that by understanding the second definition, they could prevent such disagreements and engage in productive discussions about quality.

As testers, we often argue that the product needs to be of better quality, and when doing so we usually use the second definition because we want to reduce the number of software errors. However, we should be cautious when presenting our arguments because the manager we’re talking to may follow the first definition of quality and may not fully understand our perspective. . It is helpful if, as Juran, suggests we understand the distinctions between the two definitions to handle such discussions effectively.

“Managing for quality” is a group of methods defined by Joseph Juran that can be used by any organisation to improve its results. Juran viewed these methods as being universally applicable. To manage quality, a company should establish a vision, set goals and create plans to achieve high-quality outcomes. ‘Managing for quality uses these three management processes that are known as The Juran Trilogy:

Designing or planning for quality
Compliance, controlling or assuring quality
Improving or creating breakthroughs in quality

These three processes are designed to be similar to the processes used to manage finance. The financial processes are:

Financial planning includes preparing financial budgets and defining what is to be done in the year ahead
Financial control includes evaluating the financial performance of the organisation.
Financial improvement which can include cost-reduction programmes and new product development

These financial processes are universal as they provide the basis for financial management. There is an analogy that can be made between quality and financial management as both involve the concept of three processes for managing quality and finance is the same. This analogy can help leaders as they do not need to change their conceptual approach. They can use their financial training to manage quality.

The process of quality planning includes: establishing goals, identifying who the consumers are, determining the needs of the customers, developing features which respond to customers’ needs, developing processes to produce the products, establishing process controls and transferring the plans to the operating teams.

Quality control includes creating metrics and comparing actual performance to targets and goals.

Quality improvement includes proving the need with a business case, establishing a project infrastructure, identifying and establishing project teams, providing teams with resources such as training, and establishing controls to hold the gains.

This trilogy will improve quality and minimise issues such as bugs. By focusing on quality improvement, waste is reduced as a result. Once waste has been reduced through quality improvement, the metrics and controls implemented for quality control may require adjustments to align with the new situation. The team may choose to track metrics related to different aspects to ensure continuous improvement in quality.

The Juran Trilogy is designed for management, and it is also useful for agile development teams.

Run your Playwright browser testing test scripts instantly on 50+ browser and OS combinations using the LambdaTest cloud.

Aligning Testing with Customer Needs: Pre- and Post-Deployment Testing

The quality planning process raises points that are useful for the team to address. During planning meetings, teams outline their work and strategize for incorporating new features. It is crucial for the team to address the concerns identified in the quality planning process. By understanding the target audience and their specific needs, the team can deliver work that surpasses customer expectations and brings delight to them. Identifying customers is important. Juran wrote that “a customer is a cast of characters and each has a unique need that must be met”[2]. Customers can be classified as internal or external customers. Developers and testers can attend user testing sessions and talk to customer service teams to find out more about their customers. The knowledge gained from understanding who the customers are will help them to develop features that respond to customers’ needs. Customers’ needs not only include their wants and desires but also their emotions. The team needs to learn how to separate and prioritise them. Testers can leverage their understanding of the customers and their needs to design tests specifically targeting the validation of features against those needs. The tests that are planning should include both pre-deployment tests that run in production and post-deployment tests to ensure that the feature performs as expected and meets customer expectations. By aligning the testing process with customer needs, the team can ensure that the feature delivers the desired outcomes.

Leverage LambdaTest automation testing platform for faster, reliable and scalable experience on cloud.

Development teams also define process controls that enable them to develop quality software. These ways of working may include team agreements, a definition of done, coding standards, and checklists. Developers also need to be aware of how to “transfer the plans to the operating forces” and this should include supporting testing. The team should take into account the ‘testability’ of their feature when doing quality planning. Testability has been defined as ”test support inside the product providing control or visibility”[3]. Features that support testability include error logging, including the sources of errors, and diagnostics that alert the team to potential problems[3]. If the testability of a feature is low, it can have a detrimental effect on the quality of the feature making it hard to maintain, so it should be considered an integral part of quality planning.

Quality control is an essential aspect for teams to assess their performance and report on their work. They could report on Quality Costs, analyzing how they change as a result of their efforts . Further, it is crucial to include tests that run in production after deployment to ensure that the feature functions as expected. These tests validate that the feature is meeting the desired outcomes and aligning with customer expectations. By incorporating quality control measures and comprehensive testing, teams can continuously improve their work and deliver high-quality software.

The team will want to reduce waste and will therefore need a quality improvement process. It may want to use its team retrospectives to consider how to improve quality. If the improvement process reduces the number of bugs that need to be fixed and the number of complaints from customers, the team will have more time to develop new features.

Which are the most wanted automation testing tools in 2023 that have climbed the top of the ladder so far? Let’s take a look.

Conclusion

Juran’s quality planning methodology offers valuable insights for testers, enabling them to enhance the overall quality. The trilogy, comprising quality planning, control, and improvement, serves as a framework for engaging in meaningful discussions with our teams. By incorporating these concepts, we can elevate the quality of work delivered by our teams.

Online Selenium Grid to run your browser automation testing scripts on cloud infrastructure containing 3000+ desktop and mobile browser environments.

What will come after “agile”?

Mikeharris52 — Tue, 25 Apr 2023 06:18:42 +0000

I think that probably most development teams describe themselves as being “agile” and probably most development teams have standups, and meetings called retrospectives.There is also a lot of discussion about “agile”, much written about “agile”, and there are many presentations about “agile”. A question that is often asked is what comes after “agile”? Many testers work in “agile” teams so this question matters to us.

Before we can consider what comes after agile we need to consider what agile is. Agile is an iterative and incremental development methodology. Agile teams develop software in iterations and each iteration makes an increment toward the team’s goal. An agile team can decide, after an iteration or two, that the goal they are working towards should be changed and start to work on a new goal. Working iteratively makes the team agile as it can change direction quickly and easily. There are several agile methodologies and one of the most widely used methodologies is scrum.

Check out, iOS simulator by LambdaTest that allows you to seamlessly test your websites and webapp on latest to legacy devices, OS versions and browsers. Sign up for free!

What is agile?

When thinking about how to define what agile is we tend to be drawn to the Agile Manifesto which was created in 2001, but there were agile ways of working before the “Agile Manifesto”. The earliest Iterative and incremental development I found was at Bell Telephone labs in the 1930s. Walter Shewhart was an engineer at Bell Telephone Labs In his lectures in the 1930’s he introduced the concept of a straight-line, three-step scientific process of specification, production, and inspection[1]. He went on to revise this idea into a cycle[2]. The creation of this cycle has been described as part of the evolution of the scientific method[3] and it became known as the Shewhart Cycle. The cycle is shown in the diagram below:

The cycle is sometimes known as the Plan-Do-Study-Act-Cycle. A team using the Shewhart Cycle will Plan a change or test, The team will then Do, which means to carry out the change or test. Then the team will Study the results of the change or test to consider what they have learned before Acting on what they have learned. The team will then repeat the cycle and move onward.

W. Edwards Deming said that the cycle is a helpful procedure to follow for the improvement of anything in production stage. He also said that at the end of a cycle the team might tear up the work that they had done previously and start again with fresh ideas and that doing this was “a sign of advancement”.

Deming said the reason to study was to “try to learn how to improve tomorrow’s product” [4] Sometimes the Deming Cycle is referred to as the Plan Do Check Act. Deming did not like replacing the word study with the word check as studying is an important part of the cycle. He felt that the word check was inaccurate because it meant to “hold back”. [3]

The Shewhart Cycle was included by Deming in his lectures to senior management in Japan in 1950, and the cycle went into use in Japan as the Deming Cycle.

In this tutorial, learn what is Regression testing, its importance, types, and how to perform it.

What is Deming cycle?

The Deming Cycle has also been described as the Deming Wheel as it just rolls on without a beginning or an end. All four parts of the Deming Cycle can be drawn inside a circle as below. This means that the four parts of the cycle are related to one another and that there is no hierarchy, as can be seen in the diagram below:

Scrum is one of the most widely used agile methodologies, and Jeff Sutherland, one of the co-creators of scrum, has written that the Deming Cycle is how scrum development is done[5] He also says that retrospectives are the “check” part of the “Plan-Do-Check-Act cycle”, and says that it is important to get the team to change and improve their process by moving on to the act part of the cycle. It is useful for software testers that retrospectives were designed to be used in this way as we want to help the teams we work with to improve quality. Testers can use retrospectives to raise issues that help to improve quality. Sutherland says that he trains people to use Scrum by asking them to use the Deming Cycle to build paper airplanes and that by the third iteration they are making much better paper airplanes.

The Deming Cycle is the heart of agile as it is a cycle that enables teams to change and improve quickly. The cycle enables change to be made at each iteration of the cycle. However, is this how agile is understood? Do we sometimes work in teams that describe themselves as “agile” but do not use The Deming Cycle? Is “agile” sometimes described through its ceremonies rather than through using the Cycle? Are teams using “agile” for continual improvement as Deming and Sutherland recommended?

New ideas, such as Jobs to be Done, continue to be influenced by the Deming Cycle. Alan Klement describes the system of progress in Jobs to be Done as a cycle and says that his cycle is not an original idea as it comes from the Deming Cycle.[6]

Lean has also been influenced by the Deming Cycle. Lean is an American description of Japanese production systems and comes from a study by MIT[7]. The Toyota Production System was of special interest in the study. Deming worked in Japan after World War Two where he helped to rebuild the Japanese economy. Jeffrey K. Liker says “that the Deming cycle embodies the learning cycle in the Toyota Production System“. [8]

Teams, and testers, can develop their understanding of the cycle by reading the books in the references below, by using the resources of the Deming Institute, and by using the Deming Cycle.

Teams can learn to use the cycle by planning an initiative, then carrying out the planned work or test, then studying the result of their work, and then acting on what they learned before repeating the cycle.

Testers can help their teams to gain an understanding of the Deming Cycle by using plan-do-study-act for testing. When we test we plan the test, for example, we write a testing charter, then perform software testing, then we study the result of the test, and then act on the result as shown in the diagram below:

Teams should not be put off by the Deming Cycle creating a new structure for their team. The Deming Cycle creates a new structure for a team because a team using the Deming Cycle must plan first, then do the work or test that they have planned, then study the effect of the work or test, and then act on what the team has learned. Using the Deming Cycle can sound demanding as it places a new structure on the team. However, all teams have structures that place constraints on them. If a team always has its planning meeting on a certain day of the week this practice places a constraint on the team. How often a team releases its work also puts a constraint on the team. If a team releases once a month then that monthly release will force the team to work towards that release. If a team releases many times a day with continuous delivery then that will create a different constraint for the team. All teams want to improve how they work and improve their product, and they will find that using the Deming Cycle will help them to improve their processes and product.

Undoubtedly there will be something after “agile”. It will have a new name and I guess it will have to have new “ceremonies”. However, will the Deming Cycle be replaced by what replaces agile?

The Deming Cycle is a profound philosophical insight that has been used by engineering teams to improve quality for nearly one hundred years and is continuing to influence new ideas. It seems unlikely that the Deming Cycle will be replaced by what comes after agile because it was so innovative, so useful, and is still being used after so many years.

It would be great if the new way of working that comes after agile created a deeper understanding of the Deming Cycle, as this would help teams to learn, improve how they work, and improve the products they make.

Through this usability testing tutorial, you will learn how usability testing is a great way to discover unexpected bugs, find what is unnecessary or unused before going any further, and have unbiased opinions from an outsider.

Continuous delivery and continuous deployment offer testers opportunities for growth

Mikeharris52 — Fri, 21 Apr 2023 06:36:48 +0000

Development practices are constantly changing and as testers, we need to embrace change. One of the changes that we can experience is the move from monthly or quarterly releases to continuous delivery or continuous deployment. This move to continuous delivery or deployment offers testers the chance to learn new skills.

A project that makes monthly or quarterly releases has a familiar rhythm and the team builds towards the release date. The testers need to test all the cards and carry out manual regression testing. Every test in the manual scripts needs to be executed, and possibly a report needs to be made on the results of these tests. Once the release has been made it is possible that there will be bugs that were in the release that need to be fixed. The testers will also need to start running the same manual regression tests on the next release and report on them again. Testing for monthly or quarterly releases is a repetitive process. This process has been compared to the Greek myth of Sisyphus who had to roll a stone to the top of a hill, and then when the stone rolled to the bottom of the hill he had to roll it to the top of the hill again.

Get started with this complete Selenium automation testing tutorial. Learn what Selenium is, its architecture, advantages and more for automated cross browser testing.

Continuous delivery can be defined as “when all developers are working in small batches on trunk, ….and when trunk is kept in a releasable state, and when we can release at the push of a button” [1]. A team that I worked with moved from making monthly releases to continuous delivery. The team kept the main branch in a state in which it could be deployed if needed and the team made weekly releases. Continuous deployment can be defined as when, in addition to the practices that support continuous delivery “we are deploying good builds into production on a regular basis through self-service (being deployed by Dev or by Ops) [1]. A team practicing continuous deployment deploys to production each time code is merged to the main branch.

Teams that practice continuous delivery or continuous deployment use small batch sizes. That means that the “batch” of code that is deployed is small. “The theoretical lower limit for batch size is single piece flow, where each unit is performed one at a time” [1], this is what happens in continuous deployment where each merge to the main branch is deployed to production.

Teams that practice continuous delivery and continuous deployment try to create a flow of work at a sustainable pace and so should “enable and inject learning into daily work”[1]. Teams that make monthly releases build towards the release and so can not create this constant flow of work at a sustainable pace.

When a team moves from monthly releases to continuous delivery or continuous deployment a change that occurs is that there is no release candidate. Testing is not done on a release candidate instead, it is done on feature branches that have been taken from the main branch and when they are merged back into the main branch they must be ready for release to production. The main branch is kept in a state where it can be released to production. For the tester, this means that the testing on a feature branch has a different pattern than that on a release candidate.

A comprehensive end-to-end Testing tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

When testing on a feature branch, you need to be confident that the new feature or fix in the feature branches does what it is supposed to do and that it has not caused any regression. When testing a monthly release you can have time to execute manual regression tests, but if the main branch is to be kept in a state that it can be deployed to production this is not possible. Regression testing needs to be automated if you are using continuous delivery or continuous deployment.

Regression testing on monthly releases often includes running a large number of manual tests; however if your team is using continuous delivery or continuous deployment regression testing is usually automated via continuous integration. Continuous integration (CI) “means that every single time somebody commits any change”[2] to the code the change is integrated into the codebase. This entails running automated tests prior and after the code is merged into the main branch. This provides an opportunity for the tester to learn how to understand CI. The tester needs to understand CI, including what tests run as part of CI. There will always be gaps in the tests that run on CI. If the tester knows what the gaps in CI are they can work out how to automate tests to fill them and execute manual tests to cover the gaps when this is required. Making mind maps of the tests that are automated can help identify gaps in the automated tests.

Testers can also get involved in automating regression tests themselves and in this way testers can help to prevent bugs rather than find them. There are great free resources such as Test Automation University, LambdaTest Certifications and Exercism which can help testers gain the skills they require to automate tests. There are also lots of resources to learn how to use javascript to aid testing.

A comprehensive e2e Testing tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

That regression testing is automated creates time for the tester that they can spend on exploratory testing. Exploratory testing is a powerful way to uncover issues, and so will help the projects that the tester is working on. Having extra time to do exploratory testing will also help the tester develop their exploratory testing skills.

Projects that use continuous delivery and continuous deployment also tend to have a microservices architecture. Microservices are services which have independent testing and deployment, and each service is simple[1]. The tester has the opportunity to learn about the microservices, and ways to do this include talking to the developers, studying any architecture diagrams that exist, reading the readme files for each service in GitHub and attending the developers’ meetings. [4]

Testers can build their relationships with developers by helping them test their code. The tester can share their knowledge of testing techniques, such as boundary value analysis, with developers as this will help them test and produce better quality software.

Release processes for monthly releases can involve a certain amount of pain for testers. Sometimes we are asked to take the responsibility of making the release decision even though the tester is often a junior member of the team, other times testers have to take part in large committee meetings of stakeholders that decide if the software can be released. Release processes for continuous deployment and continuous delivery should be automated this means that making releases does not put pressure on the tester. The tester’s input to the release in continuous delivery and continuous deployment is their testing, this means that we can focus on our testing and learn new testing skills.

New Selenium IDE supports cross browser testing and parallel tests for automation along with record and replay function. Here’s why you shouldn’t miss out on it.

Development teams are not autonomous, they are open systems whose work affects other teams and is affected by other teams. This is systems thinking and systems thinking contributed to continuous delivery and continuous deployment. Testers can learn to use systems thinking to enhance their testing and support their team. This can help the tester think beyond their role to understand what other systems are affected by their team’s work and what systems affect their team’s work.

One of the lessons of systems thinking is that everyone shares responsibility, so no one person should be blamed when something goes wrong. This view should also be at the heart of every agile and lean development team that implements continuous delivery or continuous deployment. This is something that testers should learn from and take to heart. When there is a failure we need to learn from it and not blame someone.

Teams that make monthly releases can find that after each release there is a flurry of activity fixing regression bugs that were deployed in the release. This does not happen with teams that practice continuous delivery or continuous deployment. Releases will be deployed multiple times a day using continuous deployment, and software will be deployed regularly with continuous delivery. These regular releases give the development team an opportunity to recover from bugs and incidents quickly as fixes can be deployed quickly. Once a fix has been deployed the tester can offer to take the lead in doing root cause analysis to find the root cause of the bug or incident. The tester can learn to use the Five Whys and Ishikawa Diagrams to do root cause analysis.

Testers can also support the work of their teams by producing metrics that help the team measure their improvement of quality. DORA metrics[3] were identified by the Accelerate State of DevOps survey report by DORA. These metrics are designed to help teams that practice continuous delivery and continuous deployment find areas for improvement and know how they are doing. These are different to the metrics for monthly releases as they are not about how many bugs have been put into production but are about how quickly a team recovers from an error.

Continuous delivery and continuous deployment offer testers opportunities to grow and learn new skills so testers should embrace the opportunities when their teams move to continuous delivery and continuous deployment.

Black Box testing? Don’t worry; we will be covering what is Black box testing, merits, demerits, types & techniques.

Grow Your Skills with Low-Code Automation Tools

Mikeharris52 — Thu, 13 Apr 2023 06:25:23 +0000

Some of the tools we can use to automate tests are low-code tools. One of the tools I use to automate browser testing is the low-code tool Ghost Inspector. You can develop reliable automated tests and learn a great deal about test automation by using Ghost Inspector.

Ghost Inspector can be used to automate tests without writing any code. You can build a test out of steps that do not require coding. You can identify elements in the web page that you are testing using an identifier such as an XPath or a CSS selector, and then choose a test step that interacts with the element in the way that you require, for example by clicking or by assigning a value. This provides a simple way to create automated tests. Creating tests without writing code can be valuable because it enables a tester who can not write code to start creating tests. However, if a large number of tests are created in this way they can become can be time-consuming to maintain and hard to read. They can take a lot of time to maintain because if an element on a page that you are testing changes you will have to find every use of that element and update it. Tests created in this way can also be hard to read as when you read the steps see a step that clicks on a div whose class starts with a certain string, and then a step that waits for an element that is a span whose class contains a certain string, and you are left trying to remember what do these steps do.

There are a number of things that you can do to make the most of low-code tools and make your tests easier to maintain and read.

Also check, Black Box testing its merits, demerits, types & techniques.

Maintaining your tests

One way to make your tests easier to read and maintain is to encapsulate groups of steps in a module that you can then import the module into tests. Encapsulating steps in a module helps to make tests easier to maintain because if a page element changes you only need to update the steps in the module instead of updating steps in many tests. This makes maintenance easier and quicker. Creating tests is also quicker if you have created modules because instead of creating new steps for your new test you can use these modules to create new tests. An example of this would be importing a module “login”, that contains the steps to log in, rather than creating all the steps to log in each time you create a test. The login module can be used whenever a test needs to log in.

The naming of these modules is important for two reasons. Firstly you need a name that you can find easily in your library of modules and secondly, the name needs to be descriptive so that when you read the name of the module in a test it is clear what the module does. Having modules that are named well also makes your tests much easier to read.

Run Appium mobile testing of native and web apps. Improve your app quality with instant access to real devices on LambdaTest. Register now for free

Dynamic behavior with variables

Ghost Inspector is a low-code tool that supports the use of variables. When you start to create tests you can create tests without using variables, but using variables also makes your tests easier to create, maintain and read. A variable holds a value that can be updated. The value it holds can be a URL, an email, a password, a CSS selector and something else that a test uses. If the value represented by the variable changes you only need to change the value held in the variable, instead of everywhere the value is used. Giving your variables names that can be clearly understood will help the readability of your tests.

Variables work in a given scope. The scope could be a test, a test suite or be ‘global ‘ so that the variable can be used in all the tests and test suites. Variables that you create within a test only work within that test. Variables that you create in a test suite only work within tests that are part of that test suite, and variables that you create under your organization work globally on all tests that you create.

Modules can use the variables that you create. An example of a module using variables would be to assign values to variables for email and password and then have the login module use those variables to log in. This would enable the login module to be used to log in as different users.

A comprehensive UI testing tutorial that covers what UI testing is, its importance, benefits, and how to perform it with real-time examples.

Accessing the power of the browser with JavaScript

Ghost Inspector also enables the user to use JavaScript to create steps in tests. You can create steps that execute JavaScript, in which JavaScript returns true, or extract a variable from JavaScript. You don’t need to use JavaScript to create Ghost Inspector tests but using JavaScript in test steps enables you to extend Ghost Inspector functionality and provides a way to learn JavaScript. You can learn at your own pace. There are lots of resources to learn JavaScript. You can start by storing variables in a JavaScript object in an Extract From JavaScript Object step like this:

const emailAndPassword = { email: "user@email.com", password: "password" };
return emailAndPassword

You could then use the variable in a module to log in to the application that you are testing.

You can also create steps that extract values from page elements or create a variable from one of the values held in a JavaScript Object. Ghost Inspector includes a step that checks for the presence of one element on a page, and if you want to check for more than one element with the same CSS selector you can write a step to do that uses document.querySelectorAll(selector).length to get the number of elements and then use an ‘if loop’ to check that the number of elements is correct. If the correct number of elements is found the step will return true if not the step returns false and the test fails. Creating steps with JavaScript can help you develop your skills with JavaScript at your own pace.

Your tests will be more consistent and easier to maintain if you create standards for your tests. An example of a standard you could create would be a naming standard for variables. You could create a standard for naming variables that states that variables should have a prefix to show if their scope is local to the test, to the test suite or that they are global variables that can be used throughout your tests. A standard for naming variables could look like this:

Names of standards should be camel case
Names of organization-level variables should start with org
Names of test suite-level variables should start with ts

A standard like this will help you maintain and develop tests because when you read the variable’s name, you will know its scope.The standards can be extended to include other points that you find useful such as what type of element selector is preferred, and how libraries of modules should be organized. Using standards when creating tests will also help collaboration because everyone who is creating the tests should use the standards when creating tests.

In this Ad hoc testing tutorial, let’s deep dive into what Ad hoc testing is, its advantages, disadvantages, types, characteristics, and their best practices.

The Five S’s

It is also useful to use the Five S’s to create a disciplined structure to help you create and maintain automated low-code tests. The Five S’s are recommended by Mary and Tom Poppendiek as a way to create the discipline necessary to develop quality software. They wrote that “the five S’s are a classic lean tool to organize a workspace” [1].

The Five S’s can help keep Ghost Inspector automated tests in a state where they are easy to maintain, have no flaky tests and are easy to read.

The Five S’s are described in Implementing Lean Software Development [1] by translating the original Japanese words into English and by giving examples of using each of the S’s in the kitchen, in the workplace and for a development project. I have used Mary and Tom Poppendiek’s idea and created a table showing the English translation of the Japanese words and examples of using the Five S’s in the kitchen, workplace and Ghost Inspector test automation.

JAPANESE	ENGLISH	KITCHEN	WORKSPACE	GHOST INSPECTOR TEST AUTOMATION
Seiri	Sort	Sort through kitchen tools and throw away any unused tools.	Sort through the servers, and find old files that will never be used. Delete or back them up.	Remove unused modules
Seiton	Systemise	Find a place for everything and make it easy to find.	Craft desktop layouts and file structures so that things are easy to find	Organise tests, test suites and modules so that everything is easy to find.
Seiso	Shine	Clean the kitchen.	Clean whiteboards and desktops.	Bring old tests in line with the standards
and improve performance.
Seiketsu	Standardise	Fill and run the dishwasher every night	Put automation and standards in place.	Reduce complexity, improve ease of maintenance and create standards.

In many ways, Sustain is the most important of the Five S’s because it is by sustaining the practices you create using the Five S’s that your automated tests will become more reliable, easier to maintain and easier to read.

In this Data driven testing tutorial, let us deep dive into what data driven testing is, its pros & cons, its types, data driven testing in an agile environment, benefits, and their best practices.

Wrapping up

In making the most of low code test automation you will create reliable automated tests and learn a range of software development skills such as using the scope of variables, coding in JavaScript, encapsulation to create modules, writing standards, and how to use the Five S’s. These skills will help you create stable test automation with Ghost Inspector and will help you develop your test automation skills.

Run your Jest testing automation in massive parallel across multiple browser and OS combinations with LambdaTest, Read more.

How should we test in the Red Beads Experiment?

Mikeharris52 — Tue, 11 Apr 2023 06:08:27 +0000

The Red Beads Experiment was a part of Dr. W. Edwards Deming’s four-day seminars for senior management in which he asked members of the audience to play roles in a factory that made white beads.

The experiment looks very simple but is constructed to highlight common problems in the industry. It is also useful for testers to look at the experiment to see what contribution the testers make in the experiment and whether they could have a more positive effect.

W. Edwards Deming is best known for his work in rebuilding the Japanese economy after World War Two. His ideas influenced Toyota, and are part of lean and agile. In later life, he worked with US companies such as Ford and Proctor and Gamble. He is also referred to as “the grandfather of quality”.

The experiment starts by asking six members of the audience to be Willing Workers, two members of the audience to be Inspectors, one member of the audience to be a Chief Inspector, and one member of the audience to be a Secretary. Dr Deming acted as the supervisor. The volunteers are all to work for the White Beads Company, which makes white beads.

The Inspectors can be seen as being testers, and the Chief Inspector can be seen as being the Test Lead or Test Manager.

Upload your app for testing within seconds using the LambdaTest cloud and perform mobile app testing right away. Find bugs early on, improve performance, quality, user experience and make the most of mobile app testing on LambdaTest.

The supervisor explains the roles to the volunteers. The willing workers are given precise instructions as to how to put a paddle, that contains 50 holes for beads, into a vessel that contains white and red beads. They are also told at which angle to bring the paddle out of the vessel. When the paddle comes out of the vessel it contains both red and white beads. Each action with the paddle represents a day’s work for a worker. The workers take the paddle to the inspectors who count how many red beads are in the paddle. The red beads are defects as the willing worker’s role is to create white beads. The chief inspector will compare the count of the two Inspectors and announce the correct count. The secretary will then record the number of red beads against the name of the willing worker.

On Day One the supervisor announces that there is a merit system. After each willing worker has used the paddle to extract beds from the vessel, the supervisor comments on whether the willing worker deserves a merit increase or will go on probation. The supervisor is disappointed with the results of the first day as there are too many red beads and announces that management has declared a goal of no more than three red beads in a day’s work.

The supervisor is also disappointed with the results of Day Two. He tells the willing workers that their jobs are dependent on their performance and that costs are greater than revenue.

Day Three starts with announcements that it is “Zero Defects Day” and posters are put up saying “Take pride in your work”. The supervisor comments on the number of red beads in the day’s work done by each willing worker telling them whether they get a merit or are on probation and reminds the workers that management is watching costs.

At the beginning of Day Four, the supervisor informs the willing workers that “quality is up to you” and says that management has a plan. The plan is to keep the plant open by only employing the best workers. At the end of the day, the three willing workers whose paddles contained the most red beads are laid off and the other three willing workers are asked to work double shifts to keep the plant open.

Run your Selenium Testing scripts on the LambdaTest cloud grid. Test on 3000+ desktop & mobile environments. Try it for free!

On Day Five the three remaining workers work double shifts. The supervisor is disappointed as the results have not improved and announces that management has decided to close the plant.

In his book “The New Economics” Dr. Deming gives fourteen lessons from the Red Beads Experiment. These lessons are mainly for management. He says that the variation in the number of red beads in each day’s work came entirely from the system and that there was no evidence that any one worker was better than any other.

Dr. Deming wrote that the willing workers were victims of the process as they had to follow the supervisor’s rules and had no chance to improve the process. The inspectors are victims too as they also lose their jobs.

The inspectors and chief inspectors are the test team in the plant. How do they contribute to the work of the plant? They independently report the number of red beads in each worker’s work to the chief inspector. There is a system of inspection as the two inspectors are independent of each other but do they add value to the production process?

It is useful to consider what lessons there are for testers in The Red Beads Experiment. The inspection/testing function in the plant is carried out by the inspectors and chief inspector. The inspectors record the number of red beads, defects, in the work done by the willing workers and the chief inspector reports the results.

Dr. Deming says, in The New Economics, that we may perceive Red Beads in our own company and in our own work. The only role of an inspector is to find red beads, that is to find defects. They only look for defects once the work has been done, when the defects already exist. This is not unlike testers who work in “waterfall” teams who only test work that is “finished”. The work of the inspectors does not improve the quality of the plant’s output. The chief inspector’s only role is to report the number of red beads found, that is to report the number of defects. This also does not improve the quality of the plant’s output.

Management should support the inspectors working to break down the barriers that exist between the inspectors and the willing workers and between The White Beads Company and its suppliers. Breaking down these barriers will enable collaboration which can improve the quality of incoming material, of production methods and so improve the output of the plant.

The inspectors would add more value to the plant if they worked to prevent defects rather than working to find defects. The quality of the product is poor by the time the inspectors inspect it, therefore the inspection is too late to improve quality. They should stop inspecting the output of the willing workers and instead use their skills in testing, their knowledge of quality, and production to help to build quality into the plant’s processes. There are several ways that they can do this.

Test your native, hybrid, and web apps across all legacy and latest mobile operating systems on the most powerful Android emulator online.

The inspectors and chief inspector are a different team from the willing workers. The willing workers endeavor to produce white beads, and the inspectors count the number of defects. The two teams have different goals: one to produce white beads and the other to count red beads. However, neither of the teams are autonomous, so neither of the teams is a closed system. If management viewed the two teams as part of a system that produces white beads, the two teams could work together to improve quality. An example of how the inspectors could work together with the workers to improve quality would be that the inspectors could use their knowledge of inspection and production to experiment with new methods of production to see if they could find a more efficient method of producing white beads. They can make improvements using Deming’s Plan-do-study-act cycle by planning the trial of a new production method, doing the trial, studying the result of the trial, and acting on what they have learned from the study.

Working with suppliers to improve quality would benefit the White Beads Company. The company would benefit from viewing itself and its suppliers as a system that produces white beads. One of the fourteen lessons that Dr. Deming draws from the Red Beads Experiment is that management could have worked with the suppliers of beads to improve the quality of incoming material by reducing the number of red beads in the supplied material. The inspectors and chief inspector have experience of the issues with quality in the plant and can use this to work with the suppliers to create operational definitions at each stage of production to reduce the number of red beads in the incoming material. In “Out of the Crisis” operational definitions are defined as putting “communicable meaning into a concept.

Adjectives like good, reliable… have no meaning until they are expressed in operation terms of sampling, test and criterion”. If the inspectors and chief inspector help the supplier create operational definitions at each stage of production of the raw material they can help the supplier reduce the number of red beads in the material, which will enable the willing workers to produce more white beads. The inspectors testing skills will help them define operational definitions as they will understand how to create criteria that are easy to test. By working with suppliers to improve the quality of raw materials the inspectors are helping to ‘build quality in’ rather than trying to inspect quality in after the work has been completed.

The chief inspector has a senior position and can use their position to investigate how the team of inspectors can improve quality. Dr. Deming’s System of Profound Knowledge provides a system for management that can be used to improve quality. There are four parts of the system.

In this Ad hoc testing tutorial, let’s deep dive into what Ad hoc testing is, its advantages, disadvantages, types, characteristics, and their best practices:https://www.lambdatest.com/learning-hub/ad-hoc-testing

The first part is the appreciation of a system. The chief inspector should look at the White Beads Company using systems thinking in order to see the whole system that produces white beads and the interaction of components within the system.

The second part is a knowledge of variation. The volume and quality of production will vary. The chief inspector should use their knowledge of statistics to understand the causes of this variation.

The third part is psychology. People are not cogs in a machine and the chief inspector should understand people and how people interact, as people are fundamental to a company’s success.

This article explains the emulator vs simulator vs real device differences, the learning of which can help you select the right mobile testing solution for your business.

The fourth part is the theory of knowledge. A theory is a prediction of the future based on our understanding of the past. The chief inspector should develop theories on how to improve the quality of the output of the White Beads Company and then use the plan-do-study-act cycle to test the theories.

The chief inspector should be supported by management in using Dr Deming’s System of Profound Knowledge to continually improve the company’s processes.

In the Red Beads Experiment, the inspection process in the White Beads Company is only designed to find red beads and this is very much like testers who only test “finished “ code. The inspectors can help the White Bead Company to survive and grow if management supports them in viewing the whole system of producing white beads and in using their skills to ‘build quality in’ at each stage of the process. The chief inspector can also continually improve the company’s processes if they are supported by management to use Dr. Deming’s System of Profound Knowledge.

Automate Cypress cloud tests and perform browser automation testing with LambdaTest. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free!