Баг не пройдёт!

Кто делает сайты? Давайте разберёмся.

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

Наша воображаемая 3D модель парит в воздухе и расцветает ромашками при наведении курсора. Здесь постарался разработчик.

Ромашки и 3D появились на сайте не случайно. То, что посетители без ума от союза высоких технологий и природы, понял аналитик, наблюдая за ними 2 недели на тематических форумах.

Но есть ещё один этап разработки, суть которого — сделать так, что вы о нём даже не вспомнили. И это — тестирование. Если оно выявило все баги и не допустило, чтобы разработчик по ошибке сделал ромашки на полпикселя больше, чем на макете дизайнера — работа тестировщика удалась! И вы о ней никогда не узнаете.

Если только мы не опишем её в бложике.

А почему бы и нет? У нас уже были статьи по этой теме и даже классная инфографика, но с тех пор процессы поменялись. Поэтому пройдёмся по этапам разработки, в которых участвуют тестировщики (они же — quality assurance специалисты, для друзей просто QA), и посмотрим, чем они занимаются.

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

В других случаях тестировщик и проект знакомятся на этапе вёрстки. Когда свёрстаны первые макеты, QA проверяет их на соответствие тому, что нарисовал дизайнер и утвердил заказчик. И смотрит, как вёрстка отображается в разных браузерах и на мобильных устройствах.

Когда front-end протестирован, мы начинаем разработку. Тестировщик обязательно участвует вместе с программистами в её планировании путём вскрывания картишек . Обсуждает задачи с менеджером, слушает и запоминает, что и как на проекте должно работать. А потом контролирует, чтобы разработчики об этом тоже не забыли. И так — по каждому спринту.

Когда спринт спланирован, тестировщик и разработчик вместе пишут тест-кейсы. Это такой чек-лист с пунктами для проверки, работает ли фича.

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

Когда программист проверил за собой, мучить сайт начинает QA-специалист. Для этого использует браузеры Google Chrome, Mozilla FireFox, IE и Opera последней версии. Мы учитываем топовые браузеры, потому что непопулярные, с малой долей рынка или старые могут не поддерживать параллаксы и вау-эффекты, которые мы придумываем.

Но, если заказчик желает проверить и отладить проект под браузером «Спутник» — нет проблем, посчитаем бюджет и сделаем.

Также сайт тестируется на мобильных устройствах, которых у нас полная коллекция.

Главная задача тестировщика — отловить все баги. Для этого приходится имитировать бурную деятельность дотошных пользователей. Три-четыре раза зарегистрироваться в личном кабинете, сделать заказ, отменить, передумать и снова заказать. Побыть при этом и пользователем, и администратором.

Пойманные ошибки заносятся в баг-лист. Тестировщик фиксирует, где система дала сбой, на каком устройстве и в каком браузере. Прикладывает скриншот. И выставляет каждому багу оценку от 0 (шеф, всё пропало!) до 4 (у вас тут -, а надо —, и вообще очепятки). Если чуть подробнее и зануднее, то:

0 — Критические баги.
1 — Критичное Usability, забытые фичи.
2 — Некритичные баги.
3 — Некритичное Usability.
4 — Тексты.

В зависимости от оценки менеджер проекта расставляет разработчикам приоритеты по задачам. Чем меньше цифра, тем быстрее баг пофиксят (а что бывает, если разработчик меняет задачи местами, смотрите здесь).

После багфикса тестировщик снова проверяет проект. Если находит ошибки, новые или старые — опять заносит в баг-лист, программист их исправляет... И так по кругу, пока не достигнем идеала.

Как говорилось в начале текста, работа тестировщика не заметна пользователю. Заметно только её отсутствие. Но мы на каждом этапе отчитываемся перед заказчиком и показываем результаты — чтобы он понимал, что платит за работу, а не за имитацию бурной деятельности. Поэтому мы пускаем заказчиков в баг-лист. Они видят всё как есть: с комментариями разработчиков, ошыпками, иногда — с нецензурной лексикой (о которой менеджер предупреждает заранее и по возможности прячет). Зато история войны с багами, с реальными кровью и слёзами — перед глазами заказчика.

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

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

Когда проект согласован с заказчиком, акты подписаны и внешнему менеджеру не к чему придраться, мы переносим сайт на боевой домен. Тестировщик возвращается к проекту и устраивает smoke-test — проверяет, чтобы при переносе не сломался основной фукционал: заказ товаров, корзина, фильтры, личный кабинет и т.д.

Когда проект завершён, команда разработки собирается на ретроспективу. И тестировщик тоже — у него, как у человека, который прошерстил сайт вдоль и поперёк на этапах от вёрстки до релиза, можно узнать много полезного для будущих проектов.

Так что тестирование проектов — штука важная. Хоть оно и проходит без видимых результатов для тех, кто не привык видеть сайты на стадии альфа-зародыша. Тестирование полезно для проекта, заказчика, пользователей и веб-студии. А если в продакшн мимо разработчиков, менеджера проекта, тестировщика и внешнего менеджера проскочил-таки баг, мы его обязательно фиксим. Работа над ошибками по гарантии бесплатно :)