How to Decide if You Should Automate a Test Case

Test automation is imperative for the fast-paced agile projects of today. Testers need to continuously plan, design and execute automated tests to ensure the quality of the software. But the most important task is to decide what to automate first.

In my article published on the TestRail Quality Hub, I have compiled & shared a list of questions to help you prioritise what you should automate next and guide your test automation strategy.

Here is a checklist of questions to ask yourself as you decide on automating a Test Case–

*******

Is the test going to be repeated?

Is it a high-priority feature? 

Do you need to run the test with multiple datasets or paths? 

Is it a Regression or Smoke Test?

Does this automation lie within the feasibility of your chosen test automation tool?

Is the area of your app that this is testing prone to change?

Is it a Random Negative Test?

Can these tests be executed in parallel, or only in sequential order?

Are you doing it only for the reports?

********

For the detailed explanation of each of these points, read the complete article here –>

Are your Test cases really effective?

Test teams are forever designing and adding new tests, running them, and reporting results. But is your test team creating tests that are effective at finding real problems?

How do you know if your tests are actually working, and not just adding to the ever-increasing test count?

In my article published on the Testrail blog site, I discuss some ways you can gauge the effectiveness of your tests — and improve them.

Defects Found

The top and most obvious indicator of the effectiveness of your test cases is the defects you find when executing them. As you and your team execute the designed test cases, constantly ask yourself these questions:

  • Are these tests guiding me toward defects?
  • Am I finding problems with the predefined test cases? Or do I have to do more exploration before even getting close to a problem?
  • Are these tests exercising unique flows or use paths?

Metrics

You can also look at your defect lists and find related test cases for the defect logged (if you have that ability in your defect management system). This interlinking helps the team understand what test cases led to the issues found.

You can then further analyze whether that test case was created during test design or later added to the list when the issue was found.

Exploration

If your test cases are not effective, you will not find any useful bugs in test execution. That will mean most of your time is spent in unplanned exploration or ad hoc testing. So, by looking at the time spent in actual test execution versus the time spent on ad hoc testing, you can figure out the effectiveness of the test cases you designed.

If your test cases are effective, you will find issues, explore more use paths, navigate through different integrations with other features, and test different aspects of the same functionality.

If at the end of your test execution, you feel that you have not done all of that, you can infer that is because your test cases might be too simplistic or obvious, and therefore not effective enough to find any useful bugs.

History

Continue Reading here–>

Achieving the Goal of In-Sprint Test Automation

Getting test automation done is a challenge, especially within the tight deadlines imposed by Scrum. As much as the thought of continuous in-sprint test automation sounds enticing, the practicality of it may elude most Scrum teams.

In my article published here– I look at some of the main things you need to consider in order to get your test automation done within the confines of your sprint.

Framework

The first thing to focus on is a framework that is useful, is easy to understand, and helps all stakeholders participate in test automation.

This is essential because you want to make test automation a continuous activity that is a part of daily work, not a once-a-sprint (or once-a-release) work item. For this to happen, the framework must make it equally comfortable for a businessperson, developer, functional tester or automation expert to add their contribution and see the results of their efforts.

There are many business-friendly frameworks and techniques, like behavior-driven development (BDD), as well as many tools that can create tests in a domain language and then translate them to script code.

All stakeholders must be trained on using the framework, and their area of contribution must be made clear to them, with practical hand-holding. The automation tester can then focus on maintaining the framework, generating test suites and editing failing scripts, while the creation of test automation will be a continuous task assigned to everyone involved.

Collaboration

The next thing to focus on is collaboration between the various stakeholders. A continuous automation framework can only survive when it is being fed and tended to by everyone on the team.

  • The business people, like a business analyst or a product owner, can help by adding user scenarios or defining the requirements in a framework-friendly format. This may require them to be trained on the preferred format based on the framework being used
  • The developers can help by creating reusable methods for steps of the script. They can also create and maintain an object repository for all elements they add to the UI while testers use the pseudo names of the elements in the test scripts. This means that the scripts can be created before (and independent of) the application UI, and such scripts won’t need editing when the UI changes, as long as the object repository is kept up to date
  • The testers can help by adding more scenarios, specifying and creating test data, and executing the scripts periodically

Strategy

How to strategize the development of test scripts is crucial to making in-sprint automation a reality. Using API-level automation whenever possible will reduce the time and effort.

Continue Reading –>

Read More »

How to Decide if You Should Automate a Test Case

Test automation is imperative for the fast-paced agile projects of today. Testers need to continuously plan, design and execute automated tests to ensure the quality of the software. But the most important task is to decide what to automate first. 

In my article published at the Gurock Blog website, I have have compiled a list of questions to help you prioritize what you should automate next and guide your test automation strategy.

Think of this like a checklist that helps you make automation decisions quickly and effectively and create a standard process around them for your team to follow. Here are the list of questions to ask yourself.

Do check out the complete article for a detailed discussion on each of these-

Is the test going to be repeated?

Is it a high-priority feature?

Do you need to run the test with multiple datasets or paths? 

Is it a Regression or Smoke Test?

Does this automation lie within the feasibility of your chosen test automation tool?

Is the area of your app that this is testing prone to change?

Is it a Random Negative Test?

Can these tests be executed in parallel, or only in sequential order?

Are you doing it only for the reports?

Test automation tools will provide you with useful insights into the quality of the software that you can showcase with the use of some insightful reports. But are these reports the only reason you are looking at automation? Just looking at the red or green status results of the test reports might not be the best way to assess the software quality. You will need to spend time analyzing the tests that failed, why they failed, and what needs to be corrected. Tests created once will need maintenance and continuous monitoring to keep them up to date. All of that needs to be kept in mind and the effort needs to be accounted for.

There is more to test automation than just the fancy reports!

Looking at the questions above, analyse the state of your test case, the intent behind its automation, and its feasibility, as well as the value that you might get out of it. Hope that helps you decide what tests you should or should not be picking for automation!

<Image credits – https://unsplash.com/photos/FlPc9_VocJ4 >

Ways to Generate Quick Test Ideas

As testers, we look at everything with a critical eye. As soon as something comes up for testing, our instinct is to get down to examining it and looking for problem areas. After getting a written test script, a new tester would be tempted to begin executing scripted tests right away.

But stopping to gather our thoughts about possible test ideas first is a smarter approach that leads to better, more unbiased test coverage. However, we don’t always have a lot of time to imagine scenarios and different paths. Luckily, there is always some planning we can do beforehand.

In my article published at Gurock Testrail blog I shared some tips for generating test ideas in a time crunch.

Revisit classic test techniques

Our old, trusted test design techniques like boundary value analysis, equivalence class partitions, decision tables, and state flow diagrams are always a help when thinking about test cases. Although most of them are ingrained in the thought process of a tester and are mostly common sense, giving them a revisit, however informal, may still give us some more test ideas.

For example, creating a quick decision table for the interaction of two or more variables to observe the behavior of the system may reveal some unique combination that we might have missed. Or a quick boundary value analysis for the age field in our we form may show us a special case we might have missed.

Similarly, using state transition diagrams to draw end-to-end flows can help not only the testers, but also the developers in imagining the overall system flow and revealing problem areas.

Look at the history

The history of the project or the system can give us many insights into what we are dealing with, where the common defect clusters are, and the most problematic components.

If you are new to the test team, start by having a look at the defect tracking from past sprints or releases. You can then define and think of more test cases based on past defects and the components that have had the greatest number of defects.

If you’ve been part of the team for a while, you are probably intuitively bound to focus on these areas. But even then, it will help to consciously make an effort to list the most common types of bugs encountered and most problematic areas based on your experience. This will help not only you, but also your new and junior team members. Read full post->

Read More »

4 Tips to Create a Simplified Test Plan for Your Agile Project

Planning is an integral part of initiating any project or activity, including software testing. Although formal test plans may seem outdated and unnecessary to most fast-paced agile teams that prioritize cutting down on documentation, it’s still a good idea to keep a pared-down test plan that can guide the testing effort throughout the project.

In my article published on TestRail blog, I talk about four useful tips to create a simplified test plan for your agile project.

1. Include the basics

A test plan can be as detailed as the team requires, but at the minimum, it must contain the context, timelines, and a brief overview of the testing activities expected to be performed in the project, release, or sprint.

Based on what level of test plan you are creating, begin with a basic heading, like schedule and timelines, testing activities and types of testing expected to be performed, people involved in testing, or any new hires or training required for the project or release.

2. Build off the project plan

Most of the test plan can be derived from the context set by the overall project plan, so give that a thorough read and get the details of the project lifecycle, expected delivery schedule, interaction points with other teams, etc.

Note any specifics that emerge, like shared resources with other teams, sync points for integration tests throughout the project’s lifecycle, or special types of testing needed, like performance, load or security testing.

3. Define a clear scope

Let’s say your project is a mobile application that needs to work on both Android and iOS. It would be beneficial to list all the environments and OS versions that need to be supported. Including them in the test plan ensures you set up the test environments early and allocate testing tasks across all of them. It also ensures that you are not bogged down by repeated testing on numerous test environments at the time of release. What is not defined in the initial test plan can automatically be considered out of scope.

Continue Reading ->

4. Use visual tools like mind maps

A simple Agile Test Plan using a Mind map

Read full article here

Continuous Testing in DevOps

Agile testers need to constantly rethink their processes and tooling in order to move toward faster and more reliable software delivery. The key there is to embrace the continuity. Continuous delivery is necessary for agile development, and that cannot happen without having continuity in testing practices, too.

In my article published on TestRail blog, I discuss the various aspects of Continuous Testing in DevOps-

Continuous testing

Continuous testing can be defined as a methodology focused on continuous quality and improvement. It can use a number of practices and tools to help do that.

Continuous testing encompasses the verification and validation of each piece of the software under development to ensure:

  • Code quality — Are developers creating code of good quality?
  • Application correctness — Are developers creating the correct features?
  • Place in the pipeline — Can the application code flow through the pipeline and across environments and specified tests successfully and easily?
  • A good customer experience — Are users seeing value in the delivered application?

Continuous testing is the way toward continuous delivery. Teams that struggle with continuously delivering on time or with high quality often find the solution to their problems by setting up good continuous testing practices.

Read the full article for some tips to improve your continuous testing framework and help your DevOps succeed, like-
  • Ensure test automation is the best fit
  • Leverage automation benefits in all aspects
  • Select the right tools
  • The Typical Pipeline & what it requires

Continue Reading ->

Agile teams must strive for continuous improvement of their continuous testing strategy. If they’re successful, they can reduce their release times from months or years to weeks or days (or even hours!). By adopting the correct practices and embracing the spirit of continuous learning and improvement, we can help our testers to become champions of agile.

<Image Credits – manufacturingchemist.com>

Read Along- ‘Agile Testing’ Chapter-10

“Business-Facing Tests that Critique the Product”

  • Critiquing or evaluating the product is what business users or tester do when they assess and make judgement about the product.
  • These are the tests performed in Quadrant 3 of our Agile Testing Quadrants
  • It is difficult to automate Business facing tests that critique the product, because such testing relies on human intellect, experience, and insight.
  • You won’t have time to do any Quadrant 3 tests if you haven’t automated tests in Quadrants 1 and 2.
  • Evaluating or critiquing the product is about manipulating the system and trying to recreate the actual experience of end users.

Demonstrations

  • Show customers what you are developing early & often.
  • End-of-iteration demos are important to see what has been delivered and revise priorities
  • Rather than just waiting for end of sprint demos, use any opportunity to demonstrate changes as you go.
  • Choose a frequency of demos that works for your team. Informal demos can be more productive

Scenario Testing – Business users can help define plausible scenarios & workflows that can mimic end user behavior

Soap Opera Testing – Term coined by Hans Buwalsa (2003) can help the team understand business & user needs. Ask “What’s the worst thing that can happen, and how did it happen?”

Exploratory Testing

  • As an investigative tool, it is a critical supplement to the story tests and our automated regression suite.
  • Sophisticated, thoughtful approach to testing without a script, combining learning, test design and test execution

Usability Testing

There are 2 types of usability testing. The first is done up front by user experience folks, using tools such as wire frames to drive programming. These are part of Quadrant 2.

The second type talks about the kind of usability testing that critiques the product. We use tools such as User Personas and our Intuition to help us look at the product with the end user in mind.

API Testing

Instead of just thinking about testing interfaces, we can also look at APIs and consider attacking the problem in other ways and consider tools like simulators & emulators.

Testing Documentation

User manuals & online help need validation just as much as software. Your team may employ specialists like technical writers who create & verify documentation. The entire team is responsible for the quality of documentation.

Read Along- ‘Agile Testing’ Chapter-2

“The Principles for agile testers”

Points to remember and Quotable Quotes

Definition of Agile Tester-

“A professional tester who embraces change, collaborates well with both technical and businesspeople, and understands the concept of using tests to document requirements and drive development.”

  • Skills are important, but attitude counts more
  • An agile tester does not see herself as a quality police officer, protecting her customers from inadequate code.
  • Agile testers don’t limit themselves to solving only testing issues.
  • Creativity, openness to ideas, willingness to take on any task or role, focus on the customer and a constant view of the big picture – are some components of the agile testing mindset.
  • A team that guides itself with agile values and principles will have higher team morale and better velocity than a poorly functioning team of talented individuals.
  • The principles important for agile testers are –
    • Provide continuous feedback
    • Deliver value to customer
    • Enable face-to-face communication
    • Have courage
    • Keep it Simple
    • Practice continuous improvement
    • Respond to change
    • Self-organize
    • Focus on people
    • Enjoy
  • AATD “Agile Attention Deficit Disorder” – Anything not learned quickly might be deemed useless!
  • Automating tests is hard, but it is much easier when you have the whole team working together.
  • Agile development rewards the agile tester’s passion for her work!

I had written an article about differences between Agile and Traditional testing approaches a few years back. Though I had not read this book at the time, I now feel how many of the points were similar and resonate the same even now. You can read my article here – https://testwithnishi.com/2016/10/20/5-ways-agile-testing-is-different-from-traditional-testing/

***Update **About face-to-face communication** during Covid-19 ***

As I am reading this book during this bizarre time of social-distancing, working remotely and entire nations on lockdown, the part about ‘face-to-face’ communication has a new meaning now. As Janet Gregory also pointed out in response to this article, our definition of face-to-face has changed over the last few weeks over the entire world! We are lucky to have technology that helps us continue effective communication within our teams, have conversations, video calls, screen shares, continue learning over webinars and continue working, feeling useful and being productive.

Hoping things change soon and we can go back to having fun, productive discussions with our team mates over coffee. Until then — Happy social distancing!

*************

Speaking at the DevOps & Agile Testing Summit – 8Nov’19, Bangalore

I was invited to speak at the DevOps and Agile testing Summit organised and conducted by 1.21GWs on 8th Nov 2019 at Bangalore. It was a great event which brought together many keen minds as delegates and many inspiring speakers. https://1point21gws.com/devops/bangalore/

My talk was on “The Building Blocks of a Robust Test Automation Strategy”. As we know testing teams are faced with a number of questions, decisions and challenges throughout their test automation journey. But there is no single solution for their varied problems! In this talk I outlined a number of strategies that agile teams can follow– be it their selection of what to automate and how much, what approaches to follow, whom to involve, and when to schedule these tasks so that the releases are of best quality.

I am grateful that my talk was so well received and led to great discussions later with many participants. I enjoyed the day and am always glad to be invited by the 1.21GWs team.

A peek into the event – pictures from my session

@Sahi Pro was also a knowledge partner at the event and delegates also got a peek into Sahi Pro via video and brochure handouts.

Looking forward to many more successful events! 🙂