Почему лучше сначала описывать фактический результат (ФР) и только потом ожидаемый (ОР)? Если сначала указывать ожидаемый результат, а не фактический читающего будет сильно сбивать с толку. Бывают случаи, что разработчик прочитав сначала ожидаемый, подумает: так это же не проблема, так и должно работать и не дочитав до фактического результата, переведёт ошибку в статус “Решена”. Поэтому я рекомендую ВСЕГДА писать сначала фактический результат! Конечно, в разных компаниях по-разному, но в большинстве пишут сначала ФР, потом ОР. Если в какой-то компании это не так, то нужно будет подстроиться и писать как принято в этой компании Недавно наткнулась на одном форуме откуда появилась традиция сначала указывать ожидаемый результат: 1. Копипаста из тест-кейса: последовательность шагов и положительный результат 2. Психология разработчиков :) говорят, что разработчики обычно читают с конца))) Спасибо за прочтение поста)) Как принято у вас в компании? сначала указываете фактический результат или ожидаемый? Или может быть вообще не указываете ни ОР, ни ФР. Или если в компании, в которой Вы работаете, принято сначала указывать ОР, напишите, пожалуйста, в комментариях почему? :)
Мы уже поговорили о критичности и разновидностях багов, сегодня поговорим о видах бага на примере mail.ru (мобильное приложение/сайт) -Визуальный. Относится к интерфейсу приложения. Кнопка [Отправить письмо] "уехала" за пределы видимости -Функциональный. Не отправляется письмо: пользователь нажимает кнопку [Отправить письмо], но ничего не происходит. Или другой пример - файл не прикрепляется к письму -UX-баг, который влияет на удобство. Например, чтобы прикрепить файл, пользователю приходится несколько раз покидать форму отправки письма и возвращаться обратно или кнопка для прикрепления файла расположена неудобно, её сложно найти -Баг нагрузки. Сайт mail.ru должен выдерживать большой наплыв посетителей, например, 31 декабря, когда все рассылают поздравления родственникам и друзьям с вложенными "открытками"-картинками, поэтому важно проводить нагрузочное тестирование. Например, искусственно создаётся ситуация, когда в один раздел одновременно зашло несколько тысяч пользователей. Если приложение не загружается или зависает - это баг нагрузки. О видах тестирования, в том числе о нагрузочном тестировании обязательно поговорим в будущих постах -Баг производительности. Мобильное приложение mail.ru занимает в памяти смартфона слишком много места, работает медленно и быстро тратит заряд батареи -Баг требований. До начала разработки приложения или отдельной «фичи» (кусок функционала) в требованиях что-то не учли. Например, забыли добавить оповещение, что нельзя прикрепить файл формата .bmp. Приложение может работать с ошибками после прикрепления файла указанного формата или не отправится письмо с таким вложением. Разработчик написал код так, как было в требованиях (или как он их понял). В итоге, сайт или приложение вроде бы работает, как описано в требованиях, но не так, как хотел заказчик Спасибо за прочтение поста! Буду благодарна за подписку, лайки, комментарии :)
Почему нужно постараться сократить число шагов? При описании последовательности шагов, которая приводит к ошибке, также лучше придерживаться золотой середины, как и во всём :) Перед тем как оформить баг, необходимо убедиться, что в описании шагов нет лишних или ненужных шагов воспроизведения, которые будут отвлекать и тратить время команды. Приведу пример: На первом месте работы я как-то очень долго пыталась воспроизвести “плавающий” (гейзенбаг) и в итоге у меня получилось 11 шагов в описании. У разработчика по моему описанию баг не воспроизвелся, мы вместе с ведущим тестировщиком подошли к нему и я воспроизвела этот баг на его компьютере. Ведущий тестировщик посмотрела, воспроизвела у себя и сократила до 3-х шагов)))) P.S всегда нужно стараться сократить количество шагов при возможности Пример плохой последовательности шагов для воспроизведения: 1. Перейти на сайт 2. Зайти на страницу обратной связи 3. Кликнуть курсором в поле "Имя" 4. Ввести имя 5. Кликнуть курсором в поле e-mail 6. Ввести действующий e-mail 7. Навести курсор на кнопку [Отправить сообщение] 8. Кликнуть по кнопке [Отправить сообщение] Указанную последовательность шагов можно и нужно сократить до двух шагов! Пример хорошей последовательности шагов: 1. Заполнить поля формы обратной связи на сайте 2. Нажать на копку [Отправить сообщение]
Поговорим о разновидностях багов. Недавно наткнулась на такую классификацию, была очень удивлена. Из перечисленных терминов ранее слышала только Гейзенбаг :) -Борбаг - стабильная ошибка, которую легко обнаружить. Воспроизводится по описанному кейсу -Гейзенбаг (или плавающий баг) - обнаружить проблематично, то появляется при воспроизведении по одному и тому же кейсу, то нет -Мандельбаг - ошибка с непредсказуемым поведением. Вот тут предлагаю пример: идём по одному и тому же кейсу (последовательность шагов), но в результате получаем разное поведение, я понимаю это так. Если у Вас другое мнение, жду в комментариях :) -Шрединбаг - опасная, критическая ошибка, которая никак не проявляет себя, однако внезапно возникает, если кто-то наткнётся на неё в исходном коде или попытается использовать программу в необычных условиях и осозна́ет, что система вообще не могла работать при наличии такой ошибки И термин, сегодня придуманный моим мужем (имеет место быть, может быть пойдёт в массы): -КвазарБаг - со стороны кажется одной ошибкой, но при детальном рассмотрении - это скопление множества ошибок. Бывает такое нашёл баг, начинаешь копать вокруг и находишь ещё несколько... Спасибо за прочтение поста! Если кто-то сталкивался с другими терминами по разновидностям багов, пишите в комментариях!
Почему необходимо всегда описывать ожидаемый результат? В разных источниках часто встречается такая фраза: Что очевидно для Вас, совсем не очевидно для разработчика, другого тестировщика, который будет проверять исправление бага по Вашему описанию, РМ… Представим ситуацию, тестировщик описал проблему и пишет Результат: 97 И нет ожидаемого результата… Разработчик: ок и меняет на 98 Тестировщик отправляет в повтор без комментария Разработчик: ок и меняет на 9.7 Тестировщик отправляет в повтор Разработчик меняет на букву Тестировщик отправляет в повтор…. Разработчик до этого был терпелив, но терпение иссякло и пишет горе-тестировщику в личку: да, как надо-то было?! Тестер: написано в спецификации/ТЗ/в описании задачи и т.д. Разраб: и что там написано?! Нельзя что ли в описании бага было написать?! Я должен время своё тратить и перечитывать уйму текста? Да, я привела вымышленную и сильно утрированную ситуацию, но такое бывает. Поверьте, подобные тестировщики не на хорошем счету у разработчиков и не пользуются авторитетом… обычно прилетающий баг от подобных “специалистов по тестированию” заранее вызывает раздражение у разработчиков, потому что даже не посмотрев описание им сразу понятно, что придется потратить много времени на выяснения и только потом приступить к исправлению ошибки Особенно раздражает поверье среди тестировщиков, что если разраб делал всё по спеке, то ему обязательно должно быть известно, что ожидается в результате. Поверьте через 2-3 месяца Вы и сами не особо вспомните, что было написано в спецификации :) да и разработчик мог совсем не придерживаться того, что написано в спеке. Или разработчику надо перелопатить всю спецификацию, чтобы найти нужное место? Поэтому в описании бага, совсем не лишним будет: -ссылка на спецификацию -цитата из спецификации -скрин с выделенным текстом из спецификации Не забывайте указывать ожидаемый результат! Даже если он и так очевиден, в духе: "описанная ошибка не появляется", но вполне может быть, что вместо появления ошибки ожидается: открытие какой-то формы или запуск отчета и т.д. да, всё что угодно! Спасибо за прочтение поста! :)
