With frequent time boxed releases and flexible requirements in agile teams, test automation faces numerous challenges. The most frequent issues being too much to automate and never enough time, automation lagging behind, flaky scripts that need too much maintenance and lack of skill, time & resources. Haven’t we all asked what to automate and how to go about the daily tasks with the automation cloud looming over our heads. Here we’ll discuss answers to some of these questions and try to outline a number of approaches that agile teams can take in their selection of what to automate, how to go about their automation and whom to involve, and when to schedule these tasks so that the releases are debt free and of best quality.

What to Automate –> Regression averse approach | Selective approach | Sanity Automation | Max automation approach

When to Automate –> End-of-Release | Sprint n-1 approach | Continuous automation

How to Automate –> All hands approach | Shared Automation expert | Code-averse tool

Understanding these possibilities, you can pick the right combination to form your own test automation strategies. Let us have a look at an integration of these possibilities, the possible combinations and what may or may not work!


Learning Outcome

  • Learn the different possible approaches you can take for What, When and How to automate
  • Understand each approach, its flow of work and a tester’s contribution
  • How to create a robust test automation strategy using a combination of these approaches
  • See which potential combinations may or may not work!

Target Audience

Testers, Test Automation Engineers, Test Managers, Agile Team Leads, Scrum Masters

schedule Submitted 6 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Maaret Pyhajarvi
    By Maaret Pyhajarvi  ~  6 months ago
    reply Reply

    This is not a description of a talk I would be likely to accept unless I believed in the person behind the talk, and having met you over skype Nishi, I believe in you. The abstract does not do you justice, and I have been thinking for weeks on how could I help you in writing to make it better.

    The main problem I think is that it is very vague. It approaches all automation, from a project planning kind of a perspective. From that disregard of how different organizations and tool choices are already essentially different, it build promiseware but does not tell of any of the actual things you would teach.

    Instead of "answers to some of the problems", you need to tell me briefly what problem and what specific answer. Why would I put my faith in you that the answers you provide are more valuable than the next persons? You don't give a change of agreeing or disagreeing with what you want to teach, you keep it a secret. And instead of keeping secrets, you should be telling your answers briefly here, and elaborate them brilliantly in your talk delivery so that I will never forget them again.

    Also, since you don't say anything to lead me believe otherwise, I look at where you work and read this as a risk of tool demo. Working with a tool vendor, making the relationship of your learning/teachings and your tool is relevant. What you leave out, I read in between the lines.

    Another point for Selenium Conference India specifically is that they seek "technical talks", whatever that may mean. It usually means we show things concretely, on practical level with code samples, demos, specifics. Do you see a version of what, when and how that would be more specific?

    • Nishi Grover Garg
      By Nishi Grover Garg  ~  6 months ago
      reply Reply

      Hello Maaret

      Thanks for your time and effort spent in reviewing my proposal. I appreciate each word of feedback.

      In this talk the agenda is to talk about common problems faced in test automation journey like - too much to automate, automation always lagging behind, flaky scripts and lack of time / expertise. These are what I outline in the beginning and then describe how we can overcome these common challenges if we just 'thought' about it more in the planning stage itself. 

      Then I proceed with outlining the questions we should be asking ourselves and what are the different possible approaches we can take for each of these questions---

      What To Automate -> Sanity automation , Regression-averse automation, Selective automation , Max automation 

      When To Automate -> End-of-Release , Sprint (n-1) , In-Sprint Automation

      How To Automate -> Shared Automation Person, Whole Team Approach, Code-averse Tool

      Then we showcase how we can devise our test automation strategy by picking a combination of these three. One approach from each of what-when and how. I also discuss what possible combinations may or may not work.

      From your feedback I see that the abstract sounded more vague because I had delibrately not outlined or named each of these approaches I will talk about in the abstract so that people actually get to discuss and hear the explanantion instead of bringing pre-conceived notion. But I get that maybe putting these out could invite more curiosity.

      Second point was if this is a tool demo or leading there- which it is not. In fact this is totally at a planning of test automation stage and does not talk about any tool or technology. It is also not a demo like "technical talk" but more of a planning guide. It does not have a demo or code sample.

      I hope this gives a clearer idea of content of the talk. I can re-word the abstract if and when needed.

      • Maaret Pyhajarvi
        By Maaret Pyhajarvi  ~  6 months ago
        reply Reply

        The idea with this playground is that you would update the best version out of the talk that you have in your mind into this description and we then "accept" it here - and the conference selection process is different. What we try to do here is to get every proposal into its shiniest version, and show you how it reads so that can make your own choices on what you change staying true to your style. 

  • Liked Jeremias Rößler

    Jeremias Rößler - recheck and the Sorcerer's Stone: Turning Selenium into Adamantium

    45 Mins

    Ever had that: after a simple change, suddenly 50+ tests are failing! Brittle tests that hinge on GUI specifics and result in the dreaded NoSuchElementException are a main headache when testing with Selenium.

    The open source project recheck offers a simple and elegant solution. Not only is a virtual identifier unaffected by UI changes, you can define it for otherwise hard to specify elements, i.e. that would require complex xpath or CSS selector expressions. And on top of that, tests are easier to create and maintain and yet much more complete in what they check. This talk gives a practical introduction to the underlying approach and the tool, complete with a life coding session.

  • Liked Parveen Khan

    Parveen Khan - Exploring a DevOps Transformation Like a Tester

    45 Mins

    Just when we, as testers, got a handle on what Agile means for us, the landscape changed yet again to a DevOps culture. Words like continuous integration (CI), continuous deployment (CD), and pipelines are now ones we’re hearing on a daily basis. As a tester, I’ll admit, I had no clue of what these words meant, and how was I to change the way I tested to fit within this DevOps culture.

    Researching about DevOps provided some information, but it was still fuzzy how testing fits into this process. As opposed to panicking about yet another shift in culture, I decided to approach this with a tester’s mindset and explore it just as I would a new application.

    In this talk, I’ll share my journey of how illustrating models to visualize and understand CI/CD pipelines helped me; my various phases of exploration of the DevOps culture; and the thoughtful questions that I posed at each phase to learn more about this methodology. I’ll also share how my new understanding of DevOps influenced my decisions on which automated tests should be contributed to the CI/CD pipeline and at which stages.

  • Liked Sri Harsha

    Sri Harsha - Memory Leaks: The silent thieves in Web Application

    20 Mins

    We’ll love browsing, it may be your blogs, visiting your pages, searching for a content and it may be an application you developed. So, have you ever observed issues like slowness in web-application while browsing, reduce in page performance over time, application quit unexpectedly, and devices stop working? And no wonder every new web technology in this era faces this issue and these applications are victim of memory leaks?

    In a world of automated system, everything is automatically managed under browser hood for a web application. Asynchronous operations, Executing instructions, Automatic garbage collection etc. But even after effective management of operations in a complex program, there is a small amount of failures happens in disposing the memory used and those are difficult to debug because they are not the application features.

    So, it is important for every web developer/tester sitting out there to understand/visualize the importance of memory leaks in an application, Because at the end we’re the one responsible to make the application to be alive