Как в InternetDevels проходит процесс тестирования сайтов

Если сайт предусматривает регистрацию - регистрируемся и смотрим, или система ведет себя, как мы того ожидаем (мы ожидаем, что после регистрации должно прийти письмо-подтверждение, или письмо с одноразовым паролем / ссылкой для входа в личный кабинет). Заходим в кабинет пользователя и проверяем, приходит нам электронное письмо. Если ничего не происходит, то, возможно, мы нашли проблему. Далее смотрим, как сайт выглядит в режиме инкогнито браузера (проверяем, все так же, как и в анонимного). Если есть разница, то нужно установить, почему так (возможно, разница действительно должна быть).

Обычно много багов можно найти уже на этапе изучения сайта, например, если открыть сайт на мобильном телефоне или в таком браузере, как Internet Explorer. Список действий на сайте можно продолжать, и они зависят от конкретных случаев. Сбор информации от клиента (спецификации проекта, техническое задание, отчеты от разработчиков, макеты и т.д.) Для будущей работы важно определить тип и масштабы проекта - например, если это интернет-магазин, то сколько в нем товаров, категорий, страниц, как и т.д.

Чтобы проверить, соответствует ли сайт требованиям клиента, нам обязательно нужно знать эти требования. Для этого мы изучаем техническую документацию клиента по сайту - это может быть макет, техническое задание (так называемые "жары") и т.д. Чем подробная документация, тем точнее и качественнее результат. Если же документации нет, то мы общаемся с заказчиком и создаем ее по ходу процесса. Очень важным является получение всех возможных доступов к админской части сайта (логин / пароль к учётной суперадмина, SSH доступы к серверу, root-права на сервере, VPN доступы (если есть), дампы баз данных, и.т.д). Вся эта информация необходима для более точной оценки масштабов работы.

Планирование работ и оценка на основе предыдущего опыта

Изучив сайт, имеющуюся документацию и требования клиента, мы планируем все, что нужно сделать, и примерно оцениваем, сколько времени на это уйдет. Исходя из нашего предыдущего опыта, мы даем приблизительную оценку в часах на 1 человека (сколько часов потребуется на всю работу, если ее выполнять один тестировщик). Например, пишем, что функционал покупок будет тестироваться 50 часов, функционал перевода - 100 часов. Стоит помнить, что оценка приблизительная, поэтому мы еще не знаем, какие инструменты мы будем использовать, какие типы тестирования мы будем задействовать (автоматизированное или ручное), количество тестовых сред будет доступна нам, сколько людей будут привлечены к процессу тестирования.

Предоставив заказчику эту предварительную оценку, мы уточняем у него некоторые вопросы, которые могут возникнуть точно возникнут в процессе оценки. Например, нужно заказчику тестирования во всех браузерах, или только в нескольких, которые важны для него. Постоянно общаясь с заказчиком, можно значительно сэкономить время и средства. С учетом всего выше собранной информации мы можем поставить более точную оценку.

Тест-среда, тест-инструменты, распределение ресурсов, расписание тестирования

Далее определяемся с тест-средой. Где мы будем писать тест-кейсы: скажем, в ексельци, на бумаге от руки, на стене пещеры, или, например, в TestRails - специализированной системе для записи тест-кейсов, хорошо помогает структурировать информацию (особенно если ее много).

Определяемся с тем, на каком сервере тестировать сайт, и это будет сайт локально развернутый, или на специализированном тест-сервере, или мы будем тестировать все изменения сразу на живом сайте (никогда не повторяйте это в домашних условиях :).

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

Когда у нас уже есть вся эта информация, мы можем посоветоваться с заказчиком и определить, сколько людей мы можем привлечь к процессу тестирования. И только теперь - мы составляем график того, когда, что и в каком порядке мы будем тестировать. На этом этапе уже можно сформировать приблизительные рабочие спринты. Сбор информации о процессе работы разработчиков

Мы рассматриваем схему работы для случаев, когда сайт поступает нам только на тестирование. Большинство наших проектов мы разрабатывали и мы же их и поддерживаем. Однако, если проект попадает к нам уже на доработку, и писался изначально не нами или и дальше продолжает писаться не нами, нам наиболее полно нужно собрать информацию о среде и процессы разработки.

Мы изучаем, как организован (был организован) процесс работы разработчиков, разрабатывают (разрабатывали) сайт. Общаемся с командой разработчиков, чтобы наладить процессы сотрудничества. Это нужно для того, чтобы "влиться" в их workflow и, по возможности, автоматизировать его - например, настроить continuous integration (методология разработки, которая позволяет контролировать процесс на любой его стадии с помощью частичной автоматизации этого же процесса: билд- скрипты, автоматические репорты, автоматизация работы с хитом) для лучшей организации работы команды.

Тест-дизайн (тест Данные / Тест-сценарий / Тест-кейс)

Как архитектор сайта создает структуру сайта, так и тест-дизайнер (обычно senior-менеджер) определяет структуру процесса тестирования, - детальные особенности работы с проектом. Это может быть выражено и задокументировано в плане работ, или с помощью чек-листа.

Или мы просто собираемся командой и решаем проблемные моменты, которые могут возникнуть точно возникнут в течение нашей работы и документируем наши решения, таким образом, мы как бы предупреждаем проблемы еще до их возникновения. Обычно на этом этапе разрабатываются тест-кейсы - придумываются, состоят, нумеруются, оформляются по соответствующим правилам, чтобы их могли понять все участники процесса.

Выполнение тестов === Обретение багов

Наступает время воплощать в жизнь все то, что дизайнилось и продумывалось. Это этап, на котором мы выполняем тесты. В процессе тестирования мы находим баги. Они обязательно находятся, каким бы замечательным ни был наш проект - иначе плохо искали.

Баг-Репортинг разработчикам

Нужно зайти в баг-трекер (например Jira) и зарепортиты баг в соответствующей задачи. Если задачи не было, ее нужно создать и указать, где конкретно и какой баг был найден и как его можно воспроизвести. Чем больше деталей содержит баг-репорт, тем лучше его поймет разработчик. Здесь прекрасно работают скриншоты, видео, пошаговое описание.

Исправление & Проверка & Закрытие

Нашли - значит, будем фиксить! Разработчик получает баг-репорт или задачу в баг-трекере (или почтового голубя), воспроизводит баг, ищет его причину и занимается исправлением.

Затем разработчик отправляет задачу тестировщиков на проверку.

Тестировщик должен быть строгим, но справедливым - проверять без компромиссов. Если менеджер определяет, что баг пофикшений - замечательно! Задача закрывается и все счастливы.

Если же нет - то нужно вернуть ее назад разработчику. И так далее - пока все не будет идеально. В конце работы нужно в структурированном виде описать все, что мы делали. Это может быть в виде ворклогу задач, или, если это TestRails, то в виде тест-нов. Главное - чтобы вся сделанная работа была подробно задокументирована. Это нужно для наших наследников, ведь если проект большой и длинный, кому-то обязательно пригодится то, что мы задокументировали.

Автоматизация критического бизнес-функционала

Если проект предусматривает автоматизацию, то автоматизируется, в первую очередь, только критический бизнес-функционал. Например, процесс покупки и оплаты в интернет-магазине (проверяем все работает корректно, правильно снимаются средства с карточки клиента и т.д.).

Автоматизация проходит с помощью тех инструментов, с которыми мы определились в пункте о Testing tools. Если есть такая необходимость - привлекаем дополнительные ресурсы и процесс тестирования сайта автоматизируется полностью, или почти полностью. На самом деле, в этом почти всегда нет необходимости, ведь это дорого и часозатратно. Мы всегда стараемся оптимизировать ресурсы и не делать лишнего, если в этом нет необходимости.

Регрессивное тестирование

Может показаться, что тестирование - это легкий, и в большинстве случаев, ненужный процесс. Однако - это важный этап разработки качественного продукта. И мы, в Internetdevels, уделяем большое внимание всем деталям этого процесса. Поэтому, чтобы обеспечить идеальную работу сайта и отловить возможные баги, которые могут возникнуть в будущем (особенно при внесении изменений в код), требуется регулярное регрессивное тестирование (мы прогоняем все имеющиеся тесты снова и снова ..., а затем повторяем процесс). Это может быть либо запуск уже созданных автоматических тестов, или ручное тестирование. В рамках регрессивного тестирования работают те же этапы: Исправление & Проверка & Закрытие.