Это перевод статьи Eli Lopian, основателя компании Typemock. Он же является исполнительным директором корпорации. Eli имеет более чем 17-летний опыт в сфере разработки. За это время он успел поработать в таких глобальных организациях как AMDOCS (NYSE:DOX) и Digital Equipment Corporation (DEC). В его обязанности входила оптимизация процесса разработки и внесение необходимых корректировок для поддержания его эффективности. Данная статья поясняет как unit-тесты повлияют на традиционный подход к тестированию в будущем, и какой эффект они имеют уже сейчас.
С начала Промышленной Революции, около 250 лет тому назад, машины активно стали замещать человеческий труд на заводах, фабриках и шахтах. С одной стороны это ведет к увеличению экономического роста, с другой – к увольнениям рабочих, чей труд был заменен. Часто люди после увольнения не в состоянии найти новое место работы или заняться переобучением. То, что сейчас происходит в области QA поразительно похоже на описанные выше процессы. Только взгляните на невероятный прирост количества компаний, занимающихся тестированием, как например Mercury Interactive, на протяжении девяностых годов прошлого века. Процесс тестирования и сами команды QA пришлись весьма кстати во времена интернет бума в девяностых. Тогда количество программ, выпускаемых на рынок, возрастало экспоненциально. Это привело к росту числа инструментов разработки и расширения штата тестировщиков. Однако, со временем неудержимый рост экономики стал постепенно спадать, бюджеты становились все скуднее, все более широким становилось применение Agile-методологий, само программное обеспечение становилось более широко распространённым и автоматизированное тестирование набирало обороты. Перед ручным тестированием встали те же проблемы, что были характерны для ручного труда на предприятиях во время Промышленной Революции. Многие QA инженеры стали переходить на новые должности, подразумевающие использование навыков программирования и разработки в повседневных задачах. Команды тестирования стали подвергаться изменениям, становиться многофункциональными. Границы между департаментами постепенно начали сходить на нет.
Но давайте вернемся на несколько шагов назад и посмотрим, а как же было раньше. Подавляющее большинство компаний выбирали водопадную модель разработки с 1950-х годов. Такой подход позволял команде сначала полностью спроектировать дизайн, затем сконцентрироваться на коде, передать его тестировщикам и после – начать исправлять дефекты. Поскольку разработчики постоянно находятся под давлением, они начали полагаться больше на отдел QA. Это привело к замкнутому кругу. Нанимаются новые тестировщики, разработчики еще больше расслабляются и передают в QA более сырой код. В какой-то момент девелоперы вовсе перестали тестировать свой код.
Это крайне негативно сказалось на эффективности работы и в конечном итоге вылилось в срыв сроков контракта. Конечный продукт не попадал к заказчику к запланированному моменту.
В то же время, в феврале 2001 года, во времена уже упоминаемого интернет бума, был принят Agile Манифест и с этого момента, появилась другая точка зрения на процесс разработки. Agile словно вдохнул новую жизнь в этот процесс. Новой целью в мире Agile стала адаптация к бесконечным изменениям и стремительное создание работающих программных модулей. Основной упор приходился именно на программистов и по мере распространения новой методологии, услуги QA были необходимы все меньше. Это означало, что тестирование находится одной ногой за бортом IT-бизнеса.
Больше тестировщиков – больше проблем
Разработка корпоративного программного обеспечения – занятие не из дешевых. По этой причине, зачастую, на середине проекта обнаруживается, что команда более не вписывается в первоначальный бюджет. В таком случае руководство вынуждено искать пути решения стоящей перед ними проблемы. Существуют три основных пути, по которым, в таком случае, может пойти команда:
1. Пополнить бюджет – всегда можно добавить больше денег, тогда можно будет уложиться во время. Но следует учитывать, что тогда и возврат от инвестиций будет меньше. Всегда следует учитывать все риски. По итогам проведенного анализа, вы можете прийти к выводу, что дальнейшие инвестиции не целесообразны. Не самый лучший из вариантов.
2. Отказаться от части функционала – ни разработчики, ни руководство не хотят поставлять клиенту программу, которая не делает того, чего от нее ожидают. Это также не выход.
3. Оставить качество на низком уровне – в повседневной жизни мы часто встречаемся с теми или иными дефектами. Что касается программного обеспечения – качество продукта здесь играет первостепенную роль. Тем не менее, третий путь становится наиболее распространенным среди компаний.
В результате мы получаем нарушение привычного порядка – с одной стороны разработчики либо заняты, либо ленятся довести свой код до оптимального уровня, с другой стороны – менеджмент урезает расходы на тестирование. Вот где могут помочь принципы Agile.
Преимущества Agile
Благодаря популярности Agile, разработчики и руководство активно применяют методологию для решения своих проблем на пути к улучшению софта. Однако все еще остаются проблемы, которые требуют внимания. В чем взгляды менеджмента и программистов сходятся, так это в том, что они хотят производить ПО в кратчайшие сроки и, желательно, при минимальных расходах.
После интернет бума и последующего отката в росте экономики, компании осознали необходимость выпуска высококачественного софта без высоких расходов на его производство. Но как урезать затраты на QA?
К счастью, Agile методология предполагает тестирование своего собственного кода. Прохождение юнит-тестов говорит о том, что выбранный модуль работает и выполняет свою функцию. Конечно, это подразумевает тесную кооперацию всех отделов. Продакт менеджер определяет, каким должна быть программа, чтобы отвечать требованиям заказчика. Разработчики и тестировщики вместе работают над написанием спецификаций. Далее девелоперы пишут юнит-тесты для своих модулей. Корректно протестированый код – единственный способ доставить работающую программу, так сказать, ядро Agile процесса. Проведенное по стандартам, юнит-тестирование подтверждает, что код работает так, как задумывал программист. Отдел QA все еще осуществляет тестирование нестандартных ситуаций, в то время как разработчики постепенно начинают осознавать ответственность за качество своего кода. Одним из фундаментальным столпов методологии Agile является работающее ПО. А некоторые принципы приведенной методологии, такие как TDD (Test Driven Development) и юнит-тестирование выполняются девелоперами. Так в чем же суть юнит-тестов и почему их стоит использовать? Особенность юнит-тестирования в том, что оно выполняет проверку определенного участка кода. Когда каждый следит за своим модулем, эффективно и быстро правит найденные дефекты – стоимость всего проекта снижается. Без четко поставленного процесса юнит-тестирования крайне трудно оставаться в рамках Agile. Все эти бесконечные изменения требований, дизайна и самого кода в конечном итоге приводят к еще большему количеству дефектов, и без знания их специфики, разработка рискует закончится провалом.
Юнит-тестирование – возможная причина смерти QA
Повторим: юнит-тестирование есть процесс, направленный на проверку работоспособности вашего обособленного участка кода. Заканчивается он только тогда, когда есть уверенность, что данный кусочек гармонично впишется в общую картину системы. Доказано, что применяя юнит-тестирование можно добиться покрытия кода, равное 90 процентам, и, в отличие от ручного тестирования, юнит-тесты могут, со временем, эволюционировать для решения более сложных задач.
Только не подумайте, что основная мысль статьи – юнит-тесты спасут мир. Они не являются панацеей. Однако, это наиболее подходящие кандидаты для тестирования кода, из-за их низкой стоимости. К тому же, конечный продукт получается более качественным и удается сократить сроки.
Если вы применяете QA отделы, то процесс затягивается. Баги отправляются к разработчикам, затем их изменения идут обратно к тестировщикам. Применение же юнит-тестов минимизирует вероятность дефектов, как только разработчик закончил работу над своим модулем.
Выводы
Как можно судить из названия статьи – QA более нежизнеспособно, в традиционном понимании. Тем не менее, мы все еще можем видеть повсеместное применение QA. Вопрос в том, как долго это продлится? Лично я придерживаюсь мнения, что в скором времени задачи тестирования перейдут непосредственно к разработчикам и специалистам QA придется подстраиваться под новый порядок.
Да, мы все еще будем видеть тестировщиков, но они скорее будут частью команды разработки, нежели отдельного департамента. Содержание QA в условиях применения Agile становится слишком дорогим, поэтому тестировщикам придется меняться.
Я искренне считаю, что мы движемся на пути к светлому будущему, где разработчики будут писать более совершенный, качественный код. Дело остается за руководством корпораций. Перед ними есть пути снижения затрат и выпуска конкурентоспособных продуктов. Им остается их применить.
Перевод статьи «The Day the QA Department Died», Eli Lopian.
www.infoq.com/articles/day-qa-dept-died
Автор: Evgenia_s5
