Optimizing For Happiness (Page 2)

Optimizing For Happiness

Sign in Subscribe

Seven Habits To Create Reliable Software - Work In Small Increments

This is the first 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

Need for Speed - my slides from ISTACon and Agile Testing Days 2015

Conferences: ISTACon [https://istacon.org] Agile Testing Days [http://www.agiletestingdays.com] Topic: "Need for Speed - Accelerate Automation Tests From 3 Hours to 3 Minutes". Abstract: "All automated tests, other than unit, are slow and unreliable for the fast development pace every company craves. When a test fails, it’

Remove Unused Code

The story of how Knight Capital [https://en.wikipedia.org/wiki/Knight_Capital_Group] went bankrupt because of a software bug is well known. In summary, the high frequency trading company (once the largest equities trader in the U.S.), lost $460M for 45 minutes on 1st of August 2012.

Shift Left - my slides from BGPHP 2015 conference

Shift Left - my slides from BGPHP 2015 conference

Conference: www.bgphp.org Topic: "Shift Left - find bugs as early as possible". Abstract: "Shift Left is development paradigm centered on the fact that problems are cheaper to fix the early they are found. In web development world where fixes can be deployed instantly, you do not want to

Story Lenses

In parts of my life, where I don’t deal software, I’m creating games in the real world. One book that I find particularly useful for game design is The Art of Game Design: A book of lenses [http://www.amazon.com/The-Art-Game-Design-lenses/dp/0123694965]. ![The Art of Game

Complexity Can Kill You (Literally)

During the past months I’ve been presenting at various software testing conferences (ISTA [https://istacon.org], STAREAST [http://stareast.techwell.com] , NordicTestingDays [http://nordictestingdays.eu]) on how to write reliable automated tests for legacy applications. In order for this effort to be successful one need to get to know

Fix Your Unstable Automated UI Tests

Fix Your Unstable Automated UI Tests

Unstable automated tests are bad. You cannot rely on the results. It takes too much time to investigate if a failure is really a bug or a false positive/negative. By definition UI tests are the worst as there are lots of moving parts involved, and the planets need to

Remove SQL injections from PHP. Forever.

Remove SQL injections from PHP. Forever.

A little bit of history SQL injection [http://en.wikipedia.org/wiki/SQL_injection] in one of the top vulnerabilities in web applications for some years now [https://www.owasp.org/index.php/Top_10_2013-Top_10]. Once found, it’s not difficult to exploit, the exploitation is reliable and

On Unit Tests

Unit tests are the second of the three pillars of automated testing [https://emanuilslavov.com/the-three-pillars-of-automated-testing/]. A lot has been written about them so I’m not going to repeat it, just will point some highlights. Unit tests are integral part of the development and are written by developers. The

Static Code Analysis for PHP

Static Code Analysis for PHP

Static Code Analysis (SCA) is the first of the three pillars of automated testing [https://emanuilslavov.com/the-three-pillars-of-automated-testing/]. This is the practice of running tools that compile (depending on the language you use) and parse your source code, matching to see of various rules are violated. No code is executed

The Three Pillars of Automated Testing

The Three Pillars of Automated Testing

In order to have fast and quality release you need to implement and balance between the three automation pillars, not leaning heavily towards one or the other. They are interconnected and act as a different layers to defend agains various problems. More posts will follow to describe in details the

automation testing

Why do all of this

What you’ll find on this blog are topics mostly related to testing software application. In particular I believe in Shift Left paradigm: try to find any defects as early as possible, where the price of the fix is cheap enough [http://programmers.stackexchange.com/questions/133824/is-it-significantly-costlier-to-fix-a-bug-at-the-end-of-the-project] . You should