Александр Александров — «дедушка тестирования» в СНГ делал доклад на юбилейной 15-ой SQA Days в Москве.
Слайды:
www.slideshare.net/VLDCORP/ss-33747358
Видео выступления:
План выступления
1.Тест-дизайн
2.Как проверять тестируемость требований
3.Требования и тестирование без тест-кейсов и/или без тестировщиков
4.Требования и изменения
5.Проще читать или проще писать
6.Как устроены тест-кейсы
7.Какие возникают трудности
8.Как их преодолевать
Начнем с того, что существует повышение общего интереса к автоматизации, это тренд и это хорошо! Но возрастает необходимость «фундамента» для разработки автоматизированных тестовых скриптов. Ведь если такого фундамента нет, то мы получаем сложность создания, использования и сопровождения скриптов. Не понятно, что они проверяют, не понятно, как они проверяют и не понятно, как они связаны с требованиями! Эта ситуация хорошо знакома тем, кто эти скрипты разрабатывает и тем, кто этими скриптами пользуется, а также тем, кто верит той информации, которая эти скрипты предоставляет.
Также следующий важный тезис — важность всего перечисленного вне контекста автоматизации тестирования. Замените все, что касается автоматического тестирования на ручное тестирование, и вы получите ровно тоже самое!
Итак, что же мы хотим?
Мы хотим упрощение и ускорение работы, а также повышение надежности результатов работы для:
— Тестировщика;
— Разработчика автоматизированных тестовых скриптов;
— Тест-менеджера, анализирующего результаты тестирования (ручного / автоматизированного)/ заказчик/будущие пользователи и т.д.
Мой доклад будет из двух неравных частей. В первой я напомню, что такое тест-дизайн, а во второй как обойти ошибки и пореже наступать на одни и те же «грабли».
Как проверять тестируемость требований
Мантры требований:
Каждые требования должны проверяться. Существуют основные критерии, на которые нужно ориентироваться. Человек может ошибаться при проверке требований. Поэтому нужно знать, как их надежно проверить! Обратите внимание, я не говорю, идеально проверить! Это невозможно! Хотя бы надежно проверить!
1 метод — Раннее проектирование тест-кейсов
То есть, как только вы начинаете использовать UML-диаграммы, story, несколько раз просмотренные, с замечаниями, начинается проектирование, то вы должны задавать вопросы: какое ограничение на это поля, а что будет после этого действия, а кто должен это сделать, а какой период по умолчанию. Благодаря этому достаточно легко обнаружить много пропусков на этапе проектирования тест-кейсов.
2 метод — Визуализация связи тест-кейсов и требований (где и как проверяется эта фича)
Потому что может оказаться, что вы написали 3000 тест-кейсов, все совершенно замечательно, но какие-то важные вещи мы просто не проверили. Причины разные: забыли, не поняли, подумали, что сделано «очевидным» для нас путем, что-то пропустили. Я указываю на это, не потому, что у меня есть универсальное решение, а потому, что так мы поступаем каждый день!
Следующий аспект, а зачем вообще нужно что-то, кроме требований?
Давайте сравним! Разница на первый взгляд очень простая, но по сути, она глубинная! Идея того, зачем нужно тестирование требований.
Требования vs. Тестирование
Соответствие программного продукта предъявляемым требованиям должна отвечать на следующие вопросы:
? Все ли требования реализованы?
? Все ли требования реализованы правильно?
? Нет ли лишнего?
? Адекватная ли диагностика?
«Зачем вы пишите 1000 кейсов, а не проще бы взять тестировщика, дать ему требования, чтобы он по ним тестировал?» Я как тест-менеджер сталкиваюсь с этим вопросом регулярно. И мне приходится все время по разному на него отвечать. Буквально недавно я отвечал на этот же вопрос: «Вот у меня серьезный сложный проект на год, в нем участвует только 2 тестировщика, которые сами тестировали требования и писали кейсы. В течение года тестировщики ушли и новые благодаря их тест-кейсам и проделанному анализу смогли перенять суть проекта и продолжить работу над ним».
Часто я слышу о том, что предлагают проводить тестирование, но без тест-кейсов и/или без тестировщиков.
Требования и тестирование без тест-кейсов и/или без тестировщиков
— Тестирование разработчиками – хорошо известны проблемы(субъекиновсть, незнание всего проекта, логика)
— Тестирование аналитиками – не нужны тест-кейсы? (интересная идея, но всегда тестируют положительны й сценарий). Проверяют лишь то, что работает как должно в требованиях, даже небольшие отклонения от корректного поведения не рассматривают. Проверяют линейный кейс, а связку требований, интеграционного тестирования не проводят)
Конечно же, в таких случаях качество и объем тестирования сильно разнятся, тестирование занимает только 20%-30% от всего возможного объема + пропускаются серьезные ошибки в требованиях.
Еще один важный аспект, на который я бы хотел обратить внимание – это то, что мы все время говорим и подразумеваем ситуацию, когда мы находимся в проекте разработки и у нас стабильная команда. Есть команда, которая профессиональна, и дружно работает. Но бывает так, что вам дают проект на сопровождение. Совершенно другая команда, в другой стране. Этих людей вы совершенно не знаете, и, конечно, есть проблемы с требованиями. Так как работ по разработке много, новых требований по системам делается мало, а сопровождение становится больше. Все это должно учитывать ряд особенностей.
Требования и изменения
Также здесь важен аспект тест-дизайна, так как если вы каждый раз в проекте, который вам дан на сопровождение, будете загадывать загадку: «Как мне протестировать то или иное изменение?», то потратите очень много времени и некоторые попытки могут быть совершенно неудачные. В то же время, работа по составлению тест-дизайна выполненная один раз до его изменения может вполне вам помочь.
И предпоследний аспект из общей части, которую мы сейчас закончим, является тестирование, управляемое данными:
А также:
Есть отдельно шаги тест-кейса и есть отдельно данные, которые подаются в тест-кейсе. Данные могут варьироваться, шаги тест-кейса стабильны, и мы тем самым можем проверить на большое количество ситуаций. Не говоря о той ситуации при тестировании, управляемое данными очень важно для случаев, когда у вас появляется эффект, зависящий от данных.
И еще один аспект, о котором я бы хотел упомянуть, гранулярность требований. Детали могут быть более или менее подробными. Но вот какие нюансы возникают, если требования подробные, то сложно поддерживать, но просто использовать. А если мало деталей, то сложно использовать, а поддерживать проще. Можно найти разумный компромисс: чек-листы и тестирование по требованиям, но он всегда будет содержать в себе риски, которые хорошо известны.
Перейдем ко второй части моего доклада.
Структура тест-кейса хорошо известна, она описана чуть ниже и ничего нового человечество не придумало
Что пишут про структуру тест-кейса
Тест-кейс включает:
— Формат;
— Контент;
Формат везде одинаков;
— Порядковый номер шага;
— Воздействие на систему;
— Ожидаемый результат;
И помните! Дьявол кроется в деталях!
Если мы проведем сравнение форматов, то мы увидим, что содержательно все у всех одинаково. Анализ и сравнение форматов:
Вот можно посмотреть один пример.
Обратите внимание на таблицу, у нас порядковый номер, действие, данные, которые мы вводим и ожидаемый результат. И что мы видим?
Во-первых, мы видим ожидаемый результат не там, потом видим не совсем корректное описание действия ( «если кнопка недоступна, то нажмите» — вопрос, должна ли быть кнопка доступна или нет?), цифры в ожидаемом результате – обозначаются некорректно (если трехзначное число, дробная часть и т.д.
Формально, все моменты включены, но по этим действиям мы не можем получить достоверную информацию о качестве продукта, так как возможно пропущены необходимые тесты.
Хорошо известно, что такое тестирование, управляемое данными. Но мы предлагаем его более детально. Расширение за счет данных делается несложно
Отделение шагов от данных
1. Раздельное описание со ссылками
2. Связь данных и ожидаемых результатов
Шаги
1. Действия для выполнения тест-кейса
2. Правила навигации
Данные
1. То, что пользователь вводит и/или выбирает и/или нажимает (поле, список, …)
2. Ожидаемые результаты
Структура тест-кейса (уточнение). Меняем формат:
И что мы получаем в результате таких изменений?
Все тут совершенно замечательно, кроме того, что тут написано «введите данные», к тому же частое использование терминов, таких как “any”, “correct”, “expected” и т.д.
Наше следующее предложение по структуре тест-кейса. Избавляемся от:
Обратите внимание, остается что-нибудь еще?
Да, это ссылка на внешний документ, к которому придется обратиться тестировщику для получения подтверждения корректного ожидаемого результата. Тут мы вспоминаем как называется доклад «Тест-дизайн: проще читать или проще писать»
Что я предлагаю?
Особое внимание я бы хотел обратить на подготовку данных. Понятно, что тест кейс может выполняться в любой ситуации. Система должна находиться в неком состоянии и это состояние должно быть заполненным. Бывают случаи, когда для того, чтобы подготовить данные нужно еще произвести какие-то действия, включающие несколько сотен шагов. Поэтому очень важно регистрировать данные, с которыми вы работаете. А еще лучше, если у вас есть возможность получить именно те данные, с которыми будет работать сам заказчик.
Данные:
1. Роли, значения
2. Ссылки на хранилище данных (запросы)
Подготовка данных:
1. Предусловия (состояние базы данных)
2. Выполнение SQL запросов
3. Действия в формате тест-кейсов
Предложенные решения являются разумным компромиссом сложности шагов и наборов данных. Иногда стоит написать два-три похожих тест-кейса, сократив на порядок объем наборов данных (за счет повторов). Все это позволит тестировщику не сбиться и пропустить что-то, а разработчику легче будет строить отображение кода скриптов на описание тест-кейса (необходимо при анализе и сопровождении скриптов).
Да, тест-дизайном мы осложняем их работу, но зато повышаем ее качество. Тест-дизайн самое сложное, что есть в тестирование. Не бывает двух похожих тест-дизайнов. В большинстве случаев, в моей практике, введение тест-дизайна на постоянной основе дает экономию трудозатрат тестирования ручного и автоматического тестировщика. И, конечно, это требует высокой квалификации тест-дизайнера. Можно взять тестировщика и даже разработчика и обучить, то может получиться хороший тест-дизайнер. Просто с улицы человека этому не обучить.
Слайды:
www.slideshare.net/VLDCORP/ss-33747358
Видео выступления:
План выступления
1.Тест-дизайн
2.Как проверять тестируемость требований
3.Требования и тестирование без тест-кейсов и/или без тестировщиков
4.Требования и изменения
5.Проще читать или проще писать
6.Как устроены тест-кейсы
7.Какие возникают трудности
8.Как их преодолевать
Начнем с того, что существует повышение общего интереса к автоматизации, это тренд и это хорошо! Но возрастает необходимость «фундамента» для разработки автоматизированных тестовых скриптов. Ведь если такого фундамента нет, то мы получаем сложность создания, использования и сопровождения скриптов. Не понятно, что они проверяют, не понятно, как они проверяют и не понятно, как они связаны с требованиями! Эта ситуация хорошо знакома тем, кто эти скрипты разрабатывает и тем, кто этими скриптами пользуется, а также тем, кто верит той информации, которая эти скрипты предоставляет.
Также следующий важный тезис — важность всего перечисленного вне контекста автоматизации тестирования. Замените все, что касается автоматического тестирования на ручное тестирование, и вы получите ровно тоже самое!
Итак, что же мы хотим?
Мы хотим упрощение и ускорение работы, а также повышение надежности результатов работы для:
— Тестировщика;
— Разработчика автоматизированных тестовых скриптов;
— Тест-менеджера, анализирующего результаты тестирования (ручного / автоматизированного)/ заказчик/будущие пользователи и т.д.
Мой доклад будет из двух неравных частей. В первой я напомню, что такое тест-дизайн, а во второй как обойти ошибки и пореже наступать на одни и те же «грабли».
Как проверять тестируемость требований
Мантры требований:
- Полнота
- Непротиворечивость
- Однозначность
- Трассируемость
- Осуществимость
- Тестируемость
- …
Каждые требования должны проверяться. Существуют основные критерии, на которые нужно ориентироваться. Человек может ошибаться при проверке требований. Поэтому нужно знать, как их надежно проверить! Обратите внимание, я не говорю, идеально проверить! Это невозможно! Хотя бы надежно проверить!
1 метод — Раннее проектирование тест-кейсов
То есть, как только вы начинаете использовать UML-диаграммы, story, несколько раз просмотренные, с замечаниями, начинается проектирование, то вы должны задавать вопросы: какое ограничение на это поля, а что будет после этого действия, а кто должен это сделать, а какой период по умолчанию. Благодаря этому достаточно легко обнаружить много пропусков на этапе проектирования тест-кейсов.
2 метод — Визуализация связи тест-кейсов и требований (где и как проверяется эта фича)
Потому что может оказаться, что вы написали 3000 тест-кейсов, все совершенно замечательно, но какие-то важные вещи мы просто не проверили. Причины разные: забыли, не поняли, подумали, что сделано «очевидным» для нас путем, что-то пропустили. Я указываю на это, не потому, что у меня есть универсальное решение, а потому, что так мы поступаем каждый день!
Следующий аспект, а зачем вообще нужно что-то, кроме требований?
Давайте сравним! Разница на первый взгляд очень простая, но по сути, она глубинная! Идея того, зачем нужно тестирование требований.
Требования vs. Тестирование
- Требования: определить, что и как должно работать
- Тестирование: определить, что не работает или работает не так, как должно работать
Соответствие программного продукта предъявляемым требованиям должна отвечать на следующие вопросы:
? Все ли требования реализованы?
? Все ли требования реализованы правильно?
? Нет ли лишнего?
? Адекватная ли диагностика?
«Зачем вы пишите 1000 кейсов, а не проще бы взять тестировщика, дать ему требования, чтобы он по ним тестировал?» Я как тест-менеджер сталкиваюсь с этим вопросом регулярно. И мне приходится все время по разному на него отвечать. Буквально недавно я отвечал на этот же вопрос: «Вот у меня серьезный сложный проект на год, в нем участвует только 2 тестировщика, которые сами тестировали требования и писали кейсы. В течение года тестировщики ушли и новые благодаря их тест-кейсам и проделанному анализу смогли перенять суть проекта и продолжить работу над ним».
Часто я слышу о том, что предлагают проводить тестирование, но без тест-кейсов и/или без тестировщиков.
Требования и тестирование без тест-кейсов и/или без тестировщиков
— Тестирование разработчиками – хорошо известны проблемы(субъекиновсть, незнание всего проекта, логика)
— Тестирование аналитиками – не нужны тест-кейсы? (интересная идея, но всегда тестируют положительны й сценарий). Проверяют лишь то, что работает как должно в требованиях, даже небольшие отклонения от корректного поведения не рассматривают. Проверяют линейный кейс, а связку требований, интеграционного тестирования не проводят)
Конечно же, в таких случаях качество и объем тестирования сильно разнятся, тестирование занимает только 20%-30% от всего возможного объема + пропускаются серьезные ошибки в требованиях.
Еще один важный аспект, на который я бы хотел обратить внимание – это то, что мы все время говорим и подразумеваем ситуацию, когда мы находимся в проекте разработки и у нас стабильная команда. Есть команда, которая профессиональна, и дружно работает. Но бывает так, что вам дают проект на сопровождение. Совершенно другая команда, в другой стране. Этих людей вы совершенно не знаете, и, конечно, есть проблемы с требованиями. Так как работ по разработке много, новых требований по системам делается мало, а сопровождение становится больше. Все это должно учитывать ряд особенностей.
Требования и изменения
- Обязательность изменений
- «Неожиданность» изменений
- Способы фиксации изменений
- Матрица связи требований и тест-кейсов (оценка трудозатрат на реализацию и тестирование изменений)
- Влияние изменений на приложение в целом
Также здесь важен аспект тест-дизайна, так как если вы каждый раз в проекте, который вам дан на сопровождение, будете загадывать загадку: «Как мне протестировать то или иное изменение?», то потратите очень много времени и некоторые попытки могут быть совершенно неудачные. В то же время, работа по составлению тест-дизайна выполненная один раз до его изменения может вполне вам помочь.
И предпоследний аспект из общей части, которую мы сейчас закончим, является тестирование, управляемое данными:
- Выводятся ожидаемые результаты в ответ на правильно вводимые данные
- Адекватная реакция на некорректные данные, в том числе и не зафиксированные в требованиях (соответствующие сообщения об ошибках)
А также:
- Классы эквивалентности
- Граничные значения
Есть отдельно шаги тест-кейса и есть отдельно данные, которые подаются в тест-кейсе. Данные могут варьироваться, шаги тест-кейса стабильны, и мы тем самым можем проверить на большое количество ситуаций. Не говоря о той ситуации при тестировании, управляемое данными очень важно для случаев, когда у вас появляется эффект, зависящий от данных.
И еще один аспект, о котором я бы хотел упомянуть, гранулярность требований. Детали могут быть более или менее подробными. Но вот какие нюансы возникают, если требования подробные, то сложно поддерживать, но просто использовать. А если мало деталей, то сложно использовать, а поддерживать проще. Можно найти разумный компромисс: чек-листы и тестирование по требованиям, но он всегда будет содержать в себе риски, которые хорошо известны.
Перейдем ко второй части моего доклада.
Структура тест-кейса хорошо известна, она описана чуть ниже и ничего нового человечество не придумало
Что пишут про структуру тест-кейса
Тест-кейс включает:
— Формат;
— Контент;
Формат везде одинаков;
— Порядковый номер шага;
— Воздействие на систему;
— Ожидаемый результат;
И помните! Дьявол кроется в деталях!
Если мы проведем сравнение форматов, то мы увидим, что содержательно все у всех одинаково. Анализ и сравнение форматов:
- Содержательно одинаковые:
- Можно еще поискать в книгах, Интернете…
- Адекватен ли контент формату?
Вот можно посмотреть один пример.
Обратите внимание на таблицу, у нас порядковый номер, действие, данные, которые мы вводим и ожидаемый результат. И что мы видим?
Во-первых, мы видим ожидаемый результат не там, потом видим не совсем корректное описание действия ( «если кнопка недоступна, то нажмите» — вопрос, должна ли быть кнопка доступна или нет?), цифры в ожидаемом результате – обозначаются некорректно (если трехзначное число, дробная часть и т.д.
Формально, все моменты включены, но по этим действиям мы не можем получить достоверную информацию о качестве продукта, так как возможно пропущены необходимые тесты.
Хорошо известно, что такое тестирование, управляемое данными. Но мы предлагаем его более детально. Расширение за счет данных делается несложно
Отделение шагов от данных
1. Раздельное описание со ссылками
2. Связь данных и ожидаемых результатов
Шаги
1. Действия для выполнения тест-кейса
2. Правила навигации
Данные
1. То, что пользователь вводит и/или выбирает и/или нажимает (поле, список, …)
2. Ожидаемые результаты
Структура тест-кейса (уточнение). Меняем формат:
- Порядковый номер шага
- Воздействие на систему
- Ссылка на данные (что за ссылка, которую необходимо)
- Ожидаемый результат (возможно, ссылка на данные и/или иллюстрация)
И что мы получаем в результате таких изменений?
Все тут совершенно замечательно, кроме того, что тут написано «введите данные», к тому же частое использование терминов, таких как “any”, “correct”, “expected” и т.д.
Наше следующее предложение по структуре тест-кейса. Избавляемся от:
- Циклов типа «Повторить шаги 5-73 для всех возможных данных»
- Конструкций типа «любой», «соответствующий». «подходящий», «ожидаемый» без необходимых уточнений, например:
Обратите внимание, остается что-нибудь еще?
Да, это ссылка на внешний документ, к которому придется обратиться тестировщику для получения подтверждения корректного ожидаемого результата. Тут мы вспоминаем как называется доклад «Тест-дизайн: проще читать или проще писать»
Что я предлагаю?
Особое внимание я бы хотел обратить на подготовку данных. Понятно, что тест кейс может выполняться в любой ситуации. Система должна находиться в неком состоянии и это состояние должно быть заполненным. Бывают случаи, когда для того, чтобы подготовить данные нужно еще произвести какие-то действия, включающие несколько сотен шагов. Поэтому очень важно регистрировать данные, с которыми вы работаете. А еще лучше, если у вас есть возможность получить именно те данные, с которыми будет работать сам заказчик.
Данные:
1. Роли, значения
2. Ссылки на хранилище данных (запросы)
Подготовка данных:
1. Предусловия (состояние базы данных)
2. Выполнение SQL запросов
3. Действия в формате тест-кейсов
Предложенные решения являются разумным компромиссом сложности шагов и наборов данных. Иногда стоит написать два-три похожих тест-кейса, сократив на порядок объем наборов данных (за счет повторов). Все это позволит тестировщику не сбиться и пропустить что-то, а разработчику легче будет строить отображение кода скриптов на описание тест-кейса (необходимо при анализе и сопровождении скриптов).
Да, тест-дизайном мы осложняем их работу, но зато повышаем ее качество. Тест-дизайн самое сложное, что есть в тестирование. Не бывает двух похожих тест-дизайнов. В большинстве случаев, в моей практике, введение тест-дизайна на постоянной основе дает экономию трудозатрат тестирования ручного и автоматического тестировщика. И, конечно, это требует высокой квалификации тест-дизайнера. Можно взять тестировщика и даже разработчика и обучить, то может получиться хороший тест-дизайнер. Просто с улицы человека этому не обучить.
