Let’s talk about automated testing tools. Are they valuable? While some people seem to think of them as a mere accessory, that couldn’t be further from the truth.

An old teacher of mine used to say that one year in the IT world was actually worth ten years—such was the pace of innovation and progress. After graduating and becoming a software developer, I could see for myself that he was right. To remain competitive in such a fast-evolving landscape, companies around the world must make use of automation, which includes having a sound automated testing strategy in place.

And to design, implement, and maintain said strategy, you’ve got to have the right tools in your toolbelt. Sure, tools aren’t everything. Like in any field, mastering the fundamentals is always going to be vital. As soon as you get the basics out of the way, though, finding and employing the best tools available becomes imperative. And that’s what this post is all about: helping you on the “finding the best tools” part.

By the end of this post, you should have a mature understanding of the current automated testing tools scene. You’ll then be able to make an educated decision about which tool or tools are the best fit for your needs. Let’s get started!

The 6 Automated Testing Tools You Should Know About

We’re now covering six automated testing tools that you need to be aware of. Keep in mind that our list is going to be a little bit different than other lists you see on similar named posts around the web.

Other posts about automated testing tools tend to focus almost exclusively on UI testing tools. This list, on the other hand, presents more variety. We’ll cover tools that fall into several different categories of automated testing—unit testing, acceptance testing, and yes, UI testing.

When you’re done with this article, you should have a good understanding of the available offerings out there to help you with each step of your automated testing strategy.

The xUnit Family of Unit Test Frameworks

Back in 1999, Kent Beck released a unit test framework for Smalltalk. It was called SmalltalkUnit (or simply SUnit), and its architecture inspired an array of frameworks for unit testing on a variety of languages and platforms.

After SUnit, the first framework to appear was JUnit, which was a port of SUnit to the Java language. Since then, many others followed. For instance:

  • NUnit, for the .NET platform
  • PHPUnit, for the PHP language
  • PyUnit, for Python

Unit testing is one of the most basic types of automated tests, so a xUnit test framework is a tool that deserves a place in your toolbox.

PIT Mutation Testing

PIT is a mutation testing framework for Java. That’s as straightforward a definition as it can get. But the definition is useless if you don’t know what “mutation testing” means.

Mutation testing is the process of deliberately adding defects to your codes. Those faults are called “mutations.” After the framework introduces a mutation, it runs your unit tests. If they fail, we say the mutation was killed. Otherwise, the mutation survived.

The “mutations killed/mutations survived” ratio you get is a reliable indicator of the quality of your unit tests suite. Think about it. If all of your tests still pass after you damaged a portion of the production code, that can only mean one of two things—either your current tests are wrong, or there aren’t enough tests.

You could do all of this by hand, sure. But it would be a prolonged, tedious, and error-prone process.


Cucumber is an interesting item on our list since it wasn’t designed to be an automation testing tool from the start. Instead, Cucumber helps teams—including non-technical people—write specifications and use cases for software features, in a clear, unambiguous way.

Cucumber allows teams to write software using the BDD (behavior driven development) approach, by allowing technical and non-technical members of the team to describe software use cases using a common language.

After you create one or more scenarios for the feature you wish to document, Cucumber allows you to generate automated tests from them. You can do that using test automation libraries that your language already supports. In Java, for instance, you could use JUnit.

Keep in mind that the tests you end up with by employing Cucumber are not unit tests. These are higher-level tests—or so-called “executable specifications.” They describe the way each software feature is meant to behave, from the user’s perspective. Such tests verify a functionality from the UI through the database, passing through every layer.

Unit tests, on the other hand, verify that a single unit works in complete isolation. It gives the developer confidence that their code does what they think it does. But it doesn’t check how the units integrate, or how the different layers work in harmony to fulfill the user’s needs.

In other words, Cucumber doesn’t compete with xUnit style framework; rather, it complements them.


Selenium is another interesting case in that it is not, per se, an automated testing tool. Instead, it’s a browser automation tool. With it, you can automate interactions with a web browser. What you do with this capability is up to you.

In practice, what most people use Selenium for is indeed testing. By using the tool, they automate interactions with their web applications, effectively creating automated tests for their web UIs.

Selenium—without the aid of Selenium IDE—isn’t a standalone tool. It’s more like an API, against which you can program—using your favorite language or platform—to create the browser automation that you need.


Serenity is a Java framework that operates with BDD tools (e.g., Cucumber) while acting as a wrapper on top of Selenium WebDriver.This tool makes it easier to write BDD-style tests and even Selenium tests. It frees you from writing a lot of boilerplate code and it also comes with useful built-in features, allowing you to take screenshots, easily integrating with Jira, parallelizing tests, and much more.

With Serenity, you can create highly detailed reports. The tool can create documentation that you can use both as test results and documentation for your app.


Finally, take a look at Testim.

Testim offers a straightforward recording function, allowing non-developers to easily create UI tests. It also enables testers toreport a bug and automatically generate a test that reproduces it. As already covered on this blog, similar tools in the past tended to result in fragile tests. Testim is different since its greatest asset is artificial intelligence.

It uses AI to improve the authoring and execution of tests. How does it do that? It analyzes the DOM objects of the page under test, extracting them along with their properties.

Then, based on this analysis, the AI figures out the optimum strategy to locate a given element. What that implies is as simple as it is powerful—even when a developer changes some attribute of the element, the test still works.

This “dynamic locator” approach is the primary advantage of using Testim compared to other frameworks— authoring and executing tests becomes way faster and stable.

Automated Testing Tools in All Shapes and Sizes: Know Them so You Can Master Them

It took us long enough but we—as in the software industry—are now finally employing automation to improve our own work, at all phases of the process. One of the manifestations of this trend is the modern automated testing movement. For a modern software development shop, having a mature automated testing strategy is no longer a luxury. It’s essential.

And a vital step in order to create such a strategy is to know and master the available tools. Today’s post helped you become aware of some of the tools at your disposal. You can also take a look at our five-step process to learn how to identify the best automation platform for your needs.

The tools we’ve covered today fall into many different categories of automated testing, and this is by design.

You now have a high-level view of not only the tools available but also the types of automated testing they support. The next step is to zoom-in and to learn more about the tools and test style that your repertoire is lacking, in order to improve it even more.

Author bio: This post was written by Carlos Schults. Carlos is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.

In today’s advancing and fast-paced world, high-speed implementation is a must. This applies to all products and services. Let’s suppose you were using an application and got stuck because of a bug. After reporting the bug, you, of course, expect the team to fix it as soon as possible. If not, your next move is going to be switching to another service.

Customers want quick fixes and faster updates. For that, most software companies are adopting focused and flexible software testing. If you keep the customers waiting, remember, the competitors are just a few clicks away! 

Saving time and resources and streamlining the entire software development lifecycle is important. That’s why most companies are opting for testing on an agile team. Let’s dig a little deeper to understand what this means. 

In this post, I’m going to explain how shifting from a traditional testing environment to an agile one makes a difference in your project’s budget, resource utilization, and time duration. You will learn about scrum testing, what challenges testers face in an agile environment, and how it’s worthwhile in the end. Consequently, you will gain insights into boosting your enterprise production and customer satisfaction.

What Is Scrum?

Scrum is a framework in which teams resolve complex situations while simultaneously delivering products. The quality of the product delivered has to be high even when the issue is complex. When a problem is complicated, it requires an efficient team collaboration. Scrum is lightweight and easy to understand. But it might be a little tough to master. Unlike popular opinion, scrum isn’t a method. It’s a framework. 

A scrum team comprises of the following:

  • The owner of the product
  • Scrum Master
  • A team of developers and testers

The entire concept of scrum rests on ensuring greater flexibility and creativity and optimizing productivity. The teams are cross-functional. This means that they don’t need to be dependent on other teams to accomplish tasks. Since the teams are self-organized, they don’t need direction from those outside the team. 

The Difference Between Agile and Scrum

Agile comprises of principles that guide through the iterative approach for software processes. But there are certain rules that testers have to follow in an agile environment. This set of rules is called scrum. Scrum is a part of an agile framework. Now, let’s take a look at both agile and scrum in detail for better understanding.


Agile management is a set of methodologies for software development. These methodologies are incremental and iterative. Agile management includes the rational unified process (RUP), extreme programming (XP), and scrum. Also, agile processes result in need and outcome evolution. This evolution in project development methodology is possible because of the collaboration between teams. 

Agile teams are cross-functional and self-organizing. The analysis, documentation, and development of a new project go hand in hand. Advancement occurs with every iteration. This approach offers ease of accommodation of changes. It also results in better scalability. The flexibility of operations and processes increases. 


Scrum is a subset of the agile environment. It’s a technique used to address complex issues and deliver high-quality products simultaneously. If an urgent change is required, the team has the flexibility to adjust. Effective collaboration and frequent communication ensure the success of scrum. Moreover, every sprint introduces better practices to increase efficiency. 

How Is Testing in Agile Different From Traditional Testing?

The Software Development Life Cycle (SDLC) needs a robust approach for quick implementations of ideas. Traditional testing was the mainstream, but efficiency increaseFs when an enterprise makes a shift from traditional to agile testing. Let’s look at how agile testing differs from traditional testing to benefit your organization.

Traditional Testing

Traditional testing aims to understand user needs and develop a product. After development, testers test the product and report bugs before deployment. The development team then works on them and fixes any errors using the best possible solution. Traditional testing works on the assumption that the processes are repetitive and predictable. 

The concept is that the team can get the processes in control during the SDLC. A hierarchy ensures stability at different levels. It standardizes procedures by allotting different tasks to people according to their skills. But while the traditional model seems clear, it lacks flexibility. The procedure is time-consuming as the team completes tasks in a fixed sequence. 

Agile Testing

Agile testing seeks to correct the rigidity rampant in traditional testing. It’s a team-based approach but, unlike traditional testing, it’s interactive and dynamic. As a result, a product’s delivery time shortens. The project is divided into time-boxed tasks called sprints. Every single sprint has a fixed duration. Here, we consider processes unpredictable. Also, the processes might seem a little difficult to comprehend at first. The reason is that the tasks don’t have a clear definition.

But the high level of adaptability and flexibility during the process makes it worthwhile. As soon as users request modifications, the agile testing process is quick to adjust to changes. The iterative cycles make changes according to consistent customer communication and feedback.

What Changes for a Tester With Scrum?

During scrum testing, the team has to test a product and see how it turned out from the customer’s point of view. Some of the main events a tester has to attend in an agile environment include:

  • Sprint-planning sessions 
  • Daily standup meetings
  • Sprint retrospectives 

Instead of leaving testing for the last stage, as they would in a traditional test environment, a tester has to carry it out throughout the process. Testers get to learn a lot of new things in addition to testing like development or business analysis. The work culture becomes different. Now, let’s take a look at some things a tester gains exposure to while working in scrum testing.

Clearer Grasp of Business Logic

Testers are exposed to in-depth knowledge of how domain applications work. They have to work closely with the development team. It enables them to create innovative and effective business case scenarios. The familiarity with architectural diagrams and development terminologies increases. Testers need to have crisp business logic so they can hold discussions with business analytics and developers about the application specifications. 

Adopt Automation for a Speedy Testing

Selenium, Appium, UFT, GitLab, Codeship, Jenkins, etc. are some of the tools testers need to get familiar with. To stay ahead in the industry, they have to welcome changes. Speedy testing requires automation. Even though there are some massive changes a tester has to face during automation, it’s a chance to sharpen their skills. Apart from that, automation reduces risks during regression testing.

Adopting services like Testim is a wise move. It offers automated functional testing using artificial intelligence. Additionally, it speeds up execution, authoring, and maintenance during automated tests.

Adhering to SDLC From the Start

In the waterfall model, testers used to stay behind before the testing begins. But in scrum testing, a tester must adhere to SDLC from the beginning of the process. The test windows broaden and collaboration improves with this approach. This way, testers also gain a deep insight into the procedure. So, no test phases are left out. 

Regular Standup Meetings

It’s mandatory for testers to attend regular standup meetings in an agile environment. These meetings last for 15-30 minutes—usually at the beginning of the day. This is when the manager or the scrum master asks every team member about what they did the day before. In addition to that, they also gather insights on the current day’s tasks and possible roadblocks. Having testers at daily standup meetings eliminates hurdles in the initial stages of a project. The entire team, including testers, remains aware of what is going on. It ensures progress in various tasks. 

What a Tester Needs to Know Before Moving to Agile Testing

For someone used to the waterfall model, adapting to the agile environment is a big change. Here are some things a tester needs to know before moving to agile testing. 

Knowledge in Automation Tools

Repetitive tests for each sprint are a waste of time. Testers need to pace up the regression testing. They also need to have knowledge of automation tools to speed up testing. These tools include Selenium WebDriver, HP UFT, and Appium. JUnit, Cucumber, Pytest, JBehave, etc. are some BDD testing and unit testing tools which is good to learn before moving into Agile testing.

Knowledge of Project Management Tools

There was a time when testers used HP Quality Center to track bugs and report them. Slack, JIRA, and Mantis are some of the versatile tools that serve more than one purpose. Besides identifying bugs, they aid in efficient collaboration and project management. 

What Does Testing Look Like in Scrum?

When I was learning about scrum, I was most surprised that the entire testing procedure is divided into four quadrants. Let’s take a look.

Quadrant 1

The first step is to check the quality of the code. The testers give immediate feedback. Then, based on the feedback, the developers carry on with their tasks. These tasks include unit testing and component architecture testing. The former refers to checking a coding unit to see if it fulfills the requirement, which is often done by the developers. The latter is to ensure that the pieces of code work when integrated.

Quadrant 2

Both the testers and developers get the requirement. Both carry out their respective tasks keeping business objectives in mind. That includes testing possible scenarios. Testers have to perform prototype and wireframe testing while keeping user experience in mind. 

Quadrant 3

Automation testing evaluates the product usage. Despite the product development being incomplete, tests are run. The scheduled demos ensure that development is going on according to business goals. These are the five stages the third quadrant covers:

  • Collaborative testing
  • User acceptance testing
  • Exploratory testing
  • Usability testing
  • Pairwise testing

Quadrant 4

Testers test performance, data migration, infrastructure, stress, and load. Other aspects include security to ensure authentication. The product should have preventive measures for hacking and attacks. Scalability is another factor testers keep in mind.

Strategizing Is the Key to Agile Testing

An impeccable strategy is a must to move from traditional testing to agile. There are four stages to this that keep things organized.

Iteration 0

This stage involves the completion of the initial setup work. Establishing a business case, analyzing requirements, and creating use cases are crucial steps. After estimating costs, the team prepares a preliminary project. 

Development Phase

Each sprint in this phase comprises agile practices. Developers verify unit testing and service integration testing. Also, the testers perform agile acceptance testing. The stakeholder testing team and project testing team together execute test cases. 

Product Deployment

The deployment of product into production comprises four steps. The first step is to train the end-users. Following that, creating data backups comes through. After marketing the release, the documentation of system documents and finalized user takes place. 

Production Support

Production support includes regular testing and reporting bugs. If there are any, the production support team fixes them. 

Challenges a Tester Might Face in Agile Testing

Since the methodologies are different in traditional and agile testing, there are many challenges testers have to face. These include: 

  • Sharp deadlines
  • Learning the development procedure and programming languages
  • Sudden changes requested from the stakeholder
  • Impeccable coordination between teams

However, these challenges are nothing when compared to the huge learning opportunity that agile testing offers. And trust me, once you start working in an agile environment, very soon you will be ready to take on all the challenges that come your way. The agile environment will help a lot in propelling your career as a tester.


Making a move from traditional to agile testing can be overwhelming for a tester at first. But once it settles down, a tester’s learning scope broadens. Consider the change as an opportunity for enhancing your skills and professional growth. Once you get the gist of it, nothing can stop you from progressing in the industry. 

Author bio: This post was written by Arnab Roy Chowdhury.Arnab is a UI developer by profession and a blogging enthusiast. He has strong expertise in the latest UI/UX trends, project methodologies, testing, and scripting.

Are you familiar with the term “test automation tool?” If you’re not, you’ve definitely come to the right place. Before I dive into why, I have a small confession to make: as a software developer, I have a strong dislike for the word “coder.”

I mean, sure, we write code in our jobs. But writing code is more a means to an end than the end itself. Instead of “someone who writes code for a living”, a better description of a software developer would be “someone who employs automation to solve problems as efficiently as possible.” I know, now you’re wondering what this seemingly random digression is all about, but it’s going to make sense soon.

Here’s the thing: developers have long ago figured out that, since their (our) jobs consist of automating all kinds of process, they could do the same to the software development processes itself. Why not automate your app’s build process? Why not go a step further and automate the whole packaging of the product? Heck, why not go even further than that and automate the deploy to final users?

Automate All That’s Automatable

The answer to all the questions above was an obvious “Let’s do it!”. Modern software development relies heavily on automation, on all fronts, from analyzing source code looking for mistakes to testing to the already mentioned build, packaging and deploy process. That’s the scenario where a test automation tool becomes relevant. But as this post title already asked, what is a test automation tool? In this post, we’ll answer the title question and more.

First, we’ll give you a broad definition of test automation. Then, we’ll proceed to define a test automation tool, explaining their use cases and how they fit into the whole test automation scenario, making the process easier. Finally, we’ll show you a few different options of test automation tools, equipping you to make an informed decision.

Let’s get started.

Defining Test Automation

We could easily define test automation as “the automation of test-related activities.” It’d be easy, quick and insufficient. Such a definition would be shallow unless we first define automation itself. And what’s automation?

We could define automation as the technique of performing tasks without human intervention. The justification for doing so is to achieve speed and efficiency levels that greatly surpass those of human beings. Also, in most cases, you’ll apply automation to tasks that are repetitive. As such, they can be extremely error-prone when performed by people.

Ok, that’s a passable definition of automation. In light of that definition, let’s now try to rephrase our first, insufficient definition of test automation:

Test automation is the process of performing software testing activities with little or no human interaction, in order to achieve greater speed and efficiency.

When putting a test automation strategy in place, it’s important for you to remember that usually, the automated part is the running of the tests. Before you’re able to execute your test cases, you first have to create them using some process. This might mean writing code. Or it might mean performing a task while using a window and recording it. Test automation is a broad topic. There is a wide range of techniques and—you’ve guessed it—tools at your disposal.

Speaking of tools, that’s exactly what we’re going to cover on the next section.

Defining Test Automation Tool

Since we’ve already defined both “automation” and then “test automation”, it doesn’t look like defining test automation tool is going to be a lot of trouble for us. Here it goes:

A test automation tool is a piece of software that enables people to define software testing tasks, that are afterwards run with as little human interaction as possible.

Again, it’s important to understand that there are a plethora of different types of test automation tools available. They might differ in the types of application they test (web, desktop, mobile), in the way the test cases are set up (by writing code using a scripting language, writing code in a full programming language, recording steps performed using a GUI) in their licenses (free, freemium, commercial) and many other factors.

Meet Some of the Test Automation Tools at Your Disposal

Now that we’re done defining stuff, it’s time for us to start showing you some of the test automation tools available for you. As we’ve said, there are many different types of tools. We’ll try to give you as broad a sample as possible, so you can experiment with the variety of tools available. Let’s get started.

Katalon Studio

Katalon Studio is a test automation tool that enables you to test your web and mobile apps, as well as APIs. This solution makes use of Selenium and Appium engines, offering users an integrated environment for testers to integrate different frameworks and tools.


UFT is a commercial tool that originally allowed its users to test desktop, web, and mobile apps. Currently, it also offers features for API testing.


Selenium is a very well-known tool when it comes to testing automation. It allows its users to write scripts in a lot of different languages, including Java, C#, Python, Perl, and Ruby. This tool also runs in several operating systems and browsers.

The disadvantage of this tool is that to use it effectively, you must spend a non-trivial amount of time building frameworks, libraries and other tools necessary for the actual automation you’re trying to accomplish.


TestComplete also enables Web, mobile, and desktop testing. It offers its users the choice between JavaScript, VBScript, Python, or C++Script to write scripts.

The tool features an object recognition engine that is able to accurately detect dynamic user interface elements, which makes it particularly useful to test apps whose user interfaces change very often.


Testim is a test automation tool that employs machine learning to help developers with the authoring, execution, and maintenance of automated tests. This tool allows developers to quickly create test cases and execute them on many web and mobile platforms. The tool learns from data with every execution.

Testim then uses all that learning to improve itself, making test cases more stable. The result of that is a robust test suite, that doesn’t break on every code change.

How to Pick the Right Test Automation Tool

As you can see, there are plenty of options for test automation tools for you to choose from. The tools you’ve just learned about are only but a few of the available tools at your disposal. So, how can you choose?

Giving a definitive, one-size-fits-all answer is hard. So what we’re doing instead is to suggest that you choose based on three main factors: target platform, learning curve, and pricing. The first factor should be easy to understand. If your product is a desktop application, then every automation tool that works only for mobile and web are automatically declassified.

The second factor you have to analyze is the learning curve. A given tool might be widely known and used, but if its learning curve is too steep, that might be a bad sign. How much of a problem is a steep learning curve? It depends on how quickly you want your team to be up and running. Maybe it makes sense for your team to take their time learning the tool because of its benefits. I wouldn’t bet on it, usually. But your mileage may vary.

Last, but not least, we have pricing. Again, it doesn’t matter how popular or sophisticated a tool is if its price is way beyond your team/department/division budget for tooling. Many of the tools presented are free or have a free tier, which allows you to at least try them before making a final decision.

So, based on these three factors—platform, learning curve, and pricing—you should be able to choose a tool that is right for your scenario. Weigh every candidate against the three factors and see how many points they score in each area.

That’s a Wrap

In today’s post, we started by defining a bunch of things. Namely: “automation”, “test automation” and finally “test automation tools”. After that, we proceeded to give you a quick overview of some of the test automation tools at your disposal. Finally, instead of giving you a generic, one-size-fits-all answer to the title question, we gave you an easy framework you can use to evaluate the available tools and find the best match for your reality.


We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. This month we’re thrilled to release a few of your most requested features; Extract Value Step enhancements, Validate Checkbox/Radio button, Failed Test Retries option in Scheduler. Check them out and let us know what you think. 

Extract Value Step Enhancements

What is it?

As part of the extract value step, you now have the ability to extract specific values from an element on the page using the new extract mode field. This allows to extract the entire string, just the numbers, date or use regular expressions.

NOTE:  You also have the flexibility to extract the first, last or all the numbers from the element on the page when using “Number” option.

Why should I care? 

There is no longer a need to add custom code to get the specific value from the element on the page.  For example – You can now use the “Number” option and extract just the price (numeric value) from the text “$1980.45”.

Validate Checkbox/Radio Button

What is it?

You now have a built in step to validate checkbox and radio buttons on the page.

Why should I care? 

You no longer need to add custom code to check whether a checkbox or radio button is checked.

Failed Test Retries Option (Scheduler)

What is it?

This is a follow up to the Failed Test Retry flag which was released earlier to be used as part of the CLI. When a value is set in this field (1-20), a failed test will be executed repeatedly until either the test passes or the max number of retries has been reached (in which case the test will finish execution with a failed status). 

Why should I care?

You now have the ability to use this option via scheduler as well; apart from just the CLI.

Maybe you’ve heard what test automation is but you’re unsure about how to fit it all together in practice. If that’s you, then you feel just like I did when I was first getting my head around how test automation works. So many conversations about testing quickly become abstract and sometimes we simply want to be practical—just show me the code!

If you feel the same way, then you’re in luck! Today we’re going to cover how automated tests work in detail. To do this, we’ll cover the test pyramid and how it relates to testing, which will set a foundation so we can go through and break down each category of testing—from unit tests to integration tests and finally to journey tests. And we did promise to keep things practical, so we’ll talk through some real-world code examples too.

By the end of this post, you should know what the test pyramid is and how it relates to automation testing. You will also learn in detail what unit, integration, and journey tests are and how they’re written.

What Are Automated Tests?

Before we begin, let’s start with a quick definition:

Automated tests perform machine-based assertions on an application to determine the state of the current application against the assertions.

In simple terms, we ask questions of our systems through testing, and the current state of the system (how it’s coded) informs our test results.

Don’t worry if it still feels abstract, as we’ll be breaking it down.

What Is the Test Pyramid?

Before we dive into our examples on each of our testing steps, let’s define them. A lot of the nuance of how automated tests should be written hinges on the theory around test pyramids, so it’s important to have a strong grasp before continuing.

At its heart, the testing pyramid is about feedback loops, and it forms a recommendation on how to structure your tests to achieve the fastest possible feedback loop.

But, what do I mean by feedback loop? I mean the time it takes from modifying some code until you know that it’s wrong (and, importantly, where it’s wrong). The notion of the pyramid is important as it represents how we should heavily load the bottom layer while keeping the top layer thin in order to retain our pyramid shape (more on balancing testing layers soon!).

Test pyramids can come in slightly different formats. For today, let’s use a simplified version, which breaks down into unit, integration, and journey tests.

Unit Tests

Unit tests are the base of our pyramid—they run fast and validate individual functions work as we expect. However, since we’re only testing at the function level, these tests don’t tell us whether our application works as a whole. But importantly, unit tests run blazingly fast. And when they fail, they tell us exactly what went wrong to the precision of a single function. So while unit tests don’t tell us if the application is broken as a user would deem it, they give us the fastest feedback possible.

Integration Tests

Integration tests form the middle of the testing pyramid. If unit tests together sum up to a single software component, then our integration tests ensure that each software component can work with another. Usually, integration tests run over a network boundary of some form. Integration tests essentially validate whether all the aforementioned functions are put together correctly and that other software components can successfully communicate with the component in question. Integration tests are less about what the functions do (that’s our unit tests), but more that our functions are put together correctly.

Journey Tests

These tests form the last layer and the top of our pyramid. Journey tests typically execute a journey as our user would see it. We don’t tend to cover edge cases in journey tests as they should be covered at base levels of the pyramid (either unit or integration).

And journey tests are merely a few, short tests that cover a lot of code. Because we’re writing so few of them and they cover so much code, they give us a lot of bang-for-your-buck for establishing if our application is working as expected since they are covering core journeys. But—frustratingly—they won’t really tell you what is broken (at least, not to the same degree that a unit test would). Additionally, journey tests can be very slow to run and brittle to maintain (but more on why this is later).

Putting the Pyramid Into Practice

Hopefully, by now you have a decent understanding of the test pyramid and how the layers fit together. Don’t worry if you don’t completely understand at this point. We’re going to break down each layer and show you how it works in practice.

Unit Tests: An Example

Unit tests run against individual pieces of code. So let’s take an example.

The following test is written using the Jest unit test library. Jest gives us the “test” and the “expect” function. With these tools, we can then describe the scenarios we want to run for our tests and also our expected output. Tests can have any number of assertions, but typically you’ll have only one (or a small amount). Keeping assertions small means we can fit them to our descriptions easier.

function isOdd(a) {

    if (typeof a != “number”) {

        throw new Error(“Must pass a number”);


    return a % 2 != 0


test(“Passing an odd number returns true”, () => {



test(“Passing an even number returns false”, () => {



test(“Passing a string throws error”, () => {

    expect(() => isOdd(“Hello”)).toThrow(“Must pass a number”);


Here we can see that we’ve written:

  • A happy path test
  • An unhappy path test
  • A dynamic type checking and error handling test

The test coverage is therefore 100 percent. However, we may want to write additional cases in the future for edge cases if we believe they add more value. For instance: what should the function do if we pass superfluous arguments? And what about edge cases? Negative numbers? Passing a zero value? Or passing a very large value? All of these are valid tests, but adding more tests has diminishing value over time. If we’re incredibly thorough with our testing at all levels, we likely won’t ship any code. It’s a balance. Choosing whether to add these additional cases will depend on factors such as: how much business impact would there be if the code were faulty? Are there other tests you could write that deliver more value?

Integration Tests: An Example

Building on top of our unit tests we have our integration tests. Below is an example of a test written with SuperTest. SuperTest is a small helper library around Jest (which we used for the unit test example). SuperTest gives us the request functionality (and its chained assertion methods).

The following code takes an endpoint, in our case “/user” makes a request to it, asserting the response to be a 200 success. SuperTest also allows us to simply test HTTP endpoints. Remember when we said integration tests often happen over a network boundary? This is precisely what we meant. We tell our test what our setup criteria are, and we can then assert that we received the correct response, error code, headers, etc.

describe(‘GET /user’, function() {

  it(‘responds with json’, function(done) {



      .set(‘Accept’, ‘application/json’)

      .expect(‘Content-Type’, /json/)

      .expect(200, done);



But you might be thinking: in the above example are we simply testing that the endpoint responds? Not that it has expected values?

At first, this may seem like a low-value test. However, since we have already covered a lot of the functional testing in our unit tests at the integration test level, we are really only testing that our application links up all of those functions and responds without errors. Of course, we can write more detailed scenarios, but we want to be careful that we’re not replicating unit test code in integration tests. Unit tests run faster, so we should ideally write our tests there when possible.

Journey Tests: An Example

Last up is the journey test. The following is an example of a journey test using the Cypress testing framework. Cypress gives us a test runner and an assertion library. The “describe”, “it”, and “cy” commands all come from the Cypress library.

describe(“When at checkout”, () => {

    it(“Can buy”, () => {






            .should(“have.text”, “Thanks for purchasing!”);



In our journey test, we are testing the physical interface of the application, which should not only include what the user sees, but also behave as a user would when conducting a task (we call this a journey). In our example, we are navigating to our route, finding a button by its class name, clicking it, and then asserting that we can see our summary.

Can you spot why we said these tests could be brittle? For instance, if a developer decides to change an element class name (which in theory might not break functionality!), this change may result in a test failure. Oh no! We can use clever ways of structuring our code to reduce the fragility of our tests, but we cannot remove the brittleness completely—it’s inherent in the nature of the journey test.

The End of Our Tour of Automated Testing

And that concludes our foray into automated testing today. I hope this post gave you a clearer picture of how automated testing works in practice. We’ve seen how we need to have a balanced pyramid and also some examples of how our pyramid could start to be implemented.

In the real world, automated testing requires constant collaboration communication and continual improvement of our codebase. As we find bugs in our code, we work to ensure our coverage is updated. But in updating our codebase we need to ensure we balance our pyramid to keep our feedback fast.

It’s not easy. But, do it right and automated testing yields incredible results that are far superior to their manual testing counterparts. Learn how to identify the best automation platform for your needs with our simple, five step process. 

And remember, the best way to learn is to get your hands dirty and have a go! So take the examples and attempt to implement your own small application with each layer of the test pyramid!

Author bio: This post was written by Lou Bichard. Lou is a JavaScript full stack engineer with a passion for culture, approach, and delivery. He believes the best products emerge from high performing teams and practices. Lou is a fan and advocate of old-school lean and systems thinking, XP, continuous delivery, and DevOps.

Over the past few years, our team has been working hard to improve the functionality and usability of our autonomous testing platform. This mindset is what made us successful in building a product that people love and trust. In 2019, we released many new features that help testers author and execute tests more efficiently.

In this webinar, we discussed how the AI works underneath the hood, what are some of the features that help in faster authoring, execution and maintenance of automated tests and finally, discussed the top features within Testim that were released this year.

Here is the recording of the webinar

Below are some useful links related to features discussed in this webinar

Some useful blog posts to quickly get to know Testim

“Automated testing” used to be a phrase that caused developers to scratch their heads. Now, it seems to me that most developers are at least familiar with the notion of automated testing. Fortunately, many devs go beyond familiarity. They turn theoretic notion into practical action by actually employing automated testing on a day-to-day basis. And nowadays there’s immense variety in the types of automated tests that can help you achieve higher software quality. In today’s post, I want to focus on a very specific type of automated testing—UI testing.

We’ll start by briefly defining what UI testing is, and then explain how it can benefit you. Then we’ll proceed to show you, step-by-step, how to get started with UI testing using Testim.

Let’s get started.

UI Testing: What It Is and Why Do You Need It

As you surely know, UI stands for “user interface.” So, defining UI testing doesn’t sound that hard, at first sight—it’s just exercising the application through its user interface. But, is that all there is to it?

Actually, it’s not. First of all, some people seem to think that UI testing isn’t necessary if you already have other types of testing in place, such as unit tests. That couldn’t be farther from the truth. UI testing is not a replacement for other types of testing—instead, it’s a compliment. Unit testing exercises the application’s units in isolation. It’s an important verification to have, but it’s not enough. It’s also important to verify how those units fit together. You have to check how the whole system behaves, from the UI, passing through each layer and then back. So, UI testing can be thought of as more of an “end-to-end” type of testing.

Other people might think that, while UI testing has some importance, you can have one or more developers just click around and see if the application behaves correctly. But that isn’t true. Manual UI testing might work for very small and simple applications. But when it comes to applications with complex business rules and rich user interfaces, manually testing quickly becomes insufficient. It is a tedious, error-prone, expensive, and hard-to-scale process.

At this point, automated UI testing is the best choice.

UI Testing Guide: How To Get Started

It’s time to get your hands dirty. We’re going to offer you a brief guide on how to get started with UI testing. It’ll by no means be an exhaustive tutorial, but it should teach you to create a basic approach upon which you can build and evolve into a more sophisticated approach later.

For this guide, we’re going to use Testim to test a very simple web app. Let’s get started.

An Example of Manual UI Testing

Before we start creating our tests, we need something to test, right? So, let’s create a toy application. It’s going to be a super simple web app, with just two controls—an input box and a button. It will allow the user to input numbers, separated by a comma. After clicking on the button, the application will add all the numbers and display the results. If the user types just one number, the result should be that number. If the input box is left empty, the result should be zero. Simple enough, right?

Creating a Toy Application

Ok, let’s get to it. This application will consist of a single HTML page with a little bit of Javascript. Nothing too fancy. Open up your favorite text editor, create a new file, and add the following content to it:

<!DOCTYPE html>



<title>String Calculator</title>

<style type=”text/css”>

label { display:block; margin: 10px;}




<h1>String Calculator</h1>

<form id=”form1″>

<label for=”numbers”>Numbers: <input type=”text” id=”numbers” name=”numbers”/></label>

<label for=”addButton”><input type=”submit” value=”Add” id=”addButton”/>


<script type=”text/javascript”>

document.getElementById(“addButton”).addEventListener(‘click’, function(){

    var text = document.getElementById(“numbers”).value.trim();

    if (!text) {

        text = ‘0’;


    var integers = text


        .map(x => parseInt(x));

    var result = integers.reduce(((a, b) => a + b), 0);






After that, save the file with the “.html” extension. Then, double-click the newly saved file. You should see your default browser showing you something like this:

Performing Manual UI Testing

Now let’s do some (manual) UI testing. Click on the input box, type 0 and click on the Add button. You should see this:

Now, redo the test, but leave the input box empty. The result should also be zero:

Repeat the test a few more times, always using a single number. The result should always be the number itself. Then, perform some tests with more than one number, separated by a comma. The result should be the sum of the numbers, as the following example shows:

After this brief session of manual UI testing, I’d be convinced that our little toy app works as intended. But, is that testing enough? For this example application, I’d say yeah, probably. But keep in mind that this silly string calculator is just a placeholder for a much more complex application, closer to the ones you’re likely working on in real life.

Getting Started With Testim

Now it’s time to show you how to get started with Testim so you can see what automated UI testing looks like.

First Steps: Creating an Account and Installing the Testim Browser Extension

First, go to and  click on “Start Trial.” You’ll be asked to sign up for an account. You can do that using your Google or GitHub account. If neither option is OK for you, sign up with an e-mail address and create a password.

After successfully logging in, you’ll see a screen like the following image:

If you click on “Create test” button, you’ll see a message asking you to install the Testim Chrome extension:

After downloading and installing the extension, you’ll be ready to start creating automated tests. This time, though, instead of testing our silly little string calculator, we’ll test a real one—the Google calculator.

Creating Your First Test With Testim

On Chrome, go to the address bar, type “calculator” and hit enter. You should see this:

Just a good old calculator. Now, we’re going to create a test for the “+” button.  While still on the same tab, click on the Testim extension’s icon, as shown in the following image:

After clicking on the extension icon, you should see the following menu:

Click on “CREATE AUTOMATED TEST.” That will open Testim and attach the current tab to it. Then, you’ll return to the calculator tab and see the following message:

What you have to do now is very simple—just use the application and your actions will be recorded. Let’s create a test for the “2 + 2” sum. Perform the sum as you would normally do it. After clicking on the “equals to” button, go back to the tab where Testim is open. You should now see this:

Click on the “SAVE” button. You’ll then see a window asking you for a name and a description for your test:

For the name, enter “Add test”. On “Description”, type “Verify the Add operation” Then click on “OK.” Congratulations, you’ve just created your first test with Testim!

Running Your Test

You’ve just created your first automated UI test using Testim. That’s nice, but how do you actually run the test?

On the left panel, click on the “Automate” button, like in the following image:

After doing so, you’ll see your test list which contains only the test you’ve just created:

To run the test, just mark its checkbox and click on the “play” button:

After clicking on the “Run Selected Tests” button, you’ll see a message warning you to avoid touching the mouse and the keyboard during the test execution:

After clicking on “OK”,  Testim will open up a new Chrome tab and run the test. Testim will execute the exact same steps you’ve recorded. After Testim finishes running the test, it’ll close the window.  Go back to the Testim tab and see the test result:

You’ve successfully run your first test using Testim. Congratulations! But…isn’t there something missing?

Adding a Verification

You’ve probably noticed that the test you’ve just created doesn’t really test anything. Yeah, the test passes but that doesn’t really mean much. In terms of unit testing, it’d be the same as having a test method with no assertions.

Our test lacks something, and that something is a verification. We need our test to check that the result of “2 + 2” is indeed four. How do we do that?

On the left panel, click on the “Automate” button. You’ll go back to the test listing. By clicking on the test name, you’ll reopen the test editor so you can change it:

You can see that the test has six steps, and the last step is clicking on the “=” sign. What we have to do now is add an extra step, whose goal is to perform the validation. To add a new step, click on the “+” button after the sixth step. You’ll see the following options:

Click on the third option and you’ll see the menu change to this:

Now, click on “Validate element text.” Testim will take you back to the calculator tab. There, click on the result field:

After doing that, go back to Testim. Now, you should see that your test has a new step:

Hover over the newly added step and click on the engine icon to show the properties panel:

Now it’s just a matter of editing the “Expected value” field, setting it to ‘4’. After doing that, click on the “SAVE” button again. You’ll see a box prompting you for a message, explaining your change. Type “Add validation step” and click on OK:

If you run the test again after saving it, it will continue to pass. However, Testim is now comparing the expected result to the actual result, just like a unit test assertion does.

UI Testing Goes Way Beyond “Clicking Around”

There are still some misconceptions about UI testing out there. One of them is that UI testing isn’t needed if you already employ different categories of testing. Another myth is the belief that informal manual UI testing—a.k.a. just clicking around—is enough.

Neither of those beliefs is true.

We hope this post has shown you not only that UI testing is indeed necessary, but also that it isn’t hard getting started with it, especially if you employ a tool like Testim.

Thanks for reading, and see you next time!

Author bio: This post was written by Carlos Schults. Carlos is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.

Quite often there is a need to validate the content of a downloaded document which could be a PDF, Word Document, CSV file or databases such as MySQL, MongoDB. All these are possible within Testim using the CLI action step. This feature helps to create and execute custom Node.js scripts at runtime; to perform different validations. Below are some tips to help with CLI action steps.

Tip 1: How to find out what node.js packages you can use?

The different node.js packages that can be used within Testim are the ones found in This is the official website that has references to all the open source node.js packages. Say for example, you are searching for a package related to pdf documents; just search for “pdf” and you will get a list of all the node.js packages available for pdf.

Tip 2:  What are the available CLI action steps within Testim?

Below are the available CLI action steps within Testim-

  • Add CLI action
  • Add CLI validation
  • Add CLI wait for
  • Validate download
  • Wait for download

Tip 3:  How to add node.js packages to Testim?

To add node.js packages to Testim, follow the below steps

  • Add one of the above mentioned CLI action steps
  • In the Properties Panel, click on PARAMS-> PACKAGE

Tip 4: How to execute CLI action steps locally?

To execute node.js scripts via CLI action steps locally, you need to first set up the runtime environment using the below command. Ensure this command is executed from the command line before running a test with a CLI action step.

npm i -g @testim/testim-cli && testim –agent

Putting everything together

Lets see how all the tips work together to execute node.js scripts. Say you want to validate the content of a downloaded document such as a PDF file. The steps to do this would be-

  • Ensure CLI Action feature is enabled (Contact our CSM or customer support for this)
  • Add the “Validate Download” action
  • Add the necessary node.js package for the pdf content validation. In this case, we are adding the latest version of the package pdf-parse
  • Then, add the necessary code to do the content validation

Here is a sample test to show how to do PDF content validation – PDF Validation

For more CLI action examples, check out the last section of this doc – CLI Action

When we talk about automation applied to the testing field, there are two expressions you’ll often hear thrown around: “automated testing” and “test automation.” But wait a minute. Aren’t automated testing and test automation the same thing? As it turns out, no. They are related concepts, but each one has a very specific meaning and purpose. And make no mistake: in order for your software organization to thrive, you’ll need both.

If up until now you thought that these two concepts are the same, don’t feel bad. For starters, you’re definitely not alone. People often mistake the two terms for one another. And secondly, your confusion ends today. That’s what this post is all about, after all.

We’ll begin by defining the two terms. Then we’ll dive a little deeper into each one of them, explaining their importance in an organization, also showing how they differently affect each role inside the team. Finally, we part ways by giving some additional tips. Let’s get started!

Defining “Automated Testing”

Right at the start of this post, we claim that “automated testing” and “test automation” aren’t the same thing, even if their names seem to imply otherwise. We’ve also told you that both are critical for your overall testing strategy. Finally, after a brief detour on the importance of testing in general, it’s time to define both approaches, clarifying how they are different—and similar—to one another.

Let’s start out by defining automated testing. And to be fair, that couldn’t be easier. “Automated testing” is just the process of automatically running a specific set of tests and verifying their results, instead of doing it manually. When you run your suite of unit tests on your development machine, you’re performing automated testing. When the CI server runs all of your unit and integration tests when someone pushes new commits to it, it’s also performing automated testing.

That’s pretty much all there is to it. With that out of the way, let’s continue to “test automation”, where things will probably be a little bit trickier.

Defining “Test Automation”

Now it’s time to define “test automation.” What is it and how it differs from the definition you’ve just read in the previous section? While automated testing is basically the running of automated tests, “test automation” is a way broader concept. It refers to completely automating the whole process of managing the different testing needs inside an organization.

Out of context, the line above most likely doesn’t explain much. Things will get a lot easier in the following sections, in which we’ll contextualize the two approaches, explaining how they fit into the overall quality strategy of a software organization and who each one benefits the most.

Automated Testing: Who Does It Help?

To really draw the distinction between automated testing and test automation, it’s important to show how they affect the different roles inside a software organization. Let’s start with automated testing. Which role in an organization benefits the most from this approach? The way I see it, the answer is clear: developers. And why is that?

A Unit Testing Example

For the sake of the argument, let’s focus on unit testing for a while. “Unit tests” is not a really great name if you think about it. No one seems to agree on what “unit” really means, for starters. But the main problem is that they aren’t really “tests.” The best way to think about unit tests is to consider them executable specifications. The term “programmer tests” has also been proposed a few times, and it makes sense. Unit tests are written by programmers, for programmers, in order to “prove”, at least to some degree of confidence, that a given piece of code really does what it’s supposed to do.

Automated Testing Is a Developer Confidence Booster

It isn’t that much of a stretch to expand our definition of “executable specifications” to also include integration tests. A common definition of integration tests would be “unit tests, kind of, but they use the real database/filesystem/etc instead of mocking/stubbing it.” Let’s do just that, then: let’s stretch our definition of “executable specifications” in order to also include integration tests. And let’s go further and pull all of that under the “automated testing” umbrella. What do we get from all of that defining and stretching?

The answer seems clear to me: the main beneficiary of “automated testing” in a software organization is the developer. Or, in other words: automated testing is a tool to achieve developer sanity. It allows developers to fearlessly refactor, knowing that they have a reliable safety net in the form of a comprehensive test suite that will warn them if they break something.

Test Automation: Who Does It Help?

We’ll now turn our focus to test automation and repeat the same analysis we just did with automated testing. Who benefits the most from test automation? The answer, again, is clear: the organization as a whole, with a special focus on the DevOps professionals. To understand why, we have to go back in time, to the (not so) good old days of the waterfall methodology.

Once Upon A Time, During The Dark Ages

In organizations that employ this methodology (and similar ones), testing is nothing but another phase in the whole cycle. And the testing phase tends to happen at the end of the cycle. More often than not, this is too little, too late. The feedback cycles slow down, reducing the usefulness and efficiency of the whole testing strategy. Nowadays, companies are moving toward a world of continuous development, deployment. They can’t afford to wait forever for the feedback from testing. The testing itself has to be continuous so that quality can be ensured at all phases of development. Automation can come in handy in this situation.

Here Comes The Enlightenment (i.e. Continuous Testing)

Automation is the missing link. It can provide the speed and consistency that you need in order to have continuous testing up-and-running. Manually managing the testing needs in such an environment would not only be incredibly hard and error-prone but also time-consuming, which in fact defeats the whole point of doing it in the first place.

By automating the managing of said testing needs, test automation helps organizations keep quality at the highest standards during the whole development cycle. Furthermore, it frees QA professionals from managing the minutia of testing needs, which means they can focus on creating more efficient case tests to ensure the application’s quality.

Automated Testing And Test Automation. You Need Both. ASAP

In today’s post, we’ve clarified the confusion between “Automated Testing” and “Test Automation”. Yep, the naming could use a little less ambiguity. But the concepts themselves are really different. However, they’re equally important if you want your organization to continue delivering software to the highest standards of quality. Automated testing is important, especially for giving your developers the confidence to fearlessly refactor their code,  which contributes to higher quality code, without a doubt.

But test automation becomes critical when your company starts moving towards a continuous development/continuous deployment scenario. Do you want your company to continue thriving in this brave new DevOps world? Put test automation to work for you and your organization.

This post was written by Carlos Schults.Carlos is a .NET software developer with experience in both desktop and web development, and he’s now trying his hand at mobile. He has a passion for writing clean and concise code, and he’s interested in practices that help you improve app health, such as code review, automated testing, and continuous build.

So your company is going Agile. If you’re a tester or QA person, that can bring about frightening thoughts about what your world will look like. For example, will you now be expected to test a codebase that changes daily, with no breaks or developer deadlines? Alternatively, you’ve heard that some teams do away with QA and testers completely once they go agile. How will you survive in this scenario?

Fear not, for there’s still a need for QA in our new agile world. However, instead of the old paradigm, where your goal involves finding defects, your new goals include preventing defects and helping ship products faster. And with this guide, you’ll be on your way to creating a robust and healthy QA process.

In this post, we’re going to take a look at what going agile means from a QA perspective and how you can change to thrive in this environment.

What Does Going Agile Mean for QA?

When reviewing the values and principles of agile, we don’t see testing addressed as clearly as we’d like. In fact, we’re not even sure if traditional QA has a place. But we need to read between the lines and picture what this means for us. Here are the four values that came from the Agile Manifesto:

  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • Individuals and interactions over processes and tools

Now let’s look at how these values fit together with QA.

Working Software Over Comprehensive Documentation

For the first value, we learn that working software comes before comprehensive documentation. Now, this doesn’t mean you can’t have any documentation, no matter what your development team tells you.

It means you should create documentation only if it provides value. In the testing world, we should spend less time writing out manual test plan documentation and more time automating the tests.

And we do have some things that will always need documentation. For example, putting together documentation for the customer can be a big part of QA’s job, as they’re most familiar with how to use the system.

As another example, you’ll need to document how to recreate a defect within the application. But don’t spend too much time filling out forms, tickets, or any other unnecessary work. Look for streamlined ways you can clearly communicate the defect to the development team without much overhead.

Whatever you do, make sure it drives the result of having working software.

Customer Collaboration Over Contract Negotiation

In the previous section, we mentioned putting together documentation for customers. That should be one of the last steps. Before the documentation, we should be working closely with our customers to understand how they use the system and why they might run into defects or bugs. Learn what their pain points are so you can share what you’ve learned with the development team.

Overall, your relationship with the customer should look like a partnership, not a criminal case.

Responding to Change Over Following a Plan

One big concern testers have when it comes to delivering software frequently involves keeping up with the testing. Everything changes in agile, and fairly quickly. Stop trying to build a plan for a future that might not come true. Instead, work to put in automated tests and guardrails so that you’re able to react quickly to changing priorities and functionality.

Sprinkle in as much automation as you can so that when change happens, you’re ready.

Individuals and Interactions Over Process and Tools

In our old waterfall world, the QA team would get a few weeks prior to release to learn and test all the new functionality. And, as waterfall usually went, those few weeks would shrink from four to three to two weeks max as software development deadlines slipped. We still needed to ship our product, and the QA team would feel much of this pain.

In this new agile paradigm, QA should be involved throughout the whole process. In fact, testers should interact daily with the team. Whether it’s pairing on a task or discussing how a story should be tested, they’re integral in discussions around testing and quality.

Another important note: agile teams have frequent ad hoc design discussions, so testers should be co-located and available to jump in on those discussions whenever they happen. So don’t create more paperwork and process to share ideas—instead, involve yourself in the whole software delivery process.

What Should QA Do Now?

Now that we’ve covered the agile values, we still might have questions as to how we’re supposed to work when agile. In this section, let’s cover some of the ways that our QA skills can help the team deliver quality software in a continuous way.

From a day-to-day standpoint, involve yourself in stand-ups, retros, and demos. Stay on top of the work the team is doing so you’re aware of dependencies between stories and what additional testing will be necessary.

What else should you do?

Join the Team

The biggest change involves not having a separate QA team. Instead, QA should be part of the development team. Since we’re part of the team, we’re able to assist in continuous testing, instead of doing it all at the end of the sprint.

Also, when we’re on the team from start to finish, we have the chance to affect the delivery of the product much more. Why is that? In an agile team, roles aren’t as clearly defined. You may be able to write your own story by stepping in as a testing coach or automation SME.

When the team focuses on delivering working software faster to the customer, you’ll have the opportunity to provide flexible support to your teammates.

Understand the Big Picture

While the developers dive into specific details of the task they’re working on, you have the responsibility of understanding the big picture. You’ll need deep knowledge of the working system to define tests and scenarios that might not be apparent from the outside. And with that whole-system view, you’ll be able to write the documentation that’s necessary for your customers.

Additionally, keep in mind application design. Understanding your product’s design can help identify interesting edge cases that should be considered.

Understanding the big picture can also help with a blind spot the engineers might miss. The big picture will help you uncover assumptions the team has made about the system. And those assumptions could leave a gaping quality hole in your end product. Therefore, you’ll always want to have a keen understanding of the system as a whole.

Automate Your Test Suite

Since agile testing is done in parallel to development, automation becomes critical. Without it, you’ll find yourself retesting the same functionality three or more times in a sprint or iteration.

Your developers will write unit and integration tests. However, they write those tests to a spec and typically can’t cover the use case from end to end. This is where you come in as a QA professional.

Now, you may think that you’ll need to learn to code to automate all these tests. Learning to code—or at least learning some light scripting—definitely has its benefits. But also take advantage of tools like Testim to easily put together automated functional tests for your product.

These automated tests can be based on the acceptance criteria in developer stories. Create tests that ensure that your product works correctly. And look for where there may be gaps in understanding, and therefore a need for additional tests.

Test Manually for the Right Reasons

Exploratory testing can identify gaps in automated tests. This shouldn’t involve going through the same manual processes over and over.

Instead, this time is for asking those “what if?” questions.

What if the order gets canceled after the shipping paperwork gets printed? What if I lose my internet connection while sending the payment?

Put time into exploratory testing to give your team more confidence that they didn’t miss a critical bug or loss of functionality.

Enable Faster Delivery

As mentioned before, because it’s so critical, we need to enable faster delivery of software. As the QA person on the team, this can mean a lot of different things. For example, help your team define what a completed story looks like. Assist with story creation. Help the team identify what’s missing or out of scope for a particular story. Guide them to ensure that you deliver your product with quality.

But most importantly, don’t be a bottleneck or a block. Enable the team to go faster.

Share Testing Practices

As QA, you have an understanding of good testing practices. Help the team by sharing your experience. Consider how a feature would be easier to test. Perhaps look for ways to make the design more testable.

Continuously Improve

Though quality is the whole team’s job, you should be driving continuous improvement of testing practices. Work to become an expert on agile testing methodologies and strategies. Help the devs create integration tests that aren’t flaky but ensure that the system is working. Help build maintainable and healthy test suites.


In an agile team, everyone is responsible for quality. And this can be your time to shine by sharing your expertise with the team. Work with your team to build quality into the development process. As I mentioned earlier, the goal no longer involves finding bugs and defects, but preventing them.

Find ways to use agile practices and values to make that happen in collaboration with the team and the customers. You’ll be able to find comfort in your new agile workplace without fear or apprehension.

Author bio: This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.

Be smart & save time...
Simply automate.

Get Started Free