Exploring a DevOps Transformation Like a Tester

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.

 
 

Learning Outcome

  • Multiple visual models of CI/CD pipeline
  • Strategies and techniques to understand the impact CI/CD has on testers
  • Understanding of how and when exploratory testing would fit into devops

Target Audience

Testers, Developers, Product owners

schedule Submitted 7 months ago

Public Feedback

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

    I know you  have delivered this talk a few times, and received mentoring before to get the text in shape before the talk took final shape. Also I am aware that the latest feedback on your delivery has received very positive feedback.

    I have only a few things I can comment on the activities you could consider for improving the text and making the submission stronger for any conferences:

    • Ask someone who has recently seen you deliver this talk if the text, in their perspective, reflects what you really spoke on. Having seen how positively your most recent delivery in a MoT meetup was received, I would suggest specifically asking from that audience. I could do it if I watched the video myself, but unfortunately I will not have that much time right now. 
    • Consider fixing the language around "as a tester". It communicates a vague meaning and an assumption that testers would be alike when we in fact are not. What you seem to be saying is that the core of your tester-ism is exploring and learning about the application at hand, and you applied the same mindset now learning not on the application but on the new kind of environment and expectations in a project you were placed in. Your audience is also "tester", perhaps, but find themselves in a box where using the term feel like this talk does not speak to them. 
    • Consider rewriting this for a more versatile audience: What is it that an application programmer could learn from your story? Or what is in this for someone who is a tester/programmer specializing in automation? I can read this stuff in between the lines, but it is well hidden in the current abstract.  As the abstract reads (intentional or not), it is written for non-programmer testing audiences, and misrepresents you loving exploratory testing AND using automation regularly as part of your work. It is a story, in a way, on how you got there, but as it never speaks of your current automation experience, it promises less of the outcome that you address when you speak of this. 

    As always, people will have different opinions on how to make a talk better. It is up to you to decide what of my feedback you act on, as my feedback is not simple typo fixes or rewording, but considering if you could frame the same talk in a more powerful way that would address mixed audiences without giving up the core of what this is about. 

     

     


  • Liked Jeremias Rößler
    keyboard_arrow_down

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

    45 Mins
    Talk
    Intermediate

    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 Nishi Grover Garg
    keyboard_arrow_down

    Nishi Grover Garg - The What, When and How of Test Automation

    45 Mins
    Talk
    Beginner

    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!

  • Liked Sri Harsha
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

    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