elfische

Я дала ссылку на пример формы отчёта. Это некий усреднённый вариант, потому что негласно устанавливаются свои правила в каждой компании.
Термины в описании бага? Ну разве что начальные условия, окружение, версия, шаги воспроизведения, результат, ожидаемый результат и тд. и тп. в зависимости о проекта. Шаги воспроизведения чаще всего записываются одним из следующих вариантов или комбинацией или так, как предписывают негласные правила:
1. Зайти в Меню
2. Нажать "Открыть"

1. Лклик /File/
2. Лклик /Open/

1. Перейдите File/Open

1. Откройте меню File
//Появляется список подменю
2. Нажмите Open
//Открывается окно...

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

Не знаю, кому как, но меня пугает выражение "1. Методика тестирования приложения;". Скажу честно, так и не нашла словосочетаний "методика тестирования" и "методология тестирования" с разъяснениями относительно ПО. А вот "методы составления тестов2, например, уже куда более понятная вещь. Да даже "методы тестирования" намного проще найти. Почему-то мне кажется, что это и имеется в виду. Или план тестирования, но объяснять это я не возьмусь: тоже неоднозначный термин.

По поводу пункта с советую прочитать статью http://alexlobach.ru...ity-i-priority/
Примеры тест-кейса и описания бага можно посмотреть здесь http://www.protestin.../templates.html
Вместо

b. Обоснование некорректности описанного поведения;

принято (по крайней мере для меня это верно) писать текущий результат и ожидаемый резултат (такой, если бы всё выполнилось правильно).

Это не самые лучшие варианты, зато самые короткие, пожалуй.

И, наверняка, есть что-то, о чём я ещё не подумала.
Fruzenshtein и kitsune

Так ведь выходные параметры тоже важны. Понятно, что в результате должен быть список ссылок. Надо проверить, как они будут отображаться (наверняка, есть какие-то сокращения; в один/два столбца; страницы; сортировка). Возможные повторения результатов (почему-то такое иногда случается). Навигация по результатам (например, с помощью клавиш). Тут ещё что-то должно быть, но что-то не соображу что (давно такими поисками не пользовалась).

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


От себя про входные данные могу ещё добавить перечисление типов проверок.
1. Посмотреть, как обрабатывается введённый текст. Например:
по первому слову, остальное отбрасывается / по всем словам
по точному вхождению / со склонениям по падежам (т.е. по запросу "стогам" выведется только "стогам" или "стог" тоже).
обработка транслита намеренного и случайного и перевод (дерево, derevo, lthtdj, tree)
чувствительность к регистру
2. Посмотреть, как обрабатываются введённые символы
3. Всякие прочие проверки на ввод: длина введённой строки, ввод или вставка в поле поиска, вставка ссылок, комманд (это уже уклон в тестирование безопасности), проч.
4. Работа клавиш, горячие сочетания (важна работа кнопки Ввод, может быть, ещё таб).
5. Всё остальное, про что я не подумала.

иногда пишет, что для того, что бы изменения вступили в силу, необходимо перезагрузить компьютер. Нажимаю "OK", перезагрузки не происходит. Сообщение такое появляется иногда. Причину не могу понять.

А вот это точно баг, даже если непонято, почему то появляется, то не пояляется сообщение. Если просит, значит, должно перезагрузиться.

О перезагрузке во время процесса инсталляции: лично я ожидаю, что прога сделает roll-back изменений, комп перезагрузится. Или другой вариант: комп перезагружается, процесс инсталляции возобновляется с места, на котором она была прервана. Но то, что нельзя перезагрузить винду во время установки, я считаю, что это не нормально.

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

Я бы на своём месте завела это не как баг, а как предложение. Подождём рабочей недели, когда сюда набегут умные опытные люди, и скажут, что они думают по этому поводу.

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

Я имела ввиду, что только по количеству багов про программиста что-то сложно сказать. Как, впрочем, и про тестировщика. Зато можно отслеживать изменения в работе: багов стало подозрительно много или, наоборот, мало. Тогда следует подумать о том, что что-то произошло и понять к лучшему оно или нет.
Вот, например, у меня сейчас ресолвленных багов 9, а открытых 49 по одному из проектов. Это о чём-нибудь говорит? Зато если знать, что обычно ресолвленных багов 0, а открытых 41, то эти цифры уже что-то значат.
С другой стороны по другому проекту ресолвленных 0, а открытых 14. Как можно сравнить этот случай с предыдущим? Никак, кроме того, что цифры не совпадают.
Т.о. по количеству багов можно оценить программиста, только относительно себя самого, а не кого-то другого.

Давайте этот вопрос обсудим подробнее.

Итак у Вас есть заказчки - это министерство, естественно с ним Вы не контактируете. У нас также собственно.
В момент Х вы планируете приемочное тестирование, как я понял у вас есть чек-листы. Кто их составляет? На основании чего их составляют? Как Вы понимаете, что принимаемая вами функциональность работает правильно?

Чек-лист составляет сам тестировщик, потому что он уже специалист в своей области. В чек-лист входят столбцы: важность, функциональность, результат.

Важность. Помимо здравого смысла НЕОБХОДИМО опросить всех, кто может принимать эту работу и выяснить, что в первую очередь должно работать. Т.е. в вашем случае без мнения аналитиков никуда. Отмечается разноцветными звёздочками: красные -- супер важно, желтые -- важно, зелёные -- если не работает или работает частично, катастрофы не будет, но лучше, чтобы работало.

Функциональность. Так как система имеет сложные бизнес-процессы (бп), всё описать не получается. Будьте готовы чем-то пожертвовать. Как описывать функциональность, тут надо подумать.
Я для себя выбрала следующий способ. Описывается каждая сущность-существительное, и крупные действия для них; сущности-действия опускаются и остаются на моей совести. Например, Сначала указаны разделы. Для каждого из них своя табличка. Сущность "случай". Крупные действия для него -- создание, редактирование, удаление, взятие на учёт. Последнее в чистом виде относится к бп. Сущность "случай" содержит вкладки: сущности "осмотр", "исследования", "извещение", "выписки". Каждая из этих сущностей так же имеет подуровни. Начиная с этого уровня сущности-действия описываются только для бп: продвижение извещений и выписок по бп (направление на подтверждение, подтверждение, взятие на учёт). Важность у этих вкладок неодинаковая. Соответственно и важность действий тоже: отмена извещений и выписок не так важна, как их подтверждение, поэтому не включена в чек-лист.
При этом пункты расположены в приблизительном соответствии с проходом по бп.
Можно фиксировать сущности-действия: создание случая, создание осмотра, подтверждение выписки, взятие на учёт по подтверждению выписки. Для меня в таком виде есть опасность, что могу забыть какое-то действие, которое не зафиксировала из-за нерезиновости списка.
Можно фиксировать переходы по бп: взятие на учёт по подтверждению извещения, взятие на учёт по подтверждению выписки, запись на приём, снятие с учёта, составление отчётов. Этот подход хорош, если никому из читающих или проходящих по чек-листу не нужно объяснять, как совершить то или иное действие.
Также у нас было предложение фиксировать новую функциональность (любое изменение), но это не прижилось. Только когда появляются новые сущности, меняется чек-лист.

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

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

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