Для нахождения ошибки существуют способы тест

говориМ о тестировании
простым языком

Тестирование и поиск ошибок: в чем разница

Вячеслав Зимин 16 октября, 2019 Нет комментариев

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

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

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

Поиск багов

Итак, моя задача — найти баги. Что я буду делать? Искать как можно больше багов. Это логично. А чем больше я их найду, тем лучше. Ну и тем моя ценность, как сотрудника, выше.

Так, а где найти как можно больше багов? Конечно в самых нестабильных областях программы. И не важно значимы они или нет. Чем нестабильней, тем привлекательней.

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

А что делать с багами, которые сложно воспроизвести? Давайте подумаем: лучше найти 1 серьезный, но сложно воспроизводимый, баг или 10 обычных. Конечно 10 обычных. Ведь задача просто найти баги. И чем больше, тем лучше.

Что мы имеем в итоге?

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

Тестирование

Теперь к тестированию. Какими наши действия будут тут?

Задача тестирования — не найти ошибки, а проверить корректность работы программы. То есть на выходе мы должны иметь не 100 найденных багов, а работающий продукт.

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

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

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

Что мы имеем в итоге?

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

Разница

Давайте на примере из жизни. Есть стиральная машина. При поиске ошибок мы будем пробовать нажать на кнопку выключения 50 раз подряд. Потом во время стирки покрутим переключатель программ во все стороны 20 минут без перерыва.
Но мы не проверим, запускается ли она при одинарном нажатии на кнопку пуск или нет. Ведь в этом месте вряд ли найдется ошибка. А если в этом месте она будет, то мне, как пользователю, такая стиральная машинка будет не нужна и я от нее откажусь.

А теперь ближе к тестированию. Возьмем сайт по заказу пиццы. Где искать ошибки? Конечно будем добавлять в корзину невообразимое количество пицц. Еще попробуем уменьшать и увеличивать количество персон 50 раз подряд. Потом в поле отправки заказа будем вводить такое, что просто не вообразить.
А банальную проверку отправки заказа обойдем стороной. И если там был баг, то никто не сможет оформить заказ.

Чувствуете разницу? Она просто колоссальная.

В случае с поиском ошибок мы по факту совсем не заботимся о качестве продукта.

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

Как верно отметил Дмитрий Безносов, продукт может быть без единого дефекта (условно), но совершенно непригоден к использованию юзерами как в плане UI/IX, так и в плане функциональности.

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

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

Источник

В поисках самого лучшего способа тестирования системы

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

В основе статьи – выступление Яна на июньской конференции Heisenbug 2017 в Питере. Ян занимается тестированием более двадцати лет. В настоящее время он работает тест-менеджером для приемочных тестов в голландской компании по стандартизации Squerist. Этот доклад о самых разных подходах к тестированию: от детальной проработки сценариев и до исследовательских туров, от сессионного тестирования и до поиска ошибок совместно с пользователями. Его цель – помочь вам повысить профессионализм, обратив внимание на те методы, которые вы до сих пор не использовали.

Почему существуют разные подходы к тестированию?

Я хотел бы начать с Линды Фишер. Вы ее не знаете, но более 19 лет назад я у нее проходил курсы по тестированию. Она говорила о том, что тестирование нужно делать вот так: сначала это, потом то (интерфейсы, проектирование и т.д.).

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

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

Двадцать лет назад разработка почти всех систем происходила примерно одинаково. Между системами не было таких серьезных различий, как в наши дни. Вот основные изменения, которые произошли с тех пор:

• Гибкость в разработке преобладает над четким планированием.
• Мы больше ориентируемся на мастерство, чем на методы.
• Цели важнее, чем процесс. Если раньше мы следовали двухсотстраничному руководству, в котором был пошагово описан весь процесс тестирования, сегодня в этом нет необходимости. Важно смотреть, какого результата мы хотим достичь, и делать все для этого.
• Быстрое тестирование преобладает над основательным. Большинство организаций хотят выйти на рынок как можно быстрее.
• Прагматичные методы преобладают над стандартами. Следование стандартам может увеличить время тестирования, количество необходимой документации и требуемого персонала более чем в три раза. Поэтому даже в организациях, которые занимаются стандартизацией, часто отказываются от тестирования по стандартам.

Основные подходы к тестированию

Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).

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

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

Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Я думаю, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.

Промежуточные подходы к тестированию

Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.

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

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

Подробное сценарное и общее сценарное тестирование (Detailed Scripting & Global scripting)

В чем отличия между подробным сценарным и общим сценарным тестированием? Объясню на примере.

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

• Перейдите на стартовую страницу
• Нажмите на кнопку «Новый»
• В поле «Кому» напишите j.cannegieter@squerist.nl
• Нажмите на кнопку «Файл»
• Выберите документ «Тест1»
• В поле «Тема» напишите «Тестовое вложение »
• Откройте почтовый ящик jcannegieter
• Проверьте, доставлено ли сообщение и вложение.

Для этого же примера сценарий общего тестирования может выглядеть так:

• Создайте и отправьте письмо с вложением одному получателю
• Проверьте, доставлено ли сообщение и вложение

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

Сессионное тестирование и поиск багов (Session Based Testing & Bug Hunts)

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

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

Сессионное тестирование предусматривает наличие:

1. Сессий тестирования.
2. Миссии и точки тестирования / идей для тестирования.
3. Заметок во время сессии.
4. Отчета после сессии (что мы обнаружили, каково качество системы и пр.).

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

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

Исследовательское тестирование и туры (Exploratory Testing & Test Tours)

В интернете можно прочитать, что исследовательское тестирование – это такой прием тестирования. На самом деле это не просто прием, а полноценный подход к тестированию, позволяющий выполнить полное тестирование систем.

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

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

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

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

В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:

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

Основные различия методов тестирования и сравнение их эффективности

Сценарное тестирование	Исследовательское тестирование
Сфокусировано на подготовке	Сфокусировано на действии
Сфокусировано на планировании	Гибкое
Опирается на методы	Прагматичное
Подчиняется процессу	Ставит в центр внимания тестировщика
Сфокусировано на документации	Сфокусировано на выполнении тестов

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

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

Как решить, какой метод тестирования подходит лучше

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

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

Категория	Ситуация	Сценарное	Исследовательское
Система	Много вычислений	+
	Ориентирована на интерфейс		+
	Ориентирована на бэкенд	+
	Мобильное приложение		+
Цели тестирования	Проверка на соответствие требованиям	+
	Проверка ценности системы		+
	Юзабилити		+
	Тестирование бизнес-правил	+
	Производительность	+
	Проверка автоматизации	+
	Безопасность	+	+
Организация	Ориентирована на планирование и подготовку	+
	Энергичный современный стартап		+
	Иерархическая, традиционная	+
	Приветствует самоуправление	+	+
Документация	Много подробной документации	+	+
	Немного документации		+
	Требования / документация постоянно меняются		+
Разработка	Каскадная модель	+	+
	Agile		+
Бюджет	Большой	+	+
	Небольшой
Время	Включение в работу на ранних сроках	+	+
	Включение в работу на поздних сроках		+
	Много времени	+	+
	Мало времени		+
Навыки тестировщиков	Аналитические, скрупулезные	+
	Критическое мышление (сомневаются во всем)		+
	Гибкость		+
	Профессиональные тестировщики	+	+
	Непрофессиональные тестировщики	+	+

Вместо заключения

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

Если ваша профессиональная деятельность связана с тестированием, наверняка вас заинтересуют вот эти доклады на нашей двухдневной декабрьской конференции Heisenbug 2017 Moscow:

Источник