Agile and numbers

In his recent post, Seth Godin writes:

When you measure the wrong thing, you get the wrong thing. Perhaps you can be precise in your measurement, but precision is not significance.

On the other hand, when you are able to expose your work and your process to the right thing, to the metric that actually matters, good things happen.

We need to spend more time figuring out what to keep track of, and less time actually obsessing over the numbers that we are already measuring.

This is the essential part of the "agile development".
In my current team we spend lots of time on "Backlog grooming sessions" arguing on numbers, getting asked "why is it 5 not 8?"
On the same time, nobody cares on getting the Burndown Chart to look like burn down. The reason is "We have many important and urgent tasks with vague deadlines emerging meanwhile in the sprint."
So on our "Sprint planning" meeting we are basically putting the "precisely measured" tickets to a heap of immeasurable ones. What we get is precisely immeasurable. Like dropping 10 carat diamonds to a bucket of soil and trying to estimate the bucket weight.
What precision we might get?

Moreover, the measurement does not influence our actions in any way.

Our the most precise scale of estimations probably should have 3 values:
- "It's OK to try to do this now"
- "Better not to try now"
- "We don't know"

Having the priorities in place, this simple scale will give us enough information to plan sprints, and dramatically reduce time spent on estimation and planning.

Test Design Strategy

Updated my Test Strategy Template with a new section.

Enjoy :-) Comments are welcome!

Test Design Strategy

Test Design activity is a process of identifying and formalizing Test Cases and Test Suites (in forms of Check Lists, mind maps, etc.) in regards to risk weights, i.e. the value customers might loose if the test is not conducted; or in other words, the risk of unawareness of the unwanted behavior of the system.

Each Test Case is explicitly related to a piece of Requirements, as well as to Test Suites it is run under.

Сем проти Джеймса (скандали-інтриги-розслідування у віршах)

Якщо ви достатньо давно в тестуванні, то маєте знати Джеймса Баха (James Bach). Не менш відомою постаттю у галузі  методологій розробки є Сем Канер (Cem Kaner), автор багатьох книжок і публікацій. Колись давно вони разом були співзасновниками Школи Контексто-керованого Тестування (Context Driven Testing School), що заклала засади сучасного розуміння дослідницького підходу (exploratory testing). Після того вони чогось посварилися, побили горщики, та перестали спілкуватися. І щось мені підказує, що розбіжності в них були зовсім не у способах тестування, а у чомусь іншому. Але що було, те загуло. 

Мої RSS підписки про Тестування. Березень 2016

За рік я знайшов кілька нових, вартих уваги блогів.
Ось останній перелік тих, хто активно пише щось корисне.
(минулорічний список тут http://lazytesterua.blogspot.com/2015_03_01_archive.html)

Блоґ	Коментар
Gerald Weinberg's Secrets of Writing and Consulting	Jerry Weinberg - американський ІТ консультант зі стажем. Цей мудрий чоловік був моїм відкриттям року. Усім раджу його книжки. Від 80-х він їх чимало написав.
Agile Testing with Lisa Crispin	Цікаві речі про тестування і менеджмент
Gojko Adzic	Розумний дядько, консультант в ІТ. Пости про автоматизацію дуже мене надихнули.
QA Hiccupps	Тестер, що намагається нестандартно дивитись на речі. Знайшов його за серією публікацій "Тестування - як жартування" (Joking With Jerry)
Uncharted Waters	Чудовий блог про різні аспекти роботи в ІТ
UX Movement	Свіжі погляди на дизайн користувацьких інтерфейсів
Seth Godin's Blog on marketing, tribes and respect	Багато пише про все підряд. Має надихати на думки...
Linux.org.ru: Новости	Раніше не згадував, але оце я читаю вже дуже давно. Щоб бути в курсі.

Where to start to automate your checks?

So you are an almost only off-shore tester on a project, and want to automate some of your daily checks to have more time for actual testing. But you lack skills to do it right, or you think you do. And the automation tools and frameworks do not suddenly appear in a project. Somebody needs to implement them.


This picture is familiar to lots of us. But how can we push the deal out of this vicious circle? If not directly to a project's but for self-development sake?

We often hear the management saying: “We do not need automation at this point.”
And they are right!
They do not need an automation of those checks YOU PROPOSED, if it is done by YOU INSTEAD of the work you are hired for, especially in that weedy way YOU NOW would do it.
Whole disadvantage from their perspective!


Starting to write code is always hard and slow at the beginning, because the code quality is in direct proportion to an amount of hours one spent attentively staring at it. So here I propose the first points to look at start:

Є час, хочу автоматизувати. З чого почати?

Автоматизація сама на проектах не з’являється, її хтось має писати.

Ця картинка знайома багатьом. Але як зрушити справу з мертвої точки? Якщо, навіть, не для проекту, а для свого розвитку?

Ми чуємо від керівництва "На даному етапі нам не потрібна автоматизація."
І це так!
Їм не потрібна автоматизація саме тих перевірок, що Ви їм запропонували, якщо її будете робити Ви замість тієї робити, на яку Вас найняли, та ще й так недолуго, як Ви зараз це робите.
З їхньої точки зору - суцільні мінуси!

Власне тестове середовище на docker

Для чого тестеру може знадобитися свій інвайронмент, якщо можна просто почекати, доки код виллють на тестовий сервер?

Мені це питання задають постійно. І відповідь, як завжди, залежить від контексту.

Щось ризиковане треба перевірити у середовищі, яке не шкода; для чогось потрібні особливі налаштування, недоступні на тестовому сервері; а хтось, як я, хоче тестити ще у девелоперській гілці, бо не може дочекатися, доки новий код нарешті дорев’ювлять і замерджать в develop.

В епоху віртуальних машин існує кілька загальних інструментів, що дозволяють запустити собі власне тестове середовище, та заразом вижерти зайву оперативку та довантажити процесор вашого комп’ютера до "прийнятних" 104%.

Як розгорнути два зв’язаних docker-контейнера: веб-сервер із Вашим проектом та базу, подивимось на прикладі PHP та MySQL.