Сегодня отмечаем День Тестировщика

Тестировщик — важный специалист в веб-студии. Он тестирует сайты и приложения, находит ошибки, отправляет на доработку исполнителям, после поправки снова проверяет, еще раз тестирует и в итоге доводит проекты до совершенства. 

Сегодня расскажем о том, как наш тестировщик Оксана ловит баги (ошибки в коде или в работе программы), которые возникают из-за чего угодно: начиная от опечатки разработчика/дизайнера/верстальщика, заканчивая мухой, сдохшей в сервере:)

Итак, самые распространенные причины багов:

• опечатался дизайнер или не учел специфику платформы, на которой будет разрабатываться продукт;
• верстальщик не учел размер экрана некоторых пользователей и и какой-то элемент не помещается на экран старого (маленького) смартфона;
• подключаемые модули/виджеты не настолько гибкие, как хотелось бы, и их невозможно вписать в дизайн или структуру сайта. Это может быть виджет чата или модуль транспортной компании. Они не всегда адаптированы под все устройства и часто невозможно подкорректировать их дизайн под корпоративные цвета. Такие баги чинятся обходными путями. Но даже виртуозный верстальщик/разработчик не всегда может все исправить;
• разработчик создает продукт у себя локально. И когда он выкладывается в общий доступ возникают баги, потому что другая скорость интернета/другие настройки браузера/другая локализация пользователя и много чего другого у пользователя.

В работе тестировщика чаще всего встречаются два вида багов:

1. Связанные с версткой. Например, проблемы в наложении элементов друг на друга или “уплывании” элементов с экрана. Также, в верстке бывают проблемы с областью клика в мобильной и ПК версии, когда в мобильной версии область клика кнопки слишком большая и перекрывает другие кнопки. Например, у нас есть кнопка “Отмена” и “Оформить заказ”. В ПК версии, допустим, проблем нет, а в мобильной версии визуально кнопки на расстоянии друг от друга, и нажимая на кнопку “Отмена” нажимается кнопка “Оформить заказ”. Получается неприятная история. В общем, в верстке все должно умещаться, выплывать, адаптироваться, не нажиматься без надобности и нажиматься по надобности. При этом, должны быть учтены все популярные браузеры и платформы. Потому что идеальная верстка в браузере Chrome, может быть невыносима или нечитабельна в браузере Safari.

2. Связанные с функционалом. Частые баги в функционале: не открывается страница, которая должна открываться/не добавляется что-то по кнопке добавления/не сохраняется то, что должно сохраняться/не уходят данные в интегрированные системы или не соответствует формат данных, которые ждут эти системы.

Исправляет ошибку тот, кто ее допустил. Дизайнер, верстальщик или разработчик. Если у тестировщика есть доступ к коду и ошибка несерьезная, он может поправить все сам. Но обычно записывается скринкаст (запись видео с экрана) или делается скриншот, пишется описание ошибки и передается ответственному. После исправлений тестировщик еще раз все перепроверяет. Бывает, что после старых ошибок появляются новые. Или проявляется та же ошибка, но в другом окружении — тогда работа по поиску багов уходит на второй круг. И так, пока все не будет работать идеально.

На каком этапе отлавливается наибольшее количество багов?

После первого выхода продукта с локальной сети разработчика в общий доступ что-то обязательно слетает. Чаще всего, разработчики сами проводят минимальные наборы тестов после выкатки своих разработок, прежде чем отдать их тестировщику.

• Ловить баги легче всего на сайтах-визитках. Там нет функционала, проверяются опечатки, адаптивность и отображение в нескольких браузерах при разной ширине экрана и все. 
• Сложнее ситуация с охотой на баги на обычном сайте, типа интернет-магазина. Но, здесь еще можно смотреть все запросы, логи (текстовые файлы, куда автоматически записываются все события, которые происходили в системе), скорость и прочее в DevTools без лишних телодвижений, в отличии от мобильного приложения.
• А вот мобильное приложение уже стоит на третьем месте по сложности поиска багов исключительно из-за того, что тут труднее смотреть логи и запросы. Для этого необходимо подключать физическое устройство к ПК и уже на нем копать логи ошибок, запросы и прочее.

Оксана рассказала нам про 7 принципов тестирования. И два из них (первое и третье) подтверждают, что не может существовать продукта разработки без багов:

1. Исчерпывающее тестирование невозможно
2. Тестирование демонстрирует наличие дефектов, а не их отсутствие
3. Заблуждение об отсутствии ошибок
4. Раннее тестирование сохраняет время и деньги
5. Принцип скопления или кластеризация дефектов
6. Тестирование зависит от контекста
7. Парадокс пестицида 

А еще она поделилась своим списком сервисов-помощников для охоты за ошибками: 

• Android Studio
• Тест-флай
• Postman
• Проверка орфографии на сайте: https://www.artlebedev.ru/orfograf/  
• VSCode
• Браузеры: Tor, FireFox, Chrome, Opera
• Расширения в Chrome: Liner. The Real Ruler, Инструмент Цветная пипетка, Мобильный симулятор — инструмент адаптивного тестирования, DevTools (много возможностей и инструментов)

Работа тестировщика чем-то похожа на работу учителя. Разработчики делают задания, приносят ему. Он находит в них ошибки, пишет списки со скриншотами (например, мы составляем по каждому проекту чек-листы в Битрикс24) и отдает обратно исполнителям. После правок разработчики отмечают выполненными все пункты, пишут “готово”. Тестировщик снова проверяет эту «контрольную» еще раз и либо «ставит зачет», либо отправляет на доработку с новыми скринами/комментариями/пунктами. Такая вот многозадачная и интересная деятельность. 

Иногда в работе тестировщиков появляются таинственные баги-призраки. И одну из таких историй Оксана поведала нам:  

«На одном из наших проектов изредка появлялась ошибка, которая не пропадала до сброса файлов cookies сайта. Появлялась редко и совершенно при неуловимых условиях. Если специально захочешь воcпроизвести - не получится. Суть вот в чем: чтобы добавить товар в корзину, нужно сначала выбрать адрес доставки или самовывоза. Но когда я выбирала адрес (не важно, доставка или самовывоз), страница перезагружается и адрес остается пустым. Этот баг появлялся на этапе разработки пару раз. Я не смогла доказать его существование, т.к. не могла воспроизвести условия его возникновения. Потом он появлялся на рабочей версии продукта раза 2-3. Та же история - не доказуемо. Однажды на этот баг я наткнулась во время созвона с разработчиками и демонстрации экрана. Мне поверили, но повторить так никто и не смог. До сих пор этот баг иногда возникает, как призрак и пропадает неожиданно сам или после сброса файлов cookies.»