Forem: DavidTz40

Common Challenges in Continuous Testing and How to Overcome Them

DavidTz40 — Thu, 30 Mar 2023 08:51:57 +0000

Today’s software industry is much more complicated than it was in the past. It is evident in almost every aspect of customer demands, fierce corporate rivalry, and, of course, global changes that directly affect this market. Because of this, businesses today need to have a competitive edge over rivals, which means they must be able to release products quickly and of exceptional quality.

Therefore, it won’t come as a huge surprise if I say that one of the most crucial objectives of every company — from startups to enterprises — will be to secure their ability to offer frequent releases to their customers. And is it easy? No, it might take several years (especially for large corporations) due to a variety of factors, including culture, technological constraints, and, of course, the testing process, which is most likely to take up the majority of the time in each project.

So, how companies can handle it? Here is where Continuous Testing comes to help. Continuous Testing, according to Wikipedia, is “the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.”

Simply put, the main objective of continuous testing is to build quality into the product from the very beginning of the software development life cycle. Using this method, we push our teams to make both culture, mindset, and technical adjustments to make sure they can test at all stages of development (Unit testing, integration testing, Security Testing, system testing, and acceptance testing) and accelerate the overall development process to achieve better results for their customers.

Continuous testing, as I mentioned above, is essential for businesses to stay one step ahead of their competition, but it also comes with inherent complexities and challenges that are worth mentioning before you dive right in.

A comprehensive User Acceptance Testing (UAT) tutorial that covers what User Acceptance Testing is, its importance, benefits, and how to perform it with real-time examples.

Challenge 1: Implement a new mindset in an existing methodology

As I mentioned earlier, before continuous testing became incorporated into the DevOps terminologies, development teams had to adopt a completely different mindset. I observed how some organizations suffered serious delays or failed to make the transition as a result of poor team communication. People dislike change, especially drastic changes like that brought on by the adoption of continuous testing.

Make it possible for your teams to comprehend the “Why” and the advantages of the change when communicating it to them. To improve the product for their customers, they will, for instance, learn new technologies and tools. Additionally, it’s crucial to give your teams time to adapt to the changes; avoid pressuring them before you’re sure they are willing to take the journey with you.

Challenge 2: Are we automating enough? Is no longer the question

Before continuous testing becoming the new norm in cloud-based developments (SaaS products), organizations’ primary objectives were to cut back on testing efforts, particularly manual testing. Therefore, the primary question that persisted throughout was, “Are we automating enough?” In the past, this was an effective strategy, but in the era of continuous testing, it needs to be reevaluated. Massive unstructured test suites that are the result of the “Automating Everything” effort become unmanageable in a matter of months and take far longer to maintain than the testing itself. Furthermore, organizations and their development teams cannot run them continuously as part of a structured process per fix per build and thus face the entire motivation of automating.

What has changed in the modern era, then? We must act quickly and concentrate on the tests that will yield the highest return on investment. This is a result of realizing that automating everything is just not practical. For instance, I used to have a simple checklist for my teams to use before deciding what to automate and what not to do. (After a few projects it was no longer necessary as they embrace it as an ongoing process).

Let’s check a few items from this checklist:

What is the value of the test from a business perspective?
What is the risk of automating/not automating the test?
Is it a repetitive test that should run per build/project?
Will it save Engineering time?

In this tutorial on Agile testing, let’s deep dive into the history of Agile testing, its advantages, disadvantages, methods, quadrants, and best practices.

Challenge 3: Continuous testing is not just for testing

The idea that continuous testing is solely focused on testing is one of the most common misconceptions. This is not the case. Even though testing is at its core, there are several other areas involved in the process that we must concentrate on to make the most of continuous testing.

For example:

Creating health dashboards related to each test suite.
Executing test suites on multiple versions, platforms, and frameworks.
The ability to re-run tests in case of failure (While keeping the failures logs, Dumps, and any other information relevant for debugging).
Generating auto reports to relevant stakeholders using.

Challenge 4: False positives and False negatives

Be aware of false negatives and false positives. They are more frequent than you would ever expect! When you run a test automation script, it may report an execution failure even if the system is functioning properly, or it may report the test execution as successful even though the system experienced failures. While both are harmful, false positives can be more destructive since you assume everything is OK until there is an issue.

Consider your rollbacks wisely. Even if you follow all of the finest continuous testing and CI/CD standards, there is no assurance that the build will not crash in production. Be always prepared for the worst-case situation. Before you deploy changes to production, make sure your data is backed up. If something goes wrong, you can immediately roll back to the previous production version and do another round of testing to validate the application works properly again.

Beware that if you roll back from the production environment, you can’t simply confirm your pre-production state and commit the customizations immediately. You must examine the whole pipeline and all test environments to ensure that there are no loose ends since you do not want to delay the very same release cycle multiple times.

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.

Challenge 5: Inadequate utilization of resources

Organizations must make investments in resources, infrastructures, frameworks, and manual labor if they want a Continuous testing process that is effective and scalable. If it is not managed and tracked over time, this interment could be very expensive. For instance, a daily CD process utilizes a variety of servers (both physical and virtual), each of which consumes resources that, when added up over time, can be quite expensive. (This is relevant even more if you use cloud providers such as Azure, AWS, and more).

Engineering teams will be expected to ensure that they are not wasting these valuable resources on pointless job executions that fail due to inadequate coding and testing. This can be a major issue for startups or low-budget projects that cannot afford to waste money on unutilized resources. As a result, it is critical to keep a constant eye on the CD execution pipeline to identify and address areas where resources are being wasted.

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.

Challenge 6: Security Vulnerabilities

Continuous testing has plenty of advantages for delivering products with great quality. Unneutrally, it is also a great potential for hackers to target your CD pipelines because there are always some security flaws that are not addressed well enough by the business. If it was not clear by now, the CD pipeline contains a massive amount of sensitive information that is related directly to the product which makes it even more attractive for attackers to try and get this data.

Today, we have some excellent ways to decrease this threat by utilizing various tactics that could be applied as a full line of defense:

Hiring external contractors to handle all aspects of the security testing process. For businesses that don’t have the internal expertise to handle this job, this solution is incredible.
Incorporate monitoring systems that track the entire pipeline to ensure that the basic security level is maintained at all times.
As a rule, we can reduce the amount of sensitive and restricted information that is transferred through code.
Secure code repositories by using different methods such as Two-factor authentication (to authenticate the author) or Secure local backup (in case of a complete hijack of the main repository.)

Challenge 7: The role and responsibilities of testers

The majority of problems we have encountered so far have been primarily technical or procedural, but what about software testers? What makes them a part of this world? What are their new responsibilities and roles? So, unless you plan to eliminate testers from your development pipeline, I advise you to take the appropriate steps to neutralize this potential time bomb. Let me explain, software testers are the ones that usually (less or more depending on the SDLC methodology used) make the tests or at least the test designs, so now in a continuous testing approach, we push more and more test activities to developers who test in stages (unit, integration, and so on) that testers simple cannot.

I frequently observed how testers struggled to grasp their new roles and what was required of them, which resulted in extreme frustration and fear for their jobs. To get around it, this change needs to be clarified in a way that lets testers know how they fit into the new SDLC and what kind of RNR is expected of them. For instance:

Track, Monitor, and debug (based on technical skills) automation results and communicate potential problems.
Perform Ad-Hoc tests using Risk-based testing and Exploratory sessions.
Managing defects during the release cycle.
Design test scenarios for major business flows.
And more.

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.

Conclusion

Since I have been working in this field for almost 20 years, I have witnessed at least one or two major occurrences that have advanced our sector. Continuous testing, in my opinion, is one of them today because it interacts with other important changes like the rising use of cloud services at all levels (IaaS, PaaS, and SaaS), as well as the fast-paced society we now live in. Therefore, continuous testing ought to be adopted in some fashion, whether through technical means or by using particular elements of it.

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

How Continuous Testing Can Improve DevOps Efficiency

DavidTz40 — Fri, 17 Mar 2023 07:40:38 +0000

What is DevOps?

The best way for businesses to accelerate the pace, efficiency, and quality of their development pipeline is through DevOps. DevOps has an outstanding track record because it significantly changes how engineering teams work together to develop, test, and produce software. DevOps is broad and inclusive, encompassing not only the use of new frameworks and development practices but also a complete philosophy and way of thinking that motivates various implementations throughout our industry.

From Wikipedia:

“DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle. DevOps is complementary to agile software development; several DevOps aspects came from the agile way of working.”

The formal definition as you can see focuses on the technical aspects and methodology, but in my opinion, DevOps brings more to the table. It is a completely new culture of innovation, ownership, and continuous learning activities with the main goal of improving the software development life cycle right from definition, and development to release.

It is not a surprise that DevOps has become the standard these days. The benefits it provides are for all to see:

Acceleration of the development process.
Quality is built-in starting from the earliest stages of development.
Improves collaboration and ownership between engineering and operations.
Reduces development and business roadblocks.
Accelerates engineering productivity.
Optimizes the software testing process so that it can give an effective result in less time.

With that being said, keep in mind that DevOps is like Agile. It is NOT a silver bullet, but it can (and should) have a great impact on your organization and customer experience.

The main benefits of Continuous testing

Faster time-to-market: DevOps practices enable organizations to deliver software updates and new features faster and more frequently, reducing the time-to-market.
Increased collaboration and communication: DevOps fosters a culture of collaboration and communication between development and operations teams, resulting in more efficient and effective software development and deployment.
Improved quality: By integrating automated testing and continuous integration and delivery (CI/CD) pipelines, DevOps helps ensure that software is thoroughly tested and of high quality before deployment.
Greater agility and flexibility: DevOps practices enable organizations to respond quickly to changing market conditions and customer needs, and to adapt their software development and deployment processes accordingly.
Increased efficiency and cost savings: DevOps reduces waste and inefficiencies in the software development process, resulting in cost savings for organizations.
Better reliability and stability: By implementing practices such as monitoring and logging, DevOps helps organizations identify and resolve issues quickly, resulting in more reliable and stable software.

Overall, DevOps is an approach that enables organizations to deliver high-quality software faster and more efficiently, while also fostering a culture of collaboration and continuous improvement.

It’s crucial to debug websites for Safari before pushing them live. In this article, we look at how to debug websites using Safari Developer tools.

Key Challenges

Continuous testing is essential for businesses to stay one step ahead of their competition, but it also comes with inherent complexities and challenges that are worth mentioning before you dive right in.

*Automating everything *— Prior to continuous testing becoming the new norm in cloud-based developments (SaaS products), organizations’ primary objectives were to cut back on testing efforts, particularly manual testing. Therefore, the primary question that persisted throughout was, “Are we automating enough?” In the past, this was an effective strategy, but in the era of continuous testing, it needs to be reevaluated. Massive unstructured test suites that are the result of the “Automating Everything” effort become unmanageable in a matter of months and take far longer to maintain than the testing itself. Furthermore, organizations and their development teams cannot run them continuously as part of a structured process per fix per build which embraces the main motivation of automating main components in the SDLC. What has changed in the modern era, then? We must act quickly and concentrate on the tests that will yield the highest return on investment. This is a result of realizing that automating everything is just not practical.
*Inadequate utilization of resources *— Organizations must make investments in resources, infrastructures, frameworks, and manual labor if they want a Continuous testing process that is effective and scalable. If it is not managed and tracked over time, this could be very expensive. For instance, a daily CD process utilizes a variety of servers (both physical and virtual), each of which consumes resources that, when added up over time, can be quite expensive. (This is relevant even more if you use cloud provider such as Azure, AWS and more).

*Continuous testing is not just for testing *— The idea that continuous testing is solely focused on testing is one of the most common misconceptions. This is definitely not the case. Even though testing is at its core, there are a number of other areas involved in the process that we must concentrate on in order to make the most of continuous testing.

Creating health dashboards related to each test suite.
Executing test suites on multiple versions, platforms, and frameworks.
The ability to re-run tests in case of failure (While keeping the failures logs, dumps and any other information relevant for debugging).
Generating auto reports to relevant stakeholders.

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.

Thoughts on DevOps and Testing

DevOps involves many different parts like tools, infrastructure, coding standards, monitoring, and many more, that depend on one another to function smoothly. But, let’s now concentrate on the element that is most intriguing to us: testing.

Although DevOps has significant benefits, you cannot get them without the right implementation. One example that I see all the time is the neglect of quality to increase speed. Therefore, you must find the correct balance between speed and quality, if you prioritize one thing over the other you will find very soon that the field and customer experience will suffer substantially and may have a great deal of impact on the business reputation. So, before focusing on speed, remember that quality cannot be neglected. Bear in mind that one of the significant core pillars of DevOps is to optimize the test process and activities so it can become more effective.

So, what can we do to increase the scale of quality?

Do your best to incorporate testers into the DevOps ecosystem. Testing should not exist outside but it should be an integral part of it.
Shift your testers into DevOps teams to increase the focus on quality and not just on speed and process.
Let them focus on exploratory test sessions before integrating a new feature into the core repository.
Let your testers focus on quality risks and how to remove them.
Ensure that defect management is in sync with the test analysis results of the CI/CD pipeline (finding defects early in the development lifecycle and preventing possible defects from emerging later in the production cycle is the main goal).

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.

Concluding Thoughts

Simply put, the main objective of continuous testing is to build quality into the product from the very beginning of the software development life cycle. Using this method, we push our teams to make culture, mindset and technical adjustments to make sure they can test at all stages of development (Unit testing, integration testing, Security Testing, system testing and acceptance testing) and accelerate the overall development process to achieve better results for their customers.

That being said, there is one problem that is worth mentioning here, what about the developers? How do they react to the new job requirements involved in the adaption of continuous testing? We have seen a significant improvement in the last decade in the “Programmer” mindset that tests are not part of the SDLC and are solely the responsibility of testers. This was an undeniable fact in traditional waterfall SDLC, and we saw how it began to shift in Agile frameworks, making it impossible for developers to not take a decisive part of test ownership . However, DevOps has made significant progress by embracing CI/CD processes and a continuous testing mindset.

From the standpoint of the developer, they must concentrate on coding and avoid spending their time on tasks like debugging and monitoring tests. In DevOps, developers must alter their perspective and accept the fact that testing is a crucial component of their new role. As engineering teams look to deliver software faster (mostly by automating all the manual labour involved in traditional development) the quality of their work still needs to be evaluated.Mistakes can be very costly and can impact the entire CI/CD process and we all know, a poor product delivery to the field, can have a decisive and permanent impact on the business reputation and lead to legal risks.

Continuous testing should be embraced right from the beginning, early in the development stage, to increase the feedback loops that will guarantee that risks are identified, mitigated and monitored. Another point worth mentioned is the “Quality ownership”. So, in traditional SDLC we have testers that took care of it, and in Agile frameworks (Scrum, Kanban etc.) the boundaries started to become vague meaning that developers took more responsibilities on quality. And in DevOps? If you embrace it right, there will no owners at all, as taking care on quality becomes everyone’s responsibility.

Top Agile Myths & Misconceptions

DavidTz40 — Mon, 06 Feb 2023 09:38:20 +0000

It sometimes amazes me that there are still people who haven’t heard of Agile or what it represents. Below are some myths and misconceptions that people have believed about Agile. Of course, if you’ve ever worked in an Agile environment, some of these items might come as a surprise. But these are things I hear again and again.

Agile Is a New Force in the Software Industry

No, Agile is not new. However, the Agile Manifesto was published in 2001. At first glance, this seems to be a relatively new concept, but it’s not. It can be traced back to the mid-60s; it is certainly not as new as people think. A close look at the report from the 1968/69 NATO Software Engineering conference reveals some great insights about the early origins of Agile (page 32, Perlis):

“Through successive repetitions of this process of interlaced testing and design, the model ultimately becomes the software system itself.”

Agile Is Better Than Traditional Methodologies

Although more and more companies are using Agile as the preferred way to develop their products, this assumption is wrong. The type of development methodology should be determined per project and based on environmental variables. For example, we can use the Waterfall methodology if we have clear and informative requirements from day one of the project. Also, the waterfall method can be used when we have a stable environment that increases the predictability of the project with respect to the work that needs to be completed.

There Is No Documentation in Agile

This myth may have started with the Agile manifesto itself by stating, “Working software over comprehensive documentation.” Even earlier Kent Beck, the founder of Extreme Programming, is reported to have said: “Documentation may only be necessary before I die, and can’t explain it personally.” This wrong interpretation led people to believe that being Agile means no documentation, which of course, is not the truth. In Agile, you can have as much documentation as you need because it can be part of the team deliverables. It provides value to the customer and the development team/organization.

Also check this tutorial on Agile testing, and deep dive into the history of Agile testing, its advantages, disadvantages, methods, quadrants, and best practices.

Deadlines do not limit agile projects

Agile is not a free ticket to abuse the project timelines like traditional methodologies. Remember that there is a customer who is paying for the software (and a company that needs to earn money). There is no chance that a customer will agree to work with a company if they are told there is no expected time for project completion. The main thing in Agile is that we can deliver incremental releases of the product to allow the customer to review the project’s progress and use a basic set of functionalities that increase as the development sprints progress.

Agile frequently uses a more explicit definition of done, such as the Definition of Done (DoD). To make sure that the customer’s needs are addressed, the team and customer have agreed on this. For a project, there may be several definitions of done, including:

DoD for a release
DoD for a feature
DoD for a User Story
DoD for a Sprint

Agile Revokes the Need for Planning

In Agile, planning is everything! There isn’t a project that does not involve significant planning. The main difference in Agile is that the planning is spread throughout the whole development process, rather than at the beginning, as in traditional development. In Agile, there is less up-front planning because planning is performed per sprint, continually until the completion of the project (there is no need for significant up-front planning that will become obsolete due to changing requirements). However, customers and critical stakeholders use sprint plans. Any deviation from a particular delivery date may be seen as a failure on the part of the team and not as a failure of the plan itself.

Agile Is the Cure for All Problems

Agile will not solve all problems related to the Software Development Lifecycle, but if used correctly, it will most likely help the organization increase the percentage of project success. It will also increase visibility, improve communication, and results in continuous improvement.

Agile Is Not Suitable for Large Projects

Managing large projects is very demanding, no matter what methodology is used. The main difference between Agile and traditional methodologies is that we take a large project and break it down into small manageable deliveries rather than delivering it all at once.

Agile Means No Design

Does this even sound logical? Of course not; being Agile does not mean a project does not require any “design” supporting it. The main difference between Agile and other models is that in Agile, the design is reviewed and updated continuously throughout the development process.

There Is No Need to Plan Your Testing Activities

Test planning in Agile is a part of the planning sessions and occurs at the beginning of each sprint, where the team will work together on stories to determine the test strategy for the upcoming sprint. Moreover, the testing effort must be based on quality standards. These must include up-front planning to support the coding activities involved in developing each user story.

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.

Who Needs Test Documentation?

In Agile testing, we have fewer documentation activities, such as creating long, comprehensive STP docs or STDs containing thousands of test cases. This does not mean the team is free from documenting their tests at some level. As part of the testing activities per sprint, the team must document their tests somehow. Irrespective of the testing methodology used (e.g., Exploratory testing, Risk-Based testing, automated testing, etc.), we need some documentation to gain the most from the test execution process.

Tools Will Remove the Need for Testers to Communicate with Other Team Members

The Agile manifesto gives importance to people over processes and tools. Tools are essential in any environment, especially in a fast-changing environment like Agile. Tools help reduce manual labor and costs and allow team members to focus on crucial quality artifacts. However, in Agile, we rely on people to collaborate, irrespective of the tools used in the development activities.
Testing practices based on a well-designed strategy are always more important than just using tools (essential as a supporting layer). Testers must be key players in the overall development sprints, including participation in daily sprint meetings, planning meetings, etc. This needs to be from the beginning of the project and they also need to be a part of the development of each user story to add their insights as early as possible.

Agile is only used in software development

In practice, Agile methods are a specific way of delivering results. Despite the fact that they were first used by the software developer community in the 1990s, Agile has nothing to do with SW development. There are numerous examples of Agile being used outside the software world and even outside of IT, ranging from marketing to finance to product development.

Agile and Scrum are synonymous terms

These two are not interchangeable. Agile is the application of the approach, while Scrum is a framework. Scrum is not a framework that is used by all Agile businesses. Which methodology will best support user needs will depend entirely on the situation.

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.

There is No Focus on Quality

The myth is that with Agile, you get what you get (implying that there is no emphasis on quality/customer satisfaction). This is not the case, as we are focused on providing value to the customer and meeting their highest priority requirements with Agile. Sprint retrospectives are also beneficial in terms of promoting quality and continuous improvement. These allow the team to ‘inspect and adapt’ the work they have done and how they have done it on a continuous basis. The retrospective focuses on process improvement. The objective is to identify only 1–2 strategic changes for the next iteration.

Conclusion

Getting the misconceptions out of the way early on is a good way to get started with Agile Methodology. The faster the team and stakeholders understand the gist of the myths and why they exist, the better for the organization’s journey to becoming Agile and effective.

Agile Testing Guilds to Foster a Culture of Learning and Innovation

DavidTz40 — Mon, 06 Feb 2023 09:16:49 +0000

I believe in craftsmanship. I believe that true professional is always looking to learn and improve their skills. I also believe that as a manager, but also as a professional, you should strive to create an environment in which employees can learn and grow.

You should encourage people to attend conferences, visit other companies to exchange experiences, read books, do training on sites like Udemy, read blogs, and possibly even write blogs themselves, etc. However, I believe it is equally important to demonstrate to your people that you are serious about knowledge development. You can achieve this by providing individuals with opportunities to grow during business hours.

I worked for several companies and was always a proponent of knowledge development. Part of my strategy is to always establish a framework in which people can meet and discuss their discipline regularly. Professional circles were used in some companies, while Guilds were used in others. Nowadays, I prefer the term Guild because it refers to being a craftsman.

A Guild is an organic and broad “community of interest,” a collective of people who want to share expertise, tools, code, and practices. Examples include the Tester Guild, the Scrum Master Guild, and so on. A Guild’s goal is to improve one’s craft. This can be accomplished by discussing new technologies, sharing experiences, and inviting people from outside the organization. The Guild is not intended to be a forum for discussing work-related issues.

I believe that as an expert in your field (or when you aspire to be one) you want nothing to hold you back from learning new things and growing both your technical and personal skills. I also believe that as an expert, you should share your knowledge among colleagues so they can learn and grow themselves.

Feature Teams Vs. Guilds

Before we dive into the Guild model, it is important to clarify that Guild members are a group of people who work on multidisciplinary teams that are organized to create a product or deliver value. For example, in the Scrum environment, we may have a quality tech lead team rather than a quality tech lead guild. What differentiates the two, is that a quality tech lead team sits together and interacts with each other all day every day, while a quality tech leads guild’s members are spread among different Scrum teams and work on the goals and tasks of that team, while also having a focus on quality.

A common practice is to create teams that focus on dedicated skills such as infrastructure, automation frameworks, UX, etc. At first, it may sound good, to create a team with a group of experts that focus on a specific platform or technical area of the product so they can provide support and guidance to the rest of the team that needs their help.

I am not saying that this practice will not work or that it is less efficient than other options. However, in my experience, this centralized approach leads to flow bureaucracy that makes it harder for feature teams to consume the services, platforms, and tools created by those centralized teams.

Remember, the centralized teams create their products. The services, platforms, and tools they provide are their product, but because they are separate from the teams they are supporting, they might build things that no one needs or that are too hard to consume.
It is important to understand that centralized teams have their backlogs, prioritization, and goals that in most cases do not reflect the same priorities and goals of their consumers. This leads to the flow bureaucracy, as feature teams find it hard to get the responses and resources from the centralized teams, which leads to increased frustration, and bottlenecks in development.

Because of the flow bureaucracy, feature teams start to create their solutions, though they should consume them from the centralized team created to provide them. They may make other technical decisions just because don’t get the response times they need for their day-to-day efforts.

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 application testing on LambdaTest.

Guild Models

When creating guilds, it is important to distinguish between two major guild models. These models are known as the “decentralized” and “centralized & decentralized” guilds:

Decentralized guild model

The decentralized guild model is based on team members that do not exclusively belong to the guild. Though they are part of the guild, they still work on separate teams with all that implies, for example:

They have their manager, which they report to.
They have day-to-day tasks like all the other team members.
They must be familiar with their team’s product.
They have other team members, which whom they work to achieve the team goals.

Centralized & Decentralized Guild Model

This guild model is similar to the decentralized model with one major difference. Guild members still take an active part in their teams, but they report to the guild managers who set their goals, visions, and mission statement, rather than having their manager be the feature team manager.

The quality tech leads (QTL) who are members of the quality guild officially report to the quality architect, who is the head of the guild. However, each one of them is embedded in their development team where they collaborate with other team members, participate in their meetings, work on stories, and generally act as an equal team member.

This guild model has some advantages over the first model. Decentralized guilds live and die by the motivation of their members, who can decide how they will use the knowledge they gain as members of the guild or whether they want to participate in guild activities. This is all about the commitment and accountability for the guild, as there is no real way to reinforce their active participation.

In a decentralized guild, each team member has two different jobs. This simple fact guarantees that in any shortage of capacity, the guild responsibilities receive the lower priority and are abandoned.

When using the centralized & decentralized guild model, we have a guild leader who is fully accountable for their guild, including keeping track of guild activities, determining goals, and ensuring that each team member works towards the guild’s mission.

Having a guild manager also allows its members to gain the support and guidance they need to promote continuous improvement processes. In addition, guild managers allow their teams to focus on the guild mission, while still allowing them to learn the needs of their teams, gain their feedback and determine the strategic plan to bring them real value.

Try an online Selenium Automation Grid to run your browser automation testing scripts. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free.

To distribute or not to distribute?

More and more businesses are collaborating with distributed teams in multiple locations. In my personal view, the number of people working in distributed teams will only increase. Working remotely affects your Guild session as well. It will become less efficient depending on the hardware and facilities you have.

Twenty people in one room can have more productive discussions than ten people in one room and ten people on the other side of the world. You must decide whether you will organize local Guild sessions or distributed Guild sessions. The benefits of having distributed Guild sessions include people from various locations sharing knowledge and thus growing relationships across multiple locations.

Local Guild sessions have the advantage of being more efficient and easier to discuss topics. You must decide for yourself what works best in your organization. I would advise you to start distributedly and gather everyone in one Guild Session. This is the toughest setup. This configuration, in my opinion, provides the most value to the organization. A backup Plan, with Guild sessions in each location, is always an option.

Is attendance required or optional?

Assume your management is fine with you organizing Guild sessions and you invite people to the meeting. Every third Monday of the month, from 14:30 to 16:00, you set aside one and a half hours. Then there will be those who will ask you, “Do I have to attend this meeting?” What should I do? Personally, I would say, “Yes, this meeting is required.” However, I believe that people cannot be forced to learn. For me, the Guild is all about learning and sharing. As a result, I’ll say, “No, but why don’t you come one or two times?” Simply give it a shot.” It is your responsibility as Guild Master to make the Guild Session as appealing as possible.

Also, check our Selenium online Grid to run your browser automation testing scripts. Our cloud infrastructure has 3000+ desktop & mobile environments.

What about leadership?

It is critical, as with many things, to have management support when organizing your Guilds. The goal for me is to increase the knowledge of those who attend the guild, and in my case, to make them better through the exchange of experiences. The Guild is not intended for project-related discussions. We will not discuss specific problems of individual teams. “Every Member Of the team in the world should be able to attend our Guild session and find it interesting,” I assert. No prior knowledge of the project or company should be required. Arguments to persuade management of the benefits of guilds include:

You can use it to promote your company and build your brand; I believe you want to hire professionals who want to attend Guild sessions.
Because people who attend external conferences can share their knowledge in their Guild, you will develop knowledge of your professionals.
It will foster cross-team relationships among people from the same profession who work in different teams.

Who is going to plan all those Guild meetings?

The opportunity has arrived… The first Guild session has begun. You put together an awesome presentation about a new concept, framework, innovation, and so on. People loved and admired it because you used the happiness door. It was highly successful! Congrats! But… there has to be another Guild session next month… Will you present a topic again, or will you ask for a volunteer? When you ask for volunteers, there will always be some people willing to present a meeting. However, I believe that every professional should be able to present to a group of people a technique, idea, or anything else.

I always assign Guild sessions to each member of the Guild and charge them for organizing their session. People are free to attend Guild meetings, where they can learn a lot of new things. The only thing I ask in exchange is that they organize at least one Guild session. So far, my experience has demonstrated that this concept works well. Of course, the sessions will range in quality from decent to epic. Most importantly, all participants are contributing, and you do not need to organize every session yourself.

When I was Guild Master of the Testers Guild, I always had one tester present a testing technique and describe how they used it in their products. I asked another tester to speak about testing. It was up to the tester to talk about how they tested in his or her previous company or a conference he or she attended. It worked beautifully! It should be noted that people are free to exchange sessions or restructure certain things. When a deadline prevents somebody from preparing a good session, it is recommendable that they manage another guild member to step in.

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

A Guild does not come to an end at 17:00 p.m.

After the actual meeting, the Guild continues. Make a place where individuals can gather to debate what is discussed in the Guild. We used Slack in one company, and each Guild had its Slack group. We discussed topics beyond the meetings and shared relevant blogs and/or articles in this forum in addition to sharing the information from the Guild sessions.

Again, set a good example. If you are the Guild Master, make it a point to share something at least once a month. If you want to learn more about the Guild, make sure to join the Guild group. If you don’t have Slack, you can use any Wiki framework or even a private Facebook or Google+ group.

Setting up a Guild

How to set up Guilds is one of the most often requested topics that I receive. We’ll go over some important factors to think about while organizing your Guild and offer some troubleshooting advice after you’re up and running.

Preparation for the Guild Sessions

Create your key messages in advance.
What are we attempting to achieve?
Make an excellent WIIFM statement (can always grab a couple of potential members to help with this). This will aid in communications and the introduction at your launch event. Validate the statement with the group at the event.
What is the primary objective (or why) of these sessions?
Planning your event — some important factors to consider include:
An icebreaker that allows members of the community to get to know one another and recognize things they have in common.
Drawcard — what will entice people to attend the event — a key speaker, an important figure from the business opening, food? What else is there?
Create a backlog, which could include seeded items such as things you believe are essential fundamental building blocks, items from the questionnaire, and some cool topics. Have a clear place to collect this backlog, as well as a simple way for individuals to add to it and set priorities going forward. Make it visible and accessible.
Consider the forum’s leadership. Is there a key role that leads it permanently, for a term, or on a rotating basis? Is the leader capable, do they require any assistance, and do they have a clear set of responsibilities?
Team Charter’ — collaborate to create a social contract, choose a cadence, and decide where and how to share/store documents and communications. Consider writing a Guild purpose/mission statement.

Tips for Running the Session

Consider various formats.
Determine the Keynote speakers.
Always have a person (self-selected or rotated) in charge of facilitating the event to guarantee we make the most of the session.
Lab — bringing their work and implementing a specific new tool or technique with assistance.
Each session should always conclude with the subject matter for the next session, the facilitator, and the format (either chosen in the room then or confirming any previously defined next sessions). Always confirm with the group that it is their main priority.
Clinic (e.g., present problems that need to be solved and divide into groups/work with a mentor)
Retrospectives or problem-solving sessions for common challenges.

Monitoring the effectiveness of the sessions

Keep track of the number of participants to spot positive and negative trends.
Think about how you’ll keep track of value — surveys. Retros after sessions?
How will the Guild demonstrate/share with stakeholders what it has learned, solved, or created? Would this be significant to them?
Run a retrospective with the Guild — what’s working, what’s not? What should we change?
Establish a feedback mechanism for continuous improvement of the guild

Tips for running a successful Guild

To help your guild succeed and last, I recommend the following:

Ensure that the guild evaluates the value of its work regularly. For the guild to remain relevant and motivated, it is critical to publish progress and results, and even more important to celebrate those successes. This visibility may also inspire the growth of new guilds.
Consider and stay on top of the guild’s operational aspects. Meetings and agendas must be communicated clearly. Who is required and who is not? Documenting and sharing meeting notes, for example. The more structure there is, the longer the guild is likely to survive.
Guilds must have a mission statement, a vision, some structure, and a written mandate. This enables not only the guild and its members to understand how to operate, but also educates outsiders about the guild, what it stands for, and its current goals. This also reduces the possibility of a second guild being formed to solve the same or similar problems.
Obtaining senior management approval and buy-in. Having this is a great first step. They must recognize the value of a guild and be open to this method of collaboration and community. It is also essential that they allow the guild to be autonomous in terms of how they work and prioritize.
Members must take the guild seriously, understand that their contribution is essential, and make a contribution to the guild’s success. The destruction of a guild can occur gradually as people abandon and investment decreases.

Creating a World-Class Quality Guild

This section reviews some of the core aspects of guild creation by telling the story of Tom, who was one of my clients and a dear friend.

“Testing Guild: A testing guild is a term used to describe sessions in which testers from various product/project teams gather in one location at the same time to discuss testing-related learnings and new technologies. Due to factors such as distance and time, these sessions may be held at the same or different locations. It is important to note that testing guilds can also include developers, scrum masters, and product owners.”

Where does our story begin?

Tom was the quality director in a leading enterprise software company that was in the middle of its Agile transition. As part of this transition, the company had a severe degradation in the quality of its deliverables, which led to frustration among the main stakeholders. As the quality director, Tom had tried for over a year to change this. He failed, as he could not handle the 60 Agile teams and their managers who managed the development efforts.

What were the challenges that we had to resolve?

When I was invited to help with this problem as an external consultant, the first thing I did was to talk with Tom to gain information and figure out the big picture and the real scale of the problem (from Tom’s point of view). After a few sessions with Tom and other key stakeholders, we determined that there are three major challenges to address as part of the solution:

C1: A limited ability to affect

It makes sense that one person (good as he might be) will not be able to lead and promote quality processes when he needs to work with so many development teams and stakeholders. Tom’s inability to make a real change within the organization led to one obvious result, frustration and the loss of motivation to keep pushing.

C2: Agile transition without focusing on quality

An Agile transition can lead to a massive degradation in quality if this area is neglected. This is exactly what happened in their case, including all the classic problems such as:

Lack of integration and collaboration across development teams.
Failure to adopt the core practices related to Agile testing.
Epic failure in the process of integrating testers in their new Agile teams.
Lack of quality practices leads to mini-waterfalls within the sprints.

C3: Objections of Development Teams

One of the interesting things that Tom said to me was about the objections of the development teams to his vision because he had never been part of their team and therefore could never understand the day-to-day pressure and challenges the team has.

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

The steps we followed as part of the guild creation

Based on the information I gathered from Tom and after a few more meetings with key stakeholders, we decided with management to create a quality guild (following the centralized & decentralized model) that will be led by Tom. These are some of the key principles we followed.

Recruitment of guild members — The first problem was that we could not find any suitable members within the organization. Therefore, we invested months in external recruitment.

Definition of the roles and responsibilities (R&R) — Due to the cross-impact the quality guild has on the organization, it was important to determine the roles and responsibilities of its members. After some thought, we decided that each team member will possess the title of “Quality Tech Lead”. Each QTL will have a specific area of responsibility that they will own as part of the day-to-day work with their teams. This is how we defined their role:

Actively participate in team Scrum meetings.
Act as a quality consultant for the team.
Assure compliance with applicable organization quality policies, standards, and procedures.
Perform root cause analysis (RCA) with the team and hold lessons-learned sessions.
Initiate and drive the adoption of technology, product, and process improvements throughout the software delivery lifecycle.

Finding the right teams for the POC — In theory, we know that our solution can be perfect for the organization, but nothing comes free and we had to work very hard to find the right teams to take part in the POC. To choose the best candidates, we had to ensure that they all understand what we intend to do and how they will benefit from it.

Definition of the guild goals and vision — Below, are some items from the presentation we made to demonstrate what the quality guild would provide to the organization and especially for the teams taking part in the POC:

Creating quality focal points within the organization.
Promoting the Agile testing mindset and continuous testing (instead of the mini-waterfalls and bad testing practices).
Implementing quality policies, standards, and procedures (quality projects, hardening, readiness, etc.).
Increasing transparency of our team’s quality work (quality initiatives, KPIs, and designated dashboards).
Training & mentoring designated teams on testing and quality practices (ET, RBT, SRM, BVA, etc.).
Helping the organization adopt a quality culture (prevention focus, continuous improvement, collaboration, etc.)

How is it going to work?

The guild model that we established at the time was new and followed a type of management that our team had never seen before. To ensure that everyone understands this change, we had to communicate the work interfaces between the QTLs and their teams:

QTLs’ physical location — The guild members (QTLs) sit with their teams.
Taking part in team activities — QTLs will take part in their team activities such as planning sessions, design meetings, etc. Furthermore, to be a real part of the team, they are also asked to participate in the team retrospectives and to present at each review meeting the overall progress of the quality projects.
Dedicated to their teams — To ensure that each QTL makes a real change and to promote continuous improvement, it was decided that each QTL will be dedicated to their team until the team is mature.
Mastering their team’s products — QTLs provide the best value when they understand the products and the technological environment of their teams. To achieve this goal, each QTL had a full training cycle before starting to promote guild activities.
Direct Management — One of the most important things that we had to define is that the QTLs are managed by Tom and not by the team’s manager. This allows QTLs to create positive tension between them and their teams related to the quality agenda. In addition, we want to let our QTLs provide more services. To do this we made it clear that Tom is the one to prioritize the QTLs work, but the teams can still add their quality items (e.g. creation of a new process, mentoring of team members, etc.).

Where do we cross the line?

Before starting the guild work, we had to make sure that every stakeholder involved in the project knows the boundaries and expectations of the guild. Below are some of the items we presented in the project kick-off meeting:

Project Kick-Off

Now that we have closed all the loose ends, we can officially start the project and assign the guild members to their teams. To ensure that this new model is working, we created a completely new infrastructure to support it. Below are some of the measures we used:

We created dedicated KPIs to track and adjust the process.
Tom, the guild manager, worked closely with each QTL to ensure they are focused on their goals and tasks.
We set weekly meetings with each QTL and their team manager to generate continuous feedback loops.
We created web dashboards accessible to anyone who has an interest in the project.
At the end of each quarter, we set a meeting with the key stakeholders to review what we achieved (and what we have not).

Things I Learned Along the Way

Below are some of the insights which I hope will contribute to your efforts when establishing guilds in your environment.

Support from management is key

Like any other initiative, before you start building guilds in your organization, it is important to have support from management. I highly recommend that when you introduce this model to management, you will be able to:

Explain how the organization will benefit from using guilds.
Describe the plan to create and initiate the guild model.
Explain the concept of guilds and the different models for implementation.
Explain how this model will influence (positively and negatively) the development teams involved in the process.

Involve all people in the guild as active contributors

Regardless of the guild model you are using, it is important to involve everyone in the guild as active contributors and not as silent participants. One way to do this is to ensure that each guild member has the opportunity to present a tool, idea, or anything else that contributes to the guild agenda.

Any guild member can become an active contributor. As professionals, it is a basic assumption that they can take ownership of a guild session, organize it, and contribute. My experience so far is that this concept works great. Of course, you cannot expect that each session will be at the highest level, but the important thing is that each team member contributes without the need to rely on a single person to organize every session.

Ensure that the guild has the right people

It is important to add only the right people. But who are the right people? Well, before I add a member to my guilds, I try to follow three basic rules:

The candidate must want to take part in the guild. They should never be part of the guild just because someone told them that they must.
The candidate should be accountable and committed to the guild activities and take an active part in knowledge sharing.
The candidate should have skills and expertise that are relevant to the vision and goals of the guild.

Ensure that your organization is ready

In some cases, the answer is that it’s simply not the time for guilds as the organization has not yet gained maturity. Perhaps there is no real capacity for team members to participate, or maybe they just do not want to learn. If that is the case, don’t enforce the use of guilds. Wait for the right time as there is no second chance for a first impression.

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

Closing thoughts and where to go from here

It is critical to organize guild sessions, educate people, and provide them with opportunities to learn. It is, in my opinion, part of the process of establishing a self-learning organization. However, organizing Guild sessions can be difficult. However, once it’s up and running, it can be extremely rewarding. So, give it a shot, inspect and adapt, and make it a success!

Barriers to Incorporating Automation in Agile Teams

DavidTz40 — Mon, 06 Feb 2023 08:50:30 +0000

As I’ve written numerous times, agile teams must automate many aspects of their work, such as testing and build creation and any other process whose automation would save time for the team.

However, despite it being clear to me that it’s very logical for agile teams to use automation for any product backlog item (PBI), I’ve concluded that it’s simply not as obvious as I thought. As a result, I decided to write this article about the main reasons agile teams fail to implement an automated solution.

DEVELOPERS’ ATTITUDES TOWARDS AUTOMATION

To understand developers’ attitudes toward automation solutions, we need to look at how they see automation in traditional environments, where separate QA teams do all the testing work without involving developers in the testing process. The direct result of this environment leads developers to become less involved in the testing process (why bother with testing if there are dedicated QA teams to do the work for us).

In addition, the waterfall development process is built with different phases for development and testing, which makes testing even more remote to developers who do not need to do much after the completion of their stage as they usually have already moved on to the next project.

There is no separate QA department in an agile environment that provides a safety net for developers. The agile development team must ensure the quality of the product, and developers must become involved in all aspects of the testing process, from the unit test level to system testing.

Developers must change their attitude, mindset, and culture to allow the team to succeed in an agile working environment. Developers who fail to do this will impede the team from delivering on their commitments.

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

UNREALISTIC MAINTENANCE COSTS

The main goal of automated frameworks is to boost the team’s ROI while increasing the test execution, build creation, and overall process. So if we think about it, one of the main goals of using automated frameworks is to free engineers from performing manual work to focus on other aspects of the project.

But what happens when the team selects the wrong automated framework and uses poor test design that consumes most of their time to maintain and stabilize the written tests? This leads to an unrealistic situation where the team spends hours and days of manual work on frameworks that were supposed to free up their time.

A classic example of this scenario that I often see is agile teams that do not want to spend time on user-interface (UI) testing. The first thing they do is develop or purchase a third-party vendor capture tool to record their tests, expecting it to solve all their automation problems. Well, this will not work. The creation of thousands of lines of UI test scripts that (usually) don’t follow code practices will create a situation where, over time, no one knows what they are supposed to do or why they were written at all. This leads to unrealistic maintenance time on tests that are maybe no longer relevant.

To overcome this barrier, the team must choose the proper framework for the automation they want to achieve. Someone capable of seeing the big picture must invest time in great test design and the future roadmap, and the team must use the relevant code practices that will make the code readable and easy to maintain over time.

PREVIOUS BAD EXPERIENCES

One prevalent barrier among engineers is fundamental, and that is a previous bad experience in automation projects that didn’t pay off. There are many challenges in automation projects, and, therefore, more opportunities can cause teams to fail, such as poor design, unstable automated frameworks, and many others. In this case, the organization must analyze the failures and ensure they will not recur in future projects.

LEGACY CODE

This is a simple fact: most engineers prefer to write their code rather than getting legacy code that other programmers wrote. When writing automated tests, we have another layer of testing, making it even harder for a developer to succeed with the project.
The first barrier is the code itself. If a developer needs to work with code that he didn’t write or participate in the design, it may be hard for him to understand the code itself and what tests should be created to provide good test coverage.
The second barrier is legacy code that isn’t designed for testability, making it almost impossible for an engineer to create automated test scripts without refuting the legacy code.

Perform browser test automation cloud on the most powerful cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

LETTING TESTERS DO THE WORK

If I need to select one reason that will lead to failure, again and again, I would probably say that it lets testers write the automated tests when they do not have the necessary knowledge and experience in the coding field.

This is just one classic example of how all team members of an agile team should be working as a single unit without separating between programmers and testers. Otherwise, the entire project can fail by letting the testers know that they have nothing to offer if they cannot handle basic test scripts in the agile world.

In the opposite direction, a robust and agile team will not let testers do this job without a supporting framework from the rest of the team. The team must understand that any automation project is the team’s problem, not the responsibility of the testers just because they were responsible for quality in the old traditional environment.

JOB SECURITY

Agile teams contain testers that, in many cases, were added to the team as a legacy from the previous environment. These testers often do not have coding experience and therefore focus on manual testing, which is less suitable in an agile environment. These testers may reject the idea of using automation processes for testing for fear of it making them less relevant in the future.

FEAR OF FAILURE

Due to challenges inherent in automation projects, automation projects can be scary to engineers, from determining the goals to the implementation itself. As I learned over the years, programmers may know to write excellent production code, but once they focus on writing automated tests, they will face many logical and technical issues that they do not have in their day-to-day work.

Need a great solution for Safari for windows testing ? Forget about emulators or simulators — use real online browsers. Try LambdaTest for free.

LACK OF SUPPORT AND KNOWLEDGE

I think that every engineer who has common sense about automation’s benefits will want to use it to simplify work. But what happens when this engineer has neither the knowledge nor the time to invest in creating this framework? How can he free time, in an already stressed environment, learn new tools such as automated frameworks and design practices such as TDD and refactoring?

To allow the team to gain the knowledge they need to master this area, the organization must provide the necessary coaching. An external expert is a great option to help the team get set up and save time. Coaching is needed in both the theoretical and technical aspects of automation practices. It is more important to free the team from learning and adopt this new approach in their day-to-day activities.

AN INVESTMENT THAT WILL NOT PAY OFF RIGHT AWAY

The team will need to invest time to create, plan, and design automated solutions that will reduce the manual work in the long term. But although the benefits are clear, we need to remember that even with the entire agile team working on the automated solution, it still requires a significant up-front investment that will reduce their ability to deliver functional PBIs in the first few sprints. This can be a big problem in an agile environment.

There is a huge psychological barrier that agile teams and the organization run into when they understand the investment they need to make at the beginning of the automated project, which will not pay off right away. Both the team and the organization must know that it takes time to decide which processes and tests should be (and can be) automated and which frameworks to use.

As I’ve seen in almost any automated project, the team must show senior management how automated solutions will help the organization increase the ROI. Although they will not see an increase in ROI in the first few iterations, without knowing the benefits, there is no chance that the organization will allow the team to invest the time they need to succeed with their automation challenges.

Making the Most of Your Testing Resources

DavidTz40 — Fri, 03 Feb 2023 08:27:52 +0000

Even successful businesses are cutting back in today’s global recession. Some companies are slowing their expansion, while others are cutting their employment. Testing firms will almost certainly be targeted as firms consider ways to save costs. Because testing is so low-profile at the top of the food chain, many people regard it as another expense center. If companies tighten their belts, testing organizations will have to do more with less (or less). However, most QA teams and others need to be more staffed and able to meet business objectives. So, how are they going to do the task now?

The solution is straightforward. We must consider how to do things more effectively to accomplish more (and better) with what we have. Then we must go further than our walls to see if new technology and tool developments may enable these changes.

Until recently, testing in the communications business resembled a continent lost in time. Little was done to give more complex testing tools or to assist testing teams in keeping up with development. They had no choice except to rely on manual testing methodologies, construct their own testing tools, and employ outmoded programming languages. The costs of these techniques have been high, ranging from squandered resources and disgruntled employees to ineffective operations.

Manual testing, for example, could be faster, error-prone, and more reliable. With more sophisticated technologies on the horizon, attaining the same quality targets would require either more employees or longer testing cycles, which is a possibility in the current economy. Building tools in-house is only sometimes an option.

Organizations believed this would help them progress toward automation years ago. Instead, it turned out to be unsustainable and a drain on talent. Many of the sharpest testers are now tethered to tool maintenance responsibilities and have little time to test. When it comes to scripting, talent is rare, and scripting languages may be brittle, making maintenance time-consuming and a burden on testers who must spend more time establishing APIs. Not to add that many testers struggle to comprehend each other’s scripts and so on.

Testing companies now have additional options because of the availability of new technologies and testing tools.

Automated Functional Testing tests helps to ensure that your web app works as it was intented to. Learn more about functional tests, and how automating them can give you a faster release cycle.

Here are some ideas on how people might start doing more with less

First, provide manual testers tools to help them be more productive. You may expect productivity improvements of 50–100% with no issues. Manual testers may now use sophisticated testing technologies to speed up day-to-day testing operations. The idea is to look for tools that are semi-automated and simple to use. They may run a test once and then click a button to rerun it when the new build arrives. Manual testers will save time if the tool can execute the test and create a significant portion of the documentation, including pass/fail metrics.

Consequently, individuals who attempted to share documentation and tests frequently discovered that the amount of work necessary to comprehend them outweighed any time savings. Modern technologies may make semi-automated testing a reality while offering a solid work product and clear, precise documentation that makes test cases and results important down the process.

Second, provide autometer’s with a platform that allows work items to flow in an assembly line form. This will make creating an automated test case a more efficient process for everyone involved and better communication regarding tests and problems. You may expect a three- to four-fold increase in productivity from your current workforce throughout the quality process. Autometer’s used to have to start from scratch with textual test plans and data. Furthermore, they had to establish and manage a wide range of libraries to protect their efforts as the product expanded. Because of the variety of tools and frameworks available in the market, autometer’s may now construct complicated tests more rapidly and efficiently than ever before.

It is a significant breakthrough to establish a pass/fail analysis and rule with a single mouse click rather than a complicated calculation. Such tools can also assist them in creating and maintaining looping, branching, and simplifying. As a result, they can construct automated test scenarios more quickly and eventually be free of time-consuming library management. Better still, they may alter a semi-automated test case created by a manual tester to create a fully automated test case. It also makes global updates simple whenever software or hardware changes, so maintenance takes less time than it would build scripts. Furthermore, even individuals with little programming skills may use this toolkit to develop complicated test scenarios.

Third, find a solution that makes testing and performing regression considerably less time-consuming, allowing you to save up resources. Up to 10–25% of the staff that had been trapped conducting maintenance will be able to resume testing. There are now tools and frameworks that can help regression teams in running nightly tests and ensuring findings are forwarded to the correct person or system. More significantly, such tools are devoid of programming faults, allowing engineers to run tests that are written in a standard language and are simple to understand.

They may use these frameworks/tools to determine what the feature is intended to accomplish and rapidly determine whether the failure is due to regression system issues or a genuine problem. They may minimize their time running regression and triaging test failures if the output is customizable to current reporting or problem systems. They can also make communication with everyone who produces test cases much easier. This should result in increased test coverage, shorter and more consistent time to market, and a superior quality product. It should also permit skilled testers to return to testing.Black Box testing? Don’t worry; we will be covering what is Black box testing, merits, demerits, types & techniques.

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

Closing

Although employers demand testing teams to perform more with the same (or less), with the new technology and testing tools available, this is not an insurmountable issue. More significantly, by embracing these advances, testing companies can guarantee that individuals are executing their jobs correctly, resulting in new procedures based on efficiency. This has resulted in enhanced code coverage, shorter testing cycles, and better efficient and effective service delivery.

***This [smoke testing](https://www.lambdatest.com/learning-hub/smoke-testing?utm_source=devto

&utm_medium=organic&utm_campaign=feb03_kj&utm_term=kj&utm_content=learning_hub) tutorial covers what smoke testing is, its importance, benefits, and how to perform it with real-time examples.***

Test managers, start managing now!

DavidTz40 — Fri, 03 Feb 2023 08:11:26 +0000

Some things in life are immutable. For example, we will only live to reach 120 years old. It is possible but extremely unlikely. Another guarantee is that testing will be squeezed into the schedule. It is doubtful that you will be given enough time for testing and a suitable position on the project’s list of priorities.

Given this fairly undeniable truth, I must ask some of you test managers out there: Why are you still getting caught off guard by these vulnerabilities as if you didn’t see them coming? Why are you putting your team through absurd amounts of overtime when other project members get to enjoy their weekends? Why are you pushing your staff to produce last-minute excuses for unexecuted tests and unexercised features due to time constraints? Why are you enabling your team to be the perfect candidate in the inevitable finger-pointing game?

Well, this is more than one question, but I must add that I am astounded by some test managers’ lack of responsibility. Trying to mitigate such problems is an essential requirement of quality management. So, if you’re not doing this, what are you doing? Contrary to common belief, just attending a meeting and applying stress does not define test management. I’m sure you all understand what I am talking about because we’ve all seen those bosses who have mastered the art of appearing productive and dominating.

They constantly attend and leave meetings, and when they receive criticism from project management, they just pass that burden on to the subordinate test engineers. When their managers scream at them, they convey that rage to their subordinate test engineers. This managerial style is not beneficial to anyone since hardly anything improves.

I’m not under the impression that there is some magical solution that will suddenly make unproductive projects run more smoothly or totally remove the test team’s regular burdens. What I mean is that it is essential to manage the situation, gradually change the tendency to wrongly pressure the test team’s schedule, and increase team morale. A test manager can achieve these effects in a variety of methods, including the two below:

Realizing That Money Can’t Buy everything

Managers frequently believe pouring money into project problems that can compensate for poor management and planning. For example, when a project’s deadline is nearing, and it is at risk of being missed, there is sometimes a temptation to assign additional workers or to automate immediately. However, increased resources, test automation, and other measures to get immediate gratification often demand more time in the near term. As a result, undertaking such endeavors when time is essential might be exceedingly detrimental. To prevent exacerbating a negative situation, test managers must be able to convey this to project management properly.

Are you using Playwright for automation testing? Run your Playwright test scripts instantly on 50+ browser/OS combinations using the LambdaTest cloud. Sign up for free.

Build Trust with Your Colleagues

If you look after your employees, they will look after you, so avoid passing the blame. Stop tossing your team under the bus. I can think of a billion new clichés, but the main point I’m trying to make is: have a backbone and start taking care of your employees! You are intended to shelter them from the project’s politics so that they can focus on completing the task. If your teammates do not believe they can rely on you to defend their best interests, they will devote most of their time and effort to establishing political cover for themselves, reducing the amount of time and effort they devote to producing.

To successfully influence your team, you must first build trust. You must be able to put your trust in them, and they must be able to put their trust in you. Having faith in your employees does not necessitate you to believe they are completing jobs, but it also does not require you to micromanage them. Neither is beneficial to the trust connection. Instead, develop and enforce the adoption of standard templates and processes, and provide a centralized site for routinely recording metrics that you can use to produce progress/trend charts as a manager.

Trend charts are a fantastic way to track progress without continually looking over your employees’ shoulders or requesting an excessive number of time-consuming daily updates. Test management systems are quite useful for this task. Use it if you have access to one. Far more often, test managers allow test management technologies to be utilized just for test storage rather than for their entire range of reporting and analytic features.

Once you’ve started to trust your subordinates, focus on gaining their faith in you. One method to accomplish this is to demonstrate your trust in them. For example, if a testing dispute between another team’s resource and one of your employees is brought to your notice, start by publicly giving your subordinate the benefit of the doubt. Then, try to clear things up with them personally.

Refrain from making it known that your team is wrong. Limit the number of overtime that may be asked of your team. With the test completion targets established early in the project, you now have a solid foundation for declining demands for extra hours. And, once you’ve persuaded resources to volunteer for overtime (which is significantly convenient to do when they believe you’re looking out for their best interests), make it known to the project team that you and your team would only work longer hours if the necessary support (development, networking, DBA, etc.) is also accessible.

There is absolutely no greater waste of resources than rushing in to conduct testing without assistance because testing is doomed the moment something goes wrong with the system. When you consistently waste your subordinates’ time, they begin to believe that you and the team do not respect their time, and you begin to lose trust and productivity.

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.

Closing

As someone who has managed test groups and worked under both competent and bad test managers, I’ve experienced both the positive and negative consequences of successfully mitigating the recognized testing problems highlighted in this article. As a result, I advise all test managers to do their job and find a means to adequately address these predicted conditions, either by following the ideas outlined above or by developing your own.

Also check, 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.

The Seven Habits of Highly Effective Testers

DavidTz40 — Thu, 02 Feb 2023 06:34:54 +0000

Stephen R. Covey’s book The Seven Habits of Highly Effective People, which was first published in 1989, has helped countless people create positive habits that would enable them to achieve interdependent effectiveness in their personal and professional lives. The seven habits are discussed in this article, which frames them for very successful testers. These are the seven habits:

Be Proactive
Begin with the End in Mind
Put First Things First
Think Win/Win
Seek First to Understand, then to be Understood
Synergize
Sharpen the Saw

Be Proactive

In every software project, a tester’s objective is to guarantee that a high-quality product is produced. You have two options when determining what went wrong with software projects that fail due to low quality: you can either be proactive or reactive. Reactive persons tend to attribute difficulties or barriers to other people and external factors. Being proactive will allow you to accept responsibility for the mistakes and come up with solutions for future initiatives. After a project is over, your team should do a “post mortem” or “retrospective” in which you candidly discuss the project’s successes and failures. Here are three suggestions for approaching upcoming undertakings with initiative:

*Communicate Effectively *— Everyone must be aware of the status of the testing effort during Testing. Provide daily status updates through email or a discussion forum. Incorporate metrics such as defect counts, requirement coverage, the number of test cases executed, passed, failed, pending execution, and so on.
Analyze Traceability — Creating a traceability matrix of test scenarios for each requirement helps you assess the test cases’ scope, testability, and completeness. Hold continuous team meetings to discuss your test scenarios to guarantee you have a thorough understanding of the need and enough test coverage. Share your test scenarios for the developers to examine before coding to reduce rework and Testing time.
Effectively Describe Defects — When reporting defects, take the time to provide a thorough defect description, procedures to replicate, and expected results. Include screen photos and as much detail as is required to replicate the issue properly. This will cut down on QA rework.

Try an online Selenium Testing Grid to run your browser automation testing scripts. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free.

Begin with the End in Mind

The ultimate objective of a software project should be to deliver high-quality solutions that exceed the clients’ requirements. Before you begin coding, develop a set of desired outcomes against which you will measure the project. For example, your success criteria may be that the program provides particular goals, has little or no known errors (or a limited number of minor defects), is well documented, and is simple to use.

By establishing the criteria for success in advance, you may objectively assess whether or not the project met the expectations. When establishing the success criteria, enlist the assistance of all group members (project managers, product managers, testers, developers, and so on). By obtaining a team perspective on the success criteria, you will have more substantial and quantifiable criteria and much greater team buy-in.

Put First Things First

It is vital to prioritize your work effort. You must prioritize the most critical items first, then the less important ones. For example, everyone believes that negative Testing is necessary to guarantee that software manages circumstances in which the user does things that are not routinely done and that the product was not meant to handle. However, compared to positive Testing, Negative Testing is less essential. Begin your testing effort by thoroughly evaluating the program to ensure it functions as intended. Afterward, carry out your negative tests (testing bounds, invalid data entry, etc.).

Think Win/Win

In many firms, developers and testing staff blame each other and cause conflict. This may be highly disruptive and significantly impact the quality of the software project and the user experience. Both test and development staff should work together to ensure that the customer obtains a high-quality product. If this is a team’s unilateral aim, it makes sense for all team members to support and encourage each other so that when the product is provided with high quality and the customer is satisfied, everyone in the team shares in the enthusiasm of a happy customer. Here are a few pointers to help you establish a trusting, respectful workplace and a win-win team:

Encourage Others — Congratulate and congratulate team members who do an excellent job. Inform your (and their) management how well you believe they perform. Express your gratitude for their efforts.
Share Your Expertise — Instead of keeping your knowledge to yourself, share it with others.
*Assist Distress Team Members *— If you observe your team members struggling, jump in and volunteer to help. If you make an offer, be sure that you follow through and that they receive the support they require. You may need guidance in the future; therefore, assisting may create a win-win situation for everyone.

Also, check this online Selenium Testing Tool to run your browser automation testing scripts. Our cloud infrastructure has 3000+ desktop & mobile environments.

Seek First to Understand, then to be Understood

Many of us have a horrible tendency to tune out a discussion and not listen because we passionately want to be acknowledged. Every tester and team member has unique experiences, viewpoints, and goals. To solve a problem, you must first listen closely and carefully to comprehend it. When you believe you have all the data, ask for suggestions for possible solutions. Having multiple possibilities enables better talks and helps team members to adjust early answers into more far-reaching ideas that handle the problem more directly. If you disagree with a strategy, don’t criticize the person who proposed it. Instead, explain why you believe there is a superior strategy based on your previous experiences.

Synergize

A synergized team requires teamwork. A synergized team is made up of diverse team members with varied abilities, backgrounds, and viewpoints. Encourage these differences while providing your staff with tools to optimize efficiency. Highly collaborative teams communicate by sharing calendars and providing status updates in discussion forums, so everyone knows what the other is doing and accomplishing. These teams note all tasks completed daily, the number of hours worked, the number of hours remaining, and any deviations from the plan.

Hey there, Check out our cloud infrastructure for Selenium automation testing to run your browser automation testing scripts.

Sharpen the Saw

Productive testers recognize the need to improve their abilities and are eager to learn new methodologies, best practices, and strategies. They are insatiably curious and devour any testing book they can access. They learn how to simplify their duties by automating test scenarios and using best practices that save QA time and improve product quality. They keep connected to the testing community by visiting testing forums. They also understand when to have a good time. They refresh their batteries by enjoying wonderful trips and engaging in extracurricular hobbies and activities.

Making the Switch to Agile Testing

DavidTz40 — Thu, 02 Feb 2023 06:17:59 +0000

Sometimes test teams may be perplexed about how to switch to agile. If you work on such a team, you almost certainly have manual regression tests, both because you’ve never had the time to automate them or because you test from the UI, and it does not make logical sense to automate them. You most likely have excellent exploratory testers that can uncover defects within complicated systems, but they do not automate their testing and require a finished product before they begin testing. You understand how to schedule testing for a release, but now everything must be completed within a two, three-or four-week iteration. How do you pull it off? How do you stay up with technological advancements?

This is a persistent challenge. In many businesses, developers believe they have moved to agile, but testers remain buried in manual testing and cannot “stay current” after each iteration. When I communicate to these professionals that they are only experiencing a portion of the benefits of their agile transformation, developers and testers say that the testers are too sluggish.

Perform browser automation testing on the most powerful cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

Done Means DONE!

The challenge is not because the testers are too slow, but because the team cannot own “done,” and until the team owns “done” and contributes to accomplishing it, the testers will look too sluggish. In every iteration, agile teams can deliver a functional product. They are not obligated to release, but the software is expected to be of sufficient quality. That indicates the testing, which is about risk management, is over. After all, how can you release if you don’t know the risks?

Testing provides knowledge about the product being tested. The tests do not establish that the product is perfect or that the engineers are excellent or bad, but instead that the product either does or does not accomplish what we expected to accomplish. This implies that the testing must be consistent with the product. If the product features a graphical user interface, the testing will have to use it at some point. However, there are several strategies for testing inside a system. The approach to test from within the GUI is to develop the tests as you go, so you don’t have to test from beginning to end and still get relevant information on the product under test.

If programmers just test at the unit level, they have no idea if a component is complete. If the testers cannot complete the testing from a system-level perspective, they do not know if a feature is functional. How, then, can you consider an iteration done if no one knows if a functionality is ready? You simply cannot. That is why having a collaborative definition of done is crucial. Is a story complete once the developers have tested it? Is a narrative complete once it has been integrated and built into an executable by the developers? What about the setup? How much testing does a feature require to determine whether or not it is complete?

There is no unique correct solution for every team. So, every team must evaluate its product, consumers, and challenges and reach a conclusion, “OK, we can say it’s done if: all of the code has been checked in, reviewed by someone, or written in pairs; all of the developer tests have been completed; and all of the system tests for this feature have been created and run under the GUI. Every few days, we’ll handle GUI-based checking, but we won’t test using the GUI.”

I’m not sure whether that’s an acceptable definition of done for your business. It would help if you considered the consequences of not doing periodic GUI testing on your product. Perhaps you don’t have a graphical user interface for your product, but you do have a database. Do the developer tests require database access? Perhaps, perhaps not. Does the testing process require access permission? I’d assume so, but maybe you have a product I’m not familiar with, and maybe they don’t really have to all the time. Perhaps additional automated tests that test db updates or migrations before anything else are required. “Done” is determined by your product and its risks. Consider the consequences of launching a product without various types of testing, and then you’ll understand what you require in an iteration to achieve a release-ready product.

Run your test scripts on the fastest test execution platform online. With LambdaTest you can cut down your test execution time significantly. Perform browser test automation on the most powerful cloud infrastructure.

Give a Mouse a Cookie

Once you’ve determined what you anticipate in an iteration, you’ll most likely require testing. Then you’ll run into the “Give a Mouse a Cookie” scenario. In a charming child’s book that bears the same name, if you give a mouse a cookie, he wants a glass of milk to go with it. Then he’ll need a rag to wipe the milk from his lips and a broom to sweep the crumbs off the ground. The need for more and more continues until the mouse becomes exhausted and desires another cookie, which restarts the cycle.

This is what emerges when a testing team seeks the “ultimate” test framework for their product. It’s an understandable desire. Unfortunately, you don’t always know what the ideal structure is until the project is finished. If you wait until the product is finished, testing will be included towards the end of the project, which is too little, too late.

Rather than building a flawless test framework, consider creating a just-good-enough test framework, for the time being, to refactor it as you go. This gives the testing team enough automation to get started, as well as growing familiarity with the automation as the iteration and project progress. It does not bind you to a framework that no longer serves you because you have invested so much money and time in designing it.

Bear in mind that testers are similar to consumers. Just as your product’s consumers can’t necessarily tell what they want or need until they see it, testers can’t always tell what test automation framework they desire or require until they begin using it.

“Done” is the result of a collaborative effort

What does the test squad “sustain” with development when you need to comprehend what “done” means and you construct a just-good-enough framework for testing? By ensuring that the whole team works on a story until it is finished.

Assume you have a story that calls for two programmers and one tester. The feature is created collaboratively by the developers. Simultaneously, the tester reshapes the tests, adds sufficient automation, or integrates the test into the current automation framework. But what if you’re shifting to agile and don’t have a framework? Then, one (or even more) of the programmers collaborates with the tester to build a suitable framework and integrate the tests for this functionality into it.
No law says programmers cannot assist testers in establishing test frameworks, writing test frameworks, or even writing tests to facilitate the completion of a story. Given that you have a team definition of “done,” doesn’t it make sense for team members to assist one another in getting things done?

Do you use a Mac and want to run the test in Internet Explorer? This article explores how to test Internet Explorer for Mac.

Closing

Once you understand what “done” means for a story and the entire team is committed to completing it, you can build a culture where the testing process can convert to agile. The cross-functional project team may move to agile as long as the programmers help with testing frameworks, the business analysts help with narrative refinement, and the testers help deliver data on the product under test.

Switching to an agile methodology involves the entire project team, not just the programmers. If you have testers that can’t “catch pace,” it’s not the responsibility of the testers. It is a problem for the whole team. You need to resolve the issue with the team, change their mindset let them see the benefit of going in this direction. Even if you start with mediocre test frameworks, you can modify them into something spectacular over time, it’s up to you.

Impediments in Scrum Project Management

DavidTz40 — Wed, 01 Feb 2023 06:23:52 +0000

You have selected your new Scrum Masters, and they are ready to do their job as one of the key stakeholders in your Scrum teams. The project starts, and everything is looking great. The Scrum events are happening, the team is working as a single unit, and the velocity is increasing, so we can conclude the team is performing at the highest level.

Then, the impediments start to appear without warning, and they don’t allow the team to keep the same performance as before. We should have a closer look at impediments.

Impediment Definition and Meaning

Before reviewing different impediments that may arise during a Scrum project, we first need to understand what an impediment is? The Cambridge dictionary describes the formal definition of “impediment” as “something that makes progress, movement, or achieving something difficult or impossible.”

In addition, if we want to see how it relates to the Scrum environment, we can add, “An impediment in Scrum is a factor that blocks the Development Team in its creation of valuable software in a sprint, or that restricts the team in achieving its intrinsic level of progress.” [Scrum: A Pocket Guide]

Here are some common questions and answers about impediments:

Q1: Can the team start a sprint with impediments?
Answer:
Yes, as long as there are no critical impediments entirely blocking their ability to work and deliver their commitments.

Q2: What should the team do if there are many impediments during the sprint?
Answer:
The team should keep working on those stories not directly impacted by the impediments. In addition, they must communicate it to their Scrum master/ Team leader to initiate a mitigation plan. To their Product Owner, they must be informed of any changes in the team’s ability to meet the sprint goal.

Q3: Who should be the owner of an impediment?
Answer:
A common answer is that it’s the SM’s responsibility to take ownership of them. This doesn’t seem right, and the SM is only responsible for summarizing, tracking, and ensuring the relevant impediments are removed. S/he can do this by using other stakeholders or doing it directly. A more accurate answer is that the SM, together with the team, must collaborate to mitigate the impediments by identifying suitable stakeholder/s who can take ownership and remove the impediment as quickly as possible.

Q4: Can an impediment stop the sprint?
Answer:
In rare cases, yes. For example, one of the team’s sprints mostly requires working with an external supplier. After the sprint starts, it becomes apparent that the supplier is not available for the team, preventing them from proceeding with work on these stories. This effectively blocks the sprint as the team can no longer meet the sprint goal.

Q5: Who is responsible for determining the prioritization for executing the mitigation plan for impediment removal?

Answer:
This prioritization process is mostly based on the team. Based on the team inputs, the Product Owner will prioritize the activities required to implement the mitigation plan. Below are factors that should be taken into consideration as part of the prioritization process:

The risks of both removing and not removing the impediment.
Effect on the sprint goal.
Impact on team motivation.
Impact on velocity.
Impact on the product and its quality.
Impact on the project timelines.

Need a great solution for cross browser testing on Safari? Forget about emulators or simulators — use real online browsers. Try LambdaTest to test on safari browser.

Common impediments in Scrum projects

In Scrum, impediments can come from different areas and in all shapes and sizes. It is thus imperative for the team to have the relevant knowledge and experience to recognize them before they become unmanaged problem/s.

Let us review some of the most common impediments that arise in almost any project:

The use of unstable builds

During the sprint, the build is corrupted. This prevents the team from progressing. Once this happens, the SM must speak with the CI team to ensure they dedicate the relevant resources to solve the problem as soon as possible.

Impediments related to the Scrum implementation process itself

Sometimes the team starts working with either a partially completed Scrum implementation or a misinterpretation of the Scrum Framework. The following are common impediments I have witnessed relating to this:

Lack of management support for the new process.
Lack of understanding of the Scrum roles and events that impact the team’s ability to perform optimally.
The scale of Scum is not defined, leading to major pitfalls related to integration between teams.
Some managers still use old techniques that prevent their teams from adopting the Agile mindset fully.

Blockers for a user story

User stories are planned and committed before the start of the sprint. Problems may occur during the sprint. Blocked stories can be a result of either external or internal factors, or both, for example:

Crucial bugs are holding back the full delivery.
Stories committed are not defined properly.
Dependency on a third party tool that has not been delivered on time.

Lack of technical knowledge

The team often needs to deliver stories without the experience or technical knowledge to handle them. The SM’s responsibility is to ensure that the team closes any knowledge gaps. A few examples:

Provide technical training for the team in areas where they do not have the necessary knowledge.
Add another member to the team who can provide the necessary knowledge and experience to handle similar stories.
Ensure an expert attends the planning meeting to share her knowledge with the team.

The bad apple in the basket

In some cases, the biggest impediment is one of the team members. This person thinks he knows everything. He believes Scrum is a waste of time, and therefore he is not willing to commit to the process. Such a team member may directly affect other team members and should be quickly dealt with.

The working environment prevents the team from performing optimally

The physical working environment should allow the team to perform at the highest level. The SM’s responsibility is to ensure the team has a suitable physical working location to maximize their performance.

Techniques Available to the Team to Remove Impediments

Creating a fast mitigation plan for impediments holding back the team is crucial in the Scrum environment. Below are some of the common techniques used by my teams to solve various impediments:

Keep an active approach.

Let us take the daily Scrum meeting, for example. Commonly, during these meetings, impediments will be raised as part of the team discussions. Therefore, I encourage Scrum Masters to be proactive and find impediments before the meeting. Remember: The SM is part of the team and should see impediments without the need for the team to report them every 24 hours explicitly.

Understanding the complete picture before creating a mitigation plan
Before creating a mitigation plan, it is important to understand the full impact of the identified implementation; below is a list of questions to use to achieve this:

How does it affect the product?
How does the impediment affect the teams’ progress?
How urgent is it that we solve it now?
Is it a blocker to releasing the product?
What are the risks and complexity in solving the impediment?
Is the impediment just a symptom of a bigger problem?
Does the impediment represent a real problem?

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

Impediments as an advantage for improvement

For me, this is what differentiates a great Scrum Master from a mediocre one; a great SM can take impediments and use them as an advantage for educating and promoting the Scrum process, Agile mindset, and team knowledge.

Give the tools instead of a quick solution.

The Scrum Master should provide the team with the necessary tools to handle the same future impediments without waiting for him/her. This will enable team members to resolve their problems and reduce the bottlenecks through the sprint.

Mitigate the root cause

This is like any other RCA process where the investigator should not resolve the symptoms but instead strive to find the root cause. If the root cause is not resolved, it will most likely result in the reoccurrence of the impediment.

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

Session-Based Test Management (SBTM) in Agile Development

DavidTz40 — Tue, 31 Jan 2023 08:00:32 +0000

Exploratory testing is one of the most effective and powerful methods of testing. It combines activities such as test design, execution, and documentation; it focuses on learning the application under test.

Furthermore, exploratory testing involves a lot of thinking and hence is incredibly beneficial for the person who is undertaking it. As a result, whoever uses this testing method must employ various thinking processes, including conscious, logical, and documentation; it focuses on learning the application under test.

We can say that testers are knowingly or unknowingly using it in their daily testing activities. One of the widespread methodologies for this testing approach is session-based exploratory testing (SBTM). This methodology is based on the idea of creating test missions focused on a particular goal, exploring it without interruption for a specific period, recording the results, and following up with a debriefing session.

An SBTM session can last from 60 to 120 minutes but there is no real rule on the time spent for testing, it all depends on the goal that the tester wants to achieve in a particular session and its complexity. After the session is completed, each session is debriefed and shared to allow relevant stakeholders to understand the session results, provide feedback, and provide the tester with ideas on how to improve in future sessions.

Here is a formal introduction to this testing approach and how to use it in your daily testing activities.

From Wikipedia:

Session-based testing is a software test method that aims to combine accountability and exploratory testing to provide rapid defect discovery, creative on-the-fly test design, management control, and metrics reporting. The method can also be used in conjunction with Scenario testing. Session-based testing was developed in 2000 by Jonathan and James Bach.

Here’s an amazing free online tool- QR Code Generator that helps you create random QR codes easily.

How to run an SBTM session?

There are different ways you can explore and use, but if I rely on my personal experience I can say that I had a lot of success when pairing two testers or tester and developer who run the session together where each one runs the same scenario on different environments and they then discuss observations/insights at the end of the session.

If you want to stick with the usual SBTM session, you can follow this structure:

Create time-boxed session (60–120 minutes)
Set the goal to guide the session.
Create the scenarios you want to execute.
Debrief the observations.
Discuss observations with the relevant committee.
Log defects based on the discussion.

In addition to the steps above, I also recommended creating a session report containing the information that will be shared during the debriefing session. This doc should include basic information such as session goal, test environments, and resources used, but also the main observations and issues uncovered during the session. Recording this information will allow everyone to understand why we are running this session, the time it takes, and what are the main findings.

A typical session report may include the following:

Link to feature/user story
Date and time started
Mission statement and goal.
Testers/developer names.
Task breakdown
Test environments
Test scenarios.
Potential defects found.
Test notes.

HTML to Markdown Converter makes it easier to save and distribute Markdown code.

How does SBTM fit in Agile Projects?

Given the flexibility SBTM provides, we can use it for both small and large Agile projects. The team can start using SBTM on each user story to get a fair understanding of the requirements and functionalities of the product. At the end of these sessions, the team can start writing high-level test cases based on the observations and issues they generated. The same approach can also fit large complex Agile projects with small adaptions.

If you want to add SBTM into your Agile software development process, then you could follow the below approach:

For each user story, brainstorm the acceptance criteria, and identify business flows to test (Manual and Automated).
For those scenarios, determine the risk and impact associated with the story.
Once we have identified the risks and business flows, it is time to create the technical test flows that will be used as input to the SBTM process.
Once an exploratory testing session is complete, all the documentation generated from the session can be attached to the specific story letting the team know the details about the session, including the defects and issues uncovered.

A PX to REM converter is a tool that converts pixel (px) values to root em (rem) values.

Why Automate Tests In An Agile Environment?

DavidTz40 — Tue, 31 Jan 2023 07:34:22 +0000

Agile teams will fail if they don’t use frameworks to automate different aspects of the development, such as tests, builds, test environments, etc. To understand why a lack of automation causes failure, we first need to know that the main focus of all agile teams is to successfully deliver real value to the customer, which can be translated into providing working software at the end of the sprint (in other words, short releases in a fast-changing environment).

An agile team should test their deliverables often, quickly, and with excellent coverage to achieve this goal. This article will review some of the most common reasons agile teams have to accomplish this important goal and the challenges they face.

There are multiple reasons why agile teams will want to automate their tests besides the knowledge that everyone else is doing it, including the following:

Manual testing takes too long.

This is the most fundamental reason for an agile team to automate their tests. Manual testing and long regressions take too long to complete in an environment that does not provide the same testing time as traditional software development methodologies (the waterfall model).

As an application gets more extensive and more complex over time, the test matrix grows longer and longer, and the team will not have time during the sprint to manually complete the regression tests needed to guarantee they meet the highest quality standards.

Running a full regression suite during a sprint is an incorrect practice in an agile environment. You cannot do it with manual execution. If your current methods do not contain any automation coverage, don’t let that stop you from starting now.

Free online tool for encrypting your personal data. RIPEMD-128 hash calculator is a cryptographic hash function that produces a 128-bit hash value.

Manual testing leads to technical debt.

If you execute your regression testing manually, you already know that it takes a considerable amount of time that you do not have. In addition, it is common practice for agile teams to run regressions every day, every iteration (which does not make any sense to do manually).

If your regression tests are executed manually, it will not allow the team to keep pace with coding. Then programmers have to free up their time to help with the testing, which leads to technical debt and increases frustration among the team.

Automation techniques improve team knowledge.

Automation can allow the team to understand the product architecture better. Using advanced techniques such as Test-Driven Development (TDD), where code tests are written before the actual code, allows programmers to understand the requirements, design, and architecture of the product.

Automated tests provide fast, early, and frequent feedback

If there is no change in the automated test script, we can expect it to pass until the application’s functionality is changed. When a programmer modifies the application code, he must maintain the automated tests to accommodate them.

If the programmer changed the automated script to support the code changes and automated tests still fail unexpectedly, the code modification might produce a regression bug. This is an excellent indicator of the efficiency of the automated test design.

Another thing we need to know is that when the team runs an automated suite of tests for all new and modified code that is checked in, this ensures that regression defects will be caught at an early stage. Bugs caught early are cheaper to fix and will not add significant risk in advanced phases of the development process.

What does it mean to receive quick feedback from automated tests? The main thing here is that once the defect is found early (in a matter of minutes to hours from the time that the programmer adds the code), the change is still fresh in the programmer’s mind and thus will be easier to troubleshoot than if it was found days later, during the manual testing process.

Free online tool to quickly calculate the checksum of a file or text. This free online tool allows you to calculate the CRC32B hash calculator simply.

Automation is a critical factor for continual stable builds

Due to the nature of agile development, it is very important that the team not spend their already limited time on unwanted problems such as partial or corrupted builds that will prevent the team from finishing their work.

Partial or corrupted builds are among the top time consumers during agile development. There is no way that the team will succeed in delivering their commitments without having an automated CI/CD system that will allow the team to have continual stable builds throughout the iteration.

Automation will help free up the team’s time.

The creation of test automation takes time, and of course, there is more time spent on maintenance. Still, once the team succeeds in creating the more significant portion of this system, it will reduce the time they used to spend on executing manual test scripts, running numerous repeatable tests, and endless manual regression cycles.

Now that the team has reliable automation that can replace the manual execution of regression cycles, the team will have the energy and time to focus on new test scenarios and learn more about the product and how it works, which increases the overall quality of the team deliverables.

Automated regression tests as a safety net

Knowing that the code has sufficient test coverage by automated regression tests gives the team significant confidence while modifying or adding new code. This confidence is high in the agile development process, where new code is checked in and tested daily.

Automated regression tests will provide the team with a safety net that will help them find unexpected defects caused by the newly added or modified code within a matter of minutes (for unit, component, and integration-level tests) or hours (if at a higher functional level, such as system or end-to-end tests).

Now, suppose the team fails to invest their time in building a solid automated suite of tests at all application levels (unit, component, integration, and system) to act as a safety net. In that case, the programmers will start to treat the testers themselves as safety nets, which will lead to “mini” waterfalls during the development process.

Teams with good coverage from automated regression tests can work in a more reliable environment that will allow them to write their code and add it to the main branch fearlessly because they don’t have to worry if the new code will break the build and what hidden defects may arise. The tests will tell them whether or not they broke anything within a short time frame.

A RIPEMD-256 hash generator is a tool that calculates the RIPEMD-256 hash value of a file or data that helps users encrypt their sensitive data.

Manual processes are more vulnerable to human error

Manual processes and manual testing are more susceptible to human error. That’s just a simple fact that we can explain by saying that manual testing is a repetitive process that gets very boring for a team member who needs to follow the same testing scripts repeatedly.

And when people get bored, mistakes are more likely to happen, obvious bugs are overlooked, testing scripts are not executed as they were the first time, and as we know, people will cut corners to complete work when facing tight deadlines.

The simple solution is to automate all tests that contribute to the team ROI from sprint to sprint. The direct result is the reduction of human error, risk mitigation, and creating a constant development process that will increase the team’s efficiency.

I mentioned the word consistency earlier, which is vital in the agile development process. The team achieves consistency once they reduce the manual processes and automate processes (testing included), reducing the possibility of human error because each process and test is done the same way repeatedly. Automated frameworks will not cut corners to achieve deadlines.