Как протестировать приложение на ошибки
Список от руководителя проектов компании-разработчика MobileUp Олега Широкова.
Несколько месяцев вы с разработчиками трудились над созданием приложения. Настало время его выпускать. Все фичи готовы и работают, как задумано.
Но всё же есть вероятность, что в процессе был упущен какой-нибудь важный момент. Поэтому мы собрали список распространённых ошибок, которые нужно обязательно проверить перед релизом, даже если вас убеждают, что всё нормально.
Материал поможет продакт-менеджерам и собственникам бизнеса на клиентской стороне убедиться в том, что их приложение действительно готово к релизу и не нуждается в срочных доработках.
Нужно проверить, как приложение ведёт себя в проблемных ситуациях. Детально это изучают тестировщики, поэтому здесь речь идет о быстром smoke-тесте самых популярных кейсов.
Если приложение использует геолокацию, то нужно проверить, как оно ведёт себя в типичных случаях.
Первая ситуация: пользователь запретил приложению доступ к геолокации
Как проверить: в настройках запретить приложению доступ к геоданным и запустить приложение.
iOS-приложение Maps.me показывает детальную инструкцию по включению геолокации. iOS-приложение «Яндекс.Карты» вообще ничего вам не сообщит, пока вы не нажмете кнопку определения местоположения.Вторая ситуация: приложению не удаётся быстро определить координаты пользователя. Например, если он находится в помещении или выключил Wi-Fi и мобильный интернет.
Как должно быть: показать последнее определённое местоположение пользователя, а если его нет — показать какую-то точку по умолчанию или заглушку, но не карту в море.
Как проверять: включить авиарежим и запустить приложение.
Приложения Google Maps, «Яндекс.Карты», Maps.me (iOS-версии) показывают последнее определенное местоположение. Android-приложение Waze показывает пользователю карту в море.Первая ситуация: пользователь совершает действие, для которого нужен доступ к интернету. Например, нажимает на кнопку «Загрузить». А интернета в этот момент нет.
Как проверить: запустить приложение, выключить интернет, нажать на какую-нибудь кнопку действия.
При попытке найти ближайшие велостанции iOS-приложение «Велогород» подсказывает, что доступа к интернету нет. В iOS-версии TaxFree4U при тапе на кнопку «Восстановить» ничего не происходит.Вторая ситуация: пользователь хочет перейти в другой раздел приложения, например, из бокового меню, а доступа к интернету нет.
Как проверить: запустить приложение, зайти в один из разделов, потом перейти в другой, отключить интернет, вернуться в предыдущий раздел.
Третья ситуация: интернет есть, но нестабильный — и он пропал в процессе загрузки экрана.
Как проверить: запустить приложение, зайти в один из разделов, потом перейти в другой раздел, для которого нужно загрузить много данных с сервера, и в процессе загрузки отключить интернет.
iOS-приложение «ВКонтакте» при разрыве связи с интернетом оставляет ленту в том состоянии, в котором успело её загрузить. iOS-версия HeadHunter при разрыве соединения вместо уже найденных и показанных на экране вакансий раньше показывала заглушку. Достаточно было немного поскроллить экран с результатами поиска.Четвёртая ситуация: при открытии экрана не было интернета, он появился уже после.
Обработка такой ситуации нужна не в каждом приложении и не на каждом экране. Но она очень актуальна для чатов, соцсетей и приложений, работающих с картой.
Как должно быть: приложение периодически проверяет, не появился ли интернет снова. Если появился — загружает нужные данные автоматически без дополнительных действий со стороны пользователя.
Как проверить: запустить приложение, включить авиарежим, выключить авиарежим.
iOS-приложение Uber при появлении интернета автоматически возобновляет загрузку данных. iOS-версия «Яндекс.Такси» ждёт, пока пользователь сдвинет карту.Логика и сценарий проверки здесь такие же, как и при проблемах с интернетом. Только вместо отключения интернета нужно попросить серверного разработчика отдавать приложению различные ошибки.
Любой грамотный дизайнер или разработчик скажет вам, что текст на экране так же важен, как удобный интерфейс и отсутствие багов. Пользователи часто не могут разобраться с непонятными пояснениями и названиями кнопок. А конкурентов и многочисленных «диванных» экспертов знатно повеселят найденные орфографические ошибки.
Поэтому обязательно нужно заглянуть на каждый экран приложения и проверить тексты на внятность и орфографические ошибки. Для ускорения работы можно попросить разработчиков сделать скриншоты всех экранов и состояний через специальный сервис. Например, Fastlane Snapshot.
В продуманных приложениях названия кнопок соответствуют тому, что произойдёт при их нажатии, и побуждают к действию. Например: «Выбрать» и «Подтвердить» вместо «ОК», «Отказаться» вместо «Отмена», «Найти мастера» вместо «Поиск мастеров».
iOS-приложение «Эриус» просто объясняет, что нужно сделать пользователю. А инструкция по оплате в iOS-приложении «Метро Москвы» написана сложным канцелярским языком, в котором тяжело разобраться.Когда пользователь совершает критичные действия, которые нельзя вернуть назад или которые могут доставить ему неудобства, нужно обязательно показывать диалоги-подтверждения. Примеры таких действий: выход из учётной записи, удаление контента, отмена заказа и так далее.
iOS-приложение «ВКонтакте» при выходе из учётной записи запрашивает подтверждение. iOS-приложение PlayStation разлогинивает сразу.Когда пользователь только установил приложение, в некоторых разделах у него будет пусто, например, в списке заказов. Чтобы эти разделы не были пустыми и грустными, в них размещают специальные заглушки с картинкой и пояснением, как заполнить этот раздел.
В продуманном приложении помимо текста будет кнопка. Например, «Создать первый заказ».
В продуманных приложениях на видном месте (например, в боковом меню или в профиле) есть контакты технической поддержки. Это позволяет уменьшить количество гневных отзывов в App Store и Google Play.
В iOS-версии Aladdin телефон и email техподдержки расположены на видном месте. А в iOS-приложении iTunesConnect есть только ссылка на веб-страницу с FAQ, при переходе на которую возникает ошибка: «Page not found».Перед релизом в приложения обычно интегрируют один или несколько сервисов по сбору аналитики: Google Analytics, Mixpanel, Fabric.io, Flurry, Appsee. Собранные данные можно удобно просматривать в веб-интерфейсе.
Если это ваше первое мобильное приложение, то вы, скорее всего, не будете детально знать, какие действия нужно отслеживать. Но есть минимальный набор, который точно нужно настроить.
Чтобы отслеживать, как часто приложение «падает» и у какого процента пользователей, настраивают сбор крэшей. Кроме того, они помогают разработчикам быстрее разобраться с причиной падения.
Статистика самых распространенных крэшей в Crashlytics для приложения DMV GenieЧасть этой информации можно посмотреть в iTunesConnect или Google Developer Console и без интеграции отдельного сервиса. Полный набор: количество установок, количество активных пользователей, среднее время, проводимое в приложении и прочее, — доступен только в специализированных сервисах аналитики.
Эта информация даст понять, востребовано ли ваше приложение и помог ли бюджет на продвижение.
Так вы сможете узнать, в каких разделах приложения пользователи проводят больше всего времени. Например, если у вас есть важный раздел с акциями, но пользователи туда не заходят, то, возможно, интерфейс приложения нужно доработать.
Если в приложении пользователи что-то заказывают или покупают, смотреть количество этих действий и считать конверсию удобно в аналитике. Для этого нужно настроить специальные «кастомные события». В приложении «Туту ЖД» список таких событий занимает четыре полных листа А4.
Раздел статистики по событиям в Google Analytics для приложения Aerostat iOSНа ранних этапах разработчик обычно настраивает взаимодействие с внешними сервисами через тестовые аккаунты. Например:
- отправку тестовых сборок (HockeyApp, TestFlight и так далее);
- крэшлог и сбор аналитики (Crashlytics, Google Analytics, Firebase и так далее);
- карты (Google Maps, «Яндекс.Карты», OSM и так далее);
- push-уведомления (Firebase и другие).
К моменту релиза приложения все эти сервисы должны быть переведены на аккаунты заказчика. Это может показаться очевидным, но мы не раз сталкивались с ситуациями, когда это не было сделано. Также после перевода всех сервисов на аккаунты заказчика нужно проверить, что они работают.
Мне кажется всю статью нужно заменить на один совет:
Проверьте, что вы наняли квалифицированного специалиста по тестированию
Так что мы вас понимаем, но пример не самый удачный. ;-)
Когда рассматривается удобство интерфейса, то общих принципов достаточно не всегда. Что если метрики сильно падают от смены текста на кнопке? Что делать?
Мы тексты на СТА - тестируем АБ-тестами регулярно. Результаты часто контринтуитивные (детали сказать не можем). :)
Правильные решения находятся в точке баланса метрик и создания верных ожиданий у пользователя.
Всем привет! Уже на следующей неделе мы запускаем новый поток по курсу «Автоматизация веб-тестирования». Этому и будет посвящен сегодняшний материал.
В этой статье рассматриваются различные способы тестирования программного обеспечения, такие как модульное тестирование (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)
Дымовые тесты – это базовые тесты, которые проверяют базовый функционал приложения. Они отрабатывают достаточно быстро и их цель дать понять, что основные функции системы работают как надо и не более того. Такое тестирование направлено на выявление явных ошибок.
Дымовые тесты могут оказаться полезными сразу после сборки нового билда для проверки на то, можете ли вы запустить более дорогостоящие тесты, или сразу после развёртывания, чтобы убедиться, что приложение работает нормально в новой среде.
Как автоматизировать тесты
Тестировщик может проводить все тесты, указанные выше, вручную, но это будет крайне затратно и непродуктивно. Поскольку люди имеют ограниченную возможность производить большое количество действий с повторениями при этом все еще проводя тестирование надежно. Однако машина может с легкостью воспроизводить эти же действия и проверить, допустим, что комбинация логин/пароль будет работать и в сотый раз без каких-либо нареканий.
Для автоматизации тестирования, вам для начала придется написать их на каком-то из языков программирования с использованием фреймворка для тестирования, который подойдет для вашего приложения. PHPUnit , Mocha, RSpec – это примеры фреймворков для тестирования, которые вы можете использовать для PHP, Javascript и Ruby, соответственно. В них есть множество возможностей для каждого языка, поэтому вам стоит немного позаниматься исследованием самостоятельно и проконсультироваться с сообществами разработчиков, чтобы понять, какой фреймворк подойдет вам лучше всего.
Если ваши тесты могут запускаться с помощью скриптов из терминала, вы можете автоматизировать их, использовав сервер непрерывной интеграции по типу Bamboo или же облачного сервера Bitbucket Pipelines. Эти инструменты будут мониторить ваши репозитории и исполнять наборы тестов, как только новые изменения будут запушены в основной репозиторий.
Если вы новичок в вопросах тестирования, обратитесь к нашему руководству по непрерывной интеграции, чтобы создать свой первый набор тестов.
Исследовательское тестирование
Чем больше функций и улучшений добавляется в ваш код, тем больше возрастает потребность в тестировании, поскольку на каждом этапе вам необходимо убеждаться, что система работает корректно. Также это понадобится каждый раз, когда вы исправляете баг, поскольку было бы не лишним убедиться, что он не вернется снова после нескольких релизов. Автоматизация – это ключ к тому, чтобы это стало возможным; написание тестов рано или поздно станет частью вашей практики разработчика.
Вопрос заключается в том, надо ли вообще в таком случае проводить ручное тестирование? Короткий ответ – да, и оно должно быть сфокусировано на том, что называется «исследовательское тестирование» (exploratory testing), которое помогает выявить неочевидные ошибки.
Сессия исследовательского тестирования не должна превышать двух часов и должна иметь четко ограниченную область действия, чтобы помочь тестировщикам сосредоточиться на определенной области программного обеспечения. После информирования всех тестировщиков о границах проведения тестирования, на их усмотрения остаются действия, которые они будут предпринимать, чтобы проверить, как поведет себя система. Такое тестирование является дорогостоящим по своей природе, но очень полезно для выявления проблем с пользовательским интерфейсом или проверки работоспособности сложных рабочих процессов для пользователей. Такое тестирование важно проводить всякий раз, когда в приложение добавляется кардинально новая функция, чтобы понять, как она поведет себя в пограничных условиях.
Заметка о тестировании
Перед тем, как закончить эту статью, я хочу поговорить о цели тестирования. С одной стороны, очень важно удостовериться, что пользователи смогут использовать ваше приложение («Я не могу войти в систему», «Я не могу сохранить данные» и т.п.), но с другой стороны не менее важно проверить, что ваша система не ломается при вводе неверных данных или неожиданных действиях. Вам нужно предвидеть, что произойдет, когда пользователь сделает опечатку, попытается сохранить неполную форму или использует неправильный API. Вам нужно проверить, сможет ли кто-то из пользователей легко скомпрометировать данные, получить доступ к тому или иному ресурсу, к которому у него не должно быть доступа. Хороший набор тестов должен попытаться сломать ваше приложение и помочь понять предел его возможностей.
И, наконец, тесты – это тоже код! Так что не забывайте о них во время code review, поскольку они могут быть последним этапом перед выпуском продукта на потребительский рынок.
По устоявшейся традиции ждем ваши комментарии и приглашаем всех на день открытых дверей, который уже 18 марта проведет наш преподаватель — ведущий автоматизатор в тестировании в Group-IB — Михаил Самойлов.
Вы, как создатель своего продукта или услуги, понимаете как он работает, какие связи между процессами и чего хотят клиенты. Поэтому при тестировании хорошо определяете ошибки и недочеты.
Конечно, ваши возможности ограничены — как знаниями и навыками, так и техническим оснащением. Вы не сможете проверить работу приложения на разных устройствах или его безопасность, наличие ошибки в коде. Но вам подвластно проверить, как работает функционал и какие упущения во внешнем виде, удобство приложения.
Сценарии тестирования
Ваша задача — встать на место пользователя и пройти его путь от входа в приложение до закрытия, при этом выполнить все действия, которые ему доступны. В ходе прохождения выявить проблемы, с которыми пользователь не должен сталкиваться, или найти изъяны в дизайне, которые водят его в заблуждение. В профессиональной среде такие сценарии называются «функциональное тестирование» и «тестирование удобства пользования». Для каждого мы написали принципы и основные моменты, на которые нужно обратить внимание.
Функциональное тестирование
Обязательно нужно тестировать приложение на пограничных состояниях.Мы разработали веб-приложение для сервиса грузоперевозок Shustrikoff. Стоимость доставки зависит от удаленности от центра города, поэтому при тестировании проверяли адреса на границе Казани и другого района. Также можно проверить заявки в разных районах города, заказ назначенный на границе дневного и ночного тарифа и т.п.
Тестирование удобства пользования
- Как обозначены обязательные и необязательные поля для заполнения? Можно ли их отличить друг от друга?
- Понятно ли, как действовать дальше и куда нажимать? Если вы всматриваетесь в экран в поисках следующего шага или кнопки, зафиксируйте этот момент. Интерфейс должен быть интуитивно понятен, вести пользователя по конкретному маршруту в назначенную точку. Важную роль в этом играют как расположение элементов на экране, так и их стиль.
- Можно ли продолжить работу в приложении после того как свернул и обратно развернул его? Не выкидывает ли пользователя?
- Цвет кнопок с одинаковой функцией совпадает.
- Как воспринимается текст на экране: заголовок заметнее всех, шрифт не напрягает, текст читается легко, смысл понятен, поля учтены.
- Звук в приложении: что с ним происходит и как он звучит в разных состояниях приложения. Например, как работает приложение, когда подключена гарнитура или включается сторонний проигрыватель либо при сворачивании приложения.
- Сколько времени и шагов понадобилось для завершения основных задач приложения? Можно ли упростить этот путь?
Оформляем и передаем информацию разработчикам
Включаем режим «бюрократии», потому что правильно оформленная ошибка сэкономит вам и разработчикам часы работы.
Представьте: разработчики не будут уточнять детали каждой ошибки, переспрашивать, для разъяснений не понадобятся эти звонки по телефону, которые мало кто любит (Привет миллениалам!). В ваших отношениях с командой будет процветать гармония и полное взаимопонимание.
- Дайте название ошибке. Будет легче ориентироваться по списку и в разговоре с командой.
- Опишите ошибку. Что конкретно не так? Как задумывалось и должно быть?
- Приложите скриншот или запись экрана, если ошибка происходит при конкретной последовательности действий.
- Какая версия: десктоп или мобильная?
- Какая платформа: iOS или Android?
- Какой браузер и какая версия браузера?
- Дайте подробный путь к странице/экрану с ошибкой.
Скорее всего команда уже использует определенный сервис для работы с задачами, где и собирает всю информацию по приложению. Поэтому они могут дать внешний доступ, чтобы вы в этом же пространстве вносили информацию по результатам своего тестирования. Собирайте все в единой структуре в одном месте.
Рассказываю о том, что отнимает большую часть времени при разработке приложений, а еще и об интересной и крайне привлекательной профессии в мире IT. Поговорим о том, кто и как тестирует программы.
Зачем проводят тестирование?
Программисты часто допускают ошибки, поэтому идеальных «беспроблемных» приложений в природе не существует. В ходе разработки (особенно длительной) «замыливается» глаз, и вникать в мелкие детали уже не получается, не говоря уже о проработке разного рода специфичных сценариев использования.
По этой причине в разработке существует отдельный этап, полностью посвященный проверке ПО на работоспособность в различных ситуациях.
Если пренебречь этой стадией создания программного продукта, то с вероятностью в 100% в итоговом приложении обнаружится баг, серьезно влияющий на производительность или функциональную составляющую приложения. Тесты помогают эту вероятность снизить.
![Тестирование кода на мобильном устройстве]()
Виды тестирования
Функциональное и нефункциональное
Под функциональным тестированием подразумевается проверка (как понятно из названия) функций приложения. Специально обученный человек тыкает во все доступные кнопки, зачастую ведет себя неадекватно и непредсказуемо для программиста, чтобы выявить все «слабые места» полуготового проекта.
Обычно проверяются именно те возможности, что уже задокументированы и точно должны работать, но в ход может пойти тестирование «неожидаемых» функций и сценариев поведения программы.
Нефункциональное тестирование включает в себя проверку производительности программы, ее надежность, отзывчивость, а также соответствие стандартам безопасности.
Статическое и динамическое
Первый вариант проходит без включения программы. Выглядит это следующим образом: инженеры открывают документацию программы, изучают описанные в ней функции, а потом исследуют код, чтобы оценить качество реализации.
Второй вариант начинается следом, когда нужно включить приложение и уже на деле проверить, работают ли заявленные функции.
Оба этапа обязательны к выполнению.
Другие виды тестирования
Существует еще несколько вариацией тестирования. Каждую мелкую задачу нередко выделяют в отдельный тип, но я перечислю лишь несколько наиболее популярных.
Нагрузочное
Проверка того, как поведет себя приложение при повышении нагрузки, в частности выше задуманной разработчиками. Такие стресс-тесты играют критическое значение в онлайн-сервисах, потенциально подвергаемых избыточной нагрузке из-за большого количества пользователей на пиковой или регулярной основе (онлайн-магазины в ходе распродаж, новостные ресурсы в период громких событий).
Тестирование UX
Особый тип проверки с акцентом на пользовательском опыте. Тестировщик примеряет на себя роль клиента и всячески пытается в нее вжиться, пока пользуется программой, впоследствии делясь впечатлениями, на основе которых вносятся коррективы.
Конфигурационное
Тестирование совместимости программного продукта с аппаратным обеспечением и другими software-компонентами (разными версиями ОС и процессоров). Такое актуально для кроссплатформенных приложений и при переходе поставщика платформы на принципиально новое аппаратное шасси (как было при появлении ноутбуков на базе чипов М1 от компании Apple).
Что тестируют на разных этапах разработки?
Если говорить о различных видах тестирования, распределяя каждое в хронологическом порядке, то получится 4 ключевых этапа.
Модульное тестирование
Оно выполняется на ранних этапах, когда готовятся отдельные куски приложения (классы, компоненты, функции). В этот момент тестировщики скрупулезно пишут автоматические тесты для каждой функции будущей программы. Это необходимо потому, что проверить «софт» в графическом интерфейсе пока нереально, да и автоматика дает лучший результат.
Тесты повторяются при каждом внесении изменений, чтобы не пропустить появление ошибок и не допустить резкого падения производительности.
Интеграционное
Проводится на следующем этапе, когда некоторые модули объединяются и превращаются в более крупный компонент, более приближенный к готовой программе.
Тестировщики проверяют, как ведут себе ранее разобщенные модули, совмещенные в единый продукт, и как этот готовый продукт функционирует сам по себе. Также на стадии интеграции проверяется совместимость создаваемого ПО с операционной системой, на которой оно будет работать, а иногда еще и с аппаратной частью, чтобы создаваемый продукт нормально функционировал на большем количестве устройств.
Системное
Стадия системного тестирования нам уже знакома, она тесно привязана к функциональному и нефункциональному типу.
Именно в ходе системного тестирования специально обученные люди проверяют, соответствует ли детище программистов тому, что было заявлено с точки зрения возможностей, и стандартам качества компании с позиции производительности, отзывчивости, отказоустойчивости и прочих технических аспектов.
При желании сюда можно включить проверку UX (хотя чаще эту методику выделяют в отдельный пункт).
Приемочное
Финальный этап, в котором участвует заказчик программы, причем он может как оценить приложение вручную без помощи инженеров, так и нанять независимую команду специалистов, способных провести скрупулезное исследование ПО, чтобы выявить в нем даже «скрытые» недочеты. А тестировщики со стороны программиста должны наглядно продемонстрировать заказчику, что все работает так, как задумано.
Итог такого тестирования – либо приемка заказа и оплата, либо отправка готового продукта на доработку.
План тестирования приложения и других программных продуктов
Есть отработанная схема тестирования продуктов, проводящаяся в три этапа перед переходом к их запуску.
Отмечу, что это не обязательная схема, которую должны применять все без исключения компании и тестировщики. Каждый вправе подстраивать процесс проверки ПО под свои нужды.
Подготовка плана тестирования
Это своего рода «дорожная карта» с указаниями, из каких действий будет состоять проверка программы и в какие примерно сроки будет завершено каждое из них. Тут важно понимать, что ни один из пунктов плана не может быть соблюден на 100%. Обязательно появятся изменения, вносимые в ходе работы, и их будет много. То начальство внесет коррективы в график работы, то заказчик изменит свои «хотелки». Увы, но процесс создания приложений тесно сопряжен с постоянно варьирующимися планами. C’est la vie.
Составление перечня тест-кейсов
Тест-кейсы – конкретные действия или наборы действий, выполняемые тестировщиками, чтобы оценить работоспособность ПО. Здесь важно учесть те сценарии, которые будут наиболее близки к реальности.
Нужно взять на себя роль потенциального пользователя и понять, как он будет взаимодействовать с утилитой – что он будет делать, как он будет это делать, не сможет ли он что-то поломать.
Ну и про отработку функций, описанных в документации, забывать тоже нельзя. Они обязаны быть в списке тест-кейсов.
Внедрение автоматических инструментов для тестирования ПО
Тестировщик также оценивают необходимость в использовании автоматизированных скриптов для проверки качества «софта», то есть кусков кода, которые запускают куски кода из разработанного ПО с целью выдать положительный или отрицательный результат.
Прелесть автотестов заключается в том, что с их помощью можно заранее предусмотреть десятки и тысячи сценариев использования отдельных функций и буквально в один клик все их провести, убедившись в работоспособности ПО.
А после этого тестировщик переходит к тем этапам, что описаны в разделе «Что тестируют на разных этапах разработки?».
10 принципов успешного тестирования
Поговорим о 10 вещах, которые нужно держать в уме при тестировании сайтов и приложений. Это не строгие рекомендации, но на них ориентируются опытные тестировщики по всему миру.
Важно тестировать «софт» на реальных устройствах, а не только в эмуляторах, и желательно с разными разрешениями, ОС и наборами аппаратных компонентов.
Любой вид тестирования нужно укладывать в рамки расписания, чтобы не затягивать.
Не пропускайте этап проверки UX. Он один из ключевых.
Не занимайтесь дебаггингом. Это работа программиста. Ваша работа – тестировать и указывать кодерам на обнаруженные ошибки.
Никаких «галопом по Европам». Вдумчивый тест даст больше результатов. Планируйте и следуйте плану, чтобы не упустить важные детали.
Устраивайте неадекватные тесты и перегрузки, чтобы убедиться в «выносливости» проверяемого ПО.
Проверяйте ПО даже на устаревших гаджетах с 2G-подключением. Среди ваших пользователей может найтись много таких.
Автотесты – ваш друг. Учитесь писать их грамотно.
Работайте в команде. Два тестировщика гораздо эффективнее ищут баги, так как могут действовать совсем иначе.
Профессия «тестировщик»
Существует целый отряд инженеров, отвечающих за контроль качества – их называют QA-инженерами. В этой профессии есть десятки подразделений по типу деятельности.
Кто-то тестирует только базы данных и не дает попасть ненужной информации в программу или случайно потерять важные для пользователя параметры.
Кто-то профессионально пишет автотесты и незаменим на ранних этапах проверки ПО.
Некоторые сотрудники отвечают за аналитику.
А кто-то проверяет сайты и приложения на наличие брешей в безопасности, чтобы убедиться в том, что пользователям не угрожает опасность при работе с детищем разработчиков.
Тестировщик – перспективное направление в IT. Востребованная профессия, активно разыскиваемая рекрутами на HeadHunter и аналогах. А еще эта работа считается самой несложной ступенью для «входа» в IT, так как освоить специализацию тестировщика можно быстрее, не так глубоко вникая в программирование в целом. И уже после опыта работы в тестировании перейти в более продвинутое направление (веб-дизайн, нейросети, криптовалюты и т.п.).
Вместо заключения
Задача тестировщика – сделать так, чтобы до пользователя добралась наиболее качественная версия задуманного ПО. Быстрая, удобная, красивая программа, за которую не будет стыдно программисту, QA-инженерам, начальству и заказчику. Если вы сами хотите стать тестировщиком, то ставьте во главу угла пользователя. Это лучший метод качественно сделать свою работу.
Я работаю QA-Engineer'ом (Quality Assurance - обеспечение качества). QA - это человек(или целый хайвмайнд под названием "QA team"), основная задача которого - обеспечить, чтобы багов было ПРИЕМЛЕМОЕ КОЛИЧЕСТВО. Да, наша работа - не искать баги, а сделать так, чтобы баги не мешали бизнес-логике. Потому что есть такая аксиома - "Баги есть всегда". И это именно аксиома - если вы долго-долго-долго думали над структурой проекта, сделали всё вот прям идеально и сидите весь такой довольный с мыслью "А у меня в коде нет багов" - вы просто не залезли глубоко в свой проект))(Особо верующие в возможную непогрешимость девелоперов могут гуглить заезженную историю про американский самолёт в Мёртвом море и ошибку отрицательной высоты)
QA, несмотря на стереотипы - важный человек на проекте. Ошибка - вещь дорогая, и чем раньше ошибку нашли - тем дешевле её устранить. Если на стадии написания документации исправление ошибки стоит, например, 1 цент(минуту времени тестировщика, который например скажет добавить валидацию на поле), то после релиза взбешённый заказчик может очень неплохо повздорить с конторой, тем самым сильно увеличив затраты(вплоть до судебных издержек, баги в том же медицинском ПО - это человеческое здоровье, а то и жизнь)
Всё в один пост не уместить, если кому интересны подробности(Agile, всякие разные людишки на проекте типа бизнес-аналитиков, какие инструменты юзают тестеры, что такое автоматизация тестирования, Как начать и как войти в IT) - в комменты всё отвечу)
Ну и чукча не писатель, как умею - так и говорю, профессиональные писатели посмотрят и наверняка увидят кучу стилистических ошибок. Опять же приветствую любую критику в комменты))
Я уже писал это раньше в похожем посте и повторю еще раз. :)
Quality Assurance есть не тестирование, а обеспечение качества - работа с процессами на разных этапах разработки, проверка на соответствие стандартам и константный доеб менеджмента/девов/аналитиков на предмет того что код говно, на стандарты положен болт, дочь СЕО трахает аналитик, на кухне нет кофе, да и вообще все криворукие. По обязанностям действительно что-то между бизнес аналитиком и тестировщиком, только сам не тестирует. И да - реально QA вы найдете в действительно больших или очень серьезных проектах (крутой файнанс и банкинг например), потому что во проектах средней руки эти обязанности будут разделены между тест лидом, тест менеджером, архитектором и бизнес аналитиком. Куа может стоить серьезную деньгу, а тестировщик будет в среднем не дороже кодера.
А вот ребята которые тестируют документацию и пишут кейсы - это уже тестировщики в чистом виде. Причем каким бы тестированием не занимались, будь то ручное или автоматизированное, кейсы нужны всегда, хотя бы для того, чтобы можно было понять, что тестируешь и понял идею и функционал правильно, а так же чтобы было что предъявить девелоперам.
У меня для вас есть одно слово - фаззинг.
Текст про тестировщиков, а не qa)
Комментарий удален. Причина: данный аккаунт был удалёнХороших тестеров очень мало, тестировать нифига не просто, за мой почти пятилетний опыт разработки нормальных тестеров по пальцам можно было пересчитать. Когда только пришла на свою первую работу меня почти всему научила именно девочка-тестировщик, за что ей огромное спасибо. С удовольствием почитаю про тестирование.
Лови плюс, коллега
Привет, коллега-багоборец!Описанный текст, видимо, актуален для очень крупных команд.
В группах из 4-10 человек, по моему опыту, все чутка проще. Документации меньше, исследовательского тестирования больше, а тест-кейсы иногда заменяются на саму документацию (которую я по привычке именую диздоком).
У кого-то личная попаболь к автору или ко всей теме вообще?=)
Почти все коменты заминусованы были без объективных причин, аж устал исправлять.
2)"Тестер ничего полезного не делает.."
Это в нулевых осталось или мне везет? В любом случае инетересно что бы сказал такой "пограммист" перформанс-инженеру или автоматизатору, они относятся к QA.
Как к вам попасть? В интернете полно разводов по данному виду деятельности.
Ну лично меня интересует как вообще попасть в IT? Все-таки самому года через 3 нужно будет работу искать. Знания вроде есть, но уверенности нет)
4)После исправления багов QA проводит Regression Test - проверка уже проверенных кусков фич, дабы фиксы багов не создали другие баги.
ты точно тестировщик?
Спасибо за полезный пост, сейчас за пару месяцев с нуля планирую освоить азы тестирования и найти работу в мск. План как это все сделать у меня уже есть, но буду рад прочесть пост о вхождении в профессию.
>QA, несмотря на стереотипы - важный человек на проекте
Это стереотипы тех, кто никогда не участвовал в процессе.
Я вот мечтаю, что бы у нас в студии был QA, но отдельный кадр пока не берут, так что занимаемся этим все понемногу, что не может не сказываться на качестве тестирования.
история про истребитель была напечатана еще в ЛКИ, кажется.
Сам пытался выполнить ТЗ на QA. Выполнил 90% ТЗ за 2 дня, дошёл до теста дубликатов (загруженных и созданных в системе) и тут влип вообще, ошибка на ошибке (хотя по идее так быть не должно), после перезапуска сервиса всё работает. Неделю думал как оформить в тестовом это. Время вышло - плюнул и пошёл в ТП этой же компании, с мыслью, что спокойно освоюсь и переведусь) Пока полёт нормальный.
А можешь сказать в принципе, что изучать человеку кроме данных двух книг (прочитал уже), после выполнения ТЗ - уже на работе и причём срочно? И на сколько актуален для QA - тех. англ? И ЯП для написания скриптов поначалу обязателен? Какой конкретно и уровень владения? SQL в целом общее понимание ( на уровне запросов) или конкретное знание той что в стеке? В целом какой уровень понимания базы IT нужен? Сетевые протоколы? Основы вёрстки? Ну и примерный план изучения технологий и до какого уровня можешь накидать - всем я полагаю будет полезно. За пост лови + :)
ТС, ты QA или AQA?
Где трудишься?)
Кстати а можешь примерно вилку з\п рассказать. В своём регионе. Ну и от чего зависит. На сколько быстрый\небыстрый рост?
Specification(подробное техническое задание продукта)
Вы наверно имели ввиду Requirement
QA всегда участвует во всех Scrum meetings(встреча команды с утреца)
Далекоооо не всегда.
1. Как тестируют свои программы инди-девелоперы?2. Я голосую за гайд по тестированию.
Проект на работе как раз проходит активную стадию QA, ох и бесите вы меня. Хотя я понимаю важность и нужность вашей работы, но бесите :D
Ну и две книжки по тестированию сюда зарекомендуй.
было бы неплохо ознакомится с литературой, которая помогла на пути становления qa
Все стереотипы, которые ты перечислил, действительно имеют основание, просто относятся не к QA в целом, а к низшему звену: манки-тестерам.
Их не очень любят за то, что эта позиция - по сути "постель", через которую подавляющее большинство пытается попасть в индустрию.
Очень многие уходят из QA в ПМы, разрабов, проектировщиков (геймдизов в контексте геймдева).
Сертификат ISTQB есть ?
Позиция я так понимаю не senior раз описана "вся" документация ?
И да, QA Engineer это не про тестировщиков. Позиция называется Software tester. И это не разница терминов. Требования к QA Engineer и Software tester на западе явно показывают разницу.
Регрессия после фикса багов повеселила. Вы прям как один индус, который сказал, что бы было бы круто каждый спринт проводить фул регрессию.
Странно как то читать через слово английский и русский. половина терминов по русски половина по английски.
почему надо писать бизнес-аналитка по русски, а спецификая по англайски, смотрится глуповато помоему.
Тестинг VS Тестинг на поде
Будни тестировщика:
Протестировать тестировщика
У компании начинающих тестеров назрел вопрос.
Есть ли в сети какие-то тесты, по которым можно понять на сколько тестировщик готов к работе или просто попробовать какого это (тестировать) на практике?
Встретились как -то программист и тестировщик.
Но было бы правдоподобнее, если б QA начал пистолетом бить разраба :D
Делай добро и оно аукнется
Это могли бы быть мы
Интересное требование в вакансии
Уровень жадности работодателей выходит на новый уровень или "Срочно разыскивается гость со своим самоваром"
Я, конечно, понимаю, что продукт свой, но куда уж настолько экономить?
P.S Хм, где-то я уже видел что-то похожее:
Юмор на свободную тему от Совы. №92 "Программист vs эффективные тестировщики"
Юмор на свободную тему от Совы, №92
Привет, меня зовут Сергей и я тестировщик!
Когда батя тестировщик
Тестировщицкий язык
Что этот тестер себе позволяет?!
Про тестирование VR
"тип который vr решение разрабатывает рассказал как у них бенчмарки устроены:
сажают юзера с плохим вестибулярным аппаратом за слабое железо - если блюванул - бенч не прошёл"
Стрессоустойчивый
Со слов бывшего коллеги.
Работает он сейчас в IT-компании тестировщиком. Понадобился им на проект еще один тестер. Вывесили вакансию.Долго ищут, все им не нравится. Тут HR присылает резюме - у кандидата большой опыт работы, подходящие скиллы, требования по зп ниже рынка. Сказка, в общем. Пригласили пообщаться.
На собеседовании были коллега (как тимлид) и начальник отдела.
Пришел мужичок - около 35, такой интеллигентного вида, в очочках, в пиджачке.
Стандартно начали - где были, что умеете, почему уходите.
Всё при общении понравилось, потом начальник рисует на листочке форму авторизации по логину/паролю и говорит - "протестируйте". В принципе, довольно стандартная ситуация.
Мужичок посмотрел несколько секунд на начальника исподлобья, громко хмыкнул и сказал: "Серьезно? Я почти 10 лет в профессии, и вы меня просите протестировать форму входа?" - сделал паузу - "Да идите вы нахуй". Встал и ушел.
Начальник опешил конечно, почесал затылок и выдал: "а в резюме писал -стрессоустойчивый"
Пол года в тестировании или взгляд с колоколенки
Почти год назад я спрашивал мнения у вас, ребята, по поводу профессии тестировщика. Было много дельных советов, и не очень, но все они были полезны в коей-то мере. И вот, я уже ровно 7 месяцев как тестировщик. Возможно, что кому-то будет полезен пост. Вероятно, что именно ты задумываешься о том, чтобы начать строить карьеру в тестировании, но пока обременён другими заботами. Я постараюсь максимально простым языком поделиться своим скромным опытом, и возможно, повлиять на твоё решение в вопросе "хочу ли я быть тестировщиком?".В общем, заваривай чайку, хватай печенюги и усаживайся поудобнее. А я беру бокал креплёного и начинаю.
Войти в Ай-Ти или хлопоты "входа"
Немного цифр. После окончания универа по профилю "Энергетика" я уже окончательно для себя решил, что хочу быть тестировщиком. У меня всегда была тяга к тому, чтобы всё, чем я пользуюсь было идеальным + большое увлечение компами и еже с ними. Небольшой опыт кодинга (говно-кодинга) в конце 10-11 класса школы и первых курсов универа, но со временем всё забылось. После получения заветной корочки и месяца беспросветных кутежей, я составил резюме и начал шерстить вакансии на хх. И вот, первый отклик. Мне выслали тестовое задание, с ним я к сожалению не справился. Как говорится, первый блин комом. Затем почти один за одним были еще 3 ответа к моим откликам. Каждая компания высылала тестовое задание, которые я уже успешно выполнил и впереди у меня состоялись 3 первых в моей жизни собеседования. Первые два я успешно провалил, а на третьем, уже имея некоторый опыт в общении с HR и тестировщиками, успешно его прошел. Спустя приблизительно неделю в один жаркий летний день мне позвонили и сообщили, что с 1 сентября я выхожу на работу. Это была моя маленькая победа. К слову, я даже рад, что в предыдущие места меня не взяли, но об этом дальше.
Ах да, цифры, подытожим - 4 отклика, 4 тестовых задания, 3 собеседования, 1 успешное, затраченное время около 3 недель.
Испытательный срок или оклад за обучение
После оффера (успешного прохождения собеседования и приглашения на работу) я начал усиленно готовиться, читал блоги, смотрел видео, впитывал и вкушал опыт других, бывалых тестировщиков. Первые два месяца я приходил на работу и изучал документацию по продукту, который мне предстояло тестировать, смотрел видео-уроки (записывали их тестировщики из компании). Очень круто, что для лёгкого входа новичков был весь необходимый материал, это очень помогло. В течение месяца я каждый день изучал новое, а два раза в неделю общался с менеджером разработки (член команды, который ставит задачи, общается с заказчиками и вообще, занимается многими организационными вопросами + защищает нас от других команд, которые хотят скинуть свои косяки на нас), рассказывал ему, что нового узнал, отвечал на его вопросы. Честно, я ощущал себя идиотом, который нифига не понимал, но очень хотел и старался вникнуть в процесс. Какие-то непонятные названия, странные слова Agile, Scrum, МР, ПМ, Тим-лид и прочие, уже кажутся такими простыми и примитивными, но тогда, будучи совсем зелёным, я их до конца не мог сложить воедино. Первые три месяца пролетели быстро, но их я запомню на всю жизнь - это самое болезненное время, когда много, просто невероятно МНОГО информации, которую нужно усвоить и научиться использовать.
И вот, наступил декабрь. К этому моменту я успешно прошёл испытательный срок. У нас была даже некая балльная система, по которой по всем критериям у меня было 5/5, что не могло не радовать + положительный отзыв МРа. И в декабре, когда я уже неплохо освоился, состоялась ретроспектива. Ретроспектива - это некое собрание, когда команда обсуждает предыдущий квартал, какие были проблемы, находит пути их решения, подводит итоги и строит планы на следующий квартал. Цель - стать лучше. Одна из задач - разрешить предыдущие проблемы. И на этой ретроспективе я понял, что эта команда та самая, с которой можно свернуть горы и сделать наш продукт очень крутым. Я много читал историй, когда коллектив, мягко говоря - хрень, но в моём случае все более, чем круто сложилось. Ребята, зная, что я совсем зеленый, легко отвечали на все мои самые глупые вопросы, чем я старался не злоупотреблять.
Пошло-поехало
Прошло ровно пол года, как почувствовал, понял, осознал (как это не назови), что тестирование - это моё. Именно спустя пол года я понял, что то, чем я занимаюсь - это призвание. Естественно, что бывают косяки, не тестируемые задачи и прочие грустны вещи, но целая картинка позитивна!
Результат работы
Спустя 7 месяцев я научился и освоил некоторые инструменты и приобрёл скиллы, а именно:
PostgreSQL (СУБД) на уровне, который нужен тестировщику (анализ связей в БД, типов данных, запросы для тестирования и выборки данных);
Консольку Linux для просмотра логов, кода на тестовых стендах, правки "на горячую", всякие curl и прочие мелочи;
Различные техники тест-дизайна;
Буквально в последний месяц начал писать автотесты в связке Ruby+Selenium Webdriver+(всякие гемы аля Browsermob-proxy);
Написание документации (тест-планы, тест-кейсы, чек-листы и пр.);
Ну и всякие мелочи из разряда "деплоить ветку на тестовый стенд", "проверить наличие задач в ветке".
Вывод и скромный совет
Хотел бы обратиться к тебе, читатель. Если ты прочитал до этого места, то тебе в принципе интересно всё о тестировании, даже бредни джуна. Запомни одно - если чувствуешь, что это твоё - "не тормози сни. " не распыляйся и занимайся этим. Тестировщики - это ценные сотрудники, они отвечают за качество продукта, а следовательно экономят деньги заказчикам и делают конечных пользователей чуточку счастливее.
Читайте также: