Emanuil Slavov - Optimizing For Happiness

The Goalkeeper's Impact

At Falcon.io we believe in empowering our teams and in their self organization. There are few top down technical mandates (e.g., use Java for backend, services should not run with root privileges). There are even less organizational mandates and ceremonies. So it’s up to each team to

Book List

In the past few years I've been making a transition from a specialized software quality related role to а more broad director of engineering role. From direct manager to manager of managers. Here is a list of books I found very helpful seeing the big picture and hopefully useful if

Build Failure Duration

Build Failure Duration (BFD) - the time it takes to fix a broken build. OK, but why is this important? 1. When a build breaks we should not be able to deploy to stage/prod environment. It's a basic build pipeline rule (I think I first saw it in The

StartBG Podcast Video

Partisipated in a video from the StartBG Podcast series (in Bulgarian only). The topic is total quality, processses and anything in-between.

No Single Metric to Rule Them All

One metric can't tell the whole story.

test environment

On Test Environments

One of my biggest problems in software testing has always been the test environment. And more specifically the problem that I had little control over it. I could not deploy whenever I liked, neither could I upgrade it, or I was not allowed to have access the internals. I had

API Tests - What's in a Name?

In 2016, I gave a talk at ExpoQA conference [http://www.expoqa.com] in Madrid. The talk was called Need for Speed[1] [https://emanuilslavov.com/api-test-whats-in-a-name/#fn-1]. In that talk, I omitted an important piece of information which I thought it was obvious to everyone. In hindsight however, it

automated testing

Deep Oracles: Multiplying the Value of Automated Tests

(This blog post is expanding on a presentation I gave recenntly. Slides are here [https://speakerdeck.com/emanuil/deep-oracles-multiplying-the-value-of-automated-tests] ) Modern software is a complex beast. We need to be sure that even after the smallest change is introduced, our application continues to function as intended (also small does not equal

testing

Integration Tests Are Awesome

In April 2017 I gave a talk at CraftConf [https://craft-conf.com] titled The Ultimate Feedback Loop [https://speakerdeck.com/emanuil/the-ultimate-feedback-loop-learning-from-customer-reported-defects] [1]. In this talk I shared the results of an investigation of almost 200 customer reported bugs in a span of two and a half years. Lots of

presentation

No Country for Old QA

In March 2017 I gave a presentation at a QA conference: QA Challenge Accepted 3.0 [http://www.qachallengeaccepted.com]. The title was No Country for Old QA and in it I summarized my experience from the last 15 years working as QA. It also included my thoughts on where

defects

The Ultimate Feedback Loop

How We Decreased Customer Reported Defects by 80% In April 2017 I was at CraftConf 2017 presenting The Ultimate Feedback Loop [https://speakerdeck.com/emanuil/the-ultimate-feedback-loop-learning-from-customer-reported-defects] . InfoQ [https://www.infoq.com] noticed this presentation and wanted to do a short interview about our results. When I sent the replies, they

HTTP

Project Nagual

This is a short post to announce a project that I’ve been working on for a while now. It’s an HTTP simulator called Nagual [https://github.com/emanuil/nagual], that can be used to fake responses from 3rd party services outside of your control. We use it to

defects

A Tale of Two Bugs

(or why you should optimize for low MTTR) All bugs are not created equal. Ideally, we want to catch them all before releasing software to our customers, but this is a pipe dream. In Toyota Kata [https://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238] , Mike Rother explains the improvement kata, which

automated testing

Running Test In Parallel - Optimal Number Of Threads

June this year I presented at expo:QA conference [http://www.expoqa.com/expoqa16/en.html]. It was a case study on how we increased the execution time of high level automation tests more than 60 times [https://speakerdeck.com/emanuil/need-for-speed-accelerate-tests-from-3-hours-to-3-minutes] . Last week I received an email from one

automated testing

Eliminating a Class of Defects

Imagine the following line of PHP code: $db->GetRow("SELECT * FROM users WHERE id = $user_id"); This line is vulnerable to SQL injection, if an attacker controls $user_id variable. This is the safe version (using parametrized query): $db->GetRow("SELECT * FROM users WHERE id = ?", array(‘$user_id’)); Options You

static code analysis

PHP Unlocker

PHP-Unlocker [https://github.com/emanuil/php-unlocker] is a static analysis tool that detects potential, unintended DB table locks for PHP applications using ADOdb [http://adodb.org]. It searches your code for improper usage of StartTrans() and CompleteTrans() methods [http://phplens.com/adodb/reference.functions.transactions.html]. So why write this

quality

The Cost of Quality

TL;DR It all comes down to economics. What is the cheapest possible way for a company to find defects in its application? For some it's - let the users find problems. For others - extensive in-house testing before each release. Apples and oranges. Recently I happened upon a book

adaptors

Keep External Dependencies Under Control

Two months ago, we were moving production servers from one datacenter to another. It was supposed to be boring, no-thrills event. There was no new code to be deployed, only running it from different location. We were pretty confident, that there would be no problems, partly because we’ve migrated

node.js

Writing Unit Tests for Node.js Application

Given the widespread adoption of node.js it’s surprising that there is not much synthesized information about the specifics of writing unit tests on this platform. Recently I open sourced Nagual [https://github.com/emanuil/nagual], HTTP simulator for faster and reliable automation tests. these are the challenges I

continuous improvement

Seven Habits To Create Reliable Software - Continuous Improvement

This is the last part of a collection of seven blog posts about how to write reliable software. When a new developer joins the company we go over this list, and so I’ve decided to organize my thoughts on the subject a bit and share them with a wider

reliability

Seven Habits To Create Reliable Software - Solve Problems Immediately

This is the sixth part of a collection of seven blog posts about how to write reliable software. When a new developer joins the company we go over this list, and so I’ve decided to organize my thoughts on the subject a bit and share them with a wider

reliability

Seven Habits To Create Reliable Software - Monitor Production

This is the fifth part of a collection of seven blog posts about how to write reliable software. When a new developer joins the company we go over this list, and so I’ve decided to organize my thoughts on the subject a bit and share them with a wider

reliability

Seven Habits To Create Reliable Software - Don’t Assume Anything

This is the fourth part of a collection of seven blog posts about how to write reliable software. When a new developer joins the company we go over this list, and so I’ve decided to organize my thoughts on the subject a bit and share them with a wider

reliability

Seven Habits To Create Reliable Software - Resources Are Not Free

This is the third part of a collection of seven blog posts about how to write reliable software. When a new developer joins the company we go over this list, and so I’ve decided to organize my thoughts on the subject a bit and share them with a wider

automation testing

Seven Habits To Create Reliable Software - Test Your Code

This is the second part of a collection of seven blog posts about how to write reliable software. When a new developer joins the company we go over this list, and so I’ve decided to organize my thoughts on the subject a bit and share them with a wider