Как выглядит тестирование программы

Тестирование — важная и неотъемлемая часть разработки, позволяющая выявить ошибки и оценить удобство использования веб-страниц.

Зачем составлять тест-кейсы, как выявить несоответствие свёрстанной страницы дизайн-макету, как протестировать юзабилити и корректность работы элементов — об этом и не только рассказывает QA-инженер компании HTDev Нурия Хусаинова. Статья будет полезна тем, кто только начинает профессиональный путь в тестировании.

Нурия Хусаинова

Почему стоит использовать ручное тестирование веб-страницы

QA-инженер может тестировать свёрстанные страницы вручную или с помощью программных средств.

Автоматизированный способ предотвращает риск возникновения ошибок, которые может допустить специалист при ручном тестировании, а также обеспечивает высокую скорость проверки. Однако написание кода для такой программы требует квалификации и опыта QA-инженера: чтобы автотест не пропускал ошибки, нужно прописать полный сценарий работы. Когда сценарий не выполняется, программа выводит сообщение об ошибке. Получается, что автоматизированное тестирование трудозатратно, поскольку написание автотестов может занять даже больше времени, чем полная проверка веб-страницы вручную.

Что делает тестировщик, мой рабочий день | тестирование ПО | Тестировщик | QA Engineer

Ручное тестирование — наиболее целесообразный метод проверки лендингов, который при этом не исключает использование специальных инструментов для более тщательной оценки.

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

Как вручную протестировать веб-страницу — разбираем на примере

Подготовительный этап: составляем тест-кейс

Тест-кейс ― это проверка работоспособности лендинга на предмет соответствию техническому заданию. Такие тесты позволяют увидеть результат действий пользователя и избежать возможных ошибок. Так, тест-кейс помогает узнать, что произойдёт, если пользователь введёт в форму обратной связи некорректный номер телефона или адрес электронной почты, и что произойдёт, если данные будут введены верно.

С опытом QA-инженер опирается только на техническое задание, а начинающие специалисты могут составить для себя перечень задач для проверки в таблице.

Основной этап: проводим тестирование

Этот этап состоит из четырёх ключевых проверок, последовательность выполнения которых не влияет на эффективность тестирования.

Тестирование НА ПРИМЕРЕ | Тестирую DEVBY

Сравниваем готовый лендинг и дизайн-макет

QA-инженер может сразу приступить к проверке лендинга с помощью вспомогательных инструментов или сначала выполнить визуальную сверку макета и лендинга.

Делать визуальную сверку необязательно, но опытные QA-инженеры проводят её неосознанно: когда смотрят на макет и сразу замечают несоответствия.

Что нужно тщательно проверить, когда сравнивают итоговый продукт и дизайн-макет:

• стили текста: размер, цвет, шрифт, отступы;
• расстояние между блоками;
• расположение блоков, иконок и картинок;
• меню или бургер;
• текст на предмет ошибок.

Изображения ― картинки, фотографии, иконки и логотипы — не должны быть замыленными. Как правило, то, насколько чётко выглядят графические элементы лендинга, видно невооружённым взглядом.

Для проверки цвета, стиля и кегля шрифтов обязательно нужно посмотреть код на веб-странице и сравнить его с тем, что использован в макете, — как в этом примере:

Чтобы ускорить этот процесс, дизайн-макет накладывается на веб-страницу ― например, с помощью бесплатного расширения Pixel Perfect для Google Chrome. Далее следует убедиться, что все элементы совпадают при наложении. Обычно расхождение в 1–2 пикселя багом не является.

Оцениваем корректность работы элементов лендинга

При тестировании интерфейса QA-инженер изучает, как работают графические элементы, использованные в лендинге. С каждым из них нужно совершить взаимодействие в соответствии с тест-кейсами, чтобы убедиться, что все изменённые состояния элементов отображаются корректно. При клике интерактивные элементы, например, ссылки, должны вести на соответствующие элементы.

Проверяем адаптивность и кросс-браузерность

При изменении ширины экрана элементы могут отображаться неверно — например, часть текста или изображения не будут видны пользователю. Чтобы этого избежать, QA-инженер просматривает веб-страницу на различных типах устройств, операционных системах и браузерах.

Для проверки адаптивности и функциональности лендинга можно использовать BrowserStack ― облачную платформу для тестирования сайтов и мобильных приложений. На момент выхода статьи инструмент доступен для россиян. Есть гибкие тарифные планы: например, использование сервиса без ограничений опций для одного пользователя стоит $39 в месяц.

Тестируем юзабилити

Проверка юзабилити показывает, насколько удобно использовать интерфейс, и как легко посетитель лендинга сможет достичь конечной цели. Этот процесс также поможет выявить орфографические и технические ошибки.

Обзорный этап: формируем перечень багов

QA-инженер передаёт разработчику список несоответствий и ошибок со скриншотами или видеозаписью экрана, включая пошаговое описание, как появляется тот или иной баг. Если проблему описать неточно, разработчик может не понять суть ошибки и соответственно не исправит её.

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

Заключительный этап: выполняем повторную проверку

После того, как разработчики исправят баги, QA-инженер снова проводит тестирование лендинга. Для этого специалист выбирает наиболее подходящий способ повторной проверки:

• Smoke-тестирование ― «дымовой», или поверхностный тест. QA-инженер проверяет, исправлены ли баги, о которых он сообщил, и дополнительно тестирует работу основной функциональности лендинга.
• Регрессионное тестирование ― более глубокая проверка для подтверждения отсутствия багов. Такой способ помогает убедиться, что все выявленные ошибки исправлены, а новые не появились.

В нашем примере при повторной проверке использовали smoke-тестирование. После того, как QA-инженер убедился, что выявленные баги устранены, он проверил работоспособность основной функциональности: кнопки «обратный звонок», формы обратной связи, кликабельность ссылок и их соответствие содержанию, отображение информации при наведении на элементы в разделе «Направления».

Профессия

Инженер по тестированию

Узнать больше

• Освоите IT-профессию, для которой не требуется опыт и техническое образование
• Изучите ручное и автоматизированное тестирование, а также языки программирования Java, JavaScript и Python
• Начнёте работать через 2 месяца обучения

Советы начинающим QA-инженерам

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

Используйте тест-кейсы. Проводить тестирование можно и без тест-кейса, но начинающим QA-инженерам он облегчит выполнение задач:

• Этапы тестирования будут структурированы ― появится наглядная картинка, что нужно протестировать.
• Отслеживание обязательных для проверки действий будет менее трудозатратным ― станет легче отслеживать, какие этапы остались без тестового покрытия, а какие прошли проверку без выявления багов и с их обнаружением.
• Новый сотрудник быстрее подключается к проекту — тест-кейсы составляют, исходя в основном из технического задания, и наглядно демонстрируют поведение функциональности лендинга.
• Регрессионное или smoke-тестирование будет проходить легче из-за наличия наглядного примера.

Запаситесь терпением и трудолюбием. Если решили тестировать без написания тест-кейсов, держите в голове план и пошагово следуйте ему. Когда вы приступаете к тестированию одного блока, не закончив его проверку, не спешите тестировать другой блок ― так возникает риск упустить что-то важное.

Не пренебрегайте повторной проверкой. Любое изменение кода может повлиять на другие части функциональности. Финальная проверка позволит убедиться, что ошибки исправлены, а новые не появились.

Читать также

Кто такой QA-инженер, чем он занимается и сколько зарабатывает

Где начинающему IT-специалисту искать стажировки: 10 лучших ресурсов

Языки программирования: для чего нужны, какие популярны, как выбрать и с чего начать изучение

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Нурия Хусаинова

Источник: netology.ru

Регрессионное Тестирование (Regression Testing)

Ты хочешь понять, что такое регрессионное тестирование, зачем оно нужно, почему про него говорят все тестировщики и при чем здесь автоматизация?

Тогда ты в правильном месте

В этой статье отвечаю на самые частые вопросы, связанные с этим типом тестирования.

Как обычно, начинаем с определений.

Что такое регрессионное тестирование?

Регрессионное тестирование (regression testing) это проверки ранее протестированной программы, выполняющиеся после изменения кода программы и/или ее окружения для получения уверенности в том, что новая версия программы не содержит дефектов в областях, не подвергавшихся изменениям.

Или в оригинале:

Regression testing — testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed. [ISTQB Glossary]

Regression Testing является одним из двух видов тестирования, связанных с изменениями. [ISTQB FL]

Зачем нужно регрессионное тестирование?

Регрессионное тестирование необходимо для получения уверенности, что изменения ПО не коснулись и не сломали другие, не измененные, части ПО.

Здесь возникает вопрос: “Каким образом изменения одной части ПО могут сломать другие?”

Ответ: это загадка природы

На самом деле нет)

В мире не бывает идеальных вещей и все мы ошибаемся. ПО и программисты — не исключение.

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

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

Фредерик Брукс в своей книге «Мифический человеко-месяц» (1975) писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50%) влечёт появление новой». [Куликов С., Базовый курс, 3-е издание]

Можно предположить, что в наше время вероятность появления ошибки — значительно меньше 20-50%, так как программы и среда разработки 1975 года сильно отличаются от современных.

Но, тем не менее, даже сегодня вероятность ошибки точно больше 0%.

Поэтому, регрессионное тестирование является ключевым инструментом обеспечения качества и должно использоваться практически на любом проекте.

Когда проводят регрессионное тестирование?

Регрессионное тестирование проводится после изменения кода программы (добавили / удалили / изменили) или изменения рабочего окружения (обновили версию PHP / Node JS / Java / Ubuntu / Windows / MySQL / MongoDB / переехали на новые сервера и т.п.)

Стоит отметить, что регрессионные тесты не нужно проводить после каждого изменения!

Например, вы изменили дату в футере сайта.

Нужно ли нам проходить 350 тест-кейсов и перепроверять весь сайт? — конечно же нет! Вы потратите свое время зря)

Такие исправления можно протестировать за 10 секунд используя самый простой чек-лист или сделав code review.

Если же такие исправления “ложат” / “ломают” сайт — вам срочно нужно задуматься о профессионализме разработчиков, это не нормально!

Или, другой пример. На одном из полей формы изменяется правило валидации: до этого максимальная длина строки равнялась 20 символам, а теперь нужно сделать 16.

Зачем после такой правки перепроверять весь сайт? (Вы не поверите, но существуют компании и команды, который до сих пор этим занимаются…)

Единственное, что нужно проверить — валидацию конкретно этого поля и, возможно, валидацию такого же поля на других формах (если они вообще существуют)

Если после изменения длины одного поля изменились правила валидации всех полей на сайте — поздравляю, у вас большие проблемы с профессионализмом разработчиков.

Вместо того, чтоб постоянно выполнять бесполезные проверки, лучше нанять более профессионального кодера. Через 2 месяца вы начнете экономить кучу денег.

При принятии решения о необходимости повторного тестирования вспоминаем принципы тестирования и задаем себе вопрос: ЧТО нам нужно проверять после этих изменений?

Какие плюсы регрессионного тестирования?

К плюсам можно отнести:

• повышение качества продукта (находим и исправляем новые дефекты)
• регрессионные дефекты показывают реальное качество кода / архитектуры системы и процесса разработки (чем больше дефектов — тем хуже код / процесс)

Выполнение повторного тестирования необходимо для анализа и улучшения качества продукта и рабочих процессов, чем, кстати, и занимаются настоящие QA Engineers.

Какие минусы регрессионного тестирования?

К минусам можно отнести:

• временные / денежные затраты (дефектов находим мало, времени тратим много, дефекты — “золотые”)
• рутина (очень немногие получают удовольствие от прохождения одних и тех же тестов по 100500 раз)
• “замыливание глаз” и парадокс пестицида

Пытаясь бороться с описанными выше минусами многие компании автоматизируют регрессионные проверки

Но, решает ли автоматизация эти проблемы? Или только усугубляет? Давайте разбираться…

Автоматизация и regression testing

Регрессионные тесты выполняются много раз и обычно проходят медленно, поэтому такие тесты — это серьезный кандидат на автоматизацию. [ISTQB FL]

На первый взгляд — выглядит логично. Но давайте посмотрим немного “глубже”.

Предположим, у нас есть небольшой проект и 50 тест-кейсов. Мы, после очередного видео / доклада — “Автоматизируй все!” — решаем их автоматизировать

Через 2 недели все готово: тесты проходят, все зеленое — класс, у нас авто-тесты, Agile и CI! (в видео сказали, что будет так)

Проходит 2 года. Количество тест-кейсов увеличилось в 20 раз, до 1,000. Иии…

Сравнение теоретического “до” и “после”:

• 50 тестов
• 1,500$ на написание тестов (1 тест-кейс = 30$)
• среднее время прогона 50 * 6 сек = 5 минут
• затраты на 1 тестовый сервер = 200$ / мес

• 1000 тестов
• 18,000$ на написание тестов (1 тест-кейс = 20$, стало проще, так как “основа” уже есть, но не 10$ — потому что старые тесты нужно постоянно поддерживать)
• среднее время прогона 1000 * 6 сек = 100 минут (. )
• затраты на 1 тестовый сервер = 200$ / мес

Решили ли мы проблемы, описанные выше? — нет.

Возможно, рутины стало чуть меньше. Но остальное — никуда не пропало + появилось новое:

1. Очень высокие затраты на тестирование (автоматизаторы, сервера, поддержка, новые инструменты и т.п.)
2. Очень большое время “прогона”
3. Парадокс пестицида никуда не делся…

Теоретически, мы можем уменьшить время прогона, купив более мощные сервера, или подняв кластер (привет новый DevOps), но это сделает затраты еще большими…

И здесь появиться финансовый вопрос — а не дешевле ли нам иметь 5 джунов, которые будут проходить регрессионные тест-кейсы изо дня в день, за те же 100 минут? (Знакомо, да? Мы вернулись туда, откуда начали)

Парадокс автоматизации? Наверное, можно так сказать

Пытаясь уменьшить затраты — мы сделали их еще больше!

Давайте вспомним, что регрессионные тесты — это серьезный кандидат на автоматизацию.

Но! Серьезный кандидат != 100% автоматизация!

Поэтому, учитывая все, написанное выше, мы можем предложить решение проблем и сделать следующие выводы:

• Автоматизировать тесты нужно, но с умом
• Каждый тест-кейс, который автоматизируется, должен быть оценен с финансовой точки зрения (= экономить ресурсы)
• Отбор теста в регрессию — должен быть обдуманным процессом (ведь каждый новый тест-кейс увеличит время прогона)
• Запуск автоматизированных проверок — должен быть “умным”. Мы не должны перепроверять весь сайт и ждать 10-15-50 минут после нескольких правок в тексте!

Все эти проблемы решаются только настоящими специалистами, включая QA лидов, автоматизаторов и DevOps инженеров.

Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.

И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!

Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)

Резюме

В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.

Этапы тестирования мобильных приложений на базе Android

Существует 3 вида Mobile Apps. Мобильное приложение – это сайт, который запускается основным браузером системы. Нативное – это программное обеспечение, разработанное только для конкретной ОС. Гибридное – это комбинация мобильного и нативного приложения (например, сайт в двух версиях – для ПК и смартфонов). Ниже мы рассмотрим поэтапный план тестирования программ для ОС Android.

Шаг №1: проверка документации

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

Шаг №2: проверка функций приложения

Мануальщик выполняет все предусмотренные функции и анализирует исправность их работы. Чем больше параметров в приложении – тем больше уходит времени на их проверку и отладку. Какие аспекты подлежат обязательному тестированию:

• запуск и выключение ПО;
• исправность интерфейса (не должны «вылетать» ошибки);
• доступ к административному разделу.

Таким образом, тестировщик проверяет, сможет ли пользователь выполнить операции, предусмотренные в приложении. Тестируется каждая иконка по отдельности.

Шаг №3: проверка юзабилити

Юзабилити – это термин, определяющий степень практичности. То есть, специалист по UX/UI перед выпуском ПО должен проверить, насколько приложение сподручно, удобно ли пользоваться панелью и пр. Иными словами, определяется КПД. На что нужно обратить внимание:

• расположение и размер кнопок/иконок;
• многозадачность приложения;
• модульная навигация;
• цветовая гармония;
• читабельный шрифт;
• скорость возобновления после сбоя;
• синхронизация компонентов;
• возможность отмены действия.

На данном этапе также уделяется внимание дизайну. Он должен быть неброским и визуально приятным.

Шаг №4: проверка пользовательского интерфейса

Тестирование ПИ необходимо для того, чтобы обеспечить соответствие графической картинки и специфики ПО. Тестировщик проверяет, как функционирует программа на экранах с разным расширением. Также уделяется внимание общему макету приложения: реклама не должна перекрывать кнопки, иконки не должны быть «плавающими» и пр.

Шаг №5: проверка совместимости

На данном этапе необходимо протестить программу на разных устройствах. Обращается внимание на конфигурацию ОС, а также браузерную, сетевую. Таким образом, приложение будет работать на девайсах с Гугл Хром, Опера, Файрфокс и пр. Учитывается тип устройства и согласуются с ПО его параметры.

Шаг №6: проверка производительности

Здесь всё просто. Тестировщик анализирует стабильность работы приложения (отсутствие ошибок и багов), скорость реакции на задачи, и проверяет, какую нагрузку способно выдержать ПО. Также на данном этапе определяется, сколько пользователей одновременно могут работать с приложением.

Шаг №7: проверка безопасности

Речь идет об анализе безопасности системы – т.е. определении рисков, связанных с эксплуатацией программного обеспечения. Задача на данном этапе – защитить программу от взлома и «слива» информации.

Шаг №8: проверка локализации

Любое приложение должно работать в режиме реального времени. Это значит, что перед запуском необходимо проверить соответствие дат, времени. Если в ПО предусмотрен автоперевод – он должен работать исправно.

Шаг №9: бета-проверка

На данном этапе программу можно заливать в сеть и приглашать желающих ею воспользоваться. Цель бета-тестирования – узнать реальные отзывы людей, проанализировать их жалобы и пожелания. Пользователи ставят оценку (условную) и выносят «вердикт» — полезное приложение или нет.

Заключительный шаг: сертификация

Сертификационное тестирование подтверждает, что ПО соответствует требованиям интернет-магазинов. В зависимости от того, где программа будет опубликована, разработчик должен подать заявление на проверку своей работы. Как правило, внимание уделяется Google Play. Если приложение прошло проверку в этом сторе – оно будет принято везде.

Источник: app-android.ru