Комментарии 12
В какой программе рисовали диаграммы? Видел разные mindmap и ваш вариант один из самых симпатичных.
есть ряд вопросов:
— само собой интересен инструмент. Что за инструмент, возможен ли совместный доступ, как помечаются приоритеты кейсов, можно ли фильтровать кейсы по типам, например, для прогона регрессии или части сценариев?
— как Вы тестируете, только черным ящиком или серым тоже. Если и серым, то где фиксируете описание и связи компонент, относящиеся ко все фиче, а не отдельным use case
— используете ли систему управления тестами. Если да, то какую — интересно, как Вы помечаете прогоны тестов в древовидной структуре.
— и наконец, какой у Вас жизненный цикл разработки продуктов, в которых используется древовидная документация. Сколько времени длится релиз, какую часть из него занимает тестирование
все это необходимо для понимания, насколько Ваша практика применима
— само собой интересен инструмент. Что за инструмент, возможен ли совместный доступ, как помечаются приоритеты кейсов, можно ли фильтровать кейсы по типам, например, для прогона регрессии или части сценариев?
— как Вы тестируете, только черным ящиком или серым тоже. Если и серым, то где фиксируете описание и связи компонент, относящиеся ко все фиче, а не отдельным use case
— используете ли систему управления тестами. Если да, то какую — интересно, как Вы помечаете прогоны тестов в древовидной структуре.
— и наконец, какой у Вас жизненный цикл разработки продуктов, в которых используется древовидная документация. Сколько времени длится релиз, какую часть из него занимает тестирование
все это необходимо для понимания, насколько Ваша практика применима
Практика более чем применима. В своё время только столкнулся с тем, что на масштабных проектах быстрей всё это делать в табличном виде. Для деревьев использовал mindmeister, в котором есть групповой доступ. Помечать прогоны там не очень удобно ибо цикла после пятого просто начинает копиться свалка. В общем, будет специальный софт — будут и деревья.
Большое спасибо за Ваш комментарий! Приятно знать, что такой подход используется кем-то еще.
Могли бы Вы подробнее рассказать о ситуациях, в которых таблицы оказались быстрее и удобнее — и почему?
Заранее спасибо.
Могли бы Вы подробнее рассказать о ситуациях, в которых таблицы оказались быстрее и удобнее — и почему?
Заранее спасибо.
Оба варианта использовали в web разработке. Для +- небольших или типовых проектов дерево подходит очень хорошо. Вести тестирование и разработку ветками удобно за счет того, что по большому счету дерево делается один раз, а потом вносятся небольшие правки для нового проекта. Количество проходов получается не очень большое, т.к кол-во правок минимально за счет типовости решений. В случае с порталами и крупными сервисами нужно переделывать всё с нуля. Процесс получается трудоемким, контроль версии вести сложно. Без специального софта, которого собственно нет, делать это нецелесообразно. Основная проблема именно в фиксации проходов по версиям и записи новых багов. В этих случаях обычная таблица онлайн + репорты по прогонам работают куда лучше. В экселе также делается древовидная структура, но с учетом необходимого места под фиксацию багов. Документ заливается в гугл докс, который позволяет смотреть историю изменений.
Спасибо за Ваш комментарий! Постараюсь ответить на Ваши вопросы:
Мы используем плагины для Jira — Structure и Zephyr. Structure позволяет формировать вложенные списки, а Zephyr используем только в контексте отдельного вида тикетов с возможностью добавления в тикет таблицы с кейсами. Соответственно, есть возможность приоретизации и выставления тегов тестам. Structure умеет фильтровать кейсы по любым параметрам какие нужно и при этом не терять структуру дерева.
Повторюсь, Zephyr для нас — это только отдельный вид тикетов, остальные его возможности мы не используем. Тест сьюты формируем фильтрами или «на глаз» — во время прогона принимаем решение, стоит ли идти по данной ветке, и вообще каким будет обход дерева. Это сделано специально — при таком тестировании всегда есть элемент исследования, человек не должен отключать голову, бездумно гоняя описанные шаги, и эффект пестицида снижается.
Необходимости в жесткой отчетности по прогонам у нас нет — по итогам тестирования тестировщик пишет отчет для менеджера в свободной форме о том, что было сделано и какой результат. Это обосновано культурой управления в самой компании — такая информация будет для менеджмента полезнее, чем набор пройденных и не пройденных тестов в нашем тестовом наборе. Для своего удобства тестировщик при желании может менять статусы тикетов и ликовать баги к тестам, но никто, кроме него самого, смотреть на это не будет.
Касательно черного и серого ящиков — в описанном Вами смысле мы тестируем черным ящиком. Я упоминала это в предыдущей статье https://habrahabr.ru/company/touchinstinct/blog/329000/ — для оценки рисков используем отдельный документ, если есть необходимость их задокументировать.
Безусловно, мне стоит подумать, как вписать это в текущую структуру тестовой документации, спасибо.
Элемент серого ящика в нашем тестировании присутствует в том смысле, что мы всегда отслеживаем взаимодействие клиент-сервера через сниффер, и в тестах это взаимодействие мы так же прописываем — где какой запрос должен отправляться, какой ответ должен прийти, какие ошибки может вернуть сервер и как приложение должно на это отреагировать.
Разработка продуктов итеративная, по 1-2 недели спринт в зависимости от того, как часто заказчик хочет видеть промежуточный билд. В начале итерации, пока пишется код, мы пишем тесты. Тесты регулярно уточняются и рефакторятся, каждая правка тестов проходит ревью у лида или второго тестировщика на проекте. Чаще всего промежуточные билды в итерацию тестируются исследовательским методом, написанная документация служит лишь картой, и тестовая документация не обязана иметь финальный готовый вид. Когда реализована вся функциональность, перед релизом проводится финальный багфикс и регрессионное тестирование. Соответственно, к регрессионному тестированию вся документация должна быть полностью готова. Оценка на финальную итерацию и подход к регрессии каждый раз переопределяется и зависит от состояния проекта, приоритетов заказчика, дедлайна и многих других факторов.
Вроде все) Надеюсь, я смогла ответить на все, что Вас интересовало.
Мы используем плагины для Jira — Structure и Zephyr. Structure позволяет формировать вложенные списки, а Zephyr используем только в контексте отдельного вида тикетов с возможностью добавления в тикет таблицы с кейсами. Соответственно, есть возможность приоретизации и выставления тегов тестам. Structure умеет фильтровать кейсы по любым параметрам какие нужно и при этом не терять структуру дерева.
Повторюсь, Zephyr для нас — это только отдельный вид тикетов, остальные его возможности мы не используем. Тест сьюты формируем фильтрами или «на глаз» — во время прогона принимаем решение, стоит ли идти по данной ветке, и вообще каким будет обход дерева. Это сделано специально — при таком тестировании всегда есть элемент исследования, человек не должен отключать голову, бездумно гоняя описанные шаги, и эффект пестицида снижается.
Необходимости в жесткой отчетности по прогонам у нас нет — по итогам тестирования тестировщик пишет отчет для менеджера в свободной форме о том, что было сделано и какой результат. Это обосновано культурой управления в самой компании — такая информация будет для менеджмента полезнее, чем набор пройденных и не пройденных тестов в нашем тестовом наборе. Для своего удобства тестировщик при желании может менять статусы тикетов и ликовать баги к тестам, но никто, кроме него самого, смотреть на это не будет.
Касательно черного и серого ящиков — в описанном Вами смысле мы тестируем черным ящиком. Я упоминала это в предыдущей статье https://habrahabr.ru/company/touchinstinct/blog/329000/ — для оценки рисков используем отдельный документ, если есть необходимость их задокументировать.
Безусловно, мне стоит подумать, как вписать это в текущую структуру тестовой документации, спасибо.
Элемент серого ящика в нашем тестировании присутствует в том смысле, что мы всегда отслеживаем взаимодействие клиент-сервера через сниффер, и в тестах это взаимодействие мы так же прописываем — где какой запрос должен отправляться, какой ответ должен прийти, какие ошибки может вернуть сервер и как приложение должно на это отреагировать.
Разработка продуктов итеративная, по 1-2 недели спринт в зависимости от того, как часто заказчик хочет видеть промежуточный билд. В начале итерации, пока пишется код, мы пишем тесты. Тесты регулярно уточняются и рефакторятся, каждая правка тестов проходит ревью у лида или второго тестировщика на проекте. Чаще всего промежуточные билды в итерацию тестируются исследовательским методом, написанная документация служит лишь картой, и тестовая документация не обязана иметь финальный готовый вид. Когда реализована вся функциональность, перед релизом проводится финальный багфикс и регрессионное тестирование. Соответственно, к регрессионному тестированию вся документация должна быть полностью готова. Оценка на финальную итерацию и подход к регрессии каждый раз переопределяется и зависит от состояния проекта, приоритетов заказчика, дедлайна и многих других факторов.
Вроде все) Надеюсь, я смогла ответить на все, что Вас интересовало.
о да, более чем, спасибо!
Довольно платное решение, не каждому по карману, но действительно удобное — подробнее чек-листов и тем более чит-листов, легковеснее тест-кейсов, чтобы использовать в быстрой разработке, интегрированное с таскменеджером, да и прогоны можно прикрутить при желании, причем бесплатно.
Довольно платное решение, не каждому по карману, но действительно удобное — подробнее чек-листов и тем более чит-листов, легковеснее тест-кейсов, чтобы использовать в быстрой разработке, интегрированное с таскменеджером, да и прогоны можно прикрутить при желании, причем бесплатно.
Каково у Вас соотношение разработчиков и тестировщиков? Если делать тестовое покрытие достаточно хорошим, то может получиться, что на каждого разработчика понадобится по одному тестировщику.
Елена, вы читали книгу Коберна «Современные методы описания функциональных требований к системам»? Кажется, что там есть ответы на многие вопросы, которыми вы задавались в процессе создания инструментов.
Я вижу в этом тексте прямое противоречие. Вы уверены, что верно используете терминологию?
Было принято решение расширять чек-листы <...> Так мы пришли к написанию подробной юзер-стори <...> по факту являющей собой один громадный тест-кейс.
Я вижу в этом тексте прямое противоречие. Вы уверены, что верно используете терминологию?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестовая документация. Превращаем таблицы в деревья