Search
Write a publication
Pull to refresh
1
0
Send message

Здравствуйте. Отвечаю на ваши вопросы:
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 с бесплатными тарифами на нескольких тестировщиков, в которых можно безболезненно выполнять основной функционал тестирования

А можно увидеть полный номер карты, привязанной к телефону. Если не ошибаюсь, это грубое нарушение 3-го требования PCI DSS
Уважаемый автор. Раз уж вас услышали, то прошу обратить внимание на следующий баг в Сбербанке:
1. Зайдите в личный кабинет с компьютера
2. Пройдите по пути Мои автоплатежи (Личное меню) > подключить автоплатеж > Перевод клиенту сбербанка
3. В поле Получатель введите, например, номер телефона друга у которого этот самый номер точно подключен к карте. Выберите карту списания и нажмите Продолжить
4. На этом этапе заполните поля как пожелаете и те, которые попросит форма > Подключить > Подтвердить по смс
5. После создания автоплатежа перейдите на Главную > Личное меню > зайдите только что созданный автоплатеж и нажмите Редактировать
6. Посмотрите на поле Получатель. Что вы видите?

Это я нашел еще в августе 19 года. Не претендую на то, что до меня его еще никто не находил. Обращался и в группу, и в техподдержку Сбера. В итоге идиот — я, у них все работает хорошо, а баг капец неприятный немного. Насобирать таким образом номера из соцсетей, фондов и прочего. А уж сколько звонков появится от «службы безопасности Сбербанка»

Information

Rating
Does not participate
Location
Россия
Registered
Activity