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

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

Я уже надеялся, что какой-то маньяк линксом читает :)
Оказалось просто фф без изображений

Старясь короче описать проблему, и упустил некоторые моменты.

Дело не только в том, что человек пишет длинно. Время от времени проскакивают более неприятные вещи.
Например, он написал "Make B child of A". Но дело в том, что это действие можно понять и как "Link B to A", и как "Relink C-to-B into A-to-B" - два разных действия.
Или использовал несуществующий объекта.
Или назвал объект с большой и с маленькой буквы в разных местах. Для программы это - совершенно разные имена.

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

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

Можно на клаве набрать, можно на экранной, можно Ctrl+V
Из-за упускания таких мелочей в описании у разработчиков частенько баги не воспроизводятся.
Тоже согласен. Но как раз в этом случае действительно нет другого способа сделать "Link B to A"

Посмотри этот топик - http://software-test...rum/topic/8436/
Спасибо!

hcnik, а есть у вас такая процедура как review?
Есть. Из-за нее я и задал этот вопрос. Только стандартов все равно не было. И получалось, что человек соглашался исправлять только то, что невозможно понять.
Что собственно получилось. Я просто написал вопиющие примеры того, как есть, с одной стороны, и как сделал бы я - с другой. Выслал его QA Lead'у, прописал буквально 3 предлагаемых стандарта, чтоб хоть часть из этого не возникала. После чего у нас был митинг, и большую часть этого приняли. К счастью. Пришлось только постараться, чтоб человек, которого я ревьюил, не обиделся, потому что большинство примеров были взяты у него.
Но, что главное, - лид согласился таки завести доку со стандартами для нас не только на эти тесты, но как стиль написания вообще. И для тест кейсов, и для создаваемых нами багов.

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

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

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

Спасибо

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

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

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

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


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

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

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

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

Прислушайтесь к себе, воспользуйтесь советом по ссылке. Очень правильный :) Если чувствуете, что что-то не так, что не нравится - не идите. У меня такое чувство после каждого собеседования есть.
Вообще лучше пойти туда, чем не пойти никуда. Это - ценный на раннем этапе практический опыт и какая-никакая строчка в резюме. К тому же лично мне очень импонирует совершенно свободный график посещения.
Я бы на вашем месте отдал предпочтение работе со старшими коллегами-тестировщиками, но такой вариант не вегда есть.