Что такое тестирование программ и зачем оно нужно
Оказывается, 75% времени при создании программ уходит вовсе не на программирование. Разбираемся, чем же занимаются тестировщики.
Вероятно, ни одну вещь в мире нельзя сделать без ошибок, и программы не исключение. Допустим, вы написали код и не видите в нём явных багов. Как узнать, что будет при реальном использовании: поведёт ли себя программа так, как от неё ожидают?
Почему тестирование — это так важно
Вот типичные программные баги:
Прежде чем новая версия компьютерной программы, сайта или мобильного приложения попадает к пользователю, она должна пройти через руки инженеров-тестировщиков. Они ищут места в коде, где программа работает не так, как задумано. Чтобы найти как можно больше ошибок, тестировщики моделируют разные ситуации, которые могут возникнуть при использовании приложения.
Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.
Какие виды тестирования существуют
Пользователи непредсказуемы. Они могут делать не только то, что предусмотрено программой, но и то, что ею категорически не предусмотрено. Тестировщик должен проверить все возможные и невозможные сценарии их поведения и убедиться, что программа продолжает работать.
Вообще, у тестирования есть философия, которая строится на том, что в любой программе по определению есть ошибки и найти их все невозможно. А если вы почему-то не нашли ошибку, значит, просто плохо искали. Удачный тест для тестировщика — тот, при котором нашли баг. А если всё нормально работало, значит, тест неудачный и свою задачу не выполняет.
Ошибки возникают не только при кодировании, но и при проектировании системы, и даже на этапе разработки технического задания. Поэтому и тестируют код не только в самом конце работы, а на разных этапах.
Есть несколько видов тестирования:
Что тестируют на разных этапах разработки
Есть несколько уровней тестирования. Их проводят в разное время:
В зависимости от этапа разработки перед тестировщиками стоят разные цели:
Не бывает идеального тестирования: в принципе невозможно доказать, что программа работает правильно при любых условиях. Но тестировщики могут найти и уточнить, в каких условиях она работает неправильно.
Как обычно проходит тестирование
Как правило, тестировщики начинают работать с программой сразу после начала проекта:
После выхода каждой новой сборки программы сначала делают дымовое тестирование — проверяют, что приложение запускается и выполняет основные функции. Если всё в порядке, программу передают на дальнейшее тестирование. Если нет — сразу возвращают на доработку.
Следующий этап — регрессионное тестирование. Тестировщики ищут баги в новых участках кода и в тех местах, где исправляли ранее найденные ошибки.
После этого программу проверяют в разных уровнях: испытывают её функциональность, производительность, работу с окружением. Это можно делать вручную или с помощью автоматических тестов-кейсов.
Автоматизированное тестирование облегчает проверку и экономит время. Лучше всего это работает в сложных приложениях с большой функциональностью.
Когда есть результат, инженеры-тестировщики готовят отчёт по тестированию и отправляют его разработчикам, чтобы те исправили найденные баги. Так происходит от версии к версии, пока результаты не будут удовлетворять критериям, описанным в тест-плане.
Кто всё это делает: немного о профессии
Если проект большой, над ним работает целая команда: одни тестировщики готовят тесты, другие проверяют их полноту и логику, третьи занимаются непосредственно тестированием. Над небольшими задачами может работать один специалист, причём удалённо.
Тестировщики — среди самых востребованных сейчас специалистов-айтишников. Появляется множество новых программ, и каждой из них нужен контроль качества. QA-специалистов нанимают крупные компании-разработчики ПО, они могут стать фрилансерами и работать сразу на несколько фирм.
Как показывает статистика работных сайтов, на рынке не хватает разработчиков автотестов, а специалистов ручного тестирования достаточно. Средняя зарплата тестировщика в Москве больше 120 тысяч рублей, а по регионам —
примерно 55–60.
На скриншотах ниже — данные с HeadHunter. В сентябре 2020 года там было 3000 открытых вакансий тестировщика.
Способы тестирования программного обеспечения
Всем привет! Уже на следующей неделе мы запускаем новый поток по курсу «Автоматизация веб-тестирования». Этому и будет посвящен сегодняшний материал.
В этой статье рассматриваются различные способы тестирования программного обеспечения, такие как модульное тестирование (unit testing), интеграционное тестирование (integration testing), функциональное тестирование (functional testing), приемочное тестирование (acceptance testing) и т.д.
Есть множество разных типов тестов, которые вы можете применить, чтобы убедиться, что изменения в вашем коде работают по сценарию. Не все типы тестирования идентичны, хотя здесь мы рассмотрим, насколько основные практики тестирования отличаются друг от друга.
Тестирование: ручное или автоматизированное?
Сначала надо понять различия между ручными и автоматизированными тестами. Ручное тестирование проводится непосредственно человеком, который нажимает на кнопочки в приложении или взаимодействует с программным обеспечением или API с необходимым инструментарием. Это достаточно затратно, так как это требует от тестировщика установки среды разработки и выполнения тестов вручную. Имеет место вероятность ошибки за счет человеческого фактора, например опечатки или пропуска шагов в тестовом сценарии.
Автоматизированные тесты, с другой стороны, производятся машиной, которая запускает тестовый сценарий, который был написан заранее. Такие тесты могут сильно варьироваться в зависимости от сложности, начиная от проверки одного единственного метода в классе до отработки последовательности сложных действий в UI, чтобы убедиться в правильности работы. Такой способ считается более надежным, однако его работоспособность все еще зависит от того насколько скрипт для тестирования был хорошо написан.
Автоматизированные тесты – это ключевой компонент непрерывной интеграции (Continuous Integration) и непрерывной доставки (continuous delivery), а также хороший способ масштабировать ваш QA процесс во время добавления нового функционала для вашего приложения. Однако в ручном тестировании все равно есть своя ценность. Поэтому в статье мы обязательно поговорим об исследовательском тестировании (exploratory testing).
Различные типы тестов
Модульные тесты считаются низкоуровневыми, близкими к исходному коду вашего приложения. Они нацелены на тестирование отдельных методов и функций внутри классов, тестирование компонентов и модулей, используемых вашей программой. Модульные тесты в целом не требуют особых затрат на автоматизацию и могут отрабатывать крайне быстро, если задействовать сервер непрерывной интеграции (continuous integration server).
Интеграционные тесты проверяют хорошо ли работают вместе сервисы и модули, используемые вашим приложением. Например, они могут тестировать интеграцию с базой данных или удостоверяться, что микросервисы правильно взаимодействуют друг с другом. Эти тесты запускаются с бОльшими затратами, поскольку им необходимо, чтобы много частей приложения работало одновременно.
Функциональные тесты основываются на требованиях бизнеса к приложению. Они лишь проверяют выходные данные после произведенного действия и не проверяют промежуточные состояния системы во время воспроизведения действия.
Иногда между интеграционными тестами и функциональными тестами возникают противоречия, т.к. они оба запрашивают множество компонентов, взаимодействующих друг с другом. Разница состоит в том, что интеграционные тесты могут просто удостовериться, что доступ к базе данных имеется, тогда как функциональный тест захочет получить из базы данных определенное значение, чтобы проверить одно из требований к конечному продукту.
Сквозные тесты (End-to-end tests)
Сквозное тестирование имитирует поведение пользователя при взаимодействии с программным обеспечением. Он проверяет насколько точно различные пользователи следуют предполагаемому сценарию работы приложения и могут быть достаточно простыми, допустим, выглядеть как загрузка веб-страницы или вход на сайт или в более сложном случае – подтверждение e-mail адреса, онлайн платежи и т.д.
Сквозные тесты крайне полезные, но производить их затратно, а еще их может быть сложно автоматизировать. Рекомендуется проводить несколько сквозных тестов, но все же полагаться больше на низкоуровневое тестирование (модульные и интеграционные тесты), чтобы иметь возможность быстро распознать серьезные изменения.
Приемочные тесты – это формальные тесты, которые проводятся, чтобы удостовериться, что система отвечает бизнес-запросам. Они требуют, чтобы приложение запускалось и работало, и имитируют действия пользователя. Приемочное тестирование может пойти дальше и измерить производительность системы и отклонить последние изменения, если конечные цели разработки не были достигнуты.
Тесты на производительности проверяют поведение системы, когда она находится под существенной нагрузкой. Эти тесты нефункциональные и могут принимать разную форму, чтобы проверить надежность, стабильность и доступность платформы. Например, это может быть наблюдение за временем отклика при выполнении большого количества запросов или наблюдение за тем, как система ведет себя при взаимодействии с большими данными.
Тесты производительности по своей природе проводить достаточно затратно, но они могут помочь вам понять, какие внешние факторы могут уронить вашу систему.
Дымовое тестирование (Smoke testing)
Дымовые тесты – это базовые тесты, которые проверяют базовый функционал приложения. Они отрабатывают достаточно быстро и их цель дать понять, что основные функции системы работают как надо и не более того. Такое тестирование направлено на выявление явных ошибок.
Дымовые тесты могут оказаться полезными сразу после сборки нового билда для проверки на то, можете ли вы запустить более дорогостоящие тесты, или сразу после развёртывания, чтобы убедиться, что приложение работает нормально в новой среде.
Как автоматизировать тесты
Тестировщик может проводить все тесты, указанные выше, вручную, но это будет крайне затратно и непродуктивно. Поскольку люди имеют ограниченную возможность производить большое количество действий с повторениями при этом все еще проводя тестирование надежно. Однако машина может с легкостью воспроизводить эти же действия и проверить, допустим, что комбинация логин/пароль будет работать и в сотый раз без каких-либо нареканий.
Если ваши тесты могут запускаться с помощью скриптов из терминала, вы можете автоматизировать их, использовав сервер непрерывной интеграции по типу Bamboo или же облачного сервера Bitbucket Pipelines. Эти инструменты будут мониторить ваши репозитории и исполнять наборы тестов, как только новые изменения будут запушены в основной репозиторий.
Если вы новичок в вопросах тестирования, обратитесь к нашему руководству по непрерывной интеграции, чтобы создать свой первый набор тестов.
Чем больше функций и улучшений добавляется в ваш код, тем больше возрастает потребность в тестировании, поскольку на каждом этапе вам необходимо убеждаться, что система работает корректно. Также это понадобится каждый раз, когда вы исправляете баг, поскольку было бы не лишним убедиться, что он не вернется снова после нескольких релизов. Автоматизация – это ключ к тому, чтобы это стало возможным; написание тестов рано или поздно станет частью вашей практики разработчика.
Вопрос заключается в том, надо ли вообще в таком случае проводить ручное тестирование? Короткий ответ – да, и оно должно быть сфокусировано на том, что называется «исследовательское тестирование» (exploratory testing), которое помогает выявить неочевидные ошибки.
Сессия исследовательского тестирования не должна превышать двух часов и должна иметь четко ограниченную область действия, чтобы помочь тестировщикам сосредоточиться на определенной области программного обеспечения. После информирования всех тестировщиков о границах проведения тестирования, на их усмотрения остаются действия, которые они будут предпринимать, чтобы проверить, как поведет себя система. Такое тестирование является дорогостоящим по своей природе, но очень полезно для выявления проблем с пользовательским интерфейсом или проверки работоспособности сложных рабочих процессов для пользователей. Такое тестирование важно проводить всякий раз, когда в приложение добавляется кардинально новая функция, чтобы понять, как она поведет себя в пограничных условиях.
Заметка о тестировании
Перед тем, как закончить эту статью, я хочу поговорить о цели тестирования. С одной стороны, очень важно удостовериться, что пользователи смогут использовать ваше приложение («Я не могу войти в систему», «Я не могу сохранить данные» и т.п.), но с другой стороны не менее важно проверить, что ваша система не ломается при вводе неверных данных или неожиданных действиях. Вам нужно предвидеть, что произойдет, когда пользователь сделает опечатку, попытается сохранить неполную форму или использует неправильный API. Вам нужно проверить, сможет ли кто-то из пользователей легко скомпрометировать данные, получить доступ к тому или иному ресурсу, к которому у него не должно быть доступа. Хороший набор тестов должен попытаться сломать ваше приложение и помочь понять предел его возможностей.
И, наконец, тесты – это тоже код! Так что не забывайте о них во время code review, поскольку они могут быть последним этапом перед выпуском продукта на потребительский рынок.
По устоявшейся традиции ждем ваши комментарии и приглашаем всех на день открытых дверей, который уже 18 марта проведет наш преподаватель — ведущий автоматизатор в тестировании в Group-IB — Михаил Самойлов.
Тестирование программ: виды, этапы, принципы
Рассказываю о том, что отнимает большую часть времени при разработке приложений, а еще и об интересной и крайне привлекательной профессии в мире IT. Поговорим о том, кто и как тестирует программы.
Зачем проводят тестирование?
Программисты часто допускают ошибки, поэтому идеальных «беспроблемных» приложений в природе не существует. В ходе разработки (особенно длительной) «замыливается» глаз, и вникать в мелкие детали уже не получается, не говоря уже о проработке разного рода специфичных сценариев использования.
По этой причине в разработке существует отдельный этап, полностью посвященный проверке ПО на работоспособность в различных ситуациях.
Если пренебречь этой стадией создания программного продукта, то с вероятностью в 100% в итоговом приложении обнаружится баг, серьезно влияющий на производительность или функциональную составляющую приложения. Тесты помогают эту вероятность снизить.
Виды тестирования
Виды тестированияФункциональное и нефункциональное
Под функциональным тестированием подразумевается проверка (как понятно из названия) функций приложения. Специально обученный человек тыкает во все доступные кнопки, зачастую ведет себя неадекватно и непредсказуемо для программиста, чтобы выявить все «слабые места» полуготового проекта.
Обычно проверяются именно те возможности, что уже задокументированы и точно должны работать, но в ход может пойти тестирование «неожидаемых» функций и сценариев поведения программы.
Нефункциональное тестирование включает в себя проверку производительности программы, ее надежность, отзывчивость, а также соответствие стандартам безопасности.
Статическое и динамическое
Первый вариант проходит без включения программы. Выглядит это следующим образом: инженеры открывают документацию программы, изучают описанные в ней функции, а потом исследуют код, чтобы оценить качество реализации.
Второй вариант начинается следом, когда нужно включить приложение и уже на деле проверить, работают ли заявленные функции.
Оба этапа обязательны к выполнению.
Другие виды тестирования
Существует еще несколько вариацией тестирования. Каждую мелкую задачу нередко выделяют в отдельный тип, но я перечислю лишь несколько наиболее популярных.
Нагрузочное
Проверка того, как поведет себя приложение при повышении нагрузки, в частности выше задуманной разработчиками. Такие стресс-тесты играют критическое значение в онлайн-сервисах, потенциально подвергаемых избыточной нагрузке из-за большого количества пользователей на пиковой или регулярной основе (онлайн-магазины в ходе распродаж, новостные ресурсы в период громких событий).
Тестирование UX
Особый тип проверки с акцентом на пользовательском опыте. Тестировщик примеряет на себя роль клиента и всячески пытается в нее вжиться, пока пользуется программой, впоследствии делясь впечатлениями, на основе которых вносятся коррективы.
Конфигурационное
Тестирование совместимости программного продукта с аппаратным обеспечением и другими software-компонентами (разными версиями ОС и процессоров). Такое актуально для кроссплатформенных приложений и при переходе поставщика платформы на принципиально новое аппаратное шасси (как было при появлении ноутбуков на базе чипов М1 от компании Apple).
Что тестируют на разных этапах разработки?
Если говорить о различных видах тестирования, распределяя каждое в хронологическом порядке, то получится 4 ключевых этапа.
Модульное тестирование
Оно выполняется на ранних этапах, когда готовятся отдельные куски приложения (классы, компоненты, функции). В этот момент тестировщики скрупулезно пишут автоматические тесты для каждой функции будущей программы. Это необходимо потому, что проверить «софт» в графическом интерфейсе пока нереально, да и автоматика дает лучший результат.
Тесты повторяются при каждом внесении изменений, чтобы не пропустить появление ошибок и не допустить резкого падения производительности.
Интеграционное
Проводится на следующем этапе, когда некоторые модули объединяются и превращаются в более крупный компонент, более приближенный к готовой программе.
Тестировщики проверяют, как ведут себе ранее разобщенные модули, совмещенные в единый продукт, и как этот готовый продукт функционирует сам по себе. Также на стадии интеграции проверяется совместимость создаваемого ПО с операционной системой, на которой оно будет работать, а иногда еще и с аппаратной частью, чтобы создаваемый продукт нормально функционировал на большем количестве устройств.
Системное
Стадия системного тестирования нам уже знакома, она тесно привязана к функциональному и нефункциональному типу.
Именно в ходе системного тестирования специально обученные люди проверяют, соответствует ли детище программистов тому, что было заявлено с точки зрения возможностей, и стандартам качества компании с позиции производительности, отзывчивости, отказоустойчивости и прочих технических аспектов.
При желании сюда можно включить проверку UX (хотя чаще эту методику выделяют в отдельный пункт).
Приемочное
Финальный этап, в котором участвует заказчик программы, причем он может как оценить приложение вручную без помощи инженеров, так и нанять независимую команду специалистов, способных провести скрупулезное исследование ПО, чтобы выявить в нем даже «скрытые» недочеты. А тестировщики со стороны программиста должны наглядно продемонстрировать заказчику, что все работает так, как задумано.
Итог такого тестирования – либо приемка заказа и оплата, либо отправка готового продукта на доработку.
План тестирования приложения и других программных продуктов
Есть отработанная схема тестирования продуктов, проводящаяся в три этапа перед переходом к их запуску.
Отмечу, что это не обязательная схема, которую должны применять все без исключения компании и тестировщики. Каждый вправе подстраивать процесс проверки ПО под свои нужды.
Подготовка плана тестирования
Это своего рода «дорожная карта» с указаниями, из каких действий будет состоять проверка программы и в какие примерно сроки будет завершено каждое из них. Тут важно понимать, что ни один из пунктов плана не может быть соблюден на 100%. Обязательно появятся изменения, вносимые в ходе работы, и их будет много. То начальство внесет коррективы в график работы, то заказчик изменит свои «хотелки». Увы, но процесс создания приложений тесно сопряжен с постоянно варьирующимися планами. C’est la vie.
Составление перечня тест-кейсов
Тест-кейсы – конкретные действия или наборы действий, выполняемые тестировщиками, чтобы оценить работоспособность ПО. Здесь важно учесть те сценарии, которые будут наиболее близки к реальности.
Нужно взять на себя роль потенциального пользователя и понять, как он будет взаимодействовать с утилитой – что он будет делать, как он будет это делать, не сможет ли он что-то поломать.
Ну и про отработку функций, описанных в документации, забывать тоже нельзя. Они обязаны быть в списке тест-кейсов.
Внедрение автоматических инструментов для тестирования ПО
Тестировщик также оценивают необходимость в использовании автоматизированных скриптов для проверки качества «софта», то есть кусков кода, которые запускают куски кода из разработанного ПО с целью выдать положительный или отрицательный результат.
Прелесть автотестов заключается в том, что с их помощью можно заранее предусмотреть десятки и тысячи сценариев использования отдельных функций и буквально в один клик все их провести, убедившись в работоспособности ПО.
А после этого тестировщик переходит к тем этапам, что описаны в разделе «Что тестируют на разных этапах разработки?».
10 принципов успешного тестирования
Поговорим о 10 вещах, которые нужно держать в уме при тестировании сайтов и приложений. Это не строгие рекомендации, но на них ориентируются опытные тестировщики по всему миру.
Важно тестировать «софт» на реальных устройствах, а не только в эмуляторах, и желательно с разными разрешениями, ОС и наборами аппаратных компонентов.
Любой вид тестирования нужно укладывать в рамки расписания, чтобы не затягивать.
Не должно быть каких-то изысканных методов выполнения поставленной перед программой задачи, с которыми рядовой пользователь не сможет справиться.
Не пропускайте этап проверки UX. Он один из ключевых.
Не занимайтесь дебаггингом. Это работа программиста. Ваша работа – тестировать и указывать кодерам на обнаруженные ошибки.
Никаких «галопом по Европам». Вдумчивый тест даст больше результатов. Планируйте и следуйте плану, чтобы не упустить важные детали.
Устраивайте неадекватные тесты и перегрузки, чтобы убедиться в «выносливости» проверяемого ПО.
Проверяйте ПО даже на устаревших гаджетах с 2G-подключением. Среди ваших пользователей может найтись много таких.
Автотесты – ваш друг. Учитесь писать их грамотно.
Работайте в команде. Два тестировщика гораздо эффективнее ищут баги, так как могут действовать совсем иначе.
Профессия «тестировщик»
Существует целый отряд инженеров, отвечающих за контроль качества – их называют QA-инженерами. В этой профессии есть десятки подразделений по типу деятельности.
Кто-то тестирует только базы данных и не дает попасть ненужной информации в программу или случайно потерять важные для пользователя параметры.
Кто-то профессионально пишет автотесты и незаменим на ранних этапах проверки ПО.
Некоторые сотрудники отвечают за аналитику.
А кто-то проверяет сайты и приложения на наличие брешей в безопасности, чтобы убедиться в том, что пользователям не угрожает опасность при работе с детищем разработчиков.
Тестировщик – перспективное направление в IT. Востребованная профессия, активно разыскиваемая рекрутами на HeadHunter и аналогах. А еще эта работа считается самой несложной ступенью для «входа» в IT, так как освоить специализацию тестировщика можно быстрее, не так глубоко вникая в программирование в целом. И уже после опыта работы в тестировании перейти в более продвинутое направление (веб-дизайн, нейросети, криптовалюты и т.п.).
Вместо заключения
Задача тестировщика – сделать так, чтобы до пользователя добралась наиболее качественная версия задуманного ПО. Быстрая, удобная, красивая программа, за которую не будет стыдно программисту, QA-инженерам, начальству и заказчику. Если вы сами хотите стать тестировщиком, то ставьте во главу угла пользователя. Это лучший метод качественно сделать свою работу.