Можно ли создать качественное ПО без тестирования?
Тестирование программного продукта сегодня – важная часть разработки не только для разработчиков, но и для бизнеса в целом. В этой статье мы уделим внимание автоматизированному и модульному тестированию, их плюсам и минусам, а также обсудим, нуждается ли ваш продукт в тестировании программного обеспечения.
Некоторые рассматривают этап тестирования как бесполезную трату времени и ненужным дополнением к процессу разработки. Главная причина для команды разработчиков, чтобы отменить или сократить время тестирования – финансовые затраты и экономия времени. Однако, у этого подхода есть и обратный эффект.
В этой статье мы хотим показать вам, что без тестирования программного продукта, сделать работу качественной вряд ли получится.
Тестирование – это процесс выявления ошибок и несоответствий между ожидаемым и реальным поведением программного продукта, осуществляемый на основе совокупности тестов. Это метод контроля качества программного обеспечения, который включает в себя проектирование тестов, выполнение тестирования и анализ полученных результатов.
Критерии тестирования обычно включают в себя:
· функционал;
· простоту разработки;
· простоту установки;
· качество документации и поддержки;
· уровень производительности.
Главная цель тестирования – определить и показать, что программный продукт готов к выходу на рынок и что все заявленные командой разработчиков функции работают на должном уровне. Тестирование запрашивается самим разработчиком, чтобы убедиться, что продукт готов и клиенты видят, за что они заплатили.
Автоматизированное тестирование
Автоматизированное тестирование – аналог ручного функционального тестирования, который выполняется программой-роботом, а не человеком.
Значительная часть эффективности работы тестировщиков зависит от того, какие задачи отданы для автоматизации и как эта автоматизация была осуществлена. Автоматизация может как принести огромное облегчение всем тестировщикам, так и завалить работу всей команды и отложить релиз, премию, отпуск.
Автоматизировать можно сотни вещей. Вот наиболее часто встречающиеся кейсы:
· автоматическое создание аккаунта пользователя;
· генерация транзакции покупки и т.д.
Вариантам нет конца и края. Такие тест-кейсы пишутся программистами компании или самими тестировщиками.
Пример создания аккаунта пользователя:
Если набрать в адресной строке ссылку, то мы увидим 4 обязательных поля, которые нужно заполнить и кнопку "Зарегистрироваться".
Вы просто вводите уникальный e-mail нового пользователя, например test_zero@ssss.ru и нажимаете на кнопку. Программа делает за вас все остальное. Пароль для всех аккаунтов будет, например "898989".
Очень удобно, когда в компании существует конвенция для одного пароля при создании тест-аккаунтов, например "898989", вне зависимости от того, используется автоматизация для создания новых аккаунтов или нет.
Дело в том, что иногда нет времени или возможности создать аккаунт с определенными транзакциями, настройками и, если такой аккаунт уже существует, зная пароль, вы сможете им воспользоваться. При этом следует не забывать о деловой этике: если этот аккаунт создан не вами, по возможности вежливо спросите у «хозяина» аккаунта разрешение.
Модульное тестирование
Модульное тестирование – процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии – появлению ошибок в уже оттестированных местах программы, а также облегчить обнаружение и устранение таких ошибок.
К примеру, у нас есть два модуля:
Создание файла с полными именами, e-mail и номерами сертификатов.
Рассылка пользователям e-mail.
Как будет происходить тестирование?
Модуль №1
Проверяем, что создается файл нужного формата:
· с полными именами и e-mail пользователей;
· с номером сертификата для каждого из этих пользователей.
Модуль №2
Допустим, код первого компонента, который должен был создать для нас файл, не работает. Мы не отчаиваемся, а просто вручную создаем файл установленного формата с взятыми с потолка e-mail, полными именами пользователей и номерами сертификатов.
Этот файл мы «скармливаем» программе рассылки e-mail и проверяем, что правильные e-mail доходят до пользователей из файла.
Хотя по спецификации 2 модуля и взаимосвязаны, из-за проблем в коде у нас получилось модульное тестирование в чистом виде. Другими словами, мы тестировали сами модули, а не связь между ними. Тестирование связи между компонентами называется интеграционным тестированием.
Профессионалы тоже делают ошибки
Ни один разработчик не может написать идеальный код, который бы потом не нуждался в рефакторинге. Это отнюдь не камень, брошенный в огород программистов, просто факт. Люди склонны совершать ошибки, но неверное движение одного может привести к нарушению нормальной работы программного продукта на всех этапах разработки.
Человек не может держать все в голове и помнить обо всех нюансах, поэтому корректирование работы – это нормальный процесс. Более того даже самый квалифицированный разработчик может не заметить баги из-за долгой работы над кодом, а глаз имеет свойство так сказать замыливаться.
Работы с арифметикой в вебе протекают по большей части в динамически типизированных языках. Это может привести к ошибкам, в следствие которых потеряются деньги клиентов или бизнеса в целом. Например, сложение текста и цифры '3' + 2 = ожидание 5, к сожалению, из-за промашки с 3, на выходе будет 32. В данном примере потребуется проверки на введённые значения – являются они числом или попыткой преобразовать в число. Написание теста с корректным прохождением и исключение в случаи ошибки.
Иногда во время разработки можно сдвинуть элементы на сайте, что позволит избежать «тестирования через скриншоты», уведомляющие разработчика о сдвиге на странице или совпадении с предыдущим релизом.
Хорошо писать тесты при фильтрации данных или корректность выборки приведут к избежанию проблем в дальнейшем, когда разработчик изменяет поля в базе данных, но забывает исправить вывод или когда при изменении структуры вывода разработчик будет уведомлен, а данные всегда будут отсылаться одинаковые.
По данным годового анализа об ошибках в программном обеспечении SoftwareFailWatch, в 2017 году компании потеряли почти 2 триллиона долларов из-за неисправности программного продукта.
Качественное тестирование позволяет существенно сократить количество обоснованных претензий к качеству программного продукта на этапе внедрения, сократить ресурсы, затрачиваемые на доработку, коррекцию и обслуживание системы. В результате затраты на обслуживание продукта снижаются на 15-20%, а репутация разработчика системы растет.
И, наоборот, если грамотное тестирование программного продукта не проводится, то стоимость обслуживания может увеличиться до 80-85% от общей стоимости разработки и внедрения, а потенциальное количество клиентов уменьшится.
Какими инструментами мы пользуемся
Говоря много об этапе тестирования, главное – не забыть указать, какими инструментами и для чего пользуются наши тестировщики:
· тестирование API – приложение с набором инструментов для тестирования Postman или Insomnia;
· приложение Recordit для записи видео с экрана монитора;
· оформление баг репортов – приложение Asana;
· написание тест-кейсов – Exсel, реже Word;
· расширение для браузера SessionBox – позволяет работать одновременно с несколькими активными сессиями.
Если вам кажется, что наш список недостаточно полон, напишите ниже в комментариях инструменты, которыми вы пользуетесь и которые готовы рекомендовать остальным.
Спасибо за ваши лайки и комментарии!