"Бритва Оккама": ACC-методология от Google

Давайте я покажу вам, как выглядят мечты и амбиции среднестатистического фаундера(заказчика) при планировании продукта: 

Продукт его мечты - эдакий супермультитул, с помощью которого можно решить любую проблему. Еще и ногти подстричь. 

А теперь давайте посмотрим, как выглядит в представлении tech-lead'а работа по планированию такого проекта:

Проблема заключается в том, что в представлении разработчика, каждый из элементов его продукта-супермультитула является одинаково приоритетным. И именно на этом он методично настаивает на каждом митинге. 

Такой подход к ведению проекта не выгоден никому из исполнителей, будь то менеджеры разнообразных направлений, разработчики, отделы контроля качества и технической поддержки. 

Но, что самое главное, не выгоден он так же и заказчику, так как изначально обрекает его продукт на медленное становление и с очень большой вероятностью хоронит его еще до того момента, когда результат трудов нескольких десятков(сотен/тысяч) людей увидит свет. 

В этой статье я поделюсь с вами прекрасной методикой планирования, использующейся в Google. Это действительно тот случай, когда заново изобретенный велосипед, благодаря правильному подходу, соревнуется в надежности и скорости с некоторыми творениями отечественного автопрома. :)

Итак, погнали.

П - Популярность

Мониторил сегодня статистику блога. Оказывается, кроме статей о багах Вконтакте, самый масштабный источник траффика - это очередной дайджест новостей из мира QA на DOU, в который успела попасть моя статья о портфолио для тестировщика.

В общем, спасибо вам, что читаете. Я прям такой весь азаза. Словом, растаял. :)

В комментариях к этому посту буду рад увидеть темы, освещения которых не хватает и вы хотели бы лицезреть их в моем скромненьком и уютненьком(ПОКА ЧТО!111адинадин ПОРАБОЩЕНИЕ ЗАХВАТ МИРА) бложеке.

Пис.

О постановке мозгов для тестировщика

Предположим, перед вами - текстовое поле. Самое обычное текстовое поле. В него можно ввести число от -99 до 99. После "тыца" на Enter на выходе получаете Строку в формате "Вы ввели число: ..."

И вот садится наш тестировщик Вася за машинку, открывает софтину и начинает думать:
1. Оукей, давайте сначала разгребемся с классами эквивалентности. У нас их четыре: 
[1..9], [-9..-1], [10..99]. [-99..-10]. 

2. Хм, а нолик-то ни туда, ни туда не влезает, и его вообще можно со знаками загонять в это самое поле. Давайте и это учтём. 

3. Продумаем тестирование граничных значений.

И вот сидит наш Вася, довольный и радостный, т.к. умудрился за столь короткое время покрыть все-все валидные значения и даже несколько невалидных(+0, -0, негативные граничные значения меньше -99 и больше 99)
Пятница, вечер, сидеть на работе не хочется, и наш Василий, хватая конверт с очередной зарплатой, идет отмечать окончание рабочей недели в рэсторан.

Но верно ли, что при правильном прохождении тест-кейсов, кусок, назначенный Василию для проверки, будет работать правильно? 

Теперь перенесемся на секунду в отдел разработки, где очень молодой, но безумно перспективный Junior Java Developer Сергей пишет код для данного функционала. И принимает его метод на вход далеко не строку, а коды ASCII-символов.
Сергей, будучи разработчиком перспективным, заранее определяет граничные значения кодов для чисел. Например, по верхней границе -  57(ASCII-код девятки). Но конец тяжелой рабочей недели и пламенная СМСка от любимой девушки не дают Сергею сосредоточиться, и вместо 57 в коде оказывается граничное верхнее значение 58.

Казалось бы, при правильных значениях всё должно работать.Но стоит нашему дорогому и горячо любимому пользователю ввести символ двоеточия, и программа будет свято убеждать его в том, что этот символ является числом. Итог: Сергея в предынфарктном состоянии срывают на работу(Release is coming)  прямо из объятий любимой, Василий остается без премии, а наш дорогой пользователь строчит гневные комментарии в раздел поддержки программы.

А всего этого могло бы и не случиться, если бы Василий заранее принял бы во внимание подобный аспект. Вот почему так важно ставить себе мозги в правильное русло, занимаясь тестированием. 

Тестируем спичку: типовое тестовое задание

""Неправильное" задание на проверку: протестировать спичку.

Мы не даем никакую дополнительную информацию об особенностях спички, способах ее применения, кто ее будет использовать и т.п. - в этом заключается неправильность задания.

Вам требуется протестировать 1 спичку. Охватить максимальное количество тестов, которые можно выполнить, используя только 1 спичку (в отчете важна будет очередность предлагаемых тестов).

Какие тесты можно было бы еще провести, если бы в наличии было:

• 2 спички
• неограниченное количество спичек

На это задание нет правильных или неправильных ответов, нам важно оценить вашу способность мыслить логически."

Вот такое тестовое задание прилетело мне на почту от одной из компаний. С одной стороны - штука довольно интересная, т.к. позволяет оценить и внимание к деталям и расположенность к работе в режиме "всё как всегда" и т.д. Ниже опишу, как тестировал спичку я.