Что такое тестирование в чем его суть как процесса: Что же такое тестирование? – Тестирование программного обеспечения — Википедия

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

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/so-what-is-software-testing Перевод: Ольга Алифанова Если бы вам пришлось ответить на вопрос «Что такое тестирование?», что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений. Плюс к тому многие недопонимают, что же такое тестирование, чем занимаются тестировщики – даже среди самих тестировщиков. Тестирование как навык и как профессия постоянно развивается. В этой статье мы рассматриваем, чем тестирование является, и чем нет. Из чего состоит тестирование Расследование Расследование определяется как «наблюдение или изучение путем близкого наблюдения и систематического изучения» [1]. Процесс тестирования должен быть расследованием. Мы не всегда знаем, что получим на выходе, но наша задача – выяснить информацию, которая поможет людям принимать решения. Это не просто сравнение работы системы со спецификацией, где прописан ожидаемый результат. Мы должны мыслить критически, задавать сложные вопросы, рисковать, подмечать то, что на первый взгляд кажется несущественным, а при тщательном анализе оказывается важным и требующим дальнейшего изучения. Исследование Список требований всегда неполон – всегда найдутся неучтенные требования, которые опущены или предполагались по умолчанию. Вне зависимости от полноты ваших требований, они всегда будут неполны. Вы не будете заранее знать, что делает ваше приложение. И тут в игру вступает исследовательское тестирование. Исследовательское тестирование определяется как одновременное обучение, тест-дизайн и прогон тестов [2]. Тестировщик исследует приложение, узнает новую информацию, учится, находит что-то новое для тестирования по ходу дела. Он может заниматься этим в одиночку или в паре с другим тестировщиком (а может, и разработчиком). Тестирование не должно восприниматься, как прогон списка готовых тестов или тест-кейсов, дающих твердый «pass/fail’ результат. Если у вас есть юзер-стори или набор требований, конечно, важно иметь их в виду. Однако критерии приемки бывает полезно переформулировать как «критерии отказа». Когда критерии приемки не удовлетворены, продукт не принят, но если они в порядке, это не значит, что в ПО нет багов. Проверки и верификация должны совмещаться с исследованием и расследованием, а также вопросами в духе «Что будет, если…», на которые вы можете не знать ответа, пока не попробуете, и ответы на которые не покрыты вашими готовыми кейсами. Снижение рисков Одна из причин, по которой мы тестируем – это поиск дефектов, рисков и другой информации о продукте, которая позволяет нам действовать, чтобы конечный пользователь не пострадал. Мы можем: Исправлять баги. Переоценить и изменить изначальные требования. Помочь пользователю с продуктом. Создать пользовательскую документацию. Донести информацию об имеющихся проблемах до заинтересованных лиц. Устранить все возможные баги, с которыми может столкнуться пользователь, просто невозможно, каким бы сложным не было ваше ПО. Однако, тестируя, мы снижаем риск того, что пользователь с ними столкнется – или серьезность последствий такого столкновения. Ценность Тестирование – это ценная часть разработки ПО, но его часто недооценивают из-за его непредсказуемой и креативной природы. Результат ежедневного труда разработчика – это код, аналитика – требования или документация, однако результаты труда тестировщика может быть довольно сложно измерить. Зачастую тестировщикам сложно рассказать о своих планах, своем прогрессе и результатах. Те, кто не разбирается в тестировании, в результате плохо понимают, что было сделано, как, и почему. В итоге понять ценность тестирования сложно. В мире множество компаний, разрабатывающих ПО вообще без тестировщиков. Отсутствие счетного результата, создаваемого тестировщиками – одна из причин, по которой некоторые предпочитают использовать тест-кейсы как способ измерения – их можно легко сосчитать. Но ценность тестирования – это намного больше, чем тест-кейсы. Исследовательское тестирование, возможно, не дает в результате набора четких кейсов, однако тестировщик находит больше интересных багов, отступая от жестких сценариев. Отчасти поэтому людям нравятся метрики, которые учитывают количество заведенных багов, написанных и пройденных кейсов, и других вещей, которые можно сосчитать. Некоторые проекты используют эти метрики, чтобы измерять качество продукта, а также качество работы разработчиков и тестировщиков. Эти метрики концентрируются на неправильных вещах и могут вас обманывать. Тестирование ценно на всех стадиях жизненного цикла разработки, не только когда пишется код. Вот что еще можно протестировать: Идеи Требования Дизайн Предположения Документацию Инфраструктуру Процессы. Задача тестировщика – задавать вопросы, исследовать, критически размышлять над этими вещами. В результате то, что могло бы стать багом в процессе разработки, можно изловить гораздо раньше. Коммуникация Коммуникация – это огромная часть работы тестировщика. Тестировщики предоставляют информацию о качестве программного продукта, поэтому очень важно передавать эту информацию точно, чтобы заинтересованные лица принимали верные решения. Человек может начать работать тестировщиком, имея слабые технические навыки, но если он силен в коммуникации и может внятно донести свою мысль – это куда важнее. Тестировщики должны использовать правильные слова и верно строить фразы, чтобы они не были противоречивыми – так снижается риск недопонимания. То, что вы хотели сказать – необязательно то, что вы в итоге сказали, и часто люди делают допущения и в результате предпринимают неверные действия, потому что коммуникация была плохой или недостаточной. Нам нужно регулярно общаться с людьми, играющими различные роли, находящимися на разных позициях и обладающих разным объемом знаний о продукте. С разработчиками, задавая им вопросы и узнавая больше о продукте, который они создают. Разработчики помогают нам вникать в технические аспекты, и им мы объясняем, что за баги мы нашли и как их воспроизвести. С владельцами продукта, чтобы понимать требования, задавать вопросы по сценариям использования и делиться информацией насчет этих сценариев, чтобы они могли принимать решения насчет релизов продукта. С тестировщиками. Если вы работаете в команде тестировщиков, очень важно общаться с коллегами, обсуждать с ними проблемы и принимать решения. Возможно, вам придется тренировать новичка или джуниора, и очень важно внятно объяснять им их задачи и помогать, если им приходится нелегко. С пользователями и заказчиками, чтобы убедиться, что их ожидания и их проблемы правильно поняты. Если вы помогаете им решить проблему, вы должны быть способны объяснить, как пошагово избавиться от нее, так, чтобы собеседник вас отлично понял. С менеджерами, чтобы сообщить, что было проделано и что осталось сделать, чтобы проинформировать их о рисках и их последствиях, а также временных рамках. Если вы предлагаете улучшения, внятно рассказывайте о своих идеях и их влиянии на продукт. Письменная коммуникация важна не меньше устной. Создать блестяще написанную, обширную документацию, которая никому не нужна, легче легкого. Мы должны убедиться, что используем правильный способ общения в каждом конкретном случае, будь то человек, процесс или проект. Потенциальная бесконечность По сути, мы всегда тестируем только выборку. Каждый нетривиальный продукт обладает непредставимым количеством параметров с большим количеством возможных значений. Откуда вы знаете, что тестируете важные значения? Мы не можем протестировать все. Часть нашей работы – принятие решений о том, что тестировать, понимание последствий того, что будет протестировано только это, и способность обосновать свой выбор. Из чего тестирование не состоит Простота О тестировании часто думают как о чем-то, чем может заниматься любой. Возможно, в какой-то степени это правдиво – любой может исследовать продукт, задавать вопросы о нем, прогнать пошагово тест-кейс или проверить, соответствует ли продукт списку требований. Но чтобы делать это хорошо и систематически, нужен настоящий навык. Нам часто говорят «пишите кейсы так, чтобы их мог прогнать любой дурак», и из-за этого создается ложное впечатление, что тестировать очень просто. Мы тупо пишем тесты согласно критериям приемки, не так ли? Но тестировщики, тестирующие свободным поиском, знают, что это не так. Даже проверки – не такое-то простое дело. Мы принимаем непростые решения, где нужны эти проверки, и какие из них следует автоматизировать. Эти решения требуют понимания фреймворков автоматизации, навыка программирования, знания, как работает API, и владения инструментами вроде Selenium. Резюмируя, мы должны разбираться в приличном наборе технологий. Помимо этого, нам нужно знать, что нужно автоматизировать, а к чему автотесты подпускать нельзя. Автоматизируемость «Ручные тестировщики нам больше не нужны – мы можем автоматизировать все!» Все мы видели те или иные вариации этой фразы в Твиттере, на форумах и в статьях. Тестирование – это исследовательская, детективная деятельность, и ее невозможно заменить автоматизированными проверками. Компьютер технически не способен исследовать продукт так, как это делает человек. Мы можем автоматизировать те или иные проверки, но компьютер и человек будут прогонять их по-разному. Живой человек заметит многое из того, на что никогда не обратит внимание машина, и прислушается к своему ощущению «тут что-то не так» – и, соответственно, даст обратную связь не только по конкретной проверке, но и по всему подмеченному в процессе. Компьютер сделает только то, что ему сказано сделать. Автоматизированные проверки очень ценны для тест-стратегии, но на данный момент неспособны заменить живых тестировщиков, потому что люди и машины занимаются принципиально разными вещами. Тестировщики используют инструменты, в том числе автотесты, для поддержки своей работы. Специальные инструменты помогают нам генерировать данные, автоматизировать рутины, анализировать результаты тестов. Ими нужно владеть, чтобы облегчить себе жизнь, а не с целью заменить ручной труд полностью. Повышение качества Тестировщики не делают ничего, что бы напрямую улучшало качество продукта. Прогоняя тест, мы никак не влияем на код – следовательно, качество ПО остается неизменным. Только после того, как разработчики исправляют баги, качество продукта может измениться. Мы не можем «втестировать» качество в продукт. Тестирование – не единственная область разработки ПО, принимающая во внимание качество продукта. За ним нужно следить на всех стадиях жизненного цикла, и за него отвечают все участники команды разработки. Тестировщики могут использовать свои специфические навыки для сотрудничества с коллегами, но за качество отвечаем не только мы – это головная боль всей команды! Ни тестировщики, ни разработчики, правящие баги, не могут в результате сделать вывод, что качество продукта улучшилось. Мы не можем протестировать все, поэтому всегда вероятны сценарии, которые мы не проверяли, таящие в себе баги. Качество может ухудшиться из-за изменений или чего-то, неизвестного нам – мы даже не подозреваем, что у нас есть проблемы, пока не произойдет нечто, вскрывающее их. И даже если тестировщики могут уверенно сказать, что продукт готов к релизу, конечные пользователи могут его забраковать – например, из-за криво составленных требований. Все зависит от точки зрения. Качество определяется как «ценность для человека, чье мнение значимо». Его трудно измерить, и поэтому с определенностью заявить, что тестирование на каком бы то ни было этапе улучшает качество продукта, довольно трудно, даже невозможно. Фиксированная, не требующая воображения деятельность, подчиняющаяся строгим правилам Самые интересные баги зачастую находятся при помощи исследовательского тестирования. Прогон одних и тех же тестов раз за разом вряд ли даст вам много новой интересной информации – и, на сердце руку положа, довольно скучно гонять их вручную. Не существует лучших практик тестирования, применимых в абсолютно любых проектах. Вы должны выяснить, что лучше всего работает в вашем контексте и в вашей области. Размышления над новыми креативными способами тестирования – очень увлекательная часть нашей работы. Способность экспериментировать, искать лучшие инструменты, изучать новые навыки и технологии, и делать то, что наилучшим образом подходит нашему проекту, помогает нам постоянно совершенствоваться и держать свои навыки в форме. Жизненно необходимо для успеха продукта Проект может быть вполне успешным и без тестировщиков – тому множество примеров. Однако даже в случае отсутствия тестировщиков как таковых тестирование все же кем-то выполняется на той или иной стадии жизненного цикла. Разработчики тестируют собственный код, а заказчики – требования. Конечный пользователь иногда тестирует продукт до релиза. Люди могут тестировать, даже не отдавая себе отчета, что они этим занимаются. Никогда не заканчивается Под бесконечностью тестирования понимается невозможность протестировать все и вся в приложении. Нет реалистичных способов протестировать все комбинации, действия пользователя, внешние условия, значения данных или пути через код. В этом плане тестирование, действительно, бесконечный процесс. Следует принять как данность, что всегда останется что-нибудь непротестированное. Большинство проектов жестко ограничены временем, бюджетом и ресурсами, и тестировщики должны укладываться в эти ограничения, тестируя максимально эффективно. Часть работы тестировщика – это принятие решений, что именно тестировать, и понимание последствий этих решений и связанных с нимирисков. Тестирование завершается, когда у менеджмента достаточно информации, помогающей принять решение, готов ли продукт к релизу. Тестирование – это многое, многое другое Я перечислила только некоторые аспекты того, что же такое тестирование. Эта статья могла бы быть значительно длиннее! Нет единого определения, что подразумевается под тестированием, а впихнуть в одно предложение все то, чем занимаются тестировщики, просто невозможно! Если поискать определение тестирования в Интернете, можно наткнуться на фразы вроде «поиск багов в приложениях» – но как мы уже выяснили, это не только и не столько поиск багов. Ссылки: Explaining Testing To Anybody — James Bach Software Testing Club — So What Is Testing ? The Impossibility of Complete Testing — Cem Kaner Exploratory Testing — James Bach Acceptance Tests : Let’s Change the Title Too — Michael Bolton The Rapid Software Testing Guide to What You Meant To Say — Michael Bolton Exploratory Testing Explained — James Bach Explore It — Elisabeth Hendrickson Обсудить на форуме

Каких ответов я жду на собеседовании по тестированию

Я провожу собеседования на тестировщиков. У меня иногда болит голова.

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

Вступление

Сначала несколько слов о себе. На данный момент являюсь начальником отдела тестирования и сопровождения компании, занимающейся корпоративными ГИС. До этого работал руководителем группы тестирования в компании, разрабатывающей коммерческие СДО (Системы дистанционного обучения). А еще раньше ведущим инженером по тестированию в компании, которая обеспечивала электронные торги по ФЗ №94. А начинал я свою карьеру более 11 лет назад в роли системного администратора (в трех различных организациях). Стажером-программистом был чуть меньше двух лет (вначале нулевых – VB). Фрилансил инженером-программистом: писал собственный баг-трекер для госкомпании… Исходя из сказанного, можно утверждать, что определенный опыт (тестирования — суммарно более 5 лет) наработан…

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

На собеседовании я всегда задаю одни и те же вопросы:

1. Почему вы решили стать тестировщиком?
2. Что такое тестирование? В чем его суть как процесса?
3. Что такое ошибка?
4. В чем цель тестирования?
5. Что вы знаете о жизненном цикле ПО?
6. Какие бывают требования?
7. Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?
8. Расскажите о тестовой документации: виды, цели.
9. Из каких этапов состоит процесс тестирования?
10. Автоматизированное тестирование – отдельный вид тестирования?
11. Какой тип/вид класс тестирования имеет смысл автоматизировать?

Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. Доходящий за то же время до 11 вопроса может быть принят на должность ведущего тестировщика, однако за 240 проведенных собеседований таких оказалось только 5 человек!

Может, я слишком требователен к ответам? Нет, я просто жду от соискателя понимания того, чем ему придется заниматься. Вот как проходит собеседование: я начинаю разговаривать с соискателем предпочтительно в форме диалога, задавая ему указанные вопросы. Если получаю ответ, правильный или близкий к правильному, то перехожу к следующему вопросу. Если соискатель «блуждает», приводит заученную формулировку или просто не может ее обосновать, я пытаюсь подвести его к правильному ответу и почему этот ответ правильный. Пытаюсь заставить рассуждать. Последний год вместо собеседований у меня получаются импровизированные лекции. И дело не только в том, что соискатели менее осведомлены или у них мало опыта. Имели место и собеседования на должность ведущего инженера по тестированию с претендентами с 10 летним опытом… результат почти всегда удручает. По-моему, дело в том, что очень много противоречивой информации и «неполезного» опыта, ведь очень многие российские компании строят процесс тестирования по модели С. Канера – когда два – три высококвалифицированных тестировщика полностью генерируют, отбирают и описывают кейсы, а проверки проводят 10 -15,100, 500+ «тестеров» не особо вникая в саму суть процесса.

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

Почему вы решили стать тестировщиком?

Наиболее частый ответ: «потому что это просто и интересно (!)». Т. е. кандидат считает, что ему будут платить деньги за щелканье мышкой в вк… Или дадут софт и скажут – сломай его… Или он просто не готовился к этому вопросу и имеет весьма слабое представление о профессии.

Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).

Бывали и ответы: «меня мама/муж/жена заставила идти на собеседование».

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

Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».

Что такое тестирование? В чем его суть как процесса?

Наиболее частый ответ (напрямую прописан у С. Канера и Р.Савина) – «поиск ошибок». И во всей литературе по тестированию почему-то никто не указывает, что это упрощение и весьма грубое, и вообще, этот ответ просто неверен!

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

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

Что такое ошибка?

Ну, здесь, слава Богу, почти все отвечают: «некорректная работа программы…». А вот дальше начинается хаос, когда спрашиваешь: «а как мы узнаем корректная работа или нет?»

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

В чем цель тестирования?

Здесь люди начинают повторять ответ на второй вопрос с разными вариациями. Наиболее внимательные соискатели пытаются пересказать то, что я им подсказывал при ответе на второй вопрос. А ответ крайне простой:

Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям.

Всё. Не больше и не меньше. Ну, конечно же, можно еще сказать, что цель тестирования – предоставление информации о количестве ошибок в продукте. А именно это и неправильно. Почему? Вот просто-таки каждодневный кейс многих тестировщиков/ПМ/аналитиков: звонок заказчика – «как там мой продукт?». «Вы знаете, в нем еще 60 багов!» – ответ тестировщика/ПМ… И что дальше? Это много? Мало? Нормально? Можно, конечно, рассказать подробно о критичности этих багов, их приоритетах, но это не ответ на вопрос заказчика, это выдача сырой необработанной информации ДВП. Теперь тот же кейс. «Как там мой продукт?», – спрашивает заказчик. «35% процентов требований реализовано полностью, еще 5% – с замечаниями и еще 2% – сейчас в реализации», – отвечает ПМ/тестировщик. Как Вам кажется, такой ответ понятнее? И пусть в эти 5% входят, уже упомянутые 60 багов-замечаний… Ответ на вопрос дан настолько точный, насколько это вообще возможно в данном формате. Вот именно это и является целью тестирования. А, соответственно, и сам процесс по своей сути должен сводиться к достижению этой цели.

Что вы знаете о жизненном цикле ПО?

Про ЖЦ ПО сказано много, да и он сильно зависит от организации процесса реализации в целом. Все же есть некоторая «золотая середина», но и здесь умудряются фантазировать дикие вещи, то сводя все к трем пунктам, то разрисовывая схему на три страницы… Всем, кто проводил/проходил собеседование, и так ясно, какие ошибки совершаются и сколько вариантов у правильных ответов. Останавливаться подробнее не буду, скажу только, что есть целый пул кандидатов, которые намертво стопорились на этом вопросе (примерно 7%).

Какие бывают требования?

До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».

Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.

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

Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» – прямое требование, из него проистекают косвенные – она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное – такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.

Есть маленький грех за мной: я отрицаю существование негативных проверок, поскольку:

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

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

Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?

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

Расскажите о тестовой документации: виды, цели.

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

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

Внешняя документация:

• Замечание – короткая записка, комментарий о небольшой неточности в реализации продукта.
• Баг-репорт – описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым – ошибки или ее проявления. Он обязательно должен содержать следующие элементы:
  • Идею тестового случая, вызвавшего ошибку.
  • Описание исходного состояния системы для выполнения кейса.
  • Шаги, необходимые для того, чтобы выявить ошибку или ее проявление.
  • Ожидаемый результат, т. е. то, что должно было произойти в соответствии с требованиями.
  • Фактический результат, т. е. то, что произошло на самом деле.
  • Входные данные, которые использовались во время воспроизведения кейса.
  • Прочую информацию, без которой повторить кейс не получится.
  • Критичность и/или приоритет.
  • Экранный снимок (скрин).
  • Версию, сборку, ресурс и другие данные об окружении.
• Запрос на изменение (улучшение) – описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя. И пути/рекомендации по модификации продукта для соответствия им.
• Отчет о тестировании (тест репорт) – документ, предоставляющий сведения о соответствии/ несоответствии продукта требованиям. Может так же содержать описание некоторых подробностей проведенной сессии тестирования, например, затраченное время, использованные виды тестирования, перечень проверенных случаев и т. п. В идеальном варианте фраза вида «Тест пройден. Ошибка не воспроизводится/Функционал работает корректно/Соответствует требованиям» означает, что продукт или его часть полностью соответствует требованиям прямым и косвенным (в производстве ПО).

Внутренняя документация:

• Тест-план (план тестирования) – формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок. Т.е. перечень направлений проверок, которые должны быть проведены в рамках сессии тестирования (и, сообразных этим направлениям, требований). Также может содержать в себе необходимую информацию об окружении, методике, прочих условиях важных для показательности данной сессии тестирования. Под направлением проверок также может пониматься более детализированная тестовая документация (в виде ссылки на нее): чек листы, тестовые комплекты, тестовые сценарии, на которую необходимо опираться при проведении сессии тестирования. Основная цель документа – описать границы сессии тестирования, стабилизировать показательность данной сессии.
• Тестовый сценарий – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им  проверок корректности поведения продукта в ходе этих действий. Может содержать информацию об исходном состоянии продукта для запуска сценария, входных данных и прочие сведения, имеющие определяющее значение для успешного и показательного проведения проверок по сценарию. Особенностью является линейность действий и проверок, т.е. зависимость последующих действий и проверок от успешности предыдущих. Цель документа – стабилизация покрытия аспектов продукта, необходимых для выполнения функциональной задачи, показательными необходимыми и достаточными проверками. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.
• Тестовый комплект – некоторый набор формализованных тестовых случаев объединенных между собой по общему логическому признаку.
• Чек-лист (лист проверок) – перечень формализованных тестовых случаев в виде удобном для проведения проверок. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Обязательно должен содержать в себе информацию о: идеях проверок, наборах входных данных, ожидаемых результатах, булевую отметку о прохождении/непрохождении тестового случая, булевую отметку о совпадении/несовпадении фактического и ожидаемого результата по каждой проверке. Может так же содержать шаги для проведения проверки, данные об особенностях окружения и прочую информацию необходимую для проведения проверок. Цель – обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования.
• Тестовый случай (тест-кейс) – формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным. Обязательно должен содержать следующую информацию:
  • Идея проверки.
  • Описание проверяемого требования или проверяемой части требования.
  • Используемое для проверки тестовое окружение.
  • Исходное состояние продукта перед началом проверки.
  • Шаги для приведения продукта в состояние, подлежащее проверке.
  • Входные данные для использования при воспроизведении шагов.
  • Ожидаемый результат.
  • Прочую информацию, необходимую для проведения проверки.

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

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

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

Но следует учитывать, что есть и свои недостатки:

• Стабильность покрытия. Со стремящейся к бесконечности долей вероятности, если проводится тестирование по документации, то будут проведены только те проверки, которые есть в данной документации. Вероятность пропуска ошибки (чаще всего несоответствие косвенному требованию, непокрытому документацией) возрастает.
• Плохая локализация ошибки тестировщиком. Либо полное отсутствие локализации. Фактический результат не совпал с ожидаемым – ошибка. А что это на самом деле: ошибка; проявление ошибки; инцидент, уже описанной ошибки, тестировщик не проверит (в подавляющем количестве случаев).
• Высокий требуемый уровень квалификации специалиста для создания и поддержания тестовой документации.
• Большие временные затраты на создание и поддержание тестовой документации.
• Слабо прогнозируемое время актуальности тестовой документации.

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

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

Из каких этапов состоит процесс тестирования?

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

1. инициация,
2. выявление требований прямых и косвенных,
3. генерация тестовых случаев,
4. отбор показательных тестовых случаев,
5. проведение проверок,
6. фиксация результатов,
7. анализ результатов,
8. передача информации о соответствии проверенного продукта требованиям.

Более подробная информация об указанных этапах:

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

Для производства ПО требования включают:

• доступно необходимое тестовое окружение,
• доступен билд/ресурс/предмет тестирования,
• код, БД, прочие компоненты объекта тестирования «заморожены», т. е. не изменяются в период всей сессии тестирования,
• модификация требований (хотя бы прямых) «заморожена»,
• известно направление тестирования,
• известны сроки на сессию тестирования.

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

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

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

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

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

Проведение проверок – тут все понятно. Либо согласно документации, либо ad hoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок. Почему-то большинство именно этот пункт называет тестированием. И в голове обывателя, незнакомого с профессией, только один этот пункт и содержится J.

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

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

Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п. Но это – уже QA J!

Вместо послесловия

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

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

Автор: korvinriner

Источник

Смысл тестирования — в процессе, а не в оставшихся артефактах. Майкл Болтон и Rapid Software Testing

В среде ИТ есть свои легенды, чьи имена знает сегодня чуть ли не каждый и чьи (что важнее) достижения в профессии показали другим новый путь к развитию. Одной из таких фигур для мира тестирования ПО был и остается Майкл Болтон, которого мы ждем на ближайшем Heisenbug 2018 Piter. В этой статье мы поговорим о Rapid Software Testing, о Майкле и его докладах.

Имея за плечами 20-летний опыт тестирования, разработки, управления и написания программного обеспечения, Майкл не просто не устает учить других, как делать тестирование наиболее эффективно, но и разрабатывает новые подходы к, казалось бы, привычному искусству тестирования ПО. Он налетал более миллиона миль на самолете, проведя сотни и сотни консультаций, лекций, учебных- и мастер-классов, и всё еще полон сил наставлять специалистов по всему миру на путь истинный — проводить тестирование быстро и эффективно.

Майкл, вместе со своим другом и коллегой Джеймсом Бахом, является соавтором отличной методологии и набора воззрений, который они называют Rapid Software Testing и о которой я решил сегодня рассказать. Rapid — это не про то, как побыстрее прогнать набор тестов, нет. Совсем наоборот, разговор о том, чтобы убрать из работы тестировщика рутину и ощущение бесконечного потока новых багов.

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

1. Процесс создания программного продукта — это отношения между людьми, как эмоциональные, так и рациональные.
2. Каждый проект находится в условиях неопределенности и давления фактора времени.
3. Несмотря на наши лучшие ожидания и намерения по отношению к проекту, некоторая степень неопытности, небрежности и некомпетентности является нормальной.
4. Тест — это деятельность; смысл его в процессе, а не в артефактах.
5. Цель тестирования — выявить статус производимого продукта и оценить, что может угрожать его полезности, так, чтобы наши клиенты могли принимать обоснованные решения по поводу него.
6. Мы обязуемся проводить надежное и экономически эффективное тестирование, и мы будем информировать наших клиентов о чем-либо, что угрожает этому обязательству.
7. Мы не станем сознательно или по небрежности вводить в заблуждение наших клиентов и коллег.
8. Тестеры несут ответственность за качество своей работы, хотя они не могут контролировать качество продукта.

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

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

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

Для начала, чем крупнее проект, тем больше будет проверок. Очень скоро, с ростом объёма кода, мы обнаружим, что никаких сил не хватит, чтобы покрыть тестами его весь, и от проверки каких-то, как мы решим в тот момент, мелочей придётся не то чтобы отказаться, но отложить их «на потом» (от этого сил и рук больше не становится, мы просто получим не одну, а минимум две очереди работы: «важное» и «сделать, когда будет время» — и долг в виде этой второй очереди будет копиться и копиться). Получаем бесконечную битву, итог которой заранее понятен: объять необъятное не получится (хотя мы, несомненно, можем мечтать, что однажды мы это и сделаем). При этом не всякий код мы можем протестировать изолированно, и баги могут вылезти в реальных условиях работы даже при полностью успешном прохождении набора тестов.

Далее, порой может оказаться, что проверки, написанные согласно имеющейся документации на проект (и на код проекта), относятся к неактуальной уже версии кода — тот неловкий момент, когда «код поправили, а доку не успели обновить». В результате конкретный тест будет «светиться зелёным», но на самом деле результату проверки доверять уже не имеет смысла. Кроме того (пусть даже мы не будем ждать обновления документации), корректно написанная и актуальная сегодня проверка может стать неактуальной завтра, когда тестируемый ею код допишут/переделают, а тест переделать забудут, и он уже не будет в состоянии ответить ни на какие разумные вопросы по поводу качества тестируемого кода.

Занудно? Ещё можно вспомнить про бюрократию, которая со временем разводится вокруг результатов более-менее объёмного по покрытию тестирования. Неуспешные тесты (особенно автоматизированные) ведут к созданию тикетов, которые, по-хорошему, тоже нужно исследовать — хотя не всегда понятно, есть ли в этом большой смысл.

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

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

Я отлично понимаю тестировщиков, которые работают планомерно, день за днём покрывая ещё непокрытые куски кода проверками, постоянно гоняющих автотесты, разбирающихся с «покрасневшими» проверками и заводящих тикеты по поводу каждой подозрительной «красной метки»: в иных проектах только так и можно сохранить душевное равновесие. Беда только, что по мере роста объема кода и числа проверок всё многообразие тестов прогоняется совсем не быстро, так что ощущение динамики жизни проекта как-то само собой притупляется. В итоге имеем ощущение бесконечной борьбы с ветряными мельницами.

Что же устами Майкла Болтона предлагает нам Rapid Software Testing? Для начала вместо полного покрытия тестами с этими бесконечными прогонами большого числа проверок мы переходим на быстрое тестирование очередного места, о котором сами, в силу опыта работы, знаний о проекте и некоторого профессионального чутья, догадываемся как о содержащем потенциальные проблемы в коде. Мы стараемся сделать проверку короткой (по времени), нересурсоёмкой (во всех смыслах), такой, чтобы ее результатам можно было доверять и чтобы эти результаты можно было понятным образом изложить. Возможно, при этом мы перейдем от автоматического запуска тестов к ручной проверке и сделаем число проверок меньше, но проверять мы будем в тех местах, где они действительно нужны, где, как наш опыт нам подсказывает, вероятнее всего и может приключиться баг из серьезных.

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

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

Положив руку на сердце, скажем: квадратно-гнездовой подход к тестированию, ярко заметный при создании традиционного полного покрытия тестами всего кода, хорошо работает для доказательства собственного участия в процессе, но не особо влияет на результат. Другими словами, нам нужно выбирать: мы стараемся быть «при деле», или мы стараемся помогать проекту. Причем решающим фактором выбора я бы назвал мысль о том, что в ИТ (как и в жизни) нельзя остановиться на месте; ты либо растешь, либо теряешь в знаниях — и, в результате, в перспективах дальнейшего движения. Другое дело, что покрывать тестами всё и вся можно механически, не особо включая голову, а с RST придется думать, и думать интенсивно, но результат того стоит!

Помните Чебурашку из мультика, когда он произносил речь на завершении постройки дома: «Мы строили, строили, и наконец построили»? Авторы RST представляют команду разработки идущей к одной общей цели (что, конечно, чаще правда; упомянутый суровый «ынтерпрайз» и иже с ним не берем, там свои законы джунглей), так что сидящий и смотрящий в бесконечные списки раз за разом проделываемых проверок человек вызывает недоумение, но, заодно, и надежду, что ему самому хочется больше вовлечься в процесс работы — и вместе с остальными приблизить момент выкатывания очередной версии ПО.

Не может быть «правильного» и «неправильного» тестирования. То, что подходит для банка, не подойдёт ни для разработки ПО в военной промышленности, ни для небольшой софтовой компании, так что о тех или иных подходах можно говорить только в привязке к контексту, из чего, очевидно, выводим, что невозможно выделить пресловутые «best practices» для тестирования в целом — нужно выбирать техники и подходы, согласующиеся с ситуацией и окружением. Как пример: столь популярный в среде стартапов Agile довольно покладист в вопросе дотошности тестирования, полагая, наоборот, что код в любом случае «скорее жив, чем мертв». Есть даже такая шутка: Agile изобрели, уволив из проекта всех тестировщиков. Что же, логику подхода понять можно — Agile делался разработчиками для разработчиков, не имея целью улучшение тестирования кода. Причины этого коренятся в культуре стартапов: там, где тестировщик по натуре своей будет сомневаться в работоспособности, предприниматель, вложивший в стартап деньги, скажет: «Ок, пусть так, но оно же может и заработать?!»

Что действительно нужно для успеха внедрения RST (и, согласно её воззрениям, для последующих улучшений в жизни проекта и его команды) — опыт, знания и страстное желание со стороны участников. Уточним: разговор про реальный опыт, а не про корочки и сертификаты о прохождении курсов и экзаменов. Последние никак не гарантируют, что, пройдя экзамен из 40 вопросов с готовыми ответами, не предполагающими выполнения какой-либо реальной работы по тестированию, человек сумеет включить интуицию в любой жизненной ситуации. Несомненно, посадить на тестирование можно почти любого человека, способного выполнять действия по стандартному алгоритму — но большой пользы проекту от таких проверок не будет.

Важным для RST является особый образ мышления: неуверенность в очевидном, привычка задавать вопросы про вещи, кажущиеся окружающим понятными и неизменными, автоматическое добавление «что, если?» в начале каждой фразы, которую мы читаем или слышим, способность видеть сложность за видимой простотой, поиск альтернативных интерпретаций всего, с чем сталкиваемся. Это своеобразная внутренняя вера в то, что баги могут быть во всем; если тестировщик думает по-другому, ему будет трудно выполнять свою работу.

Майкл Болтон говорит о себе скромно: «Учу людей, как эффективнее отвечать на вопрос, действительно ли продукт, который они получили — то, что на самом деле ожидали получить». На деле его область знания (и вовлечения слушателей) гораздо шире, именно благодаря ему многие осознали весь объем (и изящество) профессии тестировщика в принципе.

В этот раз Болтон приезжает с двумя докладами: «The logic of verification» (про фазу верификации в процессе тестирования и про избегание неверных предположений и ложных выводов) и «Testers as their own worst enemies» (о том, как тестировщики могут поднять свою репутацию и имидж в компаниях, где отношение к ним разработчиков традиционно было с позиции превосходства). Приглашаем и вас посетить Heisenbug 2018 Piter, чтобы получить удовольствие от общения с этим замечательным докладчиком.

Что такое исследовательское тестирование? / Habr

И чем оно отличается от тестирования по сценариям (сценарного тестирования)

Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.
 

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

Параллельное проектирование и выполнение тестов

Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Звучит это просто, но на практике все весьма туманно. Это происходит из-за того, что «определенный» не означает что мы жестко фиксируем все и вся. Даже в том случае, если тщательно определены все тестовые сценарии, то работа с большим количеством интересных деталей (например, как быстро печатать на клавиатуре, или какие виды поведения программы признать ошибочными) остаются на усмотрение тестировщика. Кроме того, даже в свободной форме поисковой сессии тест будет включать в себя ограничения состоящие в том, какую часть продукта тестировать или какую стратегию использовать. Хороший исследовательский тестирировщик будет записывать идеи тестов и использовать их в последующих циклах испытаний. Такие заметки иногда очень похожи на сценарии тестирования, даже если они таковыми не являются. Исследовательское тестирование иногда путают с «ad hoc» тестированием. Ad hoc тестирование обычно относится к процессу импровизации, поиска ошибки экспромтом. По определению, любой может заниматься ad hoc тестированием. Термин «исследовательское тестирование» (придумал Cem Kaner, в книге Testing Computer Software) обозначает вдумчивый подход к ad hoc тестированию. За последние десять лет, Джеймс Уиттакер, Сем Канер и я работали для выявления навыков и техник позволяющих эффективно использовать исследовательское тестирование. Например, полностью определены и сформулированы процессы исследовательского тестирования, см. General Functionality and Stability Test Procedure for Microsoft’s Windows 2000 Compatibility Certification program.

Баланс между исследовательским и сценарным тестированием

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

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

Зачем проводить исследовательское тестирование?

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

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

Тестирование. Ошибки при сертификации или ISTQB мне очень нужен / Habr

Статья полезна тем, кому небезразлична их квалификация и хочется стать лучше. Учиться никогда не поздно.

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

Мне бы хотелось написать о ISTQB, т.н. International Software Testing Qualifications Board. Это признанная во всём мире сертификация для тестировщика. Если ты такое получил, то по идее владеешь базовыми знаниями и теорией, то есть и плюсик тебе на собеседованиях добыть можешь, и в общем самоутверждаешься.

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

Исчерпывающее тестирование

Хотелось бы для начала, чтобы запомнили следующее, “исчерпывающее тестирование невозможно, независимо от того, сколько усилий затрачено на тестирование (т.н. Принцип # 2)”. Этот принцип запомнить придется. Много ссылок на материалы для подготовки кидать не буду, одну приведу в конце статьи. Пункт, в котором засомневалась я, был “При достаточных усилиях и инструментальной поддержке исчерпывающее тестирование возможно для любого программного обеспечения». Первые мысли были о том, что терпение и труд всё перетрут. Это верно только для тривиальных ситуаций, в любой реальной системе предусмотреть все ситуации не сможем, остается только свести к минимуму количество проблем.

Стадии и задачи

Информация для запоминания. Основной процесс тестирования можно поделить на этапы, направления деятельности:

• Планирование (Этап 1)
• Анализ и проектирование (Этап 2)
• Внедрение и реализация (Этап 3)
• Оценка критериев выхода и создание отчетов (Этап 4)
• Действия по завершению тестов (Этап 5)

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

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

• Определение целей тестирования
• Рецензирование базиса тестирования
• Создание тестовых наборов из тестовых процедур
• Анализ накопленного опыта для улучшения процесса

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

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

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

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

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

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

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

Тестирование в период сопровождения

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

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

Системное и компонентное тестирование

Главное помнить, что компонентное тестирование обычно является ответственностью разработчиков, в то время как системное тестирование — типичная ответственность тестировщиков.

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

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

Формальное рецензирование и его шаги

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

Основные фазы формального рецензирования — это планирование, старт, индивидуальная подготовка, изучение/оценка/запись результатов, повторная обработка, отслеживание. Этапы на самом-то деле все последовательные и логичные. Спланировали, какие критерии нужны, и выбрали людей, при запуске поделились со всем своими планами, подготовились индивидуально, учитывая все особенности и требования именно этой системы. Далее получили результаты, которые показали нашим экспертам, и все проблемы, что всплывали, поправили. И дальше следим, чтобы нигде ничего не нарушалось.

Заключение

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

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

Полезные ссылки

Материалы для подготовки
Хорошая статья о тестировании от Натальи Руколь

Создаем отдел тестирования / Habr

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

Что такое тестирование? Упрощенно, это процесс проверки того, что программа соответствует всем поставленным требованиям. Еще более упрощенно ‒ тестирование есть поиск ошибок. При этом обычно программа рассматривается как “черный ящик”, и проверка производится многократным запуском с разными исходными данными и в разных условиях.
Мы убеждены, что полноценное тестирование программного продукта в компании может выполнять только обособленное подразделение ‒ собственно, отдел тестирования. Перекладывание функций тестировщиков на разработчиков, бизнес-аналитиков или даже менеджеров ‒ путь неэффективный. В этой статье мы расскажем, как можно построить отдел тестирования.

Глоссарий

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

Люди

Самое важное ‒ найти правильных людей. Первое, с чем вы столкнетесь ‒ на тестировщиков у нас не учат, и найти человека не так уж просто. У вас два пути: “сделать тестировщиком” кого-то из ваших сотрудников или нанять со стороны человека в опытом работы.
Определенно, человек из компании уже знает особенности вашего продукта, требования клиентов и коллектив (это тоже важно). Вероятно (если вы уж занимаетесь разработкой), что кто-то из программистов свой код все же тестировал и кто-то это делал лучше и более тщательно, чем другие?
Однако, хотя переход из программистов в тестировщики возможен, никак нельзя быть уверенным, что ваши сотрудники, которым нравится своя работа, согласятся полностью посвятить себя тестированию. Я бы предположил, что они вообще не будут в восторге от такого предложения — слишком разные это профессии. Поэтому, найм со стороны также рассматривайте.
Хороший тестировщик — это не просто “выполнятель тестов”, это тот человек, который будет каждый день использовать ваш продукт и быть самым преданным его пользователем. А иметь такого человека в команде — многого стоит.

Планирование времени

Тестирование ‒ это трудоемкий и затратный по времени процесс. Один прогон регресс-тестов чего стоит! Поэтому при тестировании крайне важно планирование времени. Например, проектов у вас много, а отдел тестирования ‒ только один. Возникает много проблем при одновременных релизах.
Для решения очень удобно использовать google-календарь (про использование сервисов google я как-то уже писал), то есть создать календарь, в который можно вносить планируемые релизы, и расшарить его менеджерам и тестировщикам. Можно просматривать даты релизов и в системе управления проектами, например, Redmine, но наиболее наглядно использовать единый календарь для планирования.

Тестирование ‒ это учет и контроль

Чем иметь очень “злой” тест-кейс, намного важнее его “прогонять” регулярно и фиксировать результаты. Можно, конечно, все держать в голове или заносить результаты выполнения тестов в блокнот, но это не эффективно. Пользуйтесь TMS (Test Management System). Они позволяют использовать системный подход при тестировании ‒ когда мы изначально садимся и описываем план своих тестов, чтобы не получилось так: потестировали тут, там и, в результате, не можем сказать, каково же состояние проекта/продукта.
Самое важное при использовании TMS ‒ это анализ полученных результатов и выявление динамики развития проектов. Мы начинаем видеть от релиза к релизу, что, например:

• Увеличивается количество багов, и следует разобраться, в чем же проблема.
• Один из тестировщиков находит больше багов, чем остальные. Как поднять скиллы тестировщиков?
• Время на прогон регресс-тестов неуклонно растет с развитием проекта, но мы это наглядно видим и можем планировать.
• …… в общем, информации для анализа вполне достаточно.

Мы используем TMS Testlink. Вы можете выбрать и другие системы. Свой опыт и советы один из моих коллег рассказал в статье. Возьмите на заметку ‒ поможет в трудный момент. В TMS мы вносим все наши тесты, а потом просматриваем отчеты.

Ручное тестирование

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

Автоматизированное тестирование

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

Часто бывает так, что затраты на поддержание автотестов значительно превышают затраты на ручное тестирование. Поэтому надо действовать без фанатизма.
Требования к сотруднику практически такие же, как к программисту-администратору. Почему администратору? Потому что автотестирование тесно связано с релиз-инжинирингом.
То есть мы, как правило, либо собираем пакеты для тестирования, либо выкатываем релиз в тестовое окружение (staging environment или “карантин” в нашей терминологии). В определенный момент мы приходим к тому, что надо минимизировать время тестирования перед релизом.

Нагрузочное тестирование

О нагрузочном тестировании зайдет речь после первого пика пользователей. Если все затормозило и упало, то как только перестанут искры сыпаться из глаз, поднимая проект, разработчики сами начнут произносить эту мантру, и вам повезет, если в ТЗ к проекту вы найдете цифры нагрузок, которые ваш проект/продукт должен выдерживать. Как ни странно, и сам заказчик зачастую не знает, чего можно ожидать от пользователей. Обычно эти цифры из менеджера будут выбивать разработчики, а менеджер ‒ у потустороннего менеджера, то есть со стороны заказчика.
Каким инструментом проводить тестирование? Мы используем yandex-tank.
Требования к сотруднику, проводящему тестирование:

• знание технической структуры проекта,
• неплохой уровень администрирования в linux (я говорю про крупные проекты),
• навыки программирования.

Тестирование отказоустойчивости

Вам понадобится этот вид тестирования, как только вы начнете строить отказоустойчивые системы (например, с резервированием элементов или с graceful degradation). Печальный опыт показывает, что при отказе одно элемента в таких системах падает вообще все поведение других элементов труднопредсказуемо.
Как мы проводим тест отказоустойчивости? Анализируем техническую структуру проекта, тщательно планируем действия и в часы наименьшей загрузки выводим некоторые элементы системы из работы, изучаем последствия, вносим улучшения и корректировки. Потом повторяем.

Заключение

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

• Выбрать правильных людей — из компании или извне;
• Завести инструмент планирования времени на тестирование релизов;
• Организовать работу с TMS для формирование тест-кейсов и учета результатов тестирования;
• Собственно, регулярно проводить тесты и анализировать результаты;
• Начать с ручного тестирования и по необходимости внедрять автоматизацию; по мере развития проектов добавлять нагрузочное тестирование и тестирование отказоустойчивости.

Основные принципы организации процесса тестирования

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

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

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

С чего же начинать организацию процесса тестирования?

Я выделяю 11 основных критериев в организации процесса тестирования:

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

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

Только после того, как мы получим ответы на эти вопросы, можно начинать переходить к стандартам.

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

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

Любой ИТ процесс всегда должен удовлетворять потребностям бизнеса!

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

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

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

Говоря об области тестирования, мы должны прекрасно понимать, что именно нам предстоит тестировать. Это могут быть системы, компоненты, бизнес процессы. Для того, чтобы это понять, то нужно просто ответить на два вопроса:

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

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

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

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

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

Коммуникации и взаимодействие

Взаимодействие, как внутри команды тестирования, так и с другими участниками процесса ЖЦПО, является неотъемлемой частью организации любого процесса, а в нашем случае процесса тестирования.

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

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

Если мы рассматриваем формализацию процесса коммуникации, то важными артефактами при его выстраивании является матрица ролей и матрица эскалации.

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

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

Методология тестирования

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

Стандартно разделяют 2 общепринятых подхода к организации процесса ЖЦПО:

• Каскадная методология
• Гибкая методология

Зачастую, когда ваша компания не является стартапом, то у компании всегда определен процесс разработки ПО, который работает по одной из 2-х методологий. Каскадная – работа по длительным релизам, которые обычно могут выходить от 3-х до 12 раз в год. Гибкая – это подходы Agile, когда вся наша разработка ведется спринтами, которые могут быть от 1-го дня до 2-х недель.

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

Поэтому, можно выделить 3 подхода к тестированию ПО:

• Тестирование, основанное на требованиях
• Тестирование, основанное на рисках
• Экспертное тестирование

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

Для гибкой методологии времени на разработку тест-кейсов обычно не бывает, поэтому подготавливаются чек-листы. Набор проверок могут определяться как не по формализованным требованиям, так и на основе рисков ПО (тестирование, основанное на рисках).

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

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

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

Документирование процесса

Стоит документировать процесс или нет? Когда документировать? Нужно ли писать ненужную документацию и тратить на это время?

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

Основным стандартном по документированию процесса тестирования является IEEE 829.

К основным документам можно отнести:

• Стратегия тестирования
• Тест-план
• Матрица покрытия требований
• Тест-кейсы
• Протоколы тестирования
• Отчетность о тестировании

Если рассматривать гибкую методологию, то мы можем формализовать:

• Стратегию тестирования (описывающий порядок тестирования и подход к выполнению работ по тестированию ПО)
• Тест-план (в кратком содержании для спринта не менее 2-х недель, при меньших сроках спринта ведение не актуально)
• Чек-листы (аналогия тест-кейсам, кратко описывающие проверки в тестировании)

Управление рисками

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

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

Вести риски можно несколькими способами:

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

При заведение риска определяется его статус:

• Идентифицирован
• Отслеживается
• Предотвращается
• Реализован
• Закрыт

Влияние и вероятность в 4-х приоритетах.

Ну и самое важное – это стратегия по работе с риском:

• Избегание
• Минимизация
• Передача
• Принятие

Далее описывается сам риск, т.е. в чем он заключается и 2 пути решения, первое и резервное, если первое решение не сработало.

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

Измерение процесса тестирования

Зачем нам измерять процесс тестирования? Именно такую фразу я чаще всего слышу от многих руководителей отделов тестирования. Ответ простой: “Измерение процесса тестирования помогает понимать его эффективность для решения поставленных задач”. Я не буду углубляться в эту тему, так как у меня есть отдельная статья на тему измерения процесса тестирования.  Измерение процесса тестирования

Инструменты и инфраструктура

Какой же процесс тестирования без инструментов? Это получается ручной труд ради ручного труда 🙂 Я думаю многие из вас часто слышали о написании тест-кейсов в документах ворд, о построения графиков и диаграмм в экселе. Но, зачем тратить усилия, если рынок предлагает нам готовые продукты управления тестирования, такие как HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr и многие другие.
Поэтому, если вы приступили к организации процесса тестирования, то делайте этот процесс удобным и эффективным. Пишите тест-кейсы в удобных формах готовых продуктов, интегрируйте инструменты с системой управления задачами, настраивайте автоматизированное тестирование и т.д.

Подходя к выбору инструмента нужно всегда понимать:

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

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

Помимо инструментов управления тестирования, к инструментам тестирования также можно отнести:

• Система управления дефектами и задачами (может включаться в систему управления тестированием)
• Вспомогательные инструменты (для скриншотов, снятия логов, работы с БД, SOUP UI для XML и т.д.)
• Инструменты автоматизации (TestComplete, Selenium и т.д.)
• Системы управления знаниями (на wiki движке)

Теперь поговорим об инфраструктуре. В текущем контексте своего повествования я подразумеваю тестовые среды.

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

Стандартно я выделяю следующие типы тестовых сред:

• Среда разработки (можно ли ее относить к тестовой?, но тем не менее)
• Среда тестирования системы (может быть развернута одна или несколько систем, компонент, не требует серьезных мощностей)
• Среда интеграции (полноценный интеграционная среда для проверки работоспособности сквозных бизнес процессов)
• Среда нагрузочного тестирования (основное требования – соответствие мощностями боевому контуру)
• Среда ПродЛайк/ПреПрод (среда для отладки готового протестированного билда, проведение инсталяционного тестирования)

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

Совершенствование процесса

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

Но это не так. Почему мы должны постоянно совершенствовать процесс тестирования:

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

2. ИТ сфера постоянно развивается. Приходят новые технологи подходы, которые всегда позволяются совершенствовать процесс тестирования.

Как говорится, совершенству нет предела!

Ну а как совершенствовать – это стандартный цикл Демминга.

Запланировали – .Сделали – Проанализировали – Скорректировали

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