I'm not really a Scrum aficionado. Actually I'm pretty far from calling myself that way ;) But I can still remember the moment years ago when I was reading through Scrum Guide & some accompanying materials and I've found out a term that has really caught my attention: "the quality built-in"It may look inconspicuous, but in fact it's a very powerful concept. It can be described with the following statements: once the product has a desired level of quality, the effort to keep it there (at that level) is very low but continuousonce the product's quality has decreased, getting it…
All posts in quality assurance
This blog post is about: why Operation Kalashnikov was doomed to succeed, what does it mean to have an emotional bond to a mission, why Front-End Engineers have smashed what was so hard for Quality Assurance specialists, what kind of effects we've expected and how I've cynically machiavelised the project outcome ...Previous post in the series can be found here. Where did the last post leave us? We were just about to start Operation Kalashnikov - our final experiment aimed to prove that we either are able to tackle the challenges of E2E automation or we should go for entirely…
This post is all about how we've decided to revamp our FINAL approach to E2E automated testing in a way that was supposed to maximize the chance of final success. Warning, post contains: AK-47, what's wrong with "tightening the screw", why JavaScript is better than Java (;>).Previous post in the series can be found here. Where were we? At the end of part IV, our E2E automation was going nowhere. Or, to be more precise, it was far too slow to get us where we were aiming (Continuous-bloody-Delivery). That's was the perfect moment for an ... EarthquakeWhat kind of earthquake…
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,…
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 Building software while "on auto-pilot" doesn't work well - operational automation is more than advised, but understanding (in-depth) why-you-do what-you-do is absolutely essential. However, there are certain practices many stick to, without really understanding their purpose & descendant effects. One of them is "staging" - an anti-pattern that should in general be avoided, but when applied properly, can temporarily reduce the risks & help in transformation towards more mature delivery model. However, too many thoughtlessly treat it as a permanent element of their delivery pipeline, w/o thinking about its consequences & accompanying "…