Андрей Платов
Сегодня не программировал, пол-дня покатался по побережью в попытке открыть счет в банке. Форма на сайте не работает - думал зайти физически, но в понедельник отделение оказалось закрыто. Вторую половину дня слегка уделил бизнесу: написал письмо коллегам и кастомерам, которое по большей части и прилагаю (за исключением коммерческих деталей).
Про тестирование
Всем привет!
Саша Т. написал достойный анализ ситуации и разумные предложения по тестированию. Но Саша писал их “изнутри системы”, я же хотел бы поделится мыслями и наблюдением “снаружи”.
Мысль следующая: “Команда X (как единое целое) не считает тестирование чем то важным”. Поскольку эта “мысль” выглядит как камень в огород команды - у меня есть неколько пояснений, почему это так и почему не стоит воспринимать ее в штыки.
Во-первых, очень многие команды не воспринимают тестирование серьезно. Во-вторых, на каких-то этапах развития проекта любое тестирование (ручное, автоматическое, и так далее) на самом деле не только не важно, но и является бессмысленной тратой времени и денег. В третьих - я сам до 2005 года считал тестирование пустой тратой времени (которое гораздо важнее потратить на разработку), и я уверен очень многие и сейчас думают так, как старый (вернее, молодой я).
Действительно, если комада постоянно переделывает предмет тестирования, каждый раз выдавая новый предмет, с другим интерфейсом (API или визуальным), с другим поведением, и так далее, то какой смысл тратить силы на тестирования предмета, на смену которому завтра придет другой (скорее всего новый предмет будет называться так же как и предыдущий, но пусть нас это не обманывает - это будет новый предмет).
Теперь про то почему я считаю что “Команда X (как единое целое) не считает тестирование чем то важным” (еще раз это ни хорошо и не плохо, это просто факт, и серьезное отношение к тестированию безусловно бы привело к просадке в других местах, например в скорости реализации новых фич).
Первое: отсутствие Continuous Integration. Поставить сервер Continuous Integration - это не значит что у вас есть Continuous Integration. Это значит что у вас есть в лучшем случае автоматизированная сборка. Continuous Integration - это процесс разработки. Неотъемлемая часть такого процесса - “зеленый билд” и автоматизированные тесты. “Зеленый билд” это вообще лакмусовая бумажка, показывающая наличие или отсутствие Continuous Integration процесса и отношение команды к тестированию.
Тестирование (и тесты) могут быть важнейшей частью процесса разработки, а могут быть несерьезное как у меня до 2005 года: я конечно не против если кто-то помогает мне с тестированием, и даже находит баги необходимые к починке, и если меня бы спросили о тестировании я бы ответил, что да мы тестируем, и у нас есть тесты и люди-тестировнщики, и это все очень полезно, но все это несерьезное отношение к тестированию, поскольку для меня тогда тесты не были важнейшей и неотъемлемой частью процесса.
Вообще, чтобы команда серьезно озаботилась тестированием необходимы два магических компонента: кастомеры и регулярные обновления. Без этих двух вещей магия не случится, и можно долго рассуждать о тестировании, но все это будет не серьезно (как бы серьезно мы не звучали и с какой бы серьезностью мы не утверждали обратное). Чем важнее кастомеры, и чем регулярнее обновления, тем серьезнее у команды отношение к тестированию.
Это непреложное правило которое очень просто работает: если обновления редки (раз в пол-года, или даже раз в квартал), то команда надеется на себя (и это очень правильно): у команды найдется достаточно времени перед релизом (ну или она так наивно полагает, что время найдется) для того, чтобы “отрелизится”. Пофиксить баги, и выкатить “релиз” за который не стыдно, ну или там не дадут по голове. В таком режиме нет очевидных причин относится к тестированию серьезно и тратить на него немалый ресурс.
Изменение сознания происходит когда продукт начинает уходить кастомерам чаще: раз в месяц или раз в две недели. Лучше раз в две недели - в таком режиме команде не на что надеятся, кроме тестов. У нее нет времени на “релизы” (под релизами понимается тот процесс который у многих происходит перед релизом - feature freeze, починка багов, тестирование, починка багов и с начала). Даже если заниматься “выпуском продукта в мир” одну неделю (что очень жестко для большого продукта), при релизах раз в две недели времени на разработку практически не остается.
Сознание меняется у всей команды: с самого верха до самого низа. И это в первую очередь касается процессов. Дело даже не в самих тестах и инструментах. К любой команде можно “прикрепить” отдел тестирования с самыми лучшими специалистами и инструментами, и ничего существенно не изменится. Серезное отношение определяется не количеством и качеством людей участвующих в процессе тестирования, а отношением к нему лидера, программистов, всех остальных участников. Это отношение определяет (влияет на) процесс разработки в целом. Чтобы поставть такой процесс необходим высочайший административный ресурс проекта. Такой процесс может поставить только человек, с высшими командными полномочиями.
Возьмем, к примеру, пресловутый “зеленый билд”. Какой бы замечательной не была команда QA, только с высоты управления всем проектом можно “нагнуть” всех у частников проекта на то, что без “зеленого билда” нет будущего - и понизить приоритет всем задачам пока такой сборки не будет. Никто другой, кроме лидера проекта не обладает для этого досточными полномочиями.
Далее: меняется отношение к тестам - не важно какую замечтельную фичу или что-то там ты сделал, если твое изменение ломает билд - твоего кода просто не существует (до выяснения проблемы). Качество кода, определяемое тестами, становится приоритетнее всего остального. Наполнение тестами тестовой базы приносит радость, а людей которые ее наполняют целуют в задницу, ибо наконец на собственном опыте почувствовали как они облегчают им жизнь.
Проект с серьезным отношением к тестам - это дорого. Это время разработчиков. Они не могут забить на непроходящие тесты, они вынужденны докапываться до истины, а не просто перекидывать проблему на соседа (“это вроде у тебя там”) и обратно. Это время на создание инструментария: как бы там ни казалось в любом крупном продукте с серьезным отношением к тестированию присутсвуют самодельные тествые фреймворки и инстументы написанные под их специфику - я не раз про такое слышал общаясь с людми про RCPTT, и количество кода в проекте созданного исключительно для тестирования может достигать 50% кодовой базы.
Конкретика по нашей ситуации
…вырезано…
Опыт
Мы участвуем в разных проектах с разным отношением к тестированию. Кто-то серьезно вкладывается в тестирование и качество и всегда имеет на руках качественный продукт. Кто-то не парится по поводу тестирования и быстро идет вперед. Невозможно иметь и то и другое (и дело даже не в том что это безумно дорого), дело еще и в том что одно частично противоречит другому - быстрое движение вперед прямо зависит от скорости изменений, качество зависит обратным образом.
Соответственно, отношение проекта к тестированию должно определятся стратегией на высшем уровне. Расстановкой приоритетов между качеством/фичами, и так далее. Инструменты и тестировщики в вопросах тестирования дело уже второе.
Какой подход выбрать - стратегический вопрос, который должно решать руководство. Исторически так случилось, что Саша Т. и девочки что-то пытаются сделать с тестированием не имея ни полномочий ни ресурсов добится чего-либо существенного в этой области. Хотелось бы снять с нас эту ответственность и предать лицу обладающему такими возможностями. Что касается ресурсов (тестировщиков), если в людях есть необходимость, то я думаю нет никаких проблем девушкам продолжать заниматься тестированием под соответсвующим руководителем выполняя задачи им поставленные.
Простите за длинное письмо, я даже не думаю что мои мысли что-то изменят, но для того, чтобы быть “на одной странице” и конкретного разговора про дальнейшие шаги в тестировании, давайте определимся с важнейшим вопросом: разработка X - это Continuous Integration процесс или нет? От ответа на этот вопрос зависит гораздо больше чем кажется на первый взгляд.
Спасибо, Платов