This blog post is all about: the difference between focus on doing and focus on getting done, importance of owning your own metrics (KPIs), why data can be double-edged sword (but the transparency is still the key), that engineer who doesn't introspect into her/his work can be effective only by pure luck and that falling into "victimship" (instead of trying to fix the issue) has never ever fixed any problem.Part III of the series can be found here.Disclaimer: to make this as brief as possible, I've filtered out several side topics - e.g. test pyramid consideration,…
All posts in automated testing
This blog post is all about the difference between operational & aspirational work, how does the waste disguise itself, why QA is so prone to over-doing, that QA is much more similar to other disciplines of engineering than one may think, how making things visual helped us a lot with stopping starting :)Part II of the series can be found here.So, how far did we go in the last part? Not that far to be honest, we've identified some ways to "free the mandays" & started implementing them - but this was just the beginning of our journey ...Increasing…
In this post you'll read about the difference between writing automated tests & having testing automated, why testing framework or DSL used do not really matter, what does it mean "to free the mandays", how did we approach securing capacity for kick-starting test automation with a big hit.This is the 2nd post in the series. You can find the previous episode here.Just do it (not)!It's a very banal truth that it's very easy to create automated tests, but it's very hard to automate testing.Uhm, wait, what? What's the difference?I can easily create zillion of automated…
In this blog post you'll read about why & how Shedul has started the journey towards Continuous Delivery, what does it have in common with test automation and why 2 weeks are both a little & a lot ...Dunno about you, but I love the warstories. Theory is great, but even the greatest & most thoroughly thought-through ideas do not guarantee a success - it's (almost) all about execution and learning from successes & mistakes (both your own & others'). I have shitloads of my own stories I'd gladly share, but in many cases I simply can't - as a…
TL;DR Not all code (or rather - not code in any shape) can be tested in automated way. To assure its "proneness" to automation it has to be either written with certain qualities or refactored to provide them. There are only two ways to prevent these qualities from decay & entropy: highly conscious, mature & disciplined engineering or continuous process of automating & maintaining automated tests. Ad-hoc, "jump-in" automating efforts are in most cases a wasted energy & additional technical debt, w/o any significant benefit. One of the most consistent behaviours in software delivery…
Don't tell me you haven't seen these job ads: "Looking for Test Automating Engineer. Required skills: Gherkin, Cucumber & Spock Framework." "Offering a position for Test Automation Architect, 3+ years of front-end web application test automation required." "Open spot for Lead BDD Ninja! You have speak fluent Selenium-jitsu, Jasmine-do & Karma-fu." Clearly, enterprises have learned about the benefits of test automation (not a surprise, keeping in mind the endless swarms of Agile evangelist roaming around freely ;>) & are struggling to apply the practice in their own, specific reality. In their own, twisted ways…