Стиль написания тест-кейсов

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

1. Как убедить тест-лида и остальных, что тесты нужно писать правильно?
Под "правильным" я понимаю тест-степ как:
Описание шага: Link A to B. Ожидаемый рез-т: A is child of B.
А вот как его видят некоторые члены команды:
Описание шага: Make A a child of B by draging a link from child to parent. Confirm that A is linked to B. Ожидаемый рез-т: Confirm that A is linked to B.
Да-да, все примерно так и выглядит, я серьезно.

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

1. Как убедить тест-лида и остальных, что тесты нужно писать правильно?

Я из примера не поняла что такое "правильно" и "не правильно", видимо и забугорное начальство поэтому не понимает.

Объясните на пальцах, в чём разница между вариантами и ПОЧЕМУ ОНА ВАЖНА.

Если разница правда существенная, убедив меня, Вам не составит труда убедить кого-то ещё :)

Могу из своего опыта сказать.
Очень неудобно - когда все пишут по-разному.
Сталкивалась с тем, что один и тот же элемент графического интерфейса назывался:
"слайдер", "ползунок", и даже!! "потенциометр"!!!!

Что делать?
Естественно, пытаться как-то унифицировать изложение.
Схожая проблема (писать про одно и тоже разными словами, используя разные обороты/выражения ) есть у тех. писателей.
У них можно найти рекомендации (ну.. там не будет именно про тесты, а про ТЗ, РЭ и иже с ним.., но кой-какие идеи можно почерпнуть).
Есть у технических писателей проект стандарта - "Стиль изложения документации пользователя программного средства".
Там можно найти полезное.

А вам самому зачем это надо-то? Если "каждый пишет по-своему, при этом всем все понятно", то может и не надо ничего менять?
А если сможете определить, какие проблемы это создаёт, то вот вам и аргументы, чтобы повлиять на остальных :)
Лаконичность - это хорошо, позволяет сократить время на "писанину", но при этом есть риск увеличения времени на вникание в суть написаного другим человеком, или даже тем же самым человеком по прошествии некоторого времени. Если описывать тесты слишком подробно, то такие тесты всем понятны, но само их написание трудозатратно. Нужно искать золотую середину, при которой будет комфортно и удобно работать ВСЕМ участникам проекта, а не насаждать правила силой, "потому что так правильно и красиво".

Описание шага: Make A a child of B by draging a link from child to parent. Confirm that A is linked to B. Ожидаемый рез-т: Confirm that A is linked to B.

Я вот не понял зачем два раза повторять предложение «Confirm...»?! Ведь это уже относится к ожидаемому результату? Это идёт не действие шага, а подтверждение правильного результата выше пройденного шага.

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

1. Как убедить тест-лида и остальных, что тесты нужно писать правильно?
Под "правильным" я понимаю тест-степ как:
Описание шага: Link A to B. Ожидаемый рез-т: A is child of B.
А вот как его видят некоторые члены команды:
Описание шага: Make A a child of B by draging a link from child to parent. Confirm that A is linked to B. Ожидаемый рез-т: Confirm that A is linked to B.
Да-да, все примерно так и выглядит, я серьезно.

Второй вариант кажется более лаконичным и понятным, т.к. я пока не знаю сколько способов существует, чтобы сделать A is child of B.

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

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

Описание шага: Link A to B. Ожидаемый рез-т: A is child of B.
А вот как его видят некоторые члены команды:
Описание шага: Make A a child of B by draging a link from child to parent. Confirm that A is linked to B. Ожидаемый рез-т: Confirm that A is linked to B.

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

Как убедить тест-лида и остальных, что тесты нужно писать правильно?

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

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

Я из примера не поняла что такое "правильно" и "не правильно", видимо и забугорное начальство поэтому не понимает.
Объясните на пальцах, в чём разница между вариантами и ПОЧЕМУ ОНА ВАЖНА.

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

Схожая проблема (писать про одно и тоже разными словами, используя разные обороты/выражения ) есть у тех. писателей.
У них можно найти рекомендации

Спасибо

Второй вариант кажется более лаконичным и понятным, т.к. я пока не знаю сколько способов существует, чтобы сделать A is child of B.

В том-то и дело, что способ только один. Это все равно что сказать "Наберите в поле password свой пароль путем нажатия клавиш на квалиатуре" вместо "Введите пароль в поле password". Как в 5 шагов описывать рисование прямой линии в пейнте.

Если всем все понятно, то смысл что-то менять?

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


Поотвечал на ваши вопрсы, и намного лучше понял, что и как объяснять.

Кому от этого польза? На английском информации полно, стоит только поискать.

Тоже так думал, но найти не получилось. Нашел только информацию общего характера.

Вот кстати недавно пытался сделать тест-кейс:

Step 3
Description:			Open properties of Check Box.
				Mark the "Checked" check box and click the "Apply" button.

Expected Result: 		Verify that Check Box is marked.

Step 4
Description:			Mark the "Protected" check box and click the "Apply" button.
				
Expected Result: 		Verify that Check Box is disabled.

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

А не существует какого-то одного правила для создания и оформления тест-кейсов? У каждой конторы свой "стиль" или отсутствует вовсе, да?

Раз зашел вопрос о понимании английских текстов,
то может быть окажется полезным:
«Искусство и практика перевода.
Иное видение при переводе технических текстов с русского языка на английский. Диверсификация приемов перевода. Таблица и примеры», ИД Петрополис. ISBN 978-5-9676-0259-7 © Ярцев Ю.А. 2010

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

( мой одноклассник. Сама читала выдержки. В общем -- мне понравилось. Поскольку такой прагматичный технарский подход.)

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

1. Как убедить тест-лида и остальных, что тесты нужно писать правильно?
Под "правильным" я понимаю тест-степ как:
Описание шага: Link A to B. Ожидаемый рез-т: A is child of B.
А вот как его видят некоторые члены команды:
Описание шага: Make A a child of B by draging a link from child to parent. Confirm that A is linked to B. Ожидаемый рез-т: Confirm that A is linked to B.
Да-да, все примерно так и выглядит, я серьезно.

Второй вариант кажется более лаконичным и понятным, т.к. я пока не знаю сколько способов существует, чтобы сделать A is child of B.

Все зависит от "угла зрения". Т.е. зачем писать эти тест кейсы. На мой взгляд первый вариант лучше. Почему? Потому, что он говорит только то, ЧТО надо сделать и получить, не предписывая КАК это сделать. Второй вариант - частный случай первого. Если представить, что у нас есть 3 разных способа для того, чтобы сделать А чайлдом В, то по второму описанию надо будет написать 3 тесткейса и менять, если что-то поменяется. При первом описании, можно добавить лишь фразу: do it using drag-and-drop, keyboard shorcut and pop-up menu item. И 100% гарантирую, если будет только второе описание, тогда как есть другие варианты (не драг-н-дроп), то эти другие варианты проверены не будут ибо не описано. При первом варианте придется пошевелить мозгами и найти как сделать А чайлдом В и если будут делать разные люди, то больше вероятность, что будут делать по-разному.

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

PS: кстати, во втором случае, ожидаемый результат в приведенном примере не корректен. А и В могут быть залинкованы каким либо образом, но А не будет чайлдом Б.

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

Под "правильным" я понимаю тест-степ как:
Описание шага: Link A to B. Ожидаемый рез-т: A is child of B.

ЕСЛИ исходить из того, что все участники понимают, что такое "Link A to B", текучки у вас нет, образовательных функций тесты не преследуют, а делать это можно только одним единственным способом (by dragging a link), всем понятно как проверить что A это child B, то кроме пропущенного в ожидаемом рез-те артикля я не вижу проблем с этим тестом.

А вот как его видят некоторые члены команды:
Описание шага: Make A a child of B by draging a link from child to parent. Confirm that A is linked to B. Ожидаемый рез-т: Confirm that A is linked to B.

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

НО
Возникает важный вопрос.
Насколько критичны эти отличия?
Правда ли может быть хоть один адекватный человек с IQ не ниже среднестатистического, который это не поймёт? Сомнительно...

Я так понимаю, Вы - тест-менеджер.
У Вас есть какие-то задачи, и их явно много.

На каждую из них Вы тратите своё рабочее время, которое априори ограничено. Вы НЕ можете сделать ВСЁ СРАЗУ, и непрерывно приоритезируете собственные задачи исходя из того, насколько они важны для Вашего проекта.

Скажите честно, за счёт чего эта задача в данный момент приоритетнее других? Ведь если Вы уделяете ей внимание, значит Вы не уделяете его в это время другим задачам.

У Вас настолько идеальный процесс, что Вы можете придираться к малозначимым, не влияющим на результат отличиям в формулировках - или дело не в отличиях, а в "Хочу чтоб всё было по-моему"?

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

А не существует какого-то одного правила для создания и оформления тест-кейсов? У каждой конторы свой "стиль" или отсутствует вовсе, да?

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

К вопросу о лаконичном описании тест-кейсов. Уже несколько лет пользуюсь системой сокращений, для ускорения написания и повышения читаемости тест-кейсов. Про нее можно почитать, например, здесь: Синтаксис описания дефектов

К вопросу о лаконичном описании тест-кейсов. Уже несколько лет пользуюсь системой сокращений, для ускорения написания и повышения читаемости тест-кейсов. Про нее можно почитать, например, здесь: Синтаксис описания дефектов

спасибо за ссылочку, интересно. :)

Все зависит от "угла зрения". Т.е. зачем писать эти тест кейсы. На мой взгляд первый вариант лучше. Почему? Потому, что он говорит только то, ЧТО надо сделать и получить, не предписывая КАК это сделать. Второй вариант - частный случай первого.

LeshaL,
На мой вкус - четко.

(пока таймаут - полезла в проект ГОСТ- а. Ага, это такая моя особенность, несколько занудная, да.)
1. То, о чем пишет Алексей, присутствует и в ГОСТе.

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

2. А вот эти принципы описания, на мой вкус, могут быть адаптированы под написание тест-кейса.

5.5.2.2.
"Описание многошагового действия, или процедуры, состоит из титульной фразы и перечисления шагов процедуры.
Титульная фраза в обязательном порядке содержит явное указание на цель, для которой пользователь выполняет данную процедуру. Каждый шаг процедуры описывается в отдельном абзаце.Абзацы, соответствующие шагам процедуры, в порядке следования нумеруются арабскими цифрами.
Описание шага процедуры в обязательном порядке включает в себя следующие сведения:
– конкретные действия в пользовательском интерфейсе программного средства, предпринимаемые пользователем на данном шаге и описываемые с максимальной степенью детальности, предусмотренной в данной документации (см. раздел 7 «Правила детального
изложения»);
– результат этих действий — как он отражается в пользовательском интерфейсе программного средства и как он сказывается на процессах ввода/вывода, передачи и обработки данных."

Посмотри этот топик - http://software-test...rum/topic/8436/
В нем топик стартер дает линки на 4 ресурса, посвященных улучшению написания тест кейсов :)
Может и вам поможет и к авторитетным(если там таковые, т.к. сама не просмотрела) источникам западные коллеги прислушаются...


Ой.. я попробовала их открыть - ссылки мертвые(
Можно по названиям по гуглить, если интересно :-)