вторник, 31 июля 2012 г.

О роли QA


В наши дни разработчики делают все больше работы связанной с тестированием и выпускают работающий продукт каждую итерацию. В связи с этим роль QA становится все менее значительной.
Индустриальная революция началась примерно 250 лет назад, и с тех пор машины стали все чаще заменять людей при выполнении работ на фабриках, полях и шахтах. Это привело к значительному росту экономики. Но вместе с тем, замещение работы человека машиной породило недовольство многих людей, которые не смогли найти новую работу или сменить квалификацию. Данной проблема имеет некоторую схожесть с ситуацией, в которой сегодня оказались тестировщики. QA были спасителями во время Интернет бума – когда бюджет разработки виртуально были практически неограниченным и программное обеспечение разрабатывалось по экспоненциальному рейту. Однако, по прошествии некоторого времени экономика сдулась, бюджеты лопнули и в это время широкое распространение получила Agile-разработка, которая принесла с собой автоматическое тестирование. Подобно тому, как некоторые виды ручного труда устарели со временем в связи с промышленной революцией, ручной QA оказывается в той же категории.
Давайте попробуем вернутся назад и посмотреть, как все происходило до недавнего времени. Водопадная методология (waterfall) была выбором многих разработчиков аж с 1950 года. Этот подход позволял разработчикам сначала все спроектировать, затем фокусироваться на коде, и затем переходить к фазе тестирования, после которой приходилось лишь исправить найденные дефекты. Со временем, системы совершенствовались, методологии разработки становились все лучше и быстрее, и мы пришли к такой ситуации, когда в процессе разработки создавалось очень много программного обеспечения, что провоцировало необходимость большего количества тестировщиков. Чем больше становилось тестировщиков, тем меньше программисты заботились о качестве своего кода, зная что оно так или иначе будет проконтролировано во время тестирования.
В феврале 2001, пузырь дот-комов лопнул, и в это же время появился Agile-манифест, которые принес с собой новую идею разработки. Agile-методологии привнесли свежее дыхание в мир разработки программного обеспечения, основными моментами которого были приспособление к постоянно меняющимся условиям разработки и быстрый выпуск новых версий работающего программного обеспечения. Agile применялся все больше и больше различными командами, и в связи с этим на этапе разработки все больший приоритет отдавался тестированию кода разработчиком, нежели тестировщиком. В наши дни Agile по прежнему популярен и эффективен, и в связи с этими потребность в QA становится все меньше, и это значит что скоро потребность в них может исчезнуть вовсе.

Больше QA,больше проблем.

Разработка enterprise-решений – дорогое и сложное занятие. При использовании «водопадной» модели, часто на выходе получается не совсем то, что планировалось вначале – менеджмент на это реагирует одним из следующих способов:
·         Добавить больше денег на разработку. Это может позволить выполнить проект в срок, принимая во внимание закон убывающей доходности. Но такой сценарий не является предпочтительным для менеджмента.
·         Сократить список разрабатываемых возможностей продукта. Ни разработчики, ни менеджмент не в восторге от того, что часть той работы за которую заплатили не будет выполнена. Как правило этот вариант тоже не рассматривается большинством компаний.
·         Низкое качество. Качество – это дорого, и поэтому это первый пункт в списке на котором можно сэкономить.
Что у нас остается в итоге, так это чувство дисбаланса. Разработчики создают недостаточно качественный код, в то время как менеджмент экономит на QA. И здесь мы сталкиваемся с проблемой, которую и призвано решить методология Agile.

Это Agile

После того как лопнул пузырь дот-ком и экономика сделала шаг назад, компании осознали, что им необходимо создавать хорошие продукты без необходимости привлечения космических бюджетов. К счастью, Agile-разработка предполагает тестирование кода самими разработчиками. В то время как QA могут заниматься тестированием сложных и комбинированных последовательностей, разработчика несут ответственность за качество своего кода. Одним из ключевых моментов Agile - постоянный выпуск работающего продукта. Некоторые методологии Agile включают TDD и юнит-тестирование, которое выполняется разработчиками. Цель юнит-тестирования – позволить разработчикам сделать код как можно лучше в условиях постоянных изменений с минимумом усилий, времени и стоимости. Без хорошего покрытия юнит-тестами, очень сложно оставаться Agile, так как продукт подвержен постоянным изменениям, и юнит-тесты могут отследить и предотвратить возникающие проблемы.

Юнит-тестирование: возможный убийца QA

Было продемонстрировано, что с помощью юнит-тестирования, можно проверить на корректность до 90% кода, и в отличие от автоматизированных средств QA, правильно спроектированные юнит-тесты создаются на базе вашего кода. Как платформа для создания кода (и создания абстрактной модели), стоимость юнит-тестирования меньше, а лучшее качество продукта в итоге достигается за более короткое время, чем в случае привлечения QA для нахождения всех дефектов. Как было замечено ранее, автоматическое юит-тестирование и TDD делают возможным приспособить код разработчиками к новым возможностям и изменениям на лету. При комбинировании с другими Agile техниками, эти подходы учитывают необходимость постоянного выпуска работающего продукта. Вопрос который я хочу задать – а какую роль, если такая еще осталась, будет выполнять отдел QA?
Во многих компаниях, когда работающее программное обеспечение проходит автоматическое тестирование, этого достаточно для того что бы продукт можно было развернуть для внутреннего использования. Этот момент сильно уменьшает значимость роли отдела QA. Очевидно, что организации, которые разрабатывают продукты для внешнего использования или предъявляют высокий уровень безопасности и нормативных требований все еще будут испытывать необходимость в QA и дополнительных тестерах, но это может стать последним редутом некогда незаменимых отделов контроля качества. И их судьба будет зависеть от того, насколько много времени разработчик будет уделять тестированию своего кода, что коррелирует  с тем сколько разработчиков необходимо для автоматизации тестирования собственного кода.