Братство тестеров на страже качества ПО

Любимая цитата о тестировании Мне особенно нравится сравнение тестирования с маяком, поскольку свет маяков помогает лодкам обойти скалы точно так же, как разумное тестирование не допускает попадания проектов на мель (с) Рекс Блэк. Ключевые процессы тестирования

Почему лучше сначала описывать фактический результат (ФР) и только потом ожидаемый (ОР)? Если сначала указывать ожидаемый результат, а не фактический читающего будет сильно сбивать с толку. Бывают случаи, что разработчик прочитав сначала ожидаемый, подумает: так это же не проблема, так и должно работать и не дочитав до фактического результата, переведёт ошибку в статус “Решена”. Поэтому я рекомендую ВСЕГДА писать сначала фактический результат! Конечно, в разных компаниях по-разному, но в большинстве пишут сначала ФР, потом ОР. Если в какой-то компании это не так, то нужно будет подстроиться и писать как принято в этой компании Недавно наткнулась на одном форуме откуда появилась традиция сначала указывать ожидаемый результат: 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 месяца Вы и сами не особо вспомните, что было написано в спецификации :) да и разработчик мог совсем не придерживаться того, что написано в спеке. Или разработчику надо перелопатить всю спецификацию, чтобы найти нужное место? Поэтому в описании бага, совсем не лишним будет: -ссылка на спецификацию -цитата из спецификации -скрин с выделенным текстом из спецификации Не забывайте указывать ожидаемый результат! Даже если он и так очевиден, в духе: "описанная ошибка не появляется", но вполне может быть, что вместо появления ошибки ожидается: открытие какой-то формы или запуск отчета и т.д. да, всё что угодно! Спасибо за прочтение поста! :)

Почему я считаю, что лучше избегать использования гифок или видео при оформлении баг-репорта? Не всегда из видео/гифки понятна суть проблемы, к примеру, если на видео действия записаны очень быстро, не все клики заметны, некачественное видео и т.д. Лично меня часто сбивает с толку, что гифка циклична, иногда по запарке сложно понять, где начало, где закончилось и в чём вообще проблема? Под использованием гифок или видео я имею в виду, что в баг-репорте кроме гифки и заголовка нет подробного описания по шагам или результата и уж тем более ожидаемого! Приведу пример: время час ночи, выдача релиза, нужно проверить/закрыть пофикшенные (исправленные) баги, которые заводила не я. А там большая часть видео и гифки и в описании почти ничего. Сидела с красными глазами, ничего непонятно! Очень сильно раздражало! Лучше всего гифки или видео использовать как дополнение к текстовому описанию, когда это необходимо и никак не обойтись без приложенной гифки. Например, если очень много шагов в описании, которые невозможно сократить и разработчику будет проще посмотреть видео. Зачастую тестировщики ленятся или в силу отсутствия времени записывают видео, ведь это проще, чем потратить какое-то время, чтобы описать суть проблемы текстом. При отсутствии времени, запись видео поддерживаю, но ведь всегда можно вернуться к баг-репорту и поправить его, когда время появится. Уважайте своих коллег :) старайтесь найти золотую середину при использовании гифок или видео НО! Как говорил мой знакомый тестировщик со стажем: “Только текст, только хардкор!” :) грамотно описывать текстом суть проблемы - это искусство! и отличный навык для хорошего тестировщика #тестированиеПО #багрепорт

Джедайские техники :) Шутка-минутка. Муж недавно спросил об этой книжке Максима Дорофеева О, там что-то про Звездные войны? Я: канешн) именно об этом Он: а ты предыдущие книги читала? «Тестировщик наносит ответный удар» «Месть разработчика» «Новая надежда РМ» Про аналитика мы не смогли придумать) кроме как, «Скрытые требования». Пишите в комментариях свои идеи :) P.S мой муж знает о чем примерно книга “Джедайские техники» P.P.S никого обидеть не хотела #тестированиеПО

Помнишь легенду о черном тестировщике? На черном-черном Татуине, в одной белой-белой (конечно же) конторе работал черный-черный тестировщик Люк Скайтестер. И был у черного-черного тестировщика черный-черный ящик, в который он заколачивал ленивых-ленивых программистов, не желавших исправлять черные-черные баги. Как-то раз, за особые заслуги, отправили черного-черного тестировщика на одну черную-черную звезду, где повстречался ему черный-черный тимлид и заявил: "Люк, я твой отец!" Ну а дальше, как известно, в один черный-черный день Люк нашел критичный баг аж в самом ядре системы: бух-бах и черную-черную звезду пришлось переделывать заново. А ведь могли начать тестирование заранее, а не после релиза! (с) с просторов интернета #тестированиеПО

Тестер помни: багрепорт «ничего не работает!» оскорбляет чувства программирующих (с) с просторов интернета Еще одна классная цитата! Сейчас у меня в статусе в скайпе

Примеры плохого баг-репорта и хорошего Плохой: Заголовок: “Сломалась авторизация” вот и всё описание без шагов, без результата и уж тем более без ожидаемого результата! Пожалуйста, не делайте так! Хороший баг-репорт: Окружение: Win10 x64, Google Chrome 100.0.4896.60 Версия системы: 10.199.23.456 Заголовок: Ошибка 404 на форме авторизации при попытке входа новым пользователем Предусловия: -в систему добавлен новый пользователь -открыта форма авторизации Шаги воспроизведения: 1. Ввести логин и пароль нового пользователя 2. Нажать Enter Результат: появляется ошибка 404 Ожидаемый результат: авторизация выполнена, ошибок не возникает Примечания: -воспроизводится только для нового пользователя, которым авторизация ещё не осуществлялась -воспроизводится только при нажатии клавиши Enter, при нажатии на кнопку [Ок] не воспроизводится Вложения (аттач): скрин ошибки, лог #тестированиеПО #багрепорт

Нажми на кнопку, получишь результат И твоя мечта осуществится! Нажми на кнопку, но что же ты не рад? Потому что БАГ, БАГ, БАГ! Когда-то очень давно было статусом у меня в "аське", лично придумала))) на тот момент работала в компании, для которой подобное описание очень подходило. Баги чуть ли не от каждого клика мышкой возникали #тестированиеПО #баг #картинкиотестировании