тест кейсы какого уровня будут хорошими кандидатами для автоматизации
Системы управления тест кейсами. Какую выбрать для немедленной работы?
Как будем искать систему?
В чем сложность выбора?
Во-первых система должна нравиться и удовлетворять вашим предпочтениям. Например: легкое и простое создание кейсов, гибкая настройка (кастомизация), удобство использования, определите для себя, какая система должна быть?
Не подходят 100%
TestLink. Плюсы открытое ПО. Минусы: морально и физически устарела, при установке могут возникнуть сложности, сложная или невозможная интеграция с Jira.
TXT, DOC, XLSX. Плюсы: Бесплатно, можно сразу планировать работу, можно создавать черновики тест-кейсов, использовать как архив или заготовки. Минусы: никакой интеграции, нет контроля и учета времени.
Testia Tarantula. Плюсы: бесплатная. Минусы: плохая отчетность, нет интеграции, нет кастомизации.
Qtest. Триал версия только под заказ.
Practitest. Дорогая.
TestLodge. Будет отдельный абзац, см. ниже
Фавориты YouTube и статей: TestRail, Zephyr for Jira, QASE
Zephyr for Jira
Начнем с того, что Зефир – это не самостоятельная программа, это плагин для Jira. Поэтому, если вы не используете Jira, она вам скорее всего сразу же не подойдет.
Отдельно из минусов отмечу, что посмотреть на YouTube обзор без знания английского не получится, так, я смотрел туториал на этом канале, а он на «индийском» английском.
Ну очень много всего нужно сделать чтоб что-то заработало. Хорошая интеграция, красивые красочные отчеты, но сделана не для людей, пока заполняешь все обязательные поля для создания тест кейса, а затем столько же, а точнее, даже и больше полей, чтоб запустить тест ран, проходит много времени, а поля обязательные.
Если коротко, то просмотрел 90 минут видео-туториала, в котором к тест рану так и не приступили. Усложненная система написания тест-кейсов. – это и хорошо и плохо одновременно.
Т.к. инструмент очень мощный, то и времени и внимания требует к себе очень много. Подход к проверкам учитывает всё время, потраченное на написание тест-кейса и включает в себя: Review Story, Write Test Case, Execute Test Case всё происходит в виде тасок и подтасок на панели Скрам в формате спринтов.
TestRail
Честно, очень долгое время боготворил эту систему, т.к. отзывы везде положительные, так с энтузиазмом сравнивают с Zephyr For Jira на многих ресурсах, в т.ч. в статьях на HABR. Ну что ж, раз ее так расхваливают, значит нужно брать тестовый период и пробовать заполнять репозиторий, и назначать себе тест-раны. Но только уже при составлении тест-кейсов сразу нашелся непоправимый минус, который поменял мой взгляд на TestRail – нельзя помечать пройденный шаг. Еще один минус – тестовый период, мне кажется очень короткий. Я уже примерно месяц выбираю инструмент для хранения кейсов – и честно скажу – это достаточно сложная задача, т.к. тебе нужно опробовать все или почти все системы и дать объективный ответ, почему ты сделал такой выбор.
В целом, у TestRail достаточно большой список интеграций: Slack, Jira, GitHub и др. Инструмент достаточно мощный, но, к сожалению, мне не подошел.
А TestLodge чем не угодила?
Ну с Лоджем, очень интересно, после рассмотрения TestRail и QASE – Lodge кажется очень не доработанным, мало того, я вам скажу, что функционала в блокноте (NotePad) может и не больше, но вот Excel 100% может Lodge переплюнуть, т.к. в составленных мною кейсах в Excel – имеется возможность напротив каждого шага ставить резолюцию и прохождении или непрохождении каждого шага, например, я реализовывал данную фичу заливкой разных цветов – Зеленый – passed, Красный – Failed, Фиолетовый – Blocked и т.д., т.к. количество цветов не ограничено.
Давайте перечислим минусы TestLodge:
Ввод шагов сплошным текстом
Естественно, мы не можем на каждом шаге оставлять резолюцию пройден он или пропущен или вообще здесь БАГ
Ожидаемый результат указывается только один при прохождении всех шагов
Резолюция прохождения кейса описывается всего тремя сценариями – PASS, FAIL, SKIP
Система QASE
Неожиданно, после долгих скитаний по ресурсам интернет-статей видео на ютюб, случайно в одной из статей на аж 8м месте нашел неприметную систему QASE. Удивительно, что такая хорошая (на мой взгляд) система оказалась недооценена и о ней так мало информации. Самый большой плюс, помимо ее бесплатности – это возможность оставлять резолюции с комментариями на каждом шаге тест-кейса. Давайте оформим плюсы системы в виде списка, так будет нагляднее.
Для каждого шага есть поле для вводных данных, а также ожидаемый результат, что позволяет сделать более широкое покрытие тест-кейсами (включать микро-сценарии по ранее заведенным ошибкам), а также более подробно описать каждый шаг, а самое главное – что мы от него ожидаем.
У каждого шага можно выбрать одно из 4х состояний (Скрин 1): Pass, Fail, Skip, Block – это позволяет тест-кейсу быть более гибким, в него можно включить «экзотические сценарии» (без фанатизма), основанные и выявленные на фоне ранее заведенных ошибок. По опыту работы в Яндексе асессор-тестировщиком могу сказать, что это ужасно удобный функционал, т.к. шаг, на котором выявлено несоответствие сразу заносится в баг репорт, а также заносится окружение, стенд, и ранее пройденные шаги, вам остается придумать и написать правильный заголовок.
Для каждого шага можно написать комментарий.
У каждого тест-кейса может быть 5 состояний (Скрин 2): Passed, Failed, Blocked, Skiped, Invalid (такое редко, но бывает, Когда тест кейс есть, но он сломан или не актуален).
Программа бесплатна (до 3-х пользователей).
Имеется возможность кастомизации.
Поиск по ключевым словам, которые ранее сами занесете.
Скрин 1 – Комментарий и статус к каждому шагу 
Скрин 2 – Возможность выбирать статусы тест-кейса
Лучшие практики автоматизации тестирования: решение, что и когда автоматизировать
Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать «все». Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?
Исчерпывающее тестирование невозможно. Это один из ключевых принципов тестирования программного обеспечения. Перед тем, как начнется автоматизация тестирования, вам необходимо принять решение на основе данных о том, что вы будете автоматизировать, а что нет, и в каком приоритете. При принятии решения о том, что автоматизировать, следует учитывать несколько основных моментов, например уровень автоматизации, на котором вы будете создавать свои тесты. Автотесты можно разделить на три основных уровня: модульные тесты, интеграционные тесты и UI тесты. Вы должны оценить плюсы и минусы написания тестов на каждом из этих уровней, прежде чем приступать к их написанию.
Независимо от того, какой уровень автоматического тестирования вы выполняете, цель должна заключаться в автоматизации того, что приносит наибольшую пользу и учитывание областей, всегда тестируемых для каждого релиза, и областей, которые трудно тестировать вручную. Вам также следует обратить внимание на области, в которых требуется обрабатывать огромные объемы данных. Все эти факторы необходимо учитывать перед автоматизацией. Если вы создаете автотесты вслепую или по своей прихоти, это увеличивает вероятность того, что вы не получите от них столько пользы, сколько следовало бы.
Ниже подробно описаны пять критических областей/факторов, о которых следует помнить, когда вы рассматриваете возможность интеграции автоматического тестирования в свой текущий рабочий процесс.
Автоматизируйте ваши смоук тесты
Смоук тесты очень важно выполнять для получения уверенности, что ваше приложение функционирует на базовом уровне, после каждого изменения или при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:
Помочь быстро обнаружить блокирующие ошибки, например, не загружается приложение/веб-страница, пользователь не может войти в систему, пользователь не может создать учетную запись или платежные сервисы не работают.
Обеспечивает более быстрое устранение новых и регрессионных багов. Смоук тесты по своей природе имеют большой охват и небольшую глубину. Это приводит к тому, что тестируется широкий спектр тест-кейсов, не углубляясь в приложение. Когда эти критические области заработают, вы сможете глубже изучить приложение, чтобы протестировать другие функции.
Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.
Автоматизируйте тесты, которые выполняются всегда, например, регрессионные тесты или тесты, которые всегда находятся в начале каждого рабочего процесса.
Это позволяет вам иметь набор стабильных тестов, жизненно важных для приложения. Например, создание учетной записи пользователя необходимо будет выполнить до того, как пользователь сможет войти в систему и просмотреть панель управления, совершать платежи и т. д. Создавая набор автоматизированной регрессии, вы можете:
Запускать тесты, которые быстро выявляют любые ошибки, возникающие в результате изменений в программном обеспечении. Эти изменения могут быть новыми функциями или исправлениями багов.
Иметь набор стабильных тестов. Регрессионные тесты обычно предназначены для существующих функций, что означает, что эти функции не являются новыми и были протестированы раньше. Это предотвращает появление флаки автотестов, из за которых вам пришлось бы тратить много времени на ручное тестирование, так как вы не уверены, действительно ли тесты провалились или нет.
Экономить время, так как теперь вы можете сосредоточить свои усилия на ручном тестировании на большем количестве крайних кейсов.
Автоматизируйте обширные тесты
Исчерпывающие тесты, такие как ввод больших наборов данных, тестирование формы или тесты, требующие от тестировщика многократного выполнения одного и того же процесса, но с большим разнообразием данных, должны быть автоматизированы. Вы можете создавать автотесты на основе данных, которые позволяют сэкономить время. Для различных форм автотесты позволяют вам быстро тестировать различные комбинации входных данных, например, отсутствуют ли поля, являются ли они неполными и т. д. Тестирование на основе данных очень полезно, поскольку оно позволяет вам изменять только данные, а не тестовый сценарий, чтобы получить разные результаты. Такие тесты очень многоразовые и эффективные.
Автоматизируйте тесты, требующие нескольких конфигураций
Автоматизируйте ваши тесты производительности
Ваш следующий шаг
Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.
Тест кейсы какого уровня будут хорошими кандидатами для автоматизации
Что пишут в блогах
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Introduction
Разделы портала
Про инструменты
Автор: Майкл Болтон (Michael Bolton).
Перевод: Ольга Алифанова
Когда я слышу вопрос «У меня большой набор ручных тестов, какие из них (или, что еще хуже, «какие тест-кейсы») мне стоит автоматизировать», я беспокоюсь сразу о нескольких вещах.
Во-первых, концентрация на тест-кейсах сигнализирует о довольно убогом образе мыслей в отношении тестирования. Это связано с тем, что тест-кейсы зачастую формулируются как четкое следование явной процедуре с целью получения специфического результата. В лучшем случае следование процедуре подтвердит, что продукт может работать, а также предполагает, что любой не наблюдаемый в ходе процедуры и после нее результат не так уж важен.
Проблема тут в том, что процедуру можно варьировать потенциально бесконечным множеством способов, и множество факторов могут повлиять на сам тест или его результат. Будут ли люди пользоваться продуктом одним и только одним способом? Выявят ли эти специфические данные проблему? Могут ли другие данные выявить проблему, которую не найдешь при помощи имеющихся? Будет ли баг возникать каждый раз при следовании этому сценарию? Тест-кейсы зачастую активно подавляют исследовательскую жилку. Тест-кейсы – это не тестирование, а баги не следуют за тест-кейсами.
Во-вторых, тестирование не делится на ручное и автоматизированное. Тест невозможно автоматизировать. Автоматизации поддаются элементы процедуры теста (в частности, проверки отдельных фактов). Но ваш тест не состоит из нажатий виртуальных клавиш, выполненных машиной, или сравнения результата с какой-либо документацией.
Ваш тест – это процесс, связанный с деятельностью и размышлениями: анализом риска, дизайном эксперимента, выполнением эксперимента, наблюдениями за тем, что происходит до, во время, и после эксперимента; интерпретацией результатов и подготовкой релевантного отчета. Все это зависит от ваших намерений, образа мыслей и набора навыков. Инструменты могут помочь на этом пути, но тест – это то, что делаете вы, лично вы, а не машина.
В-третьих, множество существующих кейсов поверхностны, бессмысленны, устарели, громоздки, неэффективны, загадочны или не основаны на анализе рисков. Зачастую они сконцентрированы на пользовательском интерфейсе, а этот уровень продукта обычно не дружит с инструментами. Так как кейсы существуют, они зачастую бессмысленно перепрогоняются задолго после того, как они утратили способность искать баги. Зачем же прогонять бессмысленные тесты быстрее?
Куда лучшей идеей будет создание новых автоматизированных проверок, концентрирующихся на специфических продуктовых факторах, особенно на низких уровнях, с целью получения быстрой обратной связи. Их хорошо бы создавать в паре разработчик-тестировщик (или путем совместной работы двух разработчиков, один из которых играет роль создателя, а другой – тестировщика). Неплохая идея – разрабатывать эти проверки в ходе процесса создания какого-либо кода. Отличная идея – думать об инструментах шире, не фокусируясь только на быстром выполнении тест-сценариев.
Итак, я подталкиваю людей к смене формулировки вопроса. Вместо того, чтобы размышлять, какие (существующие) тест-кейсы стоит автоматизировать, попробуйте подумать вот о чем:
Помните: если вы относитесь к тестированию ответственно, с умом, эффективно, и концентрируетесь на поиске значимых проблем, то инструменты помогут вам найти проблемы, которые имеют значение, эффективно, с умом и ответственностью. Если вы пытаетесь «автоматизировать» плохое тестирование, вы обнаружите, что теперь вы занимаетесь плохим тестированием быстрее и хуже, чем когда бы то ни было.
Пример кейс-теста при приеме на работу
При трудоустройстве на управленческие должности сотрудники отдела кадров оценивают поведение и рабочий стиль соискателя на новом месте. Для этого используются кейс-тесты, в которых кандидату придется представить себя в роли сотрудника компании и показать, как он справится с поставленной проблемой. Изучив и проанализировав пример тест кейса, кандидаты заметно повышают шансы получить работу.
Что такое ситуационный кейс-тест
Кейс-тест – это один из методов отбора персонала, при использовании которого анализируется поведение соискателей в конкретных ситуациях. Тестирование проходит в устном, письменном или электронном виде. Кандидату предлагается описание вымышленной рабочей ситуации, или ситуации взятой из практики компании.
Иногда case тесты даются с примерами ответов, а иногда ответы придется находить самостоятельно. Такой формат помогает оценить уровень профессиональных и коммуникативных навыков кандидата, его честность, открытость, умение принимать решения.
С помощью case test предсказывают поведение будущего сотрудника на должности и оценивают, соответствует ли оно принятому стилю и политике компании.
Кейс-тесты достоверней психологических опросников и тестов профессиональных качеств. Каждый вопрос оценивает определенные качества и стиль кандидата, в то время как опросники оценивают психологический профиль в конкретный момент времени. А это не всегда правильно: даже открытый мотивированный человек на новом рабочем месте бывает замкнутым, некоммуникабельным или неинициативным из-за своей скромности.
Пример вопроса (сценария) из кейс-теста
Ситуационные тесты оценивают не качества, а умение применять их на практике для разрешения конкретных проблем.
Сфера применения
Решение кейс-ситуаций используются в практике подбора персонала с середины ХХ века. В России метод получил распространение 10-15 лет назад, до сих пор используясь при собеседованиях на руководящие должности.
Тестирование используется в составе ассессмент-центров таких компаний, как:
Чаще всего подобные испытания проходят кандидаты на руководящие должности: директора магазинов, филиалов, администраторы, главные бухгалтеры. Но иногда с ними сталкиваются претенденты на рядовые должности, например, кассиры, консультанты, операторы колл-центра, менеджеры по продажам.
Примеры тест-кейсов
Сценарии тестов разрабатываются консалтинговыми компаниями под конкретную вакансию. Например, для кандидатов на управленческие должности, сценарии связаны с взаимоотношением с подчиненными. Для массовых должностей кейс тесты, как правило, применяются устно и описывают ситуации с клиентами или посетителями. В таком формате они напоминают ролевые деловые игры.
Пример тест кейса №1.
| Верно |
|---|
| Скажу руководству, что собираюсь менять работу, продолжу работать как раньше. |
Этот вариант свидетельствует о добросовестности, готовности отвечать за свои действия, ответственно относиться к работе. Такой ответ характеризует кандидата с положительной стороны. В сложившейся ситуации правильным решением будет предупредить руководство о скором уходе, чтобы начальник начал поиск сотрудников на замену, и продолжить добросовестно работать, не принося ущерб фирме.
Если говорить о других вариантах ответа, то:
— Первый ответ говорит о неспособности работать под руководством, ненадежности, склонности ставить свои интересы выше интересов компании.
— Третий ответ говорит об отсутствии трудовой этики, недобросовестности, неумении работать в команде.
— Четвертый вариант свидетельствует о пассивной позиции, неумении отвечать за свои поступки, отсутствии самоуважения и моральных ценностей.
Образец кейс теста №2.
| Наиболее эффективно | Наименее эффективно |
|---|---|
| Поблагодарю подчиненных за работу, пообещаю, что премия будет выплачена, когда появятся деньги. | Скажу, что подчиненные неблагодарны, укажу на ошибки. |
Третий вариант решает проблему, поднимает дух в отделе. Проявляются организаторские качества, сочувствие, поддержка. Лидер всегда должен проявлять лояльность к подчиненным и вышестоящему руководству, поддерживать сотрудников, снижать влияние сложившейся ситуации на работу отдела.
Пятый вариант не решает проблему, не дает подчиненным надежду на улучшение ситуации. Непонимание недовольства сотрудников, отсутствие поддержки ухудшит ситуацию, снизит показатели продаж.
Первый вариант не решает проблему, т.к. не отражается на подчиненных.
Второй вариант временно успокоит сотрудников, но проблема не решается, ведь возмущения повторятся.
Четвертый вариант не решает проблему, разлагает обстановку, снижает мотивацию сотрудников.
Упражнения по анализу кейсов (case study)
Кроме ситуационного тестирования, работодатели на ассессменте используют формат case study. Эти задания гораздо сложнее и трудозатратней ситуационных, причем как для кандидата, так и для работодателя. Соискателю дают папку с документами (если это упражнение формата in-tray) или файлы в электронном виде (формат e-tray). Для расчетов может потребоваться калькулятор.
Как правило, задачу или проблему кейса кандидату приходится определять самостоятельно, из тех документов, что он получил.
Эти документы содержат информацию о компании (вымышленной или той, в которую устраивается человек). Таким образом, имитируется рабочая обстановка, когда сотрудник, имея на руках распечатку звонков, электронную почту, отчеты и уставные документы компании решает определенную задачу. Так рекрутер оценивает уровень подготовки будущего сотрудника, ход его мышления, мотивацию, умение решать поставленные задачи.
«Соискателю дают 20 минут на ознакомление с материалами и подготовку доклада. Ему предстоит проанализировать деловую переписку, цели, стратегии, проекты компании»
После изучения информации — подготавливается ответ. Как правило, решение представляют:
Упражнения по case-анализу определяют:
Решение задачи начинается с анализа проблемы и поиска зацепок в документации. Также выделяют приоритетные задачи, чтобы начать работу с них. Это поможет уложиться в отведенное на испытание время и дать конкретные ответы на вопросы.
«При устном ответе, если тема недостаточно раскрыта, комиссия задает уточняющие вопросы. При подготовке презентации на слайды помещают только базовые факты, а все обоснования и комментарии рассказывают устно. В пояснительной записке к заданию, как правило, указывается пример оформления ответа тест кейса»
Ситуационные тесты и упражнения по анализу кейсов разрабатываются для каждой должности и компании. Как правило, этим занимаются консалтинговые и рекрутинговые агентства. Из-за сложности создания кейса, такого разнообразия вопросов, как, например, в тестах способностей у работодателей нет. При этом задания держат в секрете, чтобы избежать утечки информации.
На этом фоне подозрительно выглядят предложения скачать или купить кейсы с решениями в Сбербанк, ВТБ, и международные компании. Чаще всего это обман, поскольку рекрутеры следят за чистотой тестирования и если испытания попадают в сеть, меняют их на ассессменте.
Единственный способ пройти собеседование и подготовиться к кейсам – решать похожие задания, читать комментарии, советы, руководства к бизнес кейсам с решением. Такая тренировка учит определять приоритет, понимать, какие решения считаются правильными, как подходить к решению тех или иных проблем.
В комментариях к каждому вопросу в тренировочных тест-кейсах описывается правильный ход мыслей и обосновывается каждый ответ. Так кандидаты учатся давать правильные ответы на ассессменте и отстаивать принятую точку зрения.
Заключение
Ситуационные тесты – второй по сложности этап собеседования, где проверяются лидерские качества, умение работать в команде, лояльность к компании, мотивация и рабочий стиль кандидата. Кроме того, результаты кейс-тестов важнее результатов других испытаний на собеседовании. Исходя из этих результатов, работодатель принимает решение о найме, ведь подобная симуляция позволяет оценить на кандидата «в деле», а не на бумаге.