Не идите на компромисс в отношении качества вашего программного обеспечения

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

Мой профессиональный опыт в области обеспечения качества программного обеспечения был разнообразным, если не сказать больше.

У меня был один работодатель, где тестирование программного обеспечения было неотъемлемой частью рабочего процесса разработки. До этого у меня не было большого опыта в разработке программного обеспечения и, в частности, в обеспечении качества программного обеспечения. Непрерывная интеграция / развертывание, модульные тесты, интеграционные тесты, сквозные тесты - все это тогда для меня были довольно новыми и довольно абстрактными концепциями. Увидев, как вся проектная группа включила эти концепции, я полностью изменил мое восприятие QA программного обеспечения. Судя по всему, проверка качества программного обеспечения была актуальна не только для тестировщиков программного обеспечения, но и использовалась не только тогда, когда больше нечего было делать.

С другой стороны, я несколько месяцев работал в проекте гибкой разработки программного обеспечения, где столкнулся с совершенно другим подходом, когда дело касалось контроля качества программного обеспечения. Модульные тесты? Нет. Сквозное тестирование? Что это, еда? Актуальная документация по API, которая объясняет все, что нужно знать разработчикам? Нет времени на это, мы должны сначала и быстро разработать миллионы функций. CI / CD? Итак, сборка работает, и мы автоматически развертываем ее, так что мы это делаем, верно? Как вы можете догадаться, это довольно (неприятный) контраст с вышеупомянутым бывшим работодателем.

Тестирование - это хорошо, но действительно ли стоит тратить на все это столько усилий вместо того, чтобы заниматься разработкой?

Да, это так. Без звездочек, без «но». Я лично убедился, что и конечный результат, и способ его достижения более удовлетворительны. Если все делать правильно и последовательно, вы можете сэкономить себе и своим (будущим) коллегам много их драгоценного времени и избавить от серьезных головных болей. Поверьте мне, если я скажу вам, что вы сделаете всем одолжение, если сделаете это.

Популярный аргумент против тестирования состоит в том, что в повестке дня есть более важные вопросы, которыми следует заняться. Когда ваш начальник хочет, чтобы вы разработали эту функцию для этого потенциального клиента или исправили эту очень надоедливую производственную ошибку, вы, скорее всего, не добьетесь успеха с помощью Сначала мне нужно написать несколько тестов или Прежде чем я это сделаю, мне нужно задокументировать или кто-то другой не поймет мой код (возможно, вы работаете в Feature Factory ). В то время, когда время вывода продукта на рынок становится все более важным, тестирование может показаться ненужным и трудоемким делом, особенно для людей, не связанных с ИТ.

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

Когда вы выступаете перед инвесторами и бизнесменами и хотите продемонстрировать свой отличный продукт, вы должны избегать неприятных моментов, например, когда ваш продукт не реагирует на вводимые данные или ваш продукт не поддерживает Internet Explorer. Теперь представьте, что это происходит не один или два раза, и вы придете к выводу, что было бы хорошо, если бы существующие функции продукта не сломались, когда вы реорганизуете код за день до презентации. Будучи соучредителем ИТ-стартапа, я понял, что мне нужно стать тем, кто сделает тестирование фундаментальной частью нашего процесса разработки.

Хватит теории, покажи мне, как это сделать!

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

  1. Модульные тесты дешевы в разработке, их легко выполнять и отлаживать, поскольку они изолируют сбои. Например, Жасмин - популярный выбор для JavaScript.
  2. Интеграционные тесты берут небольшую группу модулей и проверяют их поведение в целом, проверяя, что они согласованно работают вместе.
  3. Наконец, сквозные тесты моделируют реальные пользовательские сценарии, что позволяет быстро обнаруживать ошибки. Выполнение этих тестов занимает больше времени и может быть более сложным по сравнению с модульными тестами. С другой стороны, сквозные тесты обеспечивают более высокую достоверность того, что ваше приложение работает так, как задумано. Protractor, фреймворк для сквозного тестирования, разработанный командой Angular, мой личный фаворит для написания сквозных тестов.

Для сквозных тестов я написал себе небольшую вспомогательную библиотеку под названием better-protractor, которая полагается на Protractor. Это позволяет мне тестировать любую веб-страницу на простом JavaScript (для React, Vue.js, статических веб-страниц) и TypeScript (Angular, мой личный фаворит) без переключения фреймворков или необходимости писать свой тестовый код несколько раз. Это настройка для следующего примера.

1. Настройте Транспортир (короче, запустите эти команды в своем терминале: npm install -g protractor, обновление webdriver-manager и запуск webdriver-manager.

2. Установите better-protractor: npm install better-protractor.

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

Как мы включили QA в наш рабочий процесс разработки

  • Каждый компонент и каждая служба проходят соответствующий модульный тест, чтобы убедиться, что они работают должным образом.
  • Для каждого процесса (например, регистрации) существует тест E2E (обычно его пишут, когда функция близка к завершению).
  • В наших соглашениях о кодировании мы указали, что функции не выполняются до тех пор, пока все тесты, а также полная сборка не будут запущены в обязательном порядке.
  • Проверка кода - отличный способ не только улучшить код, но и улучшить навыки команды. См. Эту статью для получения дополнительной информации по этой теме.
  • Модульные тесты и полные сборки приложения запускаются GitLab CI автоматически. В случае сбоя сборки или выполнения модульных тестов будет отправлено уведомление Slack, и команда узнает, какой коммит вызвал это.
  • Конечно, необходимо еще провести ручное тестирование. Тем не менее, модульные тесты и особенно сквозные тесты обеспечивают высокую степень уверенности в том, что наше приложение работает так, как задумано, без необходимости вручную все тестировать.

Несколько общих советов по тестированию

Кент С. Доддс написал очень рекомендуемую статью, в которой он выдвигает некоторые интересные мысли, с которыми я полностью согласен:

  • Часто я экономлю время, когда трачу время на написание тестов. Я согласен: вам может потребоваться больше времени, а может и не потребоваться больше времени, чтобы завершить начальную задачу, но при отладке и рефакторинге в будущем вы, вероятно, сэкономите себе и своим (будущим) коллегам много времени и некоторые серьезные головные боли.
  • Инструменты статической печати и линтинга, такие как Flow и TypeScript, могут дать вам значительную уверенность. Если вы когда-либо имели дело со слабо типизированными языками, такими как JavaScript, вы знаете, как это бывает. Тем не менее, не стоит слепо доверять этим инструментам.
  • Когда вы все время стремитесь к 100% покрытию кода, вы обнаруживаете, что тратите время на тестирование вещей, которые на самом деле не нуждаются в проверке. Хотя высокий уровень покрытия кода сам по себе является хорошим признаком и, безусловно, желательным, в какой-то момент вы, вероятно, проводите тестирование только ради получения полного покрытия кода.
  • При рефакторинге кода вам придется очень редко менять тесты. В хороших тестах не следует тестировать детали реализации. Реализация может измениться, но эти изменения не должны нарушать фактическую функциональность.

Это мой скромный опыт работы с программным обеспечением. В заключение я считаю, что тестирование и контроль качества являются неотъемлемой частью любого проекта разработки программного обеспечения, и я надеюсь, что разработчики программного обеспечения и не ИТ-специалисты осознают невероятную важность тестирования и контроля качества в эпоху все более сложных и трудоемких проектов. Я хотел бы услышать о вашем опыте.