Если вы не живете в пещере и не прогуливали базовые уроки информатики в средней школе, вы наверняка уже слышали такие термины, как “программное обеспечение” и “тестирование”. Но на всякий случай напомним, что программное обеспечение (ПО) – это просто набор инструкций, которые компьютер использует для выполнения определенных задач. Тестирование же означает проверку на наличие ошибок.
Таким образом, тестирование ПО – это процесс определения корректности, полноты и качества созданных компьютерных программ Это ряд мероприятий, проводимых для выявления недостатков в ПО, чтобы эти дефекты можно было устранить до того, как продукт будет передан конечным пользователям.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Проще говоря, тестирование ПО – это серия мероприятий, проводимых для проверки того, что программная система не содержит дефектов.
Итак, мы выяснили, что все компьютеры работают на программном обеспечении, которое позволяет им выполнять те действия, которые вы на них делаете. Также не новость, что эти программы иногда дают сбои, глючат или заражаются вирусами или вредоносными программами.
Возможно, из школьного курса информатики вы помните, что существуют такие типы ПО, как системное, утилитарное и прикладное.
Если вы читаете эти строки, то наверняка используете цифровое устройство “компьютер” (мобильный телефон, планшет, ноутбук), которое работает на одном из перечисленных видов программного обеспечения – системном.
А на вашем телефоне, ноутбуке или iPad есть приложения. Например, браузер, с помощью которого вы читаете эту статью. Он, в свою очередь, работает на прикладном программном обеспечении.
Вы также наверняка знаете, что время от времени необходимо обновлять программное обеспечение устройства или приложения, иначе оно перестанет работать.
Почему в готовом ПО остаются ошибки?
Давайте возьмем Spotify в качестве примера программного приложения. Если вы потратите время на чтение информации об обновлениях, чего мы, к сожалению, не делаем, то в 80 процентах случаев там будет написано “Исправлены ошибки“ или “Устранены ошибки”. Это помимо многих других вещей, таких как “Добавлены новые функции” или “Обновлены правила и условия”.
На самом деле описание обновлений обычному человеку ни о чем не говорит. Поэтому вы, естественно, просто прокрутите страницу до кнопки обновления, чтобы побыстрее покончить с этим.
Но упоминание исправления ошибок заставляет задуматься. Почему в таком замечательном и почти идеальном продукте, каким кажется Spotify, постоянно исправляются ошибки? Неужели нельзя просто исправить всё сразу, чтобы нам больше никогда не пришлось иметь дело с очередным обновлением?
Да что там Spotify! Возьмем, к примеру, всю компанию Apple Operating System Software. Уж на что гигант, а все равно исправляет ошибки. Разве у них не должно быть возможности обнаружить эти проблемы, прежде чем вообще выпускать новый iPhone?
Слышали поговорку, что совершенства не существует? То же самое относится и к ПО. Но мы стараемся сделать его как можно более близким к совершенству. И особенно это касается коммерческих приложений, как мобильных, так и десктопных. Это помогает уменьшить количество разочарований, с которыми сталкивается обычный пользователь при попытке использовать данное программное обеспечение.
Многие вещи могут привести к тому, что программное обеспечение не будет работать так, как предполагалось. Это могут быть вирусы, перегрузка пропускной способности сервера (сколько трафика может выдержать сервер) или даже незамеченные ошибки.
При таком количестве проблем возникает необходимость в тщательном тестировании ПО. Именно поэтому многие приложения имеют бета-версию своего цифрового продукта перед официальным запуском, и этот продукт все еще будет получать обновления “для исправления ошибок” в течение следующих нескольких месяцев.
Правда в том, что каким бы долгим и тщательным ни было тестирование, всегда остается место для улучшений.
Это приводит нас к принципам тестирования.
Семь принципов тестирования
Раннее тестирование
Это настолько просто, насколько это вообще возможно. Когда вы шьете платье, вам постоянно приходится проверять каждую деталь, правильно ли она сидит, того ли она размера и т.д.
Если вы будете ждать до самого конца, то, скорее всего, у вас возникнет столько проблем, что платье не удастся сшить. Один рукав окажется шире или длиннее другого.
Так же и тестирование должно начинаться как можно раньше в процессе разработки любого цифрового продукта: от идеи до запуска в подакшен.
Потому что невозможно представить, что ПО может быть полностью лишено ошибок.
Это приводит нас ко второму принципу тестирования ПО.
Отсутствие ошибок – это заблуждение
Предположим, что после всех размышлений о дизайне продукта и исследований поведения пользователей программное обеспечение оказывается на 99% свободно от ошибок. Но в итоге какакя-то часть пользователей остается разочарованной опытом использования конечного продукта, который, якобы, был заявлен как свободный от ошибок. То есть всегда остается этот 1% дефектов, который был упущен командой разработки.
Теперь о технических моментах.
Исчерпывающее тестирование
Представьте, что вы пытаетесь решить очень сложную математическую задачу. Вам нужно определить три-четыре переменные, и для каждой из них существует более восьми различных формул.
Просматривать их все одну за другой будет крайне утомительно, отнимет много времени, сил и ресурсов. Рассматриваемый нами принцип тестирования связан именно с этим.
Если вы будете тестировать все возможные комбинации функций, окружений и входящих данных, стоимость и время создания проекта, несомненно, возрастут.
Поэтому вместо того, чтобы много работать, мы работаем умно. Практичный способ – тестировать в зависимости от важности функциональности и риска нахождения в ней дефекта, а не пытаться сделать все сразу.
Именно поэтому данный принцип гласит, что исчерпывающее тестирование невозможно.
Кластеризация дефектов
Согласно этому принципу, больше всего дефектов обычно содержится в небольшом количестве модулей. Этот принцип применяет принцип Парето к тестированию ПО: около 80 % проблем обнаруживаются в 20 % модулей. То есть, в ходе тестирования выявляются модули, где дефекты встречаются наиболее часто, и в дальнейшем именно эти модули подвергаются наиболее тщательным проверкам.
Если повторять одни и те же тесты на этом “скоплении дефектов” много раз, то вероятность найти новые дефекты будет меньше.
У каждой ошибки или дефекта обычно есть тест-кейсы, то есть то, как они тестируются, чтобы определить сбой в работе. Например, у вас возникла проблема с подпиской на Spotify: приложение не распознает ваш адрес электронной почты, когда вы пытаетесь зарегистрироваться.
При этом одна функция (такая, как вход в систему в нашем примере) может иметь несколько сценариев тестирования. То есть у вас может возникнуть проблема с адресом электронной почты, а у кого-то другого – с именем пользователя, причем в одном и том же интерфейсе входа.
Таким образом, один и тот же тест-кейс повторяется в рамках одного и того же модуля с дефектами, и, естественно, со временем новых дефектов не обнаруживается, что приводит нас к следующему принципу.
Парадокс пестицида
Его смысл в том, что старые тест-кейсы в какой-то момент перестанут находить новые дефекты. Из этого следует, что тест-кейсы необходимо оценивать и настраивать заново так, чтобы можно было найти различные ошибки.
“Каждый метод, который вы используете для предотвращения или обнаружения багов, оставляет после себя остатки более мелких багов, против которых эти методы неэффективны” .
“Парадокс пестицида”, Борис Бейзер
Это подтверждает нашу мысль о том, что постоянное тестирование всегда покажет наличие дефекта. Чем чаще тестируется программное обеспечение, тем выше шансы найти новые ошибки, которые могли остаться незамеченными. Тестирование всегда показывает наличие дефектов, а не их отсутствие.
Это может заставить вас спросить: а что, если ошибок не обнаружено? Значит ли это, что программа на 100 % свободна от ошибок?
На самом деле нет. Всегда есть этот 1%, помните?
Тестирование зависит от контекста
Риски в цифровых медицинских устройствах проверяются совсем иначе, чем в электронной коммерции. Каждое программное обеспечение имеет свои требования, специализацию, пользовательские интерфейсы и, конечно, разные цели тестирования.
По сути, тестирование должно быть адаптировано к конкретному контексту, с учетом характера, жизненного цикла разработки и назначения программного обеспечения.
Существует множество инструментов для тестирования ПО в различных контекстах. Например Appium, Robotium, Test IO и так далее используются для мобильного тестирования, WebLOAD или Neo load – для тестирования производительности, Jenkins – для юнит-тестирования, Github – для отслеживания ошибок, а NetSparker (Invicti) – для тестирования безопасности.
Заключение
В мире обеспечения качества семь принципов тестирования гарантируют выявление наличия дефектов, что в конечном итоге улучшит общее впечатление пользователей от вашего программного обеспечения.
Перевод статьи «Software Testing — A beginner’s Guide».