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/