Тестирование функциональности является основным видом тестирования, потому что программа в первую очередь должна работать правильно, и только после этого можно говорить о том, насколько она быстрая или удобная
Привет! Мы тестировщики платформы «Свое Родное» от Россельхозбанка. В статье расскажем о нашем проекте, как проводят релизы и регрессы, а также затронем актуальную тему работы приложений — обработку ошибок, а именно ошибку «Что-то пошло не так», которая встречается повсеместно.
Автор: Никола Линдгрен (Nicola Lindgren) Оригинал статьи Перевод: Ольга Алифанова
Плавающие баги раздражают не только тестировщиков, но и остальную команду. Возможно, вам повезло, и вы поймали такой баг до того, как он дошел до бета-тестировщиков – или же вы пытаетесь разобраться, что тут, черт возьми, произошло, потому что пользователи сообщили о баге, но вы не можете его воспроизвести.
У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.
На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:
Аддоны к браузерам вряд ли пригодятся в автоматизации тестирования web-систем, но при ручном тестировании они могут оказаться полезны. К примеру, можно заполнять элементы на выбранной странице, исходя из своих условий и входных данных. Ниже рассмотрено создание такого аддона для Firefox и Chrome без претензий на красоту кода.
Задача: разработать аддон для Firefox и расширение для Chrome со следующей функциональностью:
1. В тулбаре появляется кнопка (иконка).
2. При нажатии на эту кнопку анализируется URL активной страницы (вкладки). Если URL – один из заранее заданных URLs, то при нажатии на кнопку тулбара скрипт берет пару “пользователь-пароль” из опций в зависимости от URL и заполняет поля ввода логина и пароля на странице. Далее скрипт нажимает кнопку логина.
В предыдущей статье мы рассмотрели особенности тестирования «серого ящика» по сравнению с «белым» и «черным». Давайте сегодня подробнее остановимся на «черном ящике» и выясним, где и когда его используют, а также какие у него достоинства и недостатки.
Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.
Что такое «черный ящик» согласно терминологии ISTQB?
Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство.
Сдвиг влево, происходящий благодаря таким процессам, как непрерывная интеграция и непрерывные релизы, приводит к растущей необходимости быстрой обратной связи от тестировщиков.
Проблема интерфейсных тестов в том, что они довольно медленные, и поэтому они – не лучший вариант, когда нужно быстро дать разработчикам знать, сломал ли их код новый билд. API-тесты куда быстрее и более надежны.
Прежде чем рассматривать инструменты тестирования API, давайте убедимся, что мы одинаково понимаем, что это вообще такое.
Использование техник тестирования, основанных на спецификации, для покрытия путей через программу или функцию – это очень заманчивая для функционального тестирования идея. Не менее заманчиво предположить, что раз эти пути или комбинации покрыты – функциональное тестирование более или менее завершено. Моя цель – показать при помощи описанных ниже эвристик, что функциональное тестирование может – и, возможно, должно – смотреть на вещи шире, учитывая не только то, что явно прописано в требованиях или дизайн-макете. Я уверен, что при помощи этих эвристик и точек зрения можно выявить приличное количество функциональных аспектов системы.
Список основан на моем личном опыте тестирования программных продуктов. Я также благодарен Джеймсу Баху за эвристику SFDPOT, и Элизабет Хендриксон, Джеймсу Линдси и Дейлу Эмери, как создателям чит-листа эвристик тестирования.
После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Представляем доклад Глеба Рыбалко.
Популярность техник тестирования основанных на опыте набирает популярность с каждым годом. Скорее всего, Вы уже не найдете ни одного профессионала по тестированию и обеспечению качества, которому были бы не знакомы термины exploratory & ad hoc. Об этих видах тестирования пишутся книжки. Популярность этого направления уже дошла до того, что такое тестирование было включено в некоторые американские стандарты и предписания. Естественным образом такая ситуация отражается и на клиентах. Все чаще и чаще клиент сам приходит к Вам с инициативой внедрения исследовательского или ad hoc тестирования. И первое, что в таком случае хочется ответить это: «Да, да, конечно. Это нам поможет. Это же последние веяния. Давайте попробуем… «Но всегда ли исследовательское тестирование помогает?
Я дам несколько практических советов, которые помогут использовать данный вид тестирования на практике. Мы поговорим о следующих вещах:
Как определить цели данного вида тестирования на проекте
Как идентифицировать нужных людей, для команды «исследователей»
Какие тестовые артефакты действительно помогают в исследовательском тестировании
