Способы его проведения тестирования

Уже готов стать тестировщиком или хочешь освежить базовые понятия? Тогда этот гайд – то, что нужно! Команда ПОИНТ и курса Jedi.Point структурированно делится теоретическими основами тестирования: от видов до полезных инструментов.

Что такое Тестирование ПО?

Тестирование ПО – процесс, который помогает проверить выполнение всех бизнес-сценариев и требований пользователей, а также выявить все возможные проблемы и дефекты IT-продуктов.

В чем разница между тестированием, QC и QA?

Зачастую понятия «тестирование», «QA» и «QC» или путают, или используют для обозначения одного и того же. На самом деле эти термины характеризуют немного разные процессы:

тестирование отвечает непосредственно за нахождение багов;
QC (контроль качества) – за выполнение процесса тестирования (написание/прохождение кейсов, поиск/заведение дефектов etc);
QA (обеспечения качества) – за создание системы контроля, которая будет предотвращать появление багов уже на этапе разработки ПО, сокращая количество выявленных дефектов на этапе тестирования; грубо говоря – построение самого процесса тестирования.

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

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

Еще 5-6 лет назад такой вопрос обсуждался в ИТ-кругах и на просторах Интернета. Но в 2020 ясно: тестировщики без работы не останутся, а тестирование должны осуществлять специалисты в сфере QA.

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

Чтобы понять, как еще тестировщики помогают своим заказчикам, читайте также:

Виды тестирования ПО

Составить эталонную классификацию почти невозможно – выделяют аж 100 видов тестирования, которые можно сгруппировать по различным характеристикам.

Более того, периодически методы устаревают, и возникают новые термины.

С какими же основными классификациями и типами тестирования стоит ознакомиться начинающим тестировщикам?

Виды тестирования ПО по степени автоматизации

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

Любое тестирование можно выполнить как вручную, так и с помощью инструментов автоматизации.

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

Автоматизированное тестирование, в свою очередь, выполняется с помощью таких фреймворков, как Selenium, PHPUnit, Mockery и других. Его целью является снижение затрат и рисков, связанных с человеческим фактором. Особенно эффективен данный тип на долгосрочных проектах с частыми релизами и объемным регрессом.

Каждое из этих направлений имеет свою область применения, потому что 100-% автоматизация невозможна. Например, проверка юзабилити всегда осуществляется вручную.

Разница между ручным и автоматизированным тестированием

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

Также рекомендуем:

Виды по объекту тестирования

Функциональное тестирование (functional testing) проверяет часть системы, которая необходима для того, чтобы пользователь мог выполнить бизнес-сценарий от начала до конца. Оно выполняется первым, до нефункционального тестирования. Примеры: переход по разделам форума, поиск по сайту.

Методы и техники функционального тестирования:

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

Типы нефункционального тестирования:

Тестирование безопасности (security testing)

Тестирование безопасности – это вид тестирования для выявления уязвимости программного обеспечения к различным атакам (SQL, XSS etc).

Рекомендуем ознакомиться:

Тестирование локализации (localization testing)

Тестирование локализации – процесс адаптации продукта, который ранее был переведен на несколько языков для определенной страны или региона.

Юзабилити тестирование (usability testing)

Тестирование юзабилити – это метод тестирования, направленный на выявление удобства и понятности интерфейса.

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

Виды тестирования по позитивности сценария

Негативное тестирование – проверка того, что при вводе недопустимых значений/совершении недопустимых действий программа ведет себя корректно – не совершает того, чего не должна и выдает человекочитаемое сообщение об ошибке.

Позитивные тестирование – проверка того, что программа работает правильно на «правильных» данных – не выдает ошибок, делает то, что должна.

Этапы тестирования

Для описания процесса тестирования поэтапно существует несколько методик. Одна из самых понятных и простых моделей – STLC.

STLC (Software Testing Life Cycle) означает жизненный цикл тестирования программного обеспечения.

Модель жизненного цикла тестирования программного обеспечения (модель STLC) состоит из шести основных фаз.

6 фаз STLC (Software Testing Life Cycle):

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

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

По этой теме рекомендуем почитать:

Научиться тестировать в условиях отсутствия идеальных требований на проекте можно на курсе:
Тестирование без требований: выявление и восстановление информации о продукте

Планирование тестирования. На данном этапе разрабатывается стратегия тестирования, выявляются риски, выбираются инструменты и распределяются роли в команде. Все это фиксируется в таких документах, как тест-план и тест-стратегия.

Разработка тест-кейсов.

О том, почему мы пишем тест-кейсы, можно узнать в нашем видео:

Станислав Марков, тренер ПОИНТ и курса Погружение в тестирование. Jedi Point детально рассказывает о каждой фазе

А о том, как писать тест-кейсы, вы можете узнать на нашем Youtube-канале

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

Выполнение тестов. Команда QC начинает выполнение тест-кейсов в соответствии с планами тестирования и создает отчеты о багах. Также чаще всего на этом этапе происходит валидация багов. Она нужна для того, чтобы убедится, что дефекты, которые ты завёл ранее, ДЕЙСТВИТЕЛЬНО пофиксили.

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

Инструменты тестировщика

Инструменты тестирования – все продукты, которые помогают QA-инженерам организовывать свою работу на каждом этапе.

Выбор инструментов для работы тестировщика зависит от вида тестирования, личных предпочтений и места работы тестировщика. Со временем у каждого тестировщика появляется свой набор инструментов.

Инструменты для управления тестированием

Инструменты для автоматизации тестирования

Инструменты для кросс-браузерного тестирования

Инструменты для нагрузочного тестирования

Инструменты для баг трекинга

Инструменты для автоматизации тестирования мобильных приложений

Для iPhone и iPad:

Мобильные эмуляторы

Инструменты для тестирования юзабилити

Инструменты для API- тестирования

Инструменты тестирования безопасности

CSS Валидаторы

Также рекомендуем:

Надеемся, наш гайд помог вам в понимании основ тестирования. Успехов в карьере тестировщика!

А тем, кто хочет узнать о каждом аспекте тестирования на практике, рекомендуем пройти курсы тестирования ПО.

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

Источник

Способы тестирования программного обеспечения

Всем привет! Уже на следующей неделе мы запускаем новый поток по курсу «Автоматизация веб-тестирования». Этому и будет посвящен сегодняшний материал.

В этой статье рассматриваются различные способы тестирования программного обеспечения, такие как модульное тестирование (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 — Михаил Самойлов.

Источник