Комментарии 2
Я пришел не для того, чтобы ругаться.
Мне не нужны ссылки на другие источники. Я хочу уточнить, почему автор статьи так считает и пишет именно так. Я понимаю, что ответ на мой вопрос не обязателен. Вы свободный человек и вправе решать, давать ответ или нет.
Первый вопрос.
Про тест-кейс.
необходимые поля
Приоритет - smoke/sanity .
В чем разница smoke/sanity?
На примере калькулятора, как программа, а не физическое устройство.
1) Разработчик (условно) написал код и первый раз нажал "run" для проверки работоспособности приложения, версия 1.0. Для проверяющего это будет smoke/sanity?
2) Разработчик внес исправления (фиксы), версия 1.1 Для проверяющего это будет smoke/sanity?
3) Разработчик внес изменения (улучшения), версия 1.2. Для проверяющего это будет smoke/sanity?
Кто и как определяет smoke/sanity? Почему?
Второй вопрос.
Структура баг-репорта
Баг
гипо некоторым правилам.
Про Severity - есть, а Priority - нет
Почему priority нет? Забыли дописать? Не используете на практике? Считаете не надо использовать?
Упрощённое объяснение статусам Severity
Critical/High
Major/Medium
Minor/Low
Почему в Severity используется "High Medium Low"? Эта структура из опыта, которое используется в некоторых компаниях? Если да, то можно сделать сноску, что это в определенных компаниях так используется или теперь так означают и Severity Priority?
Еще в баг-репорт можно впихнуть окружение и версию стенда, а можно и комментарием оставить
Пост-шпаргалка. Давайте стараться давать лучшие практики.
Уточнение
Открываешь свою эксельку (боже, беги с этого проекта. Заводить баги и ТК в excel уже лютая дичь. 21 век на дворе
Дичь не дичь, но разные бывают компании и с разными задачами. Но это ваше мнение, я не говорю, что оно "неправильное".
Здравствуйте. Отвечаю на ваши вопросы:
1. В чем разница smoke/sanity?
Можно придерживаться распространенного мнения, что Smoke направлен вширь, а Sanity вглубь проекта. Под смоками вы проверяете работоспособность проекта, что навскидку ничего не было сломанного из действующего основного функционала, не углубляясь в тестирование. Sanity делает то же самое только глубже (например, вы проверили что кнопка нажимается, но при нажатии она открывает некую форму для заполнения. Smoke - вы проверили чисто кнопку. Sanity - вы проверили еще и заполняемость формы. Пример кривой, но для понимания)
2. Кто и как определяет smoke/sanity? Почему?
Это определяется самим тестировщиком на основе собранной информации о новом функционале. Вы понимаете что будет задето и что было изменено. Сначала вы проверяете новую функцию (например, на дев стенде). Делаете Smoke, чтобы понять: работает ли функция? Выполняет ли свой основной функционал? Потом берете в тестирование. После проверки функционал сливается на стейджинг. Вы проверяете там: не сломал ли он еще что попутно из уже рабочего кода? Не задел ли еще чего? Затем идет слитие прод. Там можно пройтись по UAT-тестам. Пишутся тоже тестировщиками на основе полученных ранее данных
3. Почему priority нет? Забыли дописать? Не используете на практике? Считаете не надо использовать?
Его надо использовать и он само собой используется на практике. И мое имхо: тестировщик должен уметь расставлять приоритеты. Приоритет - это инструмент менеджеров, потому на практике это решают за тестирование. Он показывает как быстро дефект должен быть исправлен. Но если менеджер/бизнес решит, что это сейчас не приоритет, то, увы, не докажешь
4. Почему в Severity используется "High Medium Low"? Эта структура из опыта, которое используется в некоторых компаниях? Если да, то можно сделать сноску, что это в определенных компаниях так используется или теперь так означают и Severity Priority?
Вообще, вы можете встретить подобное обозначение в некоторых TMS. Поэтому перечисление было написано через слэш. Перечислять не было смысла, т.к. сегодня они в той TMS есть, завтра уже все поменяли. Кстати, при хороших инструментах администрирования в TMS, вы сможете сами поменять на тот статус, который удобен
5. Пост-шпаргалка. Давайте стараться давать лучшие практики
Учту) Но пост-шпаргалка "С чего начать", а про "окружение и версию стенда" - это просто совет
6. Дичь не дичь, но разные бывают компании и с разными задачами.
О, я прекрасно это понимаю) И все же есть множество TMS с бесплатными тарифами на нескольких тестировщиков, в которых можно безболезненно выполнять основной функционал тестирования
Очередная шпаргалка по тестированию. А как начинать-то?