By Anand Sundaram, CEO of Applitools

I’m thrilled to share that I’ve joined Applitools as CEO.

For over a decade, I’ve admired this company for pioneering Visual AI and transforming how teams think about software quality. Applitools Eyes didn’t just make testing faster—it created an entirely new category that fundamentally changed how organizations approach quality at scale. Today, with the Applitools Intelligent Testing Platform and our Autonomous product evolving rapidly, we’re once again reshaping what’s possible.

Why I Joined Applitools

What drew me here is the rare combination of groundbreaking technology and exceptional people. Applitools has built a platform that sits at the heart of modern software delivery, helping teams validate quality at every stage—from design to deployment—and enabling them to ship with confidence.

We’re at another major inflection point. AI is transforming how software is built, tested, and delivered—at unprecedented speed and scale. Code is being generated faster than ever by both humans and machines, and quality can’t become the bottleneck. Applitools is uniquely positioned to help organizations navigate this transformation, delivering applications and services with speed, confidence, and uncompromising quality.

Looking Ahead

Over the next few weeks, I’ll be focused on listening and learning. I want to hear from our employees, customers, and partners—what excites you about Applitools, where you see opportunities, and what bold ideas we should explore together. Your insights will shape our path forward.

This is an incredible moment for Applitools. Together, we’ll build on our momentum, deepen our impact with customers, and define the future of AI-driven software quality.

Thank you to everyone who has already extended such a warm welcome. I’m honored to lead this team and excited about what we’ll accomplish together.

— Anand

Anand Sundaram

Chief Executive Officer, Applitools

Anand Sundaram is a seasoned product and technology executive with more than two decades of experience in software quality. He has held multiple senior leadership roles and founded three startups, including RSW Software, which was acquired by Teradyne and became the foundation of the Oracle Application Testing Suite. Read more.

The post A New Chapter for Applitools: CEO Anand Sundaram on Why He Joined appeared first on AI-Powered End-to-End Testing | Applitools.

Learn how to build an effective QA team that thrives in an environment where things change quickly.

Within a startup projects can be the highest priority one minute and then sidelined the next. As the QA Lead at a growing startup, recruiting testers was my number one priority in order to keep up with the pace of new projects and demands on my current testers. I’d been told a new project was top priority, so I’d just offered a role to a tester who I thought would be a great fit to hit the ground running on it. 

Luckily, I hired a person who was resilient and took the immediate pressure in stride, but putting so much pressure on them with such a high priority project and requiring them to learn the domain super quickly was not how I would onboard a tester in normal circumstances.

And then, three months of hard work later, the project was scrapped. In a startup, this happens sometimes. It’s never fun, but that doesn’t mean you and your QA team can’t learn from each stage of the experience.

Dealing with Changing Priorities, as a Domain Expert

Testers often gain considerable domain knowledge while navigating the application from the users perspective multiple times a day. However this can be difficult to sustain when the priorities are changing so frequently. During this project there were changes to designs, user journeys and business logic right up until the last minute.

How does a tester keep on top of all these changes while maintaining tests and finding bugs which are relevant and up-to-date with the latest requirements? Within this environment it can be hard to stay motivated and perform your role at the level you aspire to. As a manager in this situation, I made sure that the tester knew their work would not be compared to normal circumstances and I was aware that all the changing requirements would lead to delays. Dealing with these challenges requires a person with certain hardy attributes.

It’s All a Learning Experience

Tests or code you’ve written which are deprioritized can be disheartening, but looking at it as a learning opportunity can help deal with this. The tester involved saw opportunities to reuse some code they had written for future tests and also felt they could use the test data spreadsheet as a template for other pages of the site. I was really proud of how they dealt with changing priorities and saw opportunities to take learnings with them to future testing scenarios.

It’s Okay to Write Poor Quality Automated Tests

In this fast moving environment, where designs are likely to change and user journeys are not set in stone, it’s okay to write poor quality tests.

When writing code, you want it to be easy to understand, maintain and reuse. However in this environment that isn’t possible, so writing code that you know you will need to refactor later is absolutely fine. The automation tester often would request a code review with a long description explaining why he’d duplicated code or why he’d not moved a piece of logic to a separate function. I always approved their pull requests and suggested they leave a comment as a TODO for them to revisit once the designs and user journeys were more stable. Always reiterating that I’m not judging them for this approach. 

Get Comfortable with Tests Being Red

The tests were red, often. Seeing your tests fail less than 24 hours after you’ve created them can be quite a demoralising feeling. Especially when it’s due to the developer refactoring some part of the UI and forgetting to keep the test-id you needed for your tests. This can be very frustrating and make maintenance difficult.

In a fast moving environment, it’s okay for your tests to be red. The important thing is to keep adding tests as these will be your lifeline when you are getting ready for a release and you have a short amount of time available. These tests will be critical in the lead up to go live.

Dealing with Design Changes, as an Automation Tester

Designs are often not complete before you start development, particularly when working with overly optimistic deadlines. In this project, even the user experience (UX) research wasn’t complete at this stage. Meaning that the foundations of the frontend development process are not finalised. During this project, as mentioned previously, there were changes to designs on a regular basis. This impacts the automation tester quite significantly and can cause them to think they should wait until the frontend is stable. Often it is recommended to not automate when the frontend is changing frequently.

So what do you focus on in this scenario without becoming annoyed by all the wasted effort? Building the structure for the tests including visual, accessibility and performance. As the automation tester knew they couldn’t rely on elements or any specific locators, they focused on whole page visual snapshots, accessibility reports and page render performance metrics.

Visual Snapshots before Functional Checks

As the website was going to be changing on a daily basis, functional tests would be so brittle that we sought other alternatives.

Visual testing seemed like a great alternative as we could easily replace the base snapshots when the designs had stabilised. With this approach we weren’t targeting specific parts of the page or components, which is how I would usually use visual snapshots in order to ignore dynamic content. 

To combat this, within the content management system (CMS) we could create test pages with the same layout as the homepage, for example, to run our visual tests against the whole page. This way the content wouldn’t change on the page and we could make comparisons quickly across different resolutions. This saved us a lot of time and effort compared to functional tests.

Whole Page Accessibility Audits

As images were being swapped out, colour changes and font swaps were happening frequently, meaning developers forgetting about accessibility was a common occurrence.

The accessibility audits on the page allowed developers to get instant feedback on quick fixes they needed to make to ensure the accessibility wasn’t impacted with their most recent changes.

Page Render Performance as a Smoke Test

Marketing would frequently send over a new image, then a developer would update the image on the site, often skipping the optimization step.

Using Google Lighthouse as a smoke test, it was easy to identify images that hadn’t been optimised. Perhaps the image was the wrong size or wasn’t suitable for mobile. This meant we could quickly go back to marketing and ask them to provide a new image. Catching these performance issues as early as possible means you don’t have 100’s of images to optimise at the last minute before release.

Dealing with Projects Being Scrapped, as a Person

Days after the release, when the website was just released to the world, we got the news. Due to time pressures and changing designs right up until days before the site was made live, we didn’t deliver the highest quality website. There were bugs, the journey for the user was a bit clunky and the search results weren’t very accurate. None of this was down to the team that worked on the website, there were really some superstars and people worked weekends or late nights to deliver the website on time. However business stakeholders had decided to engage with an agency, with a view to outsource the website. 

This came as a real shock to the team and wasn’t quite the news everyone was expecting just days after working hard towards a common goal. All the tech debt and automated test coverage we left for post release was now put on hold. So how would you react when the domain knowledge you’ve acquired, code you’ve written and technology you’ve learnt overnight is not required anymore? It can be very disheartening to hear your project has been scrapped and the hard work you put in can seem like it was for nothing.

Lessons Learned, Delivering Rapidly and for Nothing

It’s not all doom and gloom. There are many lessons learned along the way which will help you develop as a resilient member of the team and also how to work in a rapidly changing environment, quite useful if you are working for a startup.

One of the most important lessons that I learned was to focus on what I could control, such as working with the automation tester to come up with solutions to the fast moving changes. I couldn’t control the deadline or the scope changes 2 days before going live. But I can give my advice as someone with experience in these situations before, of the risks late changes will cause.

Another positive to come out of this was the focus on visual, accessibility and performance in a holistic fashion. Usually I would focus on making my tests robust, target specific components and use this at the end of the project for regression purposes. However, now I have another use case for these testing types.

Testing in this setting is not ideal and requires some sacrifices in terms of quality. Leading QA on this project wasn’t an enjoyable experience, required careful management and one that I will not forget anytime soon. But I learned way more on this project than I would have learned if the project had gone smoothly.

The post How to Build a Successful QA Team in a Rapid Growth Startup appeared first on AI-Powered End-to-End Testing | Applitools.

You’ve decided that test automation is working or is going to work for you. That’s good; you’ve done your homework. Furthermore, you’ve decided that having a common or “base” automation team is your preferred organizational approach; you’ve decided this team will build and support the common automation infrastructure that will be shared across the teams in your organization or your company. Awesome!

How are you going to fund that team?

Unfortunately, money does not grow on trees and organizations have pre-defined budgets that are hard or impossible to amend. Additionally, Organization A is not generally interested in helping Organization B, unless helping is in line with meeting Organization A’s goals. This means that if Organization A has governance over the supposedly common automation infrastructure, that organization is only inclined to help Organization B as long as it also helps Organization A or, at least, doesn’t impede Organization A.

This all means that, in most cases, counting on organizations to work together for a common infrastructure “good” is not a tenable business strategy. That being the case, there are a few approaches to funding a common, or “base” automation team that are described below.

The Automation Tax

An Automation Tax is essentially what it sounds like; each year, each team or organization has a flat dollar amount or percentage of their budget allocated to fund the base automation team. In return for this funding, the funding team/organization gets unrestricted use of all code produced by the base team, including code, features, and fixes produced for other teams.

The easy math on this approach is quite attractive to many base team organizations. It’s also easy to “spread the wealth” in that large teams or organizations pay more than small ones do if the funding is a percentage of their budget. The logic here is that larger teams generally require more features and support in shared automation code than do smaller teams. The wealth is spread because all teams, large and small, gain access to features and fixes requested by other teams, regardless of the size of the requestor.

This approach can also make maintenance of the base code easier, at least from a funding standpoint. If the base team is funded a general amount from each user team, then care and feeding of the framework and stack base code is included in that amount. There is no need to scrimp and beg for “additional” funding to perform an upgrade of one of your automation tools or to port to the new version of the language or operating system that you use. It’s all built-in!

Unfortunately, this approach is not all fun and games. The accounting and reporting of work performed needs to be very detailed and will often be challenged by the user base. In addition to challenging the veracity of the reports, some common questions and challenges include:

• Team A and Team B both want the same feature added to the automation base; which team gets charged for it? It can be the case that each wants the other to pay for it. They will definitely want to see that only one of them paid for it and the base team didn’t charge twice for the work.
• Team C’s base team tax equates to approximately two people of effort based on the loaded labor rate. Team C wants to know which two people will be working on Team C’s work items. This may not be the best way to staff a base team.
• I’m the largest funder of the base team; why weren’t all of my requests completed prior to working on items for any other team?

Over time, the tax may need to be reduced because the year-over-year effort may reduce, leaving the base team with idle team members and dissatisfied “customers.”

Direct Funding

For the Direct Funding approach, each year, each team or organization decides what features and support they will need for the upcoming year, add that to their budget, and then fund the base automation team; the funders must also project when they will need each feature or bug fix. The base automation team is obliged to appropriately staff for both the workload and the expected timing of delivery.

From the users’ standpoint, this is an awesome way of funding. A user organization tells the base team what to develop, the base team negotiates the cost and the delivery date, then delivery happens. The priority of the work is pretty clear since each funding organization is paying for specified work by a specified date. If many features or fixes are required in the same timeframe, the staffing and, therefore, the cost to the funding organizations will be higher; this cost, however, is stated upfront during the funding or budgeting period so there are fewer surprises. If a user organization doesn’t like the required funding, they negotiate over the date or the content.

The downsides of this approach typically fall on the base team. The base team has to account for variable staffing based on the expected workload and expectation dates. If many projects are all to be performed in parallel, it can be necessary for the base team to ramp up or ramp down in the middle of a fiscal year; this can be problematic in some companies. Additionally, managing short-notice staffing ramps can necessitate working with an outside partner to provide contractor-based staffing; the base team leadership must work closely with this partner to project the ramp cadence, meaning the base team must have a lot of trust in the partner.

Usage Billing

In the Usage Billing approach, teams or organizations are charged on a person-by-person, period-by-period basis, be that period month-over-month, quarter-over-quarter, or other intervals. The attraction is that it’s pay-as-you-go: if person X doesn’t use it for that period, the organization isn’t charged for that person’s usage for that period.

On the surface, this sounds like an awesome arrangement, as did the Direct Funding approach. As we’ve learned, or are learning, however, nothing’s perfect.

This approach requires high bandwidth communication between the base automation team and the user teams; user teams need to make projections about their usage for the upcoming year and the base automation team needs to staff and prepare for that usage, but only up to the amount funded by projected usage. User organizations also need to project any “big” work items they need in the upcoming year; if the projects are sufficiently large, the “base” usage may not be sufficient. Like the Automation Tax Approach, the per-user, per-period bill may need to reduce as the base matures; it may also need to increase if there are anticipated “big ticket” base development items on the roadmap.

Another consideration is the definition of usage. Is usage simply, starting the tool’s UI? Or does a user need to actually run a test script? Depending on the organization or company, other definitions of usage could be applicable. A definition must be established that is realistic, tolerable to the user teams, and can generate enough funding to account for the effort needed by the base team.

Once a usage definition is established, how should that usage be tracked? There needs to be a way of recording a “use,” which can be challenging in some situations. Is the tool expected to be usable when a user is offline, e.g. on an airplane or in a non-connected area? If so how should that usage be “recorded” so that it can then be reported once the user is again on a network? Must the tool work on a permanently disconnected network such as a testing-only LAN where connections outside that LAN or segment are blocked? If so, how will usage be reported? How should usages by a shared or “service” account, as is often configured for CI/CD pipelines, be recorded? Is that a single user?

This is the solution that is the most sensitive to the technological context in that teams and organizations that use the tool the most, pay the most for its upkeep and evolution. The theory is that the more users a team has, the more changes and support that will be requested by that team so that team should contribute funding at a higher level.

There are challenges in addition to the ones previously described. Some teams will view the per-user cost to be unfair based on the value they think they are receiving. Related to that point, is that it is hard to show fairness; a lot of transparency and reporting must be in place. Finally, it can be hard for the automation team to project staffing and handle staffing changes.

The Hybrid

It may be a stretch to call this a separate approach, per se. It’s really the combination of two of the above-described approaches. The hybrids I’ve seen most often used are “Automation Tax plus Direct Funding” and “Usage Billing plus Direct Funding”.

In both cases, the “Direct Funding” is used to develop features that teams specifically pay for. Many teams may want the same feature, but whichever team requests it first pays for it and ostensibly helps to influence its behavior. Regardless, all features become available to all user teams whether they paid for them or not.

The funds obtained from Usage Billing or Automation Tax, which is paid by all user teams, are used to fund the maintenance and upkeep of the automation base. This maintenance includes bug fixes. Naturally, the hybrid approach will have similar pros and cons as the two approaches that are selected for the hybrid; this combination, however, may be more palatable for some teams than just using a single approach.

Other Considerations

There are many considerations to unpack here. A subtle consideration, but possibly the most important one, is “should I even have a shared base automation team?” By creating a base, shared, or core automation team you are committing to having automation as a core competency for your organization and company. I’m not stating that to deter anyone from this approach; in fact, most “sufficiently large” companies and organizations can benefit from considering test automation as a shared service at some level due to the economies of scale. This is a great approach so long as the cost (as defined by an organization or company) is smaller than the value provided by having a base automation team.

Another consideration is the delineation between what is built by a base automation team and what is built by the user teams. Often any features or fixes that would benefit multiple teams would fall to the base team; this also required good communication with user teams on what they are building, if it would be interesting to other teams, and how to build it in a more generic, i.e. applicable to multiple teams, manner.

We can even blend any of the approaches above with an “internal open-source” concept. For internal open-source, those automation user teams that have the appropriate skill sets can add features to the common automation code. The base automation team would be the stewards of the shared code to help ensure code added by other teams is appropriate for sharing.

Certainly, there are additional pros and cons to any of these approaches based on team experiences or the contexts in which those teams are currently working.  These explanations are meant to serve as a guide so that you can make your own decisions about creating and funding a base team in your specific contexts.

The post Funding a Common Test Automation Team appeared first on AI-Powered End-to-End Testing | Applitools.

Learn why unit testing isn’t only for developers, the importance of unit testing to software testers and quality engineers, and how you can improve your skills by building better unit tests.

The responsibility for product quality frequently falls on software testers. Yet, software testers are often divorced or even excluded from conversations around the cheapest and easiest way to inject quality into the product and the entire software development lifecycle, right from the beginning: unit testing. In this article, we’ll explore why it’s important for software testers to be able to speak clearly about unit tests and how this can help deliver better quality.

Why Unit Tests Are Important

Unit tests form the solid base of the testing pyramid. They are the cheapest kinds of tests to run, and can be run frequently throughout the deployment pipeline. Unit tests allow us to find errors the soonest, and to fix them before they bubble up in other, more expensive kinds of testing like functional or UI tests, which take much longer to complete and run than unit tests.

Unit Testing Frameworks

Most developers know how to write unit tests in the language in which they develop, and most languages have several libraries to choose from, depending on the type and complexity of testing. For example, Python has pytest, pyunit, unittest(inspired by Java’s JUnit), Nose2, and hypothesis (for property tests, a non-example based type of unit test). These are just some of the choices available, and every language has a number of possible unit testing frameworks to choose from.

You don’t need to know everything about a unit testing library, or even how to write unit tests, to get value from understanding the basics of the unit testing framework. A lot of value can be gained from knowing what framework is being used, and what kinds of assertions can be made within the framework. Also, does the framework support table tests or property-style tests? Understanding what is supported can help you better understand what aspects of your test design might be best handled in the unit-testing phase. 

Unit Testing Is the Developers Job

Yes, developers typically write unit tests. However, they are largely responsible for writing these tests to ensure that the code works – most developer tests are likely to cover happy-path and obvious negative cases. They may not think to write tests for edge or corner cases, as they are working to meet deadlines for code delivery. This is where software testers with unit test knowledge can help to make the unit tests more robust, and perhaps decrease testing that might otherwise be done at integration or functional levels.

The first step, if you are unfamiliar with the code, is to request a walkthrough of the unit tests. Understanding what developers have done and what they are testing will help you to make recommendations about what other tests might be included. Remember, adding tests here is the cheapest and fastest place to do it, especially if there are tests you want run quickly on every code change that a developer makes. 

If you are familiar with the codebase and version control systems, then you can also look for the unit tests in the code. These are often stored in a test directory, and typically named so it is easy to identify what is being tested. Quality teams can be coached to review unit tests, and compare those with their test plans. Once coached, teams can make recommendations to developers to improve unit tests and make test suites more robust. Some team members may even expand their skills by adding tests and making pull requests/merge requests for unit tests. There are many ways to participate in making unit tests more effective, involving writing no code or writing a lot of code; it’s up to you to decide what most benefits you and your team. 

But What if There Are No Unit Tests?

If you are responsible for software quality and you discover that your team or company is not doing unit testing, this can be both painful, but also a great opportunity for growth. The first step in having the conversations around developing unit tests can revolve around the efficiency, efficacy, and speed of unit tests. The next step is building awareness and fluency about quality and testing as a part of development, which is a difficult task to tackle alone, and it may not work without buy-in from key people. However, if you can get understanding and buy-in on the importance of building testing and testability into the product starting with unit-tests as the foundation, further discussions about code quality can be opened up.

Better Quality is the Goal

At the end of every day, every member of the team should be responsible for quality. However, that responsibility rests with different people in different organizations, and often with the person who has the word “quality” in their title is the person who is ultimately held responsible in the end. If you are responsible for quality, understanding the basics of how unit tests work in your code base will help you to have better discussions with developers about how to improve software quality in the fastest, cheapest way possible – directly from the code.

The post Why Should Software Testers Understand Unit Testing? appeared first on AI-Powered End-to-End Testing | Applitools.

Over the past several years, we’ve heard a lot about “shift-left” and “shift-right” testing. We’ve seen the benefits of having testing specialists involved in testing-related activities on both sides of the “DevOps loop.” Inspired by Dan Ashby’s Continuous Testing graphic, Janet Gregory and I came up with our own visualization of a continuous testing loop (figure 1). 

Testing activities happen throughout the infinite cycle of software development. Many testers now find it natural to test feature ideas during feature planning discussions. More and more teams guide development with business- and technology-facing tests, using practices like test-driven development and behavior-driven development. And, more teams embrace the idea of working together – including testers – on testing activities that happen on the right side of the loop.

The whole team approach to quality is at the heart of DevOps. We don’t throw release candidate artifacts over the wall to an operations team. We work together with SREs (site reliability engineers) and platform engineers to take care of our production environment and help prevent customer pain. Many testing specialists hesitate to get involved on the Ops side of DevOps. They aren’t familiar with the tools used for monitoring, alerting and observability. They may never have worked with operations specialists. And who wants to get paged in the middle of the night?!

I was fortunate to work with system administrators doing operations activities for much of my career. I enjoyed configuring continuous integration, and learning how to automate deployments to test environments. I discovered the value of learning how our product works by examining log data. As platforms progressed to virtual machines and then to the cloud, infrastructure as code became a thing, and new technology enabled gathering and analyzing huge amounts of data about our systems, I got both more interested and intimidated! What really caught my attention was the advent of observability. Capturing enough events so that we can ask questions about our production system that we didn’t anticipate having to ask makes so much sense to me. We testers are great at asking questions!

As a testing specialist, how can you get involved with DevOps? How can you learn the skills, how can you add value with the skills you already have? Here are a few tips that have helped me. 

Build Relationships 

When I first read Katrina Clokie’s excellent book, A Practical Guide to Testing in DevOps, I was struck by how much of the book she devotes to the importance of building bridges not only within your team but to other teams in the company. Collaboration is the secret sauce. I’ve worked to get over my shyness to reach out to people who can help me as well as my team. 

Here’s a recent example. I started a new job this year and found that people on other teams were quite willing to schedule regular 1:1 meetings with me. I took advantage! This paid off right away. We needed to migrate the deployment pipeline for one of our products to a new infrastructure. I had just learned about this new infrastructure from one of the platform team managers in our 1:1. I scheduled another meeting with him to ask about the potential risks and learn where we should focus our testing. This helped me put together an effective test strategy. I worked with a developer teammate and an SRE (aka platform engineer) embedded in our team to do the testing and we confidently completed the migration.

As part of this first project, I joined a weekly “DevOps refinement” meeting with developers from my team, our embedded SRE and others involved with platform infrastructure. The monitoring and alerting tools used by our organization were all new to me. Getting to know the people who could help me learn about them was a huge help since we are  starting to implement some observability in our product. This is a huge area of interest for me, and building these relationships has given me a step up in learning about it. Which leads me to…

Offer to Help

If you hear of a DevOps-related initiative such as a migration to a new infrastructure, or creating dashboards to monitor a new feature, put your hand up to help! On my current team, we now write user stories to create monitoring and observability dashboards as well as alerts so that we can watch new features in production. If the data looks bad, we can turn the feature flag off while we investigate. I make sure to get involved with those stories, so I can learn the tools we use for that work. 

Accepting help seems obvious, but it could escape your radar, so be on the alert for it. A platform engineer specializing in one of our tools used to have a weekly “office hour” to help people learn it but I never seemed to make time for that. Everyone else did the same, so he quit offering it. Recently, he mentioned that he’d be happy to have a weekly session with a couple people on my team to build dashboards that would give us observability into some crucial parts of our product. Well, heck, yes! I scheduled 30 minutes with him, our embedded SRE, and one of my developer teammates, to meet weekly. When we need more time, we schedule it. 

Help Establish a Practice

DevOps and observability are still new to most software organizations. If you are a testing practitioner, you may think, “I don’t know much about that even though I am interested, and I cannot help build those practices across that organization.” If you think that, you may be wrong. Small nudges can have big impacts.

At an earlier job, our quality organization was under the same leadership as monitoring and observability, and I had an opportunity to help build an observability practice. It was a much larger engineering organization than I was used to, with about 40 teams. This was at the start of the pandemic, so it was all remote. I started researching what was happening on teams across the organization that related to monitoring and observability. I put my findings on a big mind map, and then I met with individuals on different teams to go over the mind map. Two good things happened – they expressed surprise at learning what other teams were doing, and, and I learned what their team was doing as they explained it to me.

I wondered what could I do with that information? I started a page on our engineering organization wiki with a table of what all the teams were doing related to observability. I captured who was leading the effort, what tools were they using, and what were their results. Some teams did proof of concepts with OpenTelemetry and Honeycomb. Other teams were working in ElasticSearch and Kibana. Still others were using Snowflake. 

I also started a Slack channel dedicated to observability practices, and socialized the wiki page. Individuals on different teams took the initiative to update the wiki page with their observability-related activities. The teams started talking to each other. A teammate and I started holding observability practice sessions where people could share their experiences. When other teams wanted to try to build in observability, they had access to people with experience who could help them get started.

Is it a tester’s job to start a community of practice around DevOps activities? Well, why not? Ask questions, build relationships, bring the right people together – these are our tester super-powers. We need those relationships because we know we cannot test everything prior to release. We know that in these days of complex systems in the cloud, our test environments will not look like production. We know that we cannot know what our customers will do – unless we start looking at the production use data. 

We testers have work to do on both sides of that DevOps loop. By engaging in the entire development cycle, we can help to delight our customers. 

The post Getting Involved with DevOps as a Testing Specialist appeared first on AI-Powered End-to-End Testing | Applitools.

In this social world, it is very easy to get biased into believing that some practice is the best practice, or some automation tool or framework is “the best.” When anyone makes the statement – “this <some_practice> is a best practice”, or “this tool <name_of_tool> or framework <name_of_framework>” is the best, there are 2 things that come to mind:

1. The person is promoting the practice / tool / framework as a “silver bullet” – something that will solve all problems, magically.

2. The said practice / tool / framework actually worked best for them, in the context of the team adopting it

So when I hear anyone saying – “best ….” I get suspicious and think which category do they belong to – “silver bullet,” or knowledgeable folks who have done their study and determined what is working well for them.

Doing the study is extremely important to determine what is good or bad. In the context of Test Automation, there are a lot of parameters that need to be considered before you reach a decision about what tool or framework is going to become “the best tool / framework” for you. I classify these parameters as negotiables and non-negotiables.

I had the privilege of delivering the opening keynote at the recent Future of Testing event focused on Test Automation Frameworks on September 30th 2021. My topic was “The best test automation framework is …”. I spoke about the context, and the non-negotiable and negotiable criteria required to make any test automation framework the “best.”

How to Choose the Best Test Automation Framework…

Understanding the Context

Here are the questions to answer to determine the context:

Negotiable and Non-Negotiable Criteria

Once you understand the context, then apply that information to determine your non-negotiable and negotiable criteria.

Start Evaluating

Now that you understand all the different parameters, here are the steps to get started.

You can see the full mind map I used in my keynote presentation below.

You can also download the PDF version of this mind map from here.

Catch the Keynote Video

To hear more about how to choose the best test automation framework, you can watch the whole video from my keynote presentation here, or by clicking below.

The post The Best Test Automation Framework Is… appeared first on AI-Powered End-to-End Testing | Applitools.

Communicating about quality is the job of quality leaders, in formal or informal roles. The degree to which you will be heard as a quality leader depends on both what and how you communicate. It can be tempting to show off the depth of your quality experience and knowledge during these opportunities to communicate with business leaders or managers in the company. However, you are most likely to be heard if you can communicate impact that can be readily understood based on quantitative measures of the business impact of quality risks, including lost sales, increased support calls, or increased costs fixing problems that cannot be spent on new development.

All of those business impacts can be understood and communicated as quality risks. This article will tell you how to talk about quality risks to uphold product quality and exercise quality leadership in your organization, using the language of business stakeholders for maximum efficacy.

What Is a Risk in the Context of the Desired Business Outcome?

Investopedia defines business risk as “the exposure a company has to factor(s) that lower its profits or lead it to fail.”  Software leaders face a number of business risks that cause high levels of concern and drive strategy decisions that impact the day to day. What are the key risks that your leadership team feels the business faces? In order to get traction on the quality risks you encounter, you need to understand what your company perceives as their biggest risks, and relate your quality concerns to these risk areas.

Finding and Communicating the Most Impactful Risks

Once you have an understanding of the key risks that face your business, you can gather more context around the costs of risks becoming reality. You can gather data from past risks that have become reality by looking through customer complaints in the form of support tickets, customer reviews, or other evidence of impact. Then, you can learn more about the cost of the impact by speaking with support people on the amount of time they spent on tickets related to a certain problem. How much does a support person cost, and how many support people does it take to mitigate and resolve failures that did not need to happen in the first place?

Then there is the impact on sales. Sales teams keep data on the reasons a sale did not go through, or was not as robust as they expected. Reaching out to sales teams to see if major failures had a sales impact is another source of data to understand the kinds of risks that have impacted business performance.

Finally, there are developer costs of major failures. These costs include time to diagnose, contain, understand, and fix the failure in the moment, and then all efforts and re-work needed to remedy against the same or similar failure happening in the future. Using these methods and others, you can begin to determine the business costs of software quality problems.

Using Risk Learning to Determine What’s Most Important

Understanding the way that failures and risk impact the business, and knowing what risks the business is most concerned about, can help you understand what risks you will have the most ease in raising successfully. You can use a basic risk matrix to prioritize all the risks you see, based on the probability of failure, and the impact of the failure on the business. You can assign high levels of complexity and iterate on this basic formula; there are many software solutions that allow for this. However, to start prioritizing risks and level-set for internal conversations, I have found the basic formula quite effective.

Here is the basic formula for calculating a basic risk score:

total risk = probability of failure x impact of failure

The scale I have used for each level when I have used the basic formula:

A google search about calculating risk scores yields several variations on this formula, which may give you ideas about what will work best in your organization.

How Much Should I Communicate?

As quality professionals, it’s really tempting to communicate all the risks, because we understand how each presents a suboptimal user experience. Yet, brain science research has shown that people can only hold three to four things in their conscious mind at the same time. To make the most of our time with business leaders, we must focus on the top three or four risks to the project. This means communicating clearly and succinctly about the most critical risks and using face-to-face conversation time to advocate for why those risks need to be addressed. Other risks should be recorded and acknowledged in a ticketing system, work plan, or other documentation, but should not be enumerated during face-to-face time.

To communicate in a memorable way, find the most impactful customer stories connected to the cost that failures have caused the business. Research shows that storytelling is a key way to move people, and finding ways to combine quantitative cost data with stories can reinforce the need to address critical quality risk.

Finally, put together your findings in a report or communication that is short and to the point. Most people don’t pay attention beyond 2 or 3 slides or one page of a report; they want the bite-sized version of the problem, along with potential solutions that fit into the needs of the business. Clear, concise presentations will help provide the visual material to support your cost facts and customer stories.

Advocating for quality is an art and a skill. Prioritizing and communicating quality risks based on past business failures, costs, and current business concerns can help you to tell the right stories to make sure that major quality issues don’t slip through the cracks.

The post Quality Leadership: Risk Analysis as Quality Advocacy appeared first on AI-Powered End-to-End Testing | Applitools.

There are many lenses through which we can consider leadership challenges in an organization. Two possible lenses are the roles that formal and informal leaders can play.

Formal leadership consists of roles that are given, assigned, or part of someone’s daily duties or job description. Informal leadership consists of making an impact through behavior or influence, without the formal title typically associated with such activities. In this article, we’ll explore the ways to use informal leadership to increase your influence in an organization. 

How to become an informal leader

Develop relationships across the entire company

Relationships build trust, and trust is the founding component when exercising informal influence. When you take the time to develop relationships with your peers, then you have more opportunities to provide constructive feedback, work together on projects, and gain the role of the trusted advisor in an informal capacity.

Qualitative or motivational interviewing

The act of building relationships and trust is strengthened when you take a deep interest in the people you work with, particularly cross-team peers. I have successfully used qualitative interviewing strategies when starting a new job to learn more about cross-team relationships.

Keys of conducting a great qualitative interview:

• Ask your key question or questions, and using active listening, generate your follow-up questions through the conversation. 
• Listen for layers: how is someone framing the problem? For example, are they using words with a positive connotation (fascinated) or a negative connotation (frustrated)? Use the tone of the person you are speaking with to learn more about them, how they may be feeling, and to elucidate more information from your cross-team peers.
• What is someone NOT saying? Since I read her work in 2009, I’ve frequently referred to Dr. Lisa Mazzei’s work about what we can and must learn from silence. The very basic interpretation of her work is that we need to give silence as much value as the words spoken by those we speak to. To more fully understand the people you are talking to, attend to their silence as much as their words. 

Solve problems with cross-functional teams – give to get what you want

As you continue to develop relationships with cross functional teams, you will have opportunities to exercise informal leadership and influence. Doing this means that you need to know how to listen to other people’s concerns, and effectively communicate your own needs and concerns, to reach the best possible outcome for the team. 

An approach I find very helpful comes from Dialectical Behavioral Therapy (DBT). DBT, developed by Marsha Linehan, is a complex, skills-based form of therapy requiring participants to commit to multiple weekly sessions, classes, homework, group and individual sessions, over the course of many years. I have participated in this type of therapy. From this, I’ve continued to use two skills in my professional and personal life to communicate my needs, hear the needs of others, and maintain the health of my relationships: DEAR MAN and GIVE FAST. I’ll briefly describe each below, and provide links to resources for these essential communication skills.

The DEAR MAN skill is especially useful if you are not normally an assertive communicator. It provides a useful framework for everyone to have difficult conversations, be heard, and negotiate outcomes, without succumbing to overwhelming emotions that may negatively impact our immediate goals or future relationships. I have used these techniques successfully in communicating with bosses, peers, and direct reports over the past nine years of my career in software.

The GIVE FAST set of skills is useful if you find that you have difficulty listening to others when you feel upset, or if you find that you often say yes when you really mean no. Learning to listen to others and acknowledge their view while at the same time maintaining your boundaries is a key to feeling good about whatever outcomes you reach in a given communication.

Both of these skills are easy to understand, but difficult to master. Fortunately, all they require is practice to become a mindful, masterful communicator who can solve problems with leaders, peers, and direct reports.

Regularly share knowledge that helps to solve problems

In my career, I’ve encountered people who hoard knowledge, and people who share knowledge. As you can imagine, companies that have more knowledge sharers are more successful than companies where employees hoard knowledge. 

If you work in a knowledge-sharing company, then take opportunities to become involved in sharing your knowledge. Whether it’s a simple update to the wiki when you notice something wrong, or operationalizing as-yet undocumented policies and procedures to create more efficiency, you are modeling important knowledge-sharing behavior.

If you work in a knowledge-hoarding culture, you have a tougher hill to climb. However, you can be the change you want to see. Sometimes, it starts with making a decision to create a learning culture within your organization, and provide time, space, and opportunity for knowledge sharing to occur. 

Not only will your learning culture and company benefit, but as this Harvard Business Review Study showed in 2014, people who hide knowledge are “17% less likely to thrive at work” than their knowledge-sharing peers. Getting ahead and gaining influence means sharing knowledge and creating positive environments for others to do so.

Show up with a solution or solutions in mind

Everyone can complain about problems in an organization, but it takes a leader to show up with solutions to problems. Getting buy-in for your solution can be even harder.
Yet, it is important to be solution-oriented when you are faced with a problem. Typically, people in an organization have a general understanding of organizational problems. What they want and need are ideas to help solve the problem – evidence that you have thought about more than yourself and your own context. This is especially true when you are working to extend your informal leadership and influence across a broad part of your company or business.

When you face a problem, begin to think about the problem in the broader context. Ask what you can do, what you cannot do, and what could be done to help solve the problem or a portion of the problem that faces you.

If you have used the methods in this blog to create the trust-based relationships needed to establish widespread buy-in for your ideas, then you are much more likely to obtain buy-in from multiple stakeholders so that your solution ideas are raised for discussion, readily defended, and more easily accepted when presented in a broader context. 

Become the Informal Leader You’re Meant to Be

Informal leaders are necessary in every organization. Many of the best people I have hired or worked with know how to exercise informal leadership, working across boundaries and leveraging relationships, communication skills, and solution-based orientation to achieve solutions that are widely adopted and accepted across multiple teams. Using the steps and skills in this article, you too can become an informal leader. 

Keep Reading

Looking to learn more about QA leadership roles and how they fit into your career path? Check out our blog post: Are You Ready for the Leap to QA Leadership?

The post Quality Leadership: Influence through Informal Leadership appeared first on AI-Powered End-to-End Testing | Applitools.

Over the past few years I have had many questions from QA/Testing professionals asking about the ideal career path within the QA field. Most of them even question the existence of a career path within the QA or Test engineering space altogether, with a handful of them seeing no future beyond a senior role. 

Those who do see the QA field as a long term career ‘home’ often have further questions around transitioning into a management or leadership role. I can go off on a tangent regarding the differences between leadership and management but let’s leave that for another post. In this blog post I will address the QA Engineering space as a career path and the key aspects around transitioning into a QA leadership role.

There is an ongoing, raging debate in the tech industry around naming conventions of QA or Test Engineers. I will not go down that path in this article, but for simplicity’s sake I will use the term QA Engineers as an all encompassing term to include both QA/Test Engineers. So let’s get on with the topic shall we?

The Dilemma

I have seen QA Engineers go through what I call ‘mid-career crisis’. It’s not directly synonymous with a mid-life crisis, however there are some glaring symptoms which pop up across those who face it. Some of those include questions or thoughts like:

• Is there a future for me in the QA space?
• I’m just using QA and Testing as a stepping stone to something else within the tech world
• Testing is great, but where to from here?
• I will never be a VP of Engineering or even move to a CTO or C-Level
• Is growth in a test automation path enough to move me to a lead or manager role?

Whether you have asked yourself these questions or have had similar thoughts, you have come to the right place.

Although different companies have their QA roles set up slightly differently, more often than not QA Engineers find difficulty in plotting exactly where they stand on an industry level. This is another shortcoming I have observed in the tech industry regarding the QA space, that the standards across different companies and institutions often vary massively. I have seen mid level QA Engineers being classified as QA leads in some companies or even those who play a QA lead role being classified as mid level QA Engineers at other companies. Hopefully this dilemma can be solved in the future in order to create a proper global standard around QA or even tech levels in general.

Moving from Individual Contributor to Leadership

So you have completed a good few years within the QA space. You may have tried your hand at exploratory testing and automated testing. You’ve even tried changing industries such as moving from finance to telecoms to retails and everything in between.

But deep down you feel there is a greater calling, you start questioning your ‘why’ and realise you would like to aspire towards leadership or management. For some, the move away from being an individual contributor can seem daunting as firstly it removes you from your comfort zone, and secondly it requires some key added responsibilities which often needs a greater degree of time management, accountability and possibly a multi-team or cross-company participation. 

Depending on your company structure or career aspirations you might feel strongly about focusing on just the technical aspects of testing like automation or architecture and are not too concerned about the process or overall test management view, or you could very easily feel that you have a knack to cover both aspects. Regardless of your choice, if you are to make the jump into leadership there are some traits, skills and behaviours that you should possess or even seek to obtain to make the transition easier.

Zooming into QA Leadership

Experience

When addressing the topic of using experience to move into a leadership role, I often refer back to this quote: 

“Good judgment comes from experience, and experience comes from bad judgment.” ~Rita Mae Brown 

Racking up the years gives one first hand experiences within different contexts which prepares them for challenges that might occur in future. It allows you to build your own internal knowledge base around a host of different topics, situations and even how to deal with different people. Naturally this doesn’t come for free, sometimes you have to be brave enough to put yourself into those different situations as part of your learning as stepping stones towards leadership

Detailed but also have a strategic view

Moving into leadership requires your team to trust you, one way of building trust is for your team to have the confidence in your ability to understand the detail of their work, its limitations and its possibilities. 

At the same time, seniors and managers of leaders need to trust your view on seeing the bigger picture and having that strategic view. Think about a practical example: as a QA leader, your senior management sets a broader goal of increasing customer satisfaction, but also increasing team efficiency. As a QA leader, you would need to translate this goal into all areas within your control or circle of influence, so if you take test automation, firstly your team needs to trust that you understand the intricacies of the framework, how tests are structured etc. The lower down in its implementation you go, the more trust and confidence your team has in your ability to solve test automation challenges and/or contribute to its effectiveness. So you find ways and means of using test automation effectively in your given context to drive quality checks and enhancements that both ultimately drive customer satisfaction and enhance team efficiency. The better your ability to balance a detailed view with a strategic one the better the ability to make this transition into leadership more smoother.

Fortune favors the brave

Being brave and courageous within a leadership context spans many areas, however the ultimate point here is that when you move into more of a leadership role you have to be braver compared to when being in an individual contributor role. 

Sometimes saying things as it is or saying things that nobody else wants to say (even though everyone knows it) goes a long way in building this capability. 

A few examples come to mind like:

• Being more vocal in daily standups or meetings regarding certain challenges or blockages from the dev or architectural side
• Putting forward suggestions around testing or even agile practices that benefits the team as a whole
• Taking charge in driving certain initiatives which usually spans beyond the QA or testing role. 

There are many more examples of other areas you can focus on in your context.

The power of influence

Influence is a really important factor within any leadership transition. If you think about why this quality is key, think about a role that a leader has to play within a QA context. Together with your experience and the many ideas that you have cultivated over the years, you would like to implement these to the greater good of your team, department or organization. More often than not, it’s not something that one can do alone, so naturally you have to firstly get you team on board by influencing them positively as to why it’s important for the idea to be implemented, to make them see what’s in it for them, what the long term benefits are and so on. 

The other angle is not only to influence laterally or downwards but also upwards. Influencing upward could be to now use that same idea and influence the relevant stakeholders or even management on the pros (and cons) of the idea implementation, can numbers or metrics be used to show gains from the idea etc. Understanding your audience is key in developing your influential powers.

Resilience

As much as we would all like to avoid it, tough times are inevitable. Building a resilient mindset is a crucial factor in successfully conquering this. How you react in tough times and your ability to recover from setbacks or difficult situations helps drive this quality to a stronger place. 

The QA and Testing discipline usually requires one to anticipate certain risks, problems/issues within a project or functional area, so in a way the QA’s mindset is usually already prepared to soften the blow of any unfortunate eventuality by mitigating risks or identifying problems areas upfront. 

If you zoom up to a more strategic view, moving into a QA leadership role could see you apply similar techniques from a departmental or organization view around reacting to certain setbacks or difficult, tight situations. Digging down deep and knowing that others now look up to you to steer the ship means you have to ride the wave to get to the other side safely.

Other notable mentions

As you might have gathered there is no single formula to successful transition into leadership as there are also so many other ingredients into making a seamless switch. Some other key factors that I have not mentioned above include communication skills, motivating others, respect, integrity and so much more that can be added to the leadership mix to strengthen your all round abilities. 

Go ahead, Make the transition

You could also think about adding some practical steps to better prepare you to make the transition, some of which I have mentioned above already in addition these could be some other steps or actions to consider to better prepare you to make the transition.

• Take on multiple projects, either within your company, externally, or pair with someone externally to find out how things work in their context. This can broaden your horizons and expand your thought process when tackling day to day tasks.

• Exposure to different industries, tech, teams once again allows you to have a birds-eye view across the industry to make sure all options are considered in solving problems.

• Build internal or external community presence. Whether this be physically, via social media, chat groups or any other medium that is available in this vast world, use these options to your advantage to gain as much presence as possible to learn and share. 

• And finally, focus on personal areas of improvements, consider your own blind spots including learning and building leadership skills.

The post Are You Ready for the Leap to QA Leadership? appeared first on AI-Powered End-to-End Testing | Applitools.