Автор: Рависурия Ишвара (Ravisuriya Eswara)
Оригинал статьи
Перевод: Ольга Алифанова

Как инженер, я постоянно участвую в обсуждениях технического долга. Вне зависимости от обстоятельств в разрабатываемом ПО всегда будет технический долг.

А вместе с техническим долгом неизбежно появляется и тестовый долг. Определение и понимание объема и значимости тестового долга — часть моей работы.

Моё понимание технического долга

Что такое технический долг?

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

Начнем с тестового долга

Не знаю, существует ли термин «тестовый долг» в индустрии! В своей практике я использую термин «тестовый долг» уже 9 лет.

• Я использую этот термин, чтобы информировать заинтересованные стороны о дополнительной работе, которую нам приходится выполнять из-за технического долга.
• Разобравшись с тем, что такое технический долг, можно провести аналогию с тестовым долгом.
• В большинстве случаев такие характеристики системы, как тестируемость, автоматизируемость и наблюдаемость, ухудшаются из-за технического долга.
• Более того, усугубляя каскадный эффект, возникает тестовый долг.
  • Одним из основных последствий тестового долга является изменение детерминированности, заложенной в тесты.
  • Повторная работа над этой детерминированностью — задача непростая и не всегда однозначная, учитывая изменения в бизнес-операциях, технологическом уровне и инфраструктуре.

Когда я говорю, что технический долг возникает из-за того, что мы делаем и поставляем, это также означает, что создаётся и тестовый долг.

• Если говорить с инженерной точки зрения, тестирование — это часть технической деятельности.
• Мне кажется забавным, когда команду тестирования изображают как нетехническую и навешивают ярлыки, говоря, например, что тестирование «ручное», «повторяемое», «однообразное» и т.д.

Это замкнутый цикл, и повторяемость — важная часть инженерного цикла и процесса.

Знаете ли вы свой тестовый долг?

Напомню себе и вам: тестирование — это выборка! Как можно делать выборку, когда технический и тестовый долги растут?

Я расскажу про один из распространённых тестовых долгов, который есть, по моему опыту, у каждого из нас.

Требование автоматизировать в рамках спринта и «автоматизировать всё» — справедливое и практичное ли это требование? Это сейчас не тема для обсуждения, но я расскажу, как команда тестирования сталкивается с тестовым долгом при попытках выполнить такие ожидания бизнеса и заинтересованных сторон.

Технический долг рано или поздно приводит к переработке в инженерии, и это влечёт за собой масштабную переработку в тестовой инженерии. Не так ли?

Допустим, вы построили тестовую инфраструктуру, регрессионный и автоматизированный наборы тестов, интегрировали их в пайплайн. Теперь идет переработка и изменение системы в рамках отдачи ряда технических долгов.

• Влияет ли это на вашу тестовую инфраструктуру, регрессионный и автоматизированный наборы тестов?
  • Достаточно ли у команды тестирования времени и ресурсов, чтобы адаптировать тесты и поддерживать бесперебойную работу пайплайна?
  • Это не только вопрос времени и ресурсов!
    • При изменениях в технологическом стеке и архитектуре системы тестировщики должна адаптироваться и тщательно проверить эти изменения.
      • Если тестировщики не будут проверять инженерные решения системы, мы не сможем выявить риски и возможные проблемы.
      • В конечном итоге мы даже не сможем понять, какие аспекты системы вовсе не несут рисков.
      • Как этим управлять, чтобы быстро адаптироваться к изменениям и поддерживать плавность работы пайплайна?
        • Это проблема для любого тестового инженера, сталкивающегося с последствиями технического долга.

Мы, тестировщики, наблюдаем за последствиями технического долга, который включает в себя и тестовый долг в разных формах и степенях выраженности.

Подождите! Читая эту статью, задумались ли вы о намеренном тестовом долге в вашем проекте?

Что такое непреднамеренный тестовый долг и каков его эффект?

• Это не так просто выявить и изучить, хотя в случае с непреднамеренным техническим долгом это в какой-то степени возможно.
• Он существует; он влияет на все окружения каждый день!

Тестовый долг и тест-инженер

Обратите внимание: создание решений в области тестирования, способных выдерживать последствия и изменения, вызванные техническим долгом, — это навык. Это реализуемо.

Для этого технический долг не должен разрушать детерминированность, заложенную в тестах.

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

Технический долг и тестовый долг — это не одно и то же. Но тестовый долг — это результат технического долга и тесно с ним связан.

Тестирование – не драйвер изменений в системе; или, по крайней мере, я с таким не сталкивался. Минутку! Результаты тестирования могут и действительно меняют реализацию системы. Эти два утверждения — не одно и то же.

В завершение: как справляться с этими долгами? Мы работаем в сфере, все где должны развиваться, ведя диалог, договариваясь и решая проблемы, возникшие  вследствие решений бизнеса и заинтересованных лиц.

Обсудить в форуме