|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Каким должно быть приемочное тестирование в agile-проектах? (Алексей Баранцев, AgileDays-2008)Материал из CustisWiki
 Доклад концептуальный, не ограничивается рамками достаточно «канцелярского» названия, мыслей много. Основная драматургия: противостояние людей (опытных творцов, весельчаков и разумных лентяев) и механизмов (инструментов, жестких социальных организаций, регламентов и методологий). Мысль — жесткие/водопадные методологии разработки → это если ваши бойцы тупая пехота. Тогда да, муштра и вперед на минные поля — ненадежность отдельного солдата спасет дублирование и избыточность, и заплаченная цена будет оправдана. Но если у вас мощные, кросс-функциональные парни-коммандос, то нужно организовать им комфортную команду и обеспечить полную поддержку. Холить, лелеять, обеспечивать им Fun и Profit. А то, что agile проекты иногда проваливаются, виновата не избалованность людей, а отсутствие способностей — в agile проекты нужно нанимать лучших, а дальше пускай они уже выкручиваются сами, главное их не обижать. В качестве метафор «подходов прошлого тысячелетия» автор использовал концепцию стимпанка, иллюстрируя ее картинкой из steampank-style календаря «The other side of the coin» (остальные картинки, если заинтересовали, можно найти тут [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]). Со своей стороны, мы заметим, что это несколько натянутая, и нехарактерная визуализация стимпанка. Стимпанк — это не депрессивные ржавые железяки, чешущие зад лоснящегося мускулистого рабочего (ммм…?), а скорее идея максимальной эволюции старинных технологий, в предположении, что им так и не было найдено замены. А вершина эволюции — это всегда красиво (дредноуты времени Iмв, последние паровозы, американские автомобили эпохи дешевой нефти). Так что если хотите взглянуть, что есть стимпанк, лучше смотреть соответствующие аниме-мультфильмы.  Вообще видов тестирования очень много (Unit testing, Integration testing, System testing, Performance testing, Reliability testing, Security testing, Usability testing, Portability testing, Acceptance testing) и хорошо автоматизируется только первый (Unit testing), а автоматизация всего остального — это увы, всего лишь пропаганда вендоров, которые втюхивают дорогущие инструменты автоматизации. Так что в тестировании все остальное надо делать вручную «на коленке» и здесь на первый план выходит квалификация тестировщиков (люди — самый ценный ресурс!). Следующая мысль — несправедливость Agile-благ для программистов и тестировщиков. Пророки Agile многое дали программистам — Refactoring, Unit-тестирование, Continuous Integration, парное программирование, Scrum со всеми его играми и т.п. Power и Fun, как и заказывали. Тестировщикам же из этого ничего не обломилось, кроме фреймворка FIT, но докладчик с негодованием открестился от этого убогого подарка («недопрограммирование» на вики-разметке, тотальная неполнота и ограниченность). С учетом предыдущей мысли, что для правильного тестирования все равно нужны крутые супертестировщики, возникает идея, что не «тестировщик — друг программиста», а «программист — студент, сдающий экзамен тестировщику». Т.е. нанимать надо самых лучших и задорого («Разве вы не знали, что тестировщики везде получают больше разработчиков?» Profit!), желательно из программистов достигших совершенства, и потерявших интерес к программированию («Саваоф Баалович был всемогущ. Он мог все. И он ничего не мог. Потому что граничным условием уравнения Совершенства оказалось требование, чтобы чудо не причиняло никому вреда.»), программистов надо отдать тестировщикам на съедение (отдать их код на Code Review), ведь единственная корректная метрика кода — это количество WTF-ов в минуту при проведении code-review. 
Местами этот фан выглядит несколько беспредельно. Только компания привыкла, что все вертикальные поверхности, включая шкафы-купе для одежды обклеены Scrum-taskами, возникают тестировщики и исписывают стены в туалетах (концепция «Testing on the Toilet»). Докладчик рассказал, что в Беларуссии была конференция SQA Days 4 на которой был доклад «Funny testing: как добавить драйва в работу» — какой еще Fun можно придумать команде что бы не работать. Ну и в целом, нужно смотреть видео. Хотя бы для того, чтобы узнать о силе волшебной фразы «Ну и что?».
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
 |
 |
 |
