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

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

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

Поговорим о разновидностях багов. Недавно наткнулась на такую классификацию, была очень удивлена. Из перечисленных терминов ранее слышала только Гейзенбаг :) -Борбаг - стабильная ошибка, которую легко обнаружить. Воспроизводится по описанному кейсу -Гейзенбаг (или плавающий баг) - обнаружить проблематично, то появляется при воспроизведении по одному и тому же кейсу, то нет -Мандельбаг - ошибка с непредсказуемым поведением. Вот тут предлагаю пример: идём по одному и тому же кейсу (последовательность шагов), но в результате получаем разное поведение, я понимаю это так. Если у Вас другое мнение, жду в комментариях :) -Шрединбаг - опасная, критическая ошибка, которая никак не проявляет себя, однако внезапно возникает, если кто-то наткнётся на неё в исходном коде или попытается использовать программу в необычных условиях и осозна́ет, что система вообще не могла работать при наличии такой ошибки И термин, сегодня придуманный моим мужем (имеет место быть, может быть пойдёт в массы): -КвазарБаг - со стороны кажется одной ошибкой, но при детальном рассмотрении - это скопление множества ошибок. Бывает такое нашёл баг, начинаешь копать вокруг и находишь ещё несколько... Спасибо за прочтение поста! Если кто-то сталкивался с другими терминами по разновидностям багов, пишите в комментариях!