Bugs is a software thing

Bugs is a software thing.

In most business areas customers don’t pay for fixing issues. When you find a defect in your SLR camera, you just bring it back and get it fixed or get a new one for free. But in IT this is a norm when you pay for bug fixes as so this is some real functionality.

Ron Jeffries recently wrote a good story about defects. The main idea is defects shouldn’t be planned separately, they just have to be fixed and if it takes longer to release a feature we should factor this into estimates. In agile world we factor this into velocity.

But I’d like to touch base on why we usually try to plan and prioritize defects separately. Well, it is obvious, sometimes we have quite a few of them and some bugs take a lot of time.

As Kate mentioned in Ron’s story, we can minimize amount of bugs by learning from them. Correct. I’d also add that we can minimize amount of bugs by working in pairs and unit-testing. It’s rather obvious.

But the big thing which is not very well understood is that quite often bugs take a lot of time because of the way we tackle them.

I also quite often hear questions about the role of QA in agile projects. Many books just skip this question, people get confused and testing/bug fixing in a somewhat waterfall approach.

Let’s take a closer at a rather familiar loop many teams work in:

• developers implement a feature during iteration X
• when iteration X is over it is released for testing and being tested during X+1
• when testing is done, release goes to customers and they explore it during X+2

So what’s bad here? The delay in between implementation and feedback on it. It’s the root cause of everything else.

It takes a lot more time to fix a defect which is found after several weeks of work on other features, people just entirely lose context on it. Sometimes another developer has to fix defects in code of his colleagues which doesn’t speed things up.

When bugs arrive, the team works on another release already and can’t fix them immediately (the team can’t fix them immediately also because the context is lost), so bugs require some filing – clear description, steps to reproduce, severity, etc. All these things should be formally documented, testers can’t just explain them to developers. And some issue tracking systems are nasty.

Apparently, this way bugs affect schedule of subsequent releases. So bugs is a big thing now and require prioritization. Prioritization isn’t a simple thing, developers need to provide estimates, product owners have to make some tough decisions. It may be difficult to engage product owners, so delays become even bigger.

When a bug is fixed it needs to be retested, but there is again a delay between a bug fix and a another test, so we have some context switching for testers.

Actually, such a way often results in bigger and bigger delays between implementation and actual testing. Some teams come up with a really heavy-weight approach to stay on top of the bugs, but in fact they just slow things down even more.

To summarize, we get the following wastes:

• context switching (both for dev and test team)
• formal filing and tracking which drags time
• additional planning as a result (estimates, prioritization)

The key thing is to decrease delays, so the team should aim to test and fix defects almost immediately after implementation (let’s say during next 24 hours).

I heard about a brilliant approach to implement it. Unfortunately, I couldn’t implement this on one of my projects yet, but there are real projects which work in this way.

So in addition to a pair of programmers we also need a tester. They form a triplet (triple programming). The triplet works on each feature together:

• the tester take part in all discussions
• when developers work on a feature, the tester creates test cases
• when developers think the feature is ready it gets tested immediately, developers can take care of e-mails and other stuff during testing
• when a bug is found, the tester just shows it to developers, it is worked on immediately
• during delays the tester automates tests (developers can also help)
• after the tester is happy about quality, he shows the feature to customers
• any issues found during the demo are fixed immediately 

Apparently, some bugs are discovered later and go the tough way, but most of the time:

• defects do not require documenting
• defects are found and fixed in a reasonable time frame before people lose context
• explicit planning is not required

But again, the key thing is to get feedback ASAP, no matter how.

I welcome your comments.

Outlook: hide delayed tasks

There are certain tasks which I need to do, but I can’t do them until some date/time.

What I want is to put such tasks into my task list, but I don’t want them to be visible until their start date. I don’t want to put them into my calendar, I can do them after day X, but don’t know when exactly I will find time for them, so my task list is a better fit.

So the first step is to actually specify a start date for such a future task and then set up a filter on your outlook task list to hide delayed tasks and this is a little bit trickier:

1. Click on “Arrange By” on top of your task list and select “View Settings”
2. Click “Filter” button and select “Advanced” tab; by default it filters in current tasks (where Completion Date doesn’t exist AND Completion Flag doesn’t exist)
3. We also want to filter in tasks with Start Date “on or before” Today, so you click on a “Field” button under Define Criteria, select a Start Date there, specify “on or before” in Condition and type “Today” in the Value text box
4. Unfortunately this filters out all tasks without start date, apparently we want to show current task OR tasks without Start Date, so you again add Start Date field and pick up “doesn’t exist” Condition from a drop down there 
5. This is it, enjoy, delayed tasks are filtered out now

(here is how your filter should look like)

Note that conditions from 2nd and 3rd points are actually appended to resulting query using AND logic, while 3rd and 4th conditions should use OR logic. Actually, I thought that you can’t specify this logic in Advanced tab since all conditions are ANDed by default, so initially I hacked my custom query in SQL tab (poor me, those SQL queries look pretty ugly, you can check an auto-generated one).

Funny enough, but Advanced filter is so advanced that it understands 3rd and 4th conditions should be ORed. So actually you don’t need to mess around with a SQL query.

Would you read me in English?

Я читаю много блогов на английском и иногда чешутся руки оставить какой-то комментарий. Использовать свой OpenID для shсoder.by как-то глупо, ведь тут все на русском.

Подумываю, может мне стоит начать писать на английском? Лень заводить какую-то отдельную площадку.

Я думаю, что меня все равно читают гики/айтишники и проблем быть не должно, но все-таки интересно узнать ваше мнение, внизу опрос. Если отвечаете вряд ли или читать будете, но думаете, что это просто плохая идея, то не поленитесь в комментарии написать почему. Или даже так: если думаете, что идея хорошая, то отметьтесь в комментариях тоже :)

Будете ли вы читать меня на английском

Теперь беленький

Многих угнетал темный цвет фона - жалобы учтены, теперь он опять беленький.

Плюс к этому бложик можно посмотреть в неожиданных ракурсах, например, http://www.shcoder.by/view/sidebar#!/ или вот http://www.shcoder.by/view/flipcard#!/. Последний забавен тем, что все мои посты влазят на одну страницу (ну, почти все). Как-то мало я написал.

Вьюшками сильно не злоупотребляйте - там счетчики не работают. И рекламка не показывается (черт, палюсь-палюсь).