Стратигия, План, Методика

Я противник написания документов ради документов, и чем дальше, тем более рьяный. В компании из трех программистов и полутора тестировщиков не нужны никакие глобально написанные "стратегии". Зачастую вся стратегия укладывается в двух словах, понятных всем - тестим отчеты, сдать в конце недели! К черту нагрузочные, функционал только в отношении отчетов. Вот и вся стратегия, что вам еще нужно? План выглядит ровно также. Это просто список тестов, которые вы собираетесь провести. В мелкой компании План тестирования - оглавление методики, а стратегия - введение перед списком тестов. И то, если есть желание ее писать. Читать это все равно некогда.

Однако, тесты писать - надо. Вопрос в подробности написания. Нужно ли расписывать все до точки или достаточно названия теста? Я задаю себе этот вопрос по другому. Кто будет это читать? Если читать никто не будет, незачем и писать. Ну не придут ко мне тестиовщики из детского сада, что бы я всё дотошно и подробно расписывал. И штат в 10 раз внезапно не увеличится. Да пока я все напишу программеры успеют пять раз все поменять. То что я напишу, буду читать в первую очередь я, мои коллеги, которые и так в курсе как это проверять, и программеры, которые при нахождении бага прибегут и будут пытать "А что вы тут делали что бы оно вот так вот....?" Многие тесты сокращаются в одну строчку и из них получается чеклист.

Feature List. Еще немного о списке фич

Вот как обычно происходит создание отдела тестирования? Есть “контора”, “контора - пишет”, причем в прямом смысле, пишет код. Контора маленькая, программа – маленькая, требования все три с половиной программиста знают и так, то есть не фиксируют. Заказчик один, он продукт получает, платит сколько то денег. Главный находит еще и еще клиентов, нанимает еще программистов… Коммуникации между программистами неизбежно ухудшаются, хотя бы просто в силу увеличения команды. Требования и баги от клиентов превращаются в бесконечный поток, и программисты в первую очередь пытаются избавиться от непродуктивной работы, то есть – от тестирования. И тогда на сайтах с работой появляются объявления – требуется тестировщик.

Приходит тестировщик, и начинает писать… А вот что? Часто от тестировщика требуют написать “процесс”. Или регламент. Или сразу внедрить автоматизацию. Или начать тестировать и писать тесты. Требуют отчетов и планов. Голова идет кругом, работы непочатый край, и за что не возьмись – срок непредсказуем. Начальство теребит – когда?

Моё искреннее убеждение, основанное на личном опыте – всё это потом. Потом тесты, потом планы, потом процессы. Главное и первоочередное – список фич. Даже просто составив этот список, нужно прийти к главному и попросить расставить приоритеты. Это даст вам представление о том, в какую сторону копать. От саппорта вы по этому списку узнаете на что больше всего жалуются заказчики, где гнездовища багов.

Список фич хорош тем, что он конечен. Список требований или список тестов – очень непредсказуемые по объему документы. А список фич – нет. Пишите его как вам удобно, тестлинк мне показался самым удобным из бесплатных, хотя для этого не сильно приспособлен, да и сырой он как тряпка под дождём. Я задумываюсь написать собственный инструмент для ведения списка, ибо навыки необходимые есть, и задача не кажется слишком сложной. Останавливает только то, что потом захочется туда приклеить и требования, и тесты, и баги, и прогоны по ревизиям, и построение отчетов. И получится какой то аналог какого ни будь платного продукта, причем заведомо худшего качества.

Но это я отвлекся. Программу на фичи дробить следует по своему усмотрению. Основным критерием я избирал такой показатель как тестируемость. Если я нечто могу протестировать и сказать – вот, это работает – я объявлял это фичей. Разногласий с программистами здесь как правило не возникает. Есть, например, отчеты, 20 штук. Отчеты объявляются фичей, и каждый отчет тоже объявляется фичей. В отчёте есть графическая и табличная части? Ещё две фичи. Древовидная структура становится очень удобным способом представления списка.

На сегодня всё. Пора дочку спать укладывать.

SCRUM или рыночные отношения

В этом посте я отступлю от темы тестирования и коснусь управления разработкой, a именно, популярной и многими любимой технологии SCRUM. Эта технология оценки трудоемкости и управления задачами обладает многими преимуществами перед классическим водопадом. Она проста и понятна.  За исключением одного момента – Story point. Эти условные “баллы сложности” вначале всегда вызывают вопросы – что же это?
Классики советуют не думать о них в понятиях времени, тем не менее, в большинстве случаев использования, поинты приводятся к часам, ну или дням, кому как удобнее. Думать о storypoint как о строчках кода - тоже неправильно. Количество строк кода очень сложно определить заранее и зачастую это не показатель.
Когда я рассказывал о scrum своим коллегам, я получил вопрос – каков же физический смысл в этих оценках?
Физический смысл донельзя прост – это деньги. Смотрите, что получается…

Давайте для простоты приравняем очко сложности ста рублям.  Тогда задачи будут оцениваться в деньгах. Процедура оценки задач станет торговлей – руководитель проекта выставляет задачу на торги, эту задачу один программист готов выполнить за 1000 рублей, другой за 750. Остальная практика оценки задач не меняется, не буду описывать – все по скраму. Мы избавляемся от преобразований баллов в человеко-часы, это больше не нужно. Программисту сразу понятно, сколько он заработает и сколько он теряет занимаясь прокастинацией. Сроки отходят на второй план, они будут минимальны.
Думать о сложности в понятиях денег проще и руководителю и программисту. Руководитель имеет перед собой общий бюджет проекта, как правило согласованный заранее, его задача не выйти за эти пределы. Думая о проекте в абстрактных единицах легко забыть о реальности, а тут – живые деньги, которые получит программист за выполнение определенной задачи. Понятия “хороший” программист и “плохой” программист обретают свой физический смысл – хороший выполняет задачи за более короткое время и, о чудо!, получает больше. Причем сразу, не дожидаясь признания коллег и начальства, зачастую субъективного.  Программист волен в определении сроков выполнения той или иной задачи – ему все равно заплатят по сложности. Мотивация налицо – быстрее делаешь – больше получаешь. Вопрос качества пока отложим, тестировщики должны получать зарплату по другому, но очевидно, нельзя засчитывать задачу выполненной без ее принятия ответственным лицом. Это относится не только к скраму.  Программист волен в распределении времени в пределах задачи, сколько потратить на код а сколько на изучение проблемы.  Смысл в графике рабочего времени снижается до минимума, достаточно определить время общих собраний или вовсе обойтись смс рассылкой.

Я надеюсь, что такой взгляд на SCRUM вызовет обсуждение, жду ваши комментарии

Новая работа, новые коллеги

Вот еще вчера  вы были инженером, а сегодня вас позвал директор и сказал - Вася! Ты теперь начальник группы тестирования, в помощь тебе вот эти двое, ибо самые молодые, давай, жду от тебя план действий. Знакомо? Многим руководителям пришлось пройти именно по такому пути. 

Достаточно популярный вопрос на форумах тестировщиков, а в особенности их начальников - как построить группу(отдел, сектор) тестирования с нуля. Один раз мне это уже удалось, и вот, новая работа, старые задачи - решением руководства создана группа тестирования во главе с вашим покорным слугой.  Собственно, "вторая часть марлезонского балета" и будет основным предметом дальнейших публикаций в этом блоге. 

Прошло два месяца с момента последнего поста, один из них нерабочий, второй - рабочий донельзя. Нервная и физическая нагрузка у всей конторы зашкаливает за красную линию.  Близятся бАльшие испытания, "испытания всего"... Ударная сборка стендов, подготовка оборудования, написаний методик и программ испытаний умножается на финансовый кризис. Люди работают на износ, и самое худшее, САМОЕ ХУДШЕЕ, не то, что мы сдачу вовремя почти ничего не получим сверху, не то, что за несдачу вовремя с нас снимут три шкуры, а то, что совершенно непонятно, когда это закончится. 

No goals - no results. Аксиома, блин. 
Самая худшая цель - "сделать все".  Самый худший срок - "как можно быстрее"

Редеплой

Для тестирования зачастую не нужны инсталляшки. Даже более того, при мелких фиксах удобнее заменить из репозитория изменившиеся файлы, нежели проводить полную переустановку приложения. Однако в таком виде поставлять заказчикам софт, сами понимаете, нельзя. На выходе тестирования делается снимок репозитория с провереной ревизии, в папку /tags/ . Оттуда и собираются инсталляшки, патчи, системы разнообразных конфигураций... Примерно так должно быть, имхо.