что сложнее всего тестировать на практике и почему

Фундаментальная проблема тестирования

Введение

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

А вот вторая часть оказалась вопросом: “Существуют ли какие-то проблемы, общие для всех тестировщиков, мешающие работать с большей эффективностью?”.

Первое, что пришло в голову: перечислить все более-менее заметные проблемы, с которыми сталкивался при тестировании, отсеять мелочевку, остальное обобщить. Но быстро понял, что индуктивный метод ответит на вопрос, относящийся не ко “всем”, а, в лучшем случае, лишь к “большинству” тестировщиков. Поэтому решил подойти с другой стороны, дедуктивной, и вот что получилось.

Определения

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

Обратимся к википедии и здравому смыслу:
Пробле́ма (др.-греч. πρόβλημα) в широком смысле — сложный теоретический или практический вопрос, требующий изучения, разрешения; в науке — противоречивая ситуация, выступающая в виде противоположных позиций в объяснении каких-либо явлений, объектов, процессов и требующая адекватной теории для её разрешения; в жизни проблема формулируется в понятном для людей виде «знаю что, не знаю как», то есть известно, что нужно получить, но неизвестно, как это сделать. Происходит от поздн. лат. problēma, из греч. πρόβλημα «брошенное вперёд, поставленное впереди»; от προβάλλω «кидать вперёд, выставлять перед собой; обвинять».

Смысла не много, по сути, “проблема” = “что-угодно, с чем надо разобраться”.
Тестиро́вщик — специалист (на виды разделять не будем, так как нас интересуют все тестировщики), принимающий участие в тестировании компонента или системы, результатом деятельности которого является:
Работа тестировщика — комплекс мероприятий относящийся к тестированию.
Эффекти́вность (лат. effectivus) — соотношение между достигнутым результатом и использованными ресурсами (ISO 9000:2015).
Результа́т — последствие цепочки (череды) действий (итог) или событий, выраженных качественно или количественно. Возможные результаты включают преимущество, неудобство, выгоду, потерю, ценность и победу.
Как и с “проблемой” смысла мало: что-то, что получилось в итоге работы.
Ресурс — количественно измеряемая возможность выполнения какой-либо деятельности человека или людей; условия, позволяющие с помощью определённых преобразований получить желаемый результат. Тестировщик — человек, а в соответствии с теорией витальных ресурсов, каждый человек является обладателем четырех экономических активов:
денежных средств (доход) — ресурс возобновляемый;
энергии (жизненная сила) — ресурс частично возобновляемый;
времени — ресурс фиксированный и принципиально невозобновляемый;
знаний (информации) — ресурс возобновляемый, это часть человеческого капитала, которая может и нарастать, и разрушаться[1].

Хочу отметить, что определение эффективности в нашем случае не совсем корректное, так как чем больше знаний мы используем, тем ниже получается эффективность. Поэтому я бы переопределил эффективность как “соотношение между достигнутым результатом и затраченными ресурсами”. Тогда все корректно: знания при работе не тратятся, но уменьшают затраты единственного принципиально невозобновляемого ресурса тестировщика — его времени.

Решение

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

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

Как с этим быть?

Выводы вполне очевидны и многими давно используются:

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Меньше «сложного» тестирования, больше — «умного» тестирования

В связи с набором учащихся на курс «QA Engineer» подготовили перевод материала.

Приглашаем также всех желающих на демо-занятие «Методологии разработки». На этом вебинаре рассмотрим методологии разработки scrum, kanban, waterfallи изучим роль тестирования в процессе разработки.

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

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

Работать, как одна команда

Независимость тестирования не означает независимость тестировщиков.

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

Тренинги по тестированию, сообщество тестировщиков

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

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

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

«Менеджеры как учителя принципов бережливого мышления, проводящие время, обучая и тренируя других».

“Умное” тестирование

Мы делаем «умное» тестирование? Для некоторых команд тестировщиков это может быть трудным вопросом; если вы спросите о других областях, на это может найтись ответ.

«Как бы иронично это ни казалось, задача тестировщика — проверить как можно меньше. Тестировать меньше, но тестировать «умнее»».

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

Проверка — это хорошо. Внедрение механизмов мониторинга может принести реальную пользу нашим клиентам; рассмотрим оба подхода как сдвиг влево — раннее тестирование и как сдвиг вправо — мониторинг систем и предотвращение возможных сбоев. Критическим аспектом «умного» тестирования является добавленная ценность; наши тесты должны это обеспечить; в противном случае, мы просто делаем “сложное” тестирование.

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

“Умное” тестирование, качественные продукты.

Надежный план тестирования — Наличие плана должно иметь решающее значение для успеха.

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

Улучшение качества кода — Никакие коммиты не остаются не протестированными.

Непрерывное обучение — Исследовательское тестирование позволяет обнаружить важную информацию.

Performance / Load Testing & Security Testing — Чтобы избежать любого сбоя или любого риска для безопасности.

Метрики и Dashboards — Отслеживание ключевых показателей качества (например, дефектов производства, анализа рисков, дополнений к требованиям и т.д.). Постоянное совершенствование процесса обеспечения качества.

Мониторинг возможного риска на производстве — Тестовый мониторинг на производстве.

Заключение

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

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

Полезная литература

Извлеченные уроки в программном тестировании — (Lessons Learned in Software Testing) — Cem Kaner, James Bach, and Bret Pettichord.

Трансформация Тестирования — Непрерывное Тестирование на Предприятии для Agile и DevOps (Enterprise Continuous Testing Transforming Testing for Agile and DevOps) — Wolfgang Platz, Cynthia Dunlop.

Гибкое мышление (Lean Thinking) — Drs. Womack and Jones

Источник