Когда для управления проектом используется каскадная модель, разработка и тестирование осуществляются на двух разных этапах: разработчики создают функцию, а затем передают ее команде по контролю качества для тестирования, самоустраняясь от участия в дальнейшем процессе. Команда по контролю качества составляет и реализует подробные планы тестирования. Она также документирует все дефекты, обнаруженные в ходе тщательной проверки на предмет ухудшений, которые новая работа могла вызвать в существующей функциональности.
Многие команды, применяющие каскадную или другие традиционные модели тестирования, сталкиваются с тем, что по мере развития продукта объем тестирования многократно увеличивается, и отдел по контролю качества вынужден стараться изо всех сил, чтобы не отстать. Владельцы проекта встают перед тяжелым выбором: перенести релиз на более позднюю дату или сэкономить на тестировании (попробуйте угадать с первого раза, какой из этих вариантов выбирают в 99 % случаев). А тем временем разработчики начинают заниматься другими делами. При этом не только растет технический долг, но и для устранения каждого дефекта требуется дорогостоящее переключение контекста между двумя фрагментами базы кода. Положение усугубляется.
Как на беду, заработная плата команды по контролю качества обычно зависит от количества обнаруженных ошибок, из-за чего разработчики вынуждены занимать оборонительную позицию. Неужели нельзя найти для разработчиков и отдела по контролю качества способ уменьшить количество ошибок в коде и одновременно избавить владельцев проекта от мучительного выбора? Не позволит ли это создавать более качественное во всех отношениях ПО?
На помощь приходят тестирование DevOps и agile-тестирование.
Отказ от традиционных способов тестирования в пользу agile
Команды Agile и DevOps стремятся наладить стабильную поставку новых функций высокого качества. Однако традиционные методики тестирования попросту не вписываются в принципы Agile или DevOps. Высокие темпы разработки требуют нового подхода к обеспечению качества каждой сборки. В компании Atlassian тестирование проводится по принципам Agile. Все тонкости нашего подхода к тестированию раскроет Пенни Уайетт — руководитель команды по контролю качества Jira Software.
Технический долг, как задолженность по кредитной карте, растущая с процентами, поначалу ощущается как небольшая заноза, но затем быстро приобретает пугающие масштабы и сковывает действия команды, не позволяя ей следовать принципам agile. Чтобы справиться с быстрорастущим техническим долгом, мы в компании даем разработчикам возможность быть главными специалистами по качеству (более того, мы ожидаем этого от них). Мы уверены, что разработчики обладают принципиально важными навыками для обеспечения качества продукта.
- Разработчики — асы в устранении проблем с кодом.
- Разработчики, которые сами составляют тесты, более заинтересованы в том, чтобы устранить ошибки в них, если таковые обнаруживаются.
- Разработчики, которые понимают требования к функциональным возможностям и значение тестирования, как правило, пишут более качественный код.
По нашему мнению, для каждой пользовательской истории в бэклоге нужно писать код дважды: код самой функции и код автоматического теста. В некоторых командах код функции пишут разработчики, а кодом автоматических тестов занимается специальная команда, но мы считаем, что гораздо эффективнее, когда оба вида кода пишет один специалист.
Баги в новых функциях и ухудшения в существующих следует воспринимать по-разному. Если баг обнаруживается во время разработки, выделите время, чтобы понять, в чем проблема, устраните ее и продолжайте работу. Если обнаруживается ухудшение (т. е. проблема возникла в той функциональности, которая раньше работала нормально), то оно, скорее всего, проявится снова. Разработайте автоматический тест, который предотвратил бы это ухудшение в будущем.
Из этого подхода не следует, что разработчики должны работать сами. Важно, чтобы в команде были и специалисты по контролю качества. Они видят разработку функции с другой стороны, и их мнение важно. Хорошие специалисты по контролю качества знают, где обычно скрываются баги, и могут предупредить разработчиков о подводных камнях.
Вмешательство человека через глубокое тестирование
В нашей компании разработчики вместе со специалистами по контролю качества проводят глубокое тестирование — полезную практику, применяемую при разработке, для отсеивания более серьезных багов. Как и при проверке кода, при глубоком тестировании в команде разработчиков происходит обмен знаниями, полученными в ходе него. У разработчиков развиваются навыки тестировщиков, благодаря чему они изначально поставляют код более высокого качества.
Можно подумать, что глубокое тестирование — это ручное тестирование, но на самом деле нет. Во всяком случае, это не то же самое, что ручное регрессионное тестирование. Для глубокого тестирования используется подход, основанный на оценке риска, и критическое мышление. Тестировщик может использовать свое знание рисков, особенностей реализации и потребностей клиентов, и на ранних стадиях тестирования эта возможность позволяет разработчику или специалисту по контролю качества быстро и системно находить проблемы без помощи тестовых сценариев, обстоятельных планов тестирования или требований. Нам этот подход кажется эффективнее традиционного ручного тестирования, поскольку мы применяем выводы, сделанные в ходе сеансов глубокого тестирования, к исходному коду и автоматическим тестам. При глубоком тестировании мы также получаем опыт использования новой функции, который нам не дает тестирование по сценарию.
Для поддержания качества на постоянном уровне нужно сочетать глубокое и автоматическое тестирование. Глубокое тестирование позволяет обеспечить более полное соответствие кода разрабатываемых функций требованиям к качеству, нежели автоматические тесты сами по себе. Если автоматические тесты просто делают разрабатываемую функцию более стабильной, благодаря глубокому тестированию повышаются удобство ее использования и ее практическая ценность в целом, а также улучшается визуальное исполнение.
Изменения могут оказаться непростыми — очень непростыми
В заключение хочу рассказать историю из жизни, которая прекрасно обобщает весь мой опыт agile-тестирования. Когда-то на заре карьеры я руководил командой разработчиков, которые были решительно против написания автоматических тестов, потому что «этим занимается команда по контролю качества». В течение нескольких итераций на выходе мы получали код с кучей багов, и в какой-то момент я понял, что сыт по горло рассказами о негативном влиянии автоматического тестирования на скорость работы команды. Я занял принципиальную позицию: отныне весь новый код должен проверяться с помощью автоматических тестов.
Уже после первой итерации качество кода повысилось. И разработчик, который больше всех противился тестовым сценариям, первым бросился исправлять ошибку, когда та была обнаружена в ходе тестирования! В следующих итерациях были составлены новые автоматические тесты, была расширена поддержка браузеров и улучшилась наша культура разработки. Да, для выпуска функции пришлось потратить больше времени. Но количество ошибок и объем доработок резко снизился, и в результате мы сэкономили уйму времени.
Изменения очень редко происходят легко. Но, как и в случае со многими стоящими вещами, если приложить усилия и начать работать по новой модели, на выходе останется только вопрос: «Почему мы не сделали это раньше?!»
