ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

Как найти баланс в тестировании программного обеспечения

Нахождение баланса между модульным тестированием, интеграционным тестированием и сквозным тестированием

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

Это история Тома: у его компании все больше и больше клиентов. При этом команда разработчиков программного обеспечения становилась все меньше и меньше. Супер раздражает. Команда Тома была разочарована более быстрым выпуском продукта и не могла поддерживать его качество.

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

Команда Тома вежливо сказала нет. Офшорная команда приступила к тестированию в одночасье. Что еще хуже, это происходило во время вспышки коронавируса.

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

Ему нужно исправить повреждение, вернуть стабильность и одновременно успокоить детей. Ты не хочешь быть Томом прямо сейчас.

Нет, нет, нет ... нельзя отказываться от хорошей практики тестирования и опытной команды тестирования.

Нам нужно взять под контроль коронавирус. Но нам также необходимо получить контроль над качеством нашего программного обеспечения.

Вместо того, чтобы иметь миллионы тестировщиков программного обеспечения вручную, группы разработчиков перешли к автоматизации большей части своих усилий по тестированию.

Автоматические тесты идут рука об руку с практиками гибкой разработки, непрерывной доставкой и культурой DevOps. Благодаря эффективному тестированию программного обеспечения разработчики могут действовать быстро и уверенно.

Но каков наиболее оптимальный баланс между модульным, интеграционным и e2e-тестами? Можем ли мы найти единый ответ на этот вопрос?

Прежде чем ответить на этот животрепещущий вопрос, давайте вспомним, что такое эффективное тестирование:

  • В эффективной практике тестирования цель состоит в том, чтобы найти ошибки, а не писать тесты.
  • Успешный тестовый пример - это тот, который обнаруживает еще не обнаруженную ошибку.

Итак, что было бы лучшим ответом на наш вопрос?

Как найти баланс между модульными, интеграционными и сквозными тестами

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

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

Пирамида тестирования была введена более десяти лет назад, и это отличная и актуальная модель.

Пирамида утверждает, что тесты на нижних уровнях дешевле писать и поддерживать - и быстрее запускать. Он предлагает три типа тестирования: модульное тестирование, сервисные тесты и тесты пользовательского интерфейса. Тесты на верхних уровнях дороже писать и поддерживать, а запускать их медленнее. Следовательно, у вас должно быть много модульных тестов, несколько тестов служб и очень мало тестов пользовательского интерфейса.

За последние 10 лет мы увидели много изменений - от микросервисов до облака, от бессерверных до Kubernetes. Было бы глупо сказать, что модель пирамиды тестирования не лучшая для всех типов приложений? Было бы безумием сказать, что мы должны использовать новые методы тестирования?

Пирамида тестирования, TDD и модульные тесты по-прежнему являются мощными методами и, вероятно, лучше всего подходят для многих приложений.

Но, как и во всем, исключение подтверждает правило.

Давайте посмотрим на приложение IoT, которое отправляет миллионы событий в шину сообщений, например Kafka / MQTT. Затем события сохраняются в некотором хранилище данных и запрашиваются некоторым пользовательским интерфейсом аналитики. Это приложение объединяет сервисы и почти не имеет логики. Как вы думаете, будет ли разумным настаивать на написании большинства наших модульных тестов?

А как насчет таких приложений, как чат-боты, Alexa Skills или криптографические приложения? Во всех этих приложениях пирамида тестирования не самая лучшая.

Благодаря интерфейсным фреймворкам, таким как React, Angular и Vue.js, становится очевидным, что тесты пользовательского интерфейса не обязательно должны находиться на самом высоком уровне вашей пирамиды. Вы можете выполнить модульное тестирование своего пользовательского интерфейса во всех этих фреймворках.

Если вы хотите идти в ногу со временем, вам придется искать способы ускорить выпуск программного обеспечения без ущерба для его качества.

Пирамида тестирования очень проста и может служить руководством для многих проектов. Из первоначальной пирамиды тестов Кона следует помнить две вещи:

  1. Пишите тесты с разной степенью детализации.
  2. Чем выше вы получите уровень, тем меньше тестов вам нужно будет пройти.

И не привязывайтесь слишком к названиям отдельных слоев в пирамиде теста Кона.

Кон также говорит о наблюдении, что многие разработчики полностью игнорируют уровень обслуживания. Это наблюдение все еще верно.

Итак, каков ответ на наш вопрос: как найти баланс между модульным, интеграционным и e2e-тестами? Это зависит. Давайте обсудим это дальше.

Три шага для лучшего тестирования программного обеспечения в вашей команде

  1. Подробнее о тестировании программного обеспечения, непрерывной доставке и DevOps. Вот с чего можно начать:

2. Хороший способ определить лучшую стратегию с вашей командой - проанализировать и поразмышлять над такими вопросами, как:

  • Какие тесты в вашей кодовой базе оказали большое влияние?
  • Какие из них спасли вас от сбоя приложения в производственной среде?

Найдите минутку и ответьте на эти два вопроса со своей командой.

3. Google для:

Некоторые статьи, которые могут вам также понравиться:



100 лучших инженеров, разработчиков, программистов и предпринимателей, за которыми следует следить в Интернете
100 блестящих умов medium.com





Как заставить членов вашей команды и клиентов слушать вас
Экс-переговорщик ФБР Крис Восс обучает ценным навыкам, которые могут помочь вашей инженерной карьере medium.com





Лучшие советы от 5 руководителей удаленной работы
Чему мы можем научиться у компаний, которые годами успешно работают удаленно medium.com





Как стать лучшим программистом, открыв свои сильные стороны
Как стать лучшим разработчиком, зная себя и опираясь на свои сильные стороны medium.com





Как писать код с детьми дома
Вы заперты дома с детьми? Вот несколько советов, которые помогут вам оставаться в здравом уме, работать и по-прежнему улыбаться… medium.com



Удачного и сбалансированного дня.