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

[Tip] Practical Examples of Shift Left in Software Testing

Shift Left is a buzzword in Software Testing. It is not new, in fact it has always been around. Shift left is all about creating a culture where testers can be involved early in the software development life cycle to start testing activities early. Idea is to reduce the risks.

Perhaps inspired by the maxim, “a stitch in time saves nine”, Shift Left is a practical attempt to actually ensure a timely stitch; to check for errors in the software testing process earlier than the conventional time to do so.  Shift Left testing means testing earlier in the software development cycle, so that risks and unknowns can be reduced which enables smooth deliveries to the clients.

Few Examples of Shift Left:

  • Pair with the developers – More Collaboration and brainstorming on the requirements / test scenarios with the Team (including Devs and PO) so that unknowns and risks can be discovered earlier in the phase. Both Devs and QEs will have the same understanding on the requirements.
    • Rework (Issue fixing & retesting) will be less.
    • Scope creep will be less.
  • Test different layers – In SOA applications, APIs are developed first. Team should plan the API testing so that issues can be identified early in the cycle (rather than just testing from the UI).
  • Plan Non-functional Testing early in the cycle (Performance Testing, Security Testing etc) – Identifies issues early and reduces the risks.
  • Automate the “Automation Test Case Execution” – Integrate the automation scripts with Jenkins/any Build automation tools that automation scripts should run in CI region before the new code deployment. It will help in ensuring that new code change is safe or not.
  • Automate Unit Tests, Integration tests, API Tests – These tests runs faster and help in identifying the defects early in the cycle.