Posted on

What is TestOps? TestOps – Chasing the White Whale by Ioana Serban

TestOps is the reclusive member of the DevOps family. Reports of sightings have been few and far between. Although we’ve heard stories, most of us don’t know anyone who’s actually seen it in the wild. I’ve turned to my personal experience as a tester to search for clues about what TestOps is. We’ll talk about what testers have to offer in a DevOps environment and look at the magical things that happen when the worlds of testing and operations collide.

There will be real-life stories, including: simulating an environment migration under production-like traffic (+ screwing it up and learning from it)choosing an AWS architecture with actual test data to compare performance for different instance types busting the myth that you can mitigate a DOS threat by scaling horizontally. Finally, we’ll dare to look into the future at what can happen when intentionally applying a TestOps mentality to our job and what regular teams can do to get there.

Key takeaways: How getting testers involved in DevOps brings actual value.Why applying a TestOps mentality to your work can open the door to a whole new type of testing.Getting there is not as hard as you think!

Author: Ioana Serba

Posted on

Taking Control Of Your Test Environment

“Taking Control Of Your Test Environment” by Ioana Serban

Most of us have had to deal with red builds blocking our testing or have been told to test on flaky environments where half the issues you find would ‘never happen in production’. As a tester, I used to think this wasn’t my problem.

What happens though when a thinking tester decides this is her problem and wants to be part of the solution?

This talk exposes some of the possible causes why builds stay red or an environment is “flaky”. For instance: 1. There are bugs in your build. 2. You are dependent on a third-party system that is not functioning correctly. 3. Your deployment may have gone awry, something may be missing. 4. Your environment is not set up in a consistent way.

We’ll look at some approaches that target each of these causes and show testers how they can acquire the skills necessary to take control of their test environment.

In case of bugs in existing functionality, you need to ask yourself: Are you running automated checks against the build? If yes, either you don’t have the right checks in place, are ignoring failed checks, or, even worse, the issue is intermittent. Testers that seek out a deep technical understanding of their product can be capable of chasing an issue down the whole technology stack without relying on a developer.

Stubbing out a third-party service can counteract uncertainty about the functionality of your own product. To deal with the real issue though, a tester can communicate directly with the third-party team, providing information to and from both sides.

Testers can get involved with the automation of both the deployment and environment setup, which are traditionally Operations roles. This is also often the realm of “magic scripts” that are not considered part of the deliverables and are not properly tested. A tester’s input can be very valuable here.

Speaker Bio: Ioana Serban started working as a Software Engineer in Test in 2011. With a strong leaning towards the more technical side of testing, she’s interested in learning all aspects of the craft and is a big fan of challenging assumptions of what a tester is or isn’t “supposed” to do. Ioana previously worked for Adobe and is currently working for eBay as an embedded tester in an agile team. She Blogs at https://medium.com/@ioanasaysgo

Posted on

Foundation for Effective Test Automation

Here are 5 best practices from @testcraft.io to consider when it comes to designing tests effectively:

Test Design Rule #1 – Keep Your Tests Short and Simple

When thinking of how to design your tests, make sure that they abide by the KISS principle: Keep It Simple, Stupid.

No matter what you’re testing, we recommend keeping your automated tests between 5-15 steps so that they’re simple and easy to understand

Test Design Rule #2 – Build Your Tests From Reusable Components

One great way to keep your tests simple is by reusing the same components when building them.

Test Design Rule #3 – Every Test Should Be Independent

Keeping your tests independent also prevents unnecessary test breakage. If feature B changes in an application under test, there should be no need to update the tests for feature A to ensure that it continues to run.

Test Design Rule #4 – All Tests Should Have a Purpose

Defining a purpose at the start of the design process and identifying that as a clear goal throughout the design will make sure that your tests continue to stay relevant and helpful.

Test Design Rule #5 – Don’t Forget the End User

Keeping your end users in mind will also help when mitigating risk. When designing your tests, focus on different ways a user can break it. 

Read detailed tips at https://www.testcraft.io/

Posted on

[Tip] “Building Quality In” – Automation points to consider in while you prepare for the test strategy.

Building quality in means writing automated tests at multiple levels (unit, component, and acceptance) and running them as part of the deployment pipeline, which is triggered every time a change is made to your application, its configuration, or the environment and software stack that it runs on. Manual testing is also an essential part of building quality in: Showcases, usability testing, and exploratory testing need to be done continuously throughout the project.

[Reference: Continuous Delivery: Reliable Software Releases.. – Humble, Jez. ]

[bctt tweet=”Building quality in also means constantly working to improve your automated testing strategy.” url=”yes”]

While preparing the Test Strategy for any feature, consider the following points from automation perspective:

  • The automation approach for each layer – Unit, Integration, Regression etc.
  • Technical Debt (Automation Maintenance / Debt)
  • Running automated tests after each commit
  • Running automated tests as a part of deployment pipeline


Posted on

[Tip] How to Speed up the UI Automation tests?

When we ran our scenarios through the UI using Selenium it made our test suite slow.
What could you do to speed it up?
Often, the best way to speed up a UI test is to remove it, or rather, refactor it to a domain layer test that doesn’t go through the UI, but talks directly to the domain layer.
If you’re unable to do that, there are still things you can do to speed up UI tests. Start by
identifying what steps and hooks are slow.

Are you starting your web app in a Before hook for every scenario? Try starting your app only once, for all scenarios.

Are you launching a new browser for every scenario? Try reusing the browser instance.
Do your scenarios need to go through a lot of pages before you get to the UI you really want to test? Try to go directly to the page you need to test, and set up the data you need “underneath” the UI.

Many of these optimisations introduce a new problem – you might have state leaking between scenarios. When state leaks between scenarios they might pass when run in a certain order, but they might fail when run in a different order. This can make it very difficult and time consuming to fix failing scenarios. To avoid this we recommend you use Before hooks to explicitly clear state that might have been left over from the previous scenario.

Source/References: https://cucumber.io/