Как начать с автотестов
9 апреля 2022 г.Этот пост является второй частью моей серии «автотесты».
Первая часть: Как побудить моего менеджера поддерживать автоматизированные тесты?
Эта статья не о технических подробностях того, как именно писать автотесты, а скорее о подходе, который можно предпринять, чтобы инициатива автотестов не была отвергнута.
После того, как вы убедили своего менеджера поддерживать автоматизированное тестирование, вам необходимо правильно его спланировать — принятие инициативы не гарантирует неограниченный испытательный срок.
Помните, встаньте на место менеджера: однажды уступив чьему-то плану, он все еще питает сомнения и колебания. Если не будет заметных (а под заметными я подразумеваю измеримые) результатов, эти колебания и сомнения будут лелеять.
Давайте посмотрим, что мы можем сделать с числами.
Широко распространено мнение, что автоматические тесты (и TDD) приносят пользу процессу разработки программного обеспечения следующим образом:
- экономит время (сокращает время выхода на рынок) [ссылка]
- улучшает качество и снижает общую стоимость владения [ссылка]
- улучшает командный дух (одним из источников недовольства разработчиков являются рутинные, повторяющиеся задачи) [ссылка]
- снижает затраты на адаптацию (разработчики меньше боятся что-то менять и ломать)
В области разработки программного обеспечения существует мнение, что измерение качества – плохая идея, поэтому я бы не рекомендовал идти по этому пути.
Также невозможно измерить моральный дух команды цифрами, так что этот путь тоже бесполезен.
Мы можем показать только две измеримые вещи: затраты на адаптацию (время) и время выхода на рынок.
Однако расходы на адаптацию заметно снизятся только через некоторое время, пока мы хотим показать немедленные результаты.
Итак, нам осталось показать, как сокращается время выхода на рынок .
TTM включает в себя время, необходимое для прохождения всех шагов, необходимых для разработки и предоставления клиенту определенной функциональности.
Этап ручного контроля качества обычно занимает значительное время: функция ждет, пока команда контроля качества ее подберет, а затем проводится само тестирование.
Также ручной этап QA подразумевает большие задержки в случае, когда фича возвращается в разработку из-за дефектов.
Причина задержки в том, что когда функция передается в QA, разработчик обычно выбирает новую функцию для работы, а когда протестированная функция возвращается в разработку, ему снова приходится ждать.
Если разработчик сразу выбирает возвращенную функцию, применяется плата за переключение контекста.
Я упомянул исследования затрат на переключение контекста в своей статье [ограничения применимости проверки кода] (https://hackernoon.com/code-review-its-bad-expensive-and-inefficient-in-most-cases):
Существует множество публикаций о неэффективности многозадачности и переключения контекстов:
- [Миф о многозадачности, Nass, 2013] (https://www.npr.org/2013/05/10/182861382/the-myth-of-multitasking)
- [Многозадачность: затраты на переключение (американская психологическая ассоциация)] (https://www.apa.org/research/action/multitask)
- [Исполнительный контроль когнитивных процессов при переключении задач — Джошуа С. Рубинштейн, Дэвид Э. Мейер, Джеффри Э. Эванс] (https://www.apa.org/pubs/journals/releases/xhp274763.pdf)
- [Исполнительный контроль когнитивных процессов при переключении задач] (https://www.apa.org/pubs/journals/releases/xhp274763.pdf)
Имеются убедительные научные данные о том, что более эффективно работать над одной задачей за раз с как можно меньшим количеством переключений контекста.
Это доказывает, что для сокращения времени выхода на рынок (и получения немедленных результатов в этой инициативе) ручная фаза контроля качества должна быть сокращена следующим образом:
- автоматические тесты запускаются, как только их запускает разработчик (0 времени ожидания)
- автоматические тесты выполняются быстро (намного меньше времени тестирования) и, следовательно, обеспечивают почти мгновенную обратную связь, что означает отсутствие затрат на переключение контекста.
Когда начать
Поскольку мы хотим показать нашему руководителю некоторые немедленные преимущества, очевидной идеей было бы начать с автоматизации чего-то, что дало бы немедленные результаты.
Я бы посоветовал автоматизировать задачи, требующие значительного времени на «ручное тестирование».
Каждый трекер задач может показать вам время, которое задача проводит на этапе «тестирования», а если вы используете систему управления тестированием, вы можете получить еще больше информации.
Вот что у меня есть в TMS Qase:
Как видите, очевидным выбором здесь было бы сначала начать автоматизировать «авторизацию», поскольку проверка каждого выпуска вручную занимает 9 минут. .
Эти 9 минут составляют 8 часов в год , которые тратятся непосредственно на ручное тестирование этой конкретной функции, если у нас есть один выпуск в неделю.
Как только мы автоматизируем эту проверку, мы можем показать нашему менеджеру, что TTM сокращается на 9 минут для каждой задачи. Это неизбежно вызовет у нас больше доверия.
Чем больше у вас доверия, тем больше вы можете делать то, что вы считаете правильным, потенциально то, что невозможно «измерить» или не поддается количественной оценке.
[Деминг] (https://en.wikipedia.org/wiki/W._Edwards_Deming) называет "управление только тем, что поддается количественному измерению" одной из 7 смертельных болезней управления:
- Управление с использованием только видимых цифр, практически без учета неизвестных или непознаваемых цифр.
Но я редко видел, чтобы менеджеры знали об этом, отсюда и весь этот подход демонстрации результатов и завоевания доверия, чтобы сделать что-то действительно правильное.
Итак, резюмируем:
- вы уговорили своего менеджера поддержать автотесты
- вы постоянно показываете им немедленные результаты
- вы получаете доверие, чтобы иметь возможность (и иметь ресурсы) разработать правильную стратегию тестирования
- вы начинаете делать то, что правильно
Чтобы выбрать правильную стратегию тестирования, сначала ознакомьтесь с [документом] Фаулера (https://martinfowler.com/articles/practical-test-pyramid.html).
Оригинал