Словарик джуниора: десять терминов из автоматизации тестирования

В предыдущих статьях мы уже делились полезными рекомендациями, например Что читать и смотреть начинающему автотестировщику, сегодня же поговорим о терминах, знание которых существенно облегчит ваш профессиональный рост в этом направлении. Итак, 10 Test Automation терминов, которые должен знать каждый начинающий инженер, наглядными примерами иллюстрирует Елена Крамар, Lead Software Test Automation Engineer.

1. Quality gate или Ворота качества

Как следует из самого термина, ворота качества — это контрольные точки, установленные на определенных участках в процессах, в команде, чтобы «задержать, продвижение кода, который не соответствует критериям качества. Если код успешно проходит проверку, он движется дальше, к следующим воротам. А что происходит, когда какие-то из ворот блокируют его? Представьте себе рамку металлоискателя в аэропорту: если у вас при себе запрещенные предметы, устройство подает звуковой сигнал. То же самое делают и ворота качества — они сигнализируют о выявленной проблеме тестировщикам (или\и всем прочим вовлеченным в процесс специалистам: мануальным тестировщикам, руководителям проекта и т.д.) по заранее определенному каналу коммуникации — электронной почте или мессенджеру, которым пользуется команда.

2. Release Candidate (RC) или Релиз-кандидат

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

3. Log или Журнал

Верный помощник тестировщика-автоматизатора — журнал, в котором в хронологическом порядке записаны детали хода тестов. Информация записывается специальным инструментом, логгером, и может иметь жесткую структуру. Сам журнал может иметь разные форматы: от простого текстового документа до сложной системы с собственной базой данных и алгоритмами кластеризации. Все зависит от потребностей, фантазии и бюджета проекта. 

4. Stack trace или Трассировка стека

Это детальный отчет об отдельных кадрах стека в определенный момент во время выполнения кода. Обычно он отражает количество и последовательность вызванных методов. Эта информация позволяет тестировщикам с точностью до строки и символов исходного кода определить место возникновения ошибки. Трассировку стека могут увидеть и конечные пользователи как часть сообщения об ошибке.

5. Regression testing или Регрессивное тестирование

Этот тип тестирования обязательно нужно проводить после внесения каких-либо изменений в предыдущую версию продукта разработки: от имплементации нового функционала до изменений в визуальном дизайне. Регрессивное тестирование дает возможность убедиться в том, что новая функциональность не повлияла на другие части продукта и не спровоцирует непредвиденного поведения, а также в отсутствии новых ошибок. Часто под этим термином подразумевают процесс подготовки Релиз-кандидата. В таком случае, регрессивное тестирование включает планирование, предоставление информации про объем и виды тестирования, вводные данные, собственно тестирование (мануальное или автоматизированное), составление отчета о результатах и багах (если таковые были обнаружены), а также исправление багов и их последующий ретестинг.

6. Breaking change или Критическое изменение

Довольно широкое понятие, которое может означать, как существенную перестройку архитектуры продукта, так и изменение положения кнопки «Войти» на главной странице. «Критическим» считается любое изменение, которое может усложнить рутину тестировщика. Иногда даже самая мелкая, с точки зрения заказчика или пользователя, манипуляция (например, другой цвет кнопки «Заказать») может полностью разрушить всю систему автотестов. Почему так происходит? Автотесты — это такой же программный продукт, как и любое приложение, и если они не будут учитывать последние бизнес-требования, о валидации поведения продукта можно забыть. Именно поэтому инженерам по автоматизации тестирования важно быть в курсе всех критических изменений.

7. Non-functional requirements (NFR) или Нефункциональные требования

У автотеста есть требования, которые не касаются непосредственно вида и способа проводимой валидации. Нефункциональные требования — критерии, по которым оценивают качество автотестов. Речь идет о критических для фреймворка показателях: скорости, количестве, проценте покрытия тестами исходного кода или требований и пр.

8. Branch Strategy или Стратегия ветвления

Это стратегия командной работы в контексте совместной разработки кода: определенная договоренность, в частности определяющая этапы, которые код должен успешно пройти, прежде чем вновь "влиться" в главную "ветку". Каждая "ветка" отделяется от главной для выполнения определенной задачи, а затем вновь сливается с ней. Стратегия ветвления позволяет команде повысить эффективность совместной работы и значительно сэкономить время.

9. Code Refactoring или Рефакторинг кода

Это процесс реструктуризации кода, который не влияет на его функционал, но существенно меняет то, как он работает. Цель рефакторинга — сделать код чище, понятнее, быстрее, а следовательно повысить продуктивность работы инженеров по автоматизации тестирования. Рефакторинг позитивно сказывается и... на настрое команды: всем нравится пользоваться новенькими блестящими инструментами, а не старыми и ржавыми.

10. Code Stabilization или Стабилизация кода

Другая разновидность улучшения кода называется «стабилизация». Это процесс настройки кода таким образом, чтобы его выполнение приводило к одному и тому же (стабильному) результату. Как правило, он заключается только в обнаружении и устранении неисправностей и не означает существенной переработки кода.

Стабилизацию и рефакторинг хорошо иллюстрирует простой жизненный пример. Представьте себе шкаф для одежды. Как предмет интерьера он справляется со своими основными функциями: помогает создать видимость порядка в комнате и защищает вещи от пыли и грязи. Но внутри шкафа может царить творческий беспорядок. Стабилизация в этом случае означала бы раскладывание вещей по полочкам для уверенности, что двери шкафа не откроются в самый неподходящий момент — например, во время онлайн интервью — и одежда не окажется прямо посреди комнаты. А рефакторинг означал бы сортировку вещей по сезонам, тщательное раскладывание по полочкам и специальным органайзерам.

Звучит интересно? Это всего лишь верхушка айсберга того, чему можно научиться на программах по Test Automation в ЕРАМ. Регистрируйтесь и осваивайте новые навыки!