Каждый из нас обречён замечать изъян
Мироздания и расчёсывать
oxxxyМирон Фёдоров про QA
Повзрослев на год, мы продолжаем Монолог тимлида и делимся опытом тестирования нашего продукта SafePhone.
За прошедший год мы смахнули пыль с фолианта Г.Майерса «Искусство тестирования программ», повторно восхитились мудростью автора и согласились с его утверждением, что невозможно покрыть тестами мало-мальски сложную программу на 100%.
Мы убедились в применимости принципа Парето при тестировании: 80% покрытия продукта, как правило, достигаются 20% тестов. О том, как мы определяем 20% целевых тестов и улучшаем процессы QA, читайте под катом.
Автоматизировать нельзя тестировать вручную
Большинство тестов должны выполняться автоматически, в команде QA должны быть свои разработчики, которые пишут автотесты, а остальные тестировщики должны заниматься исследовательским тестированием и вместе с аналитиками определять тест-кейсы, которые нужно автоматизировать в первую очередь.
Это прекрасное и, как мы надеемся, недалёкое будущее, к которому мы стремимся. Наше основное препятствие – это device-specific функции, которые нужно вручную проверять на устройствах. Например, запрет сброса устройства к заводским настройкам или запрет перепрошивки устройства из recovery. Работу с recovery в Android в принципе нельзя автоматизировать, потому что при работе в recovery основной Android не загружается.
Device-specific не ограничивается работой с recovery. Приложению, которое управляет устройством, нужны специфические права. Их нельзя получить на публичных фермах устройств, где чаще всего тестируют UI. Например, права Device или Profile Owner.
Но, даже обладая такими правами, отклик устройства на команды управления не всегда можно получить программно. Например, можно относительно просто проверить запрет камеры, но нельзя проверить запрет многопользовательского режима (от слова – совсем). Поэтому в нашей ближайшей перспективе объём ручного тестирования мобильных клиентов будет еще изрядный.
Чтобы как-то сократить свои затраты на handjob тестирование, мы предлагаем нашим клиентам «ознакомиться» :-) с новыми версиями до их официального релиза. Клиентам нравится развитие продукта, и они не скупятся на обратную связь, а мы выпускаем более полезный и стабильный релиз. Win-win!
Что покрываем автотестами, а что тестируем руками?
Найти заветные 20% тестов, которыми можно покрыть 80% кода, непросто.
Авторы книги «Как тестируют в Google?» предлагают писать тест-план за 30 минут, чтобы отбросить лишнее. Но проблема в том, что разработчики, тестировщики, саппорт, менеджеры и клиенты понимают ценность продукта по-разному.
Чтобы не спорить, кто из них меньше прав, мы решили в первую очередь утолить «боли» клиентов, у которых по жизни больше прав.
Вот что у нас получилось.
1. В первую очередь автотестами надо покрывать те функции, с багами в которых столкнулись клиенты.
Клиент должен столкнуться с проблемой не больше одного раза. И не важно сколько мажорных релизов клиент установит себе в будущем. Проблема не должна повториться ни в одном из них.
2. Рутина – следующая в очереди за автотестами. К рутине мы относим функции, на проверку которых тратится много времени при ручном тестировании. Это либо функции с большим числом комбинаций параметров, либо функции, при проверке которых есть много однотипных операций, от частого выполнения которых глаз тестировщика начинает дёргаться замыливается.
Например, в нашем продукте админу можно назначить роль с произвольным набором полномочий доступа к UI. Даже на уровне доступных пунктов меню полномочий много, но наши полномочия более атомарные и иногда распространяются даже на отдельные кнопки. Поэтому протестировать даже типовые роли вручную непросто.
Ещё один пример автоматизации рутины – это наполнение системы нужными данными. Конечно, можно начинать работу с каждой новой сборкой с наполнения её данными через UI, но это долго. Хватит 5-10 повторений, чтобы этот процесс окончательно надоел. Поэтому чаще всего наполнение выполняется автоматически с помощью API.
Когда рутины много, нужно выбирать те функции, которые нужны клиентам в первую очередь. Самые нужные функции определить просто. Достаточно задать себе или клиенту вопрос: «Ошибку в какой функции придётся исправлять ночью или в выходной, если она случится на проде?».
3. Нужно минимизировать жертвы при рефакторинге. Рефакторинг необходим. Но когда одна или несколько команд разработчиков за него берутся, жди беды. По закону Мэрфи обязательно найдётся какой-нибудь сценарий, который нужен клиенту, но который не покрыт требованиями.
Чтобы минимизировать возможный ущерб, нужно договориться о целевом поведении. В этом помогают тест-кейсы. Если тест-кейсы рутинные, их можно автоматизировать и убедиться, что до и после рефакторинга поведение системы не изменилось. Чем больше рефакторинг, тем больше потребность в автотестах.
Иногда при рефакторинге случаются «невинные жертвы». Это когда отрефачили в одном месте, а поведение системы изменилось в другом. В реальной жизни связи между компонентами не всегда бывают детально описаны, поэтому разработчик должен сообщать о возможном влиянии изменений на соседние компоненты.
Люди не часто думают о других, а разработчики и подавно, поэтому добиться ответа о влиянии изменений непросто. Разработчиков нужно мотивировать. Например, рекомендовать заставлять писать автотесты на каждый баг, который был обнаружен в результате неучтённого влияния. После нескольких таких «наград» разработчик начинает больше думать о связях между компонентами.
Как повысить качество продукта без автотестов?
TestOps – это не только про технологии, но и про процессы. Пару лет назад мы столкнулись с тем, что в тестирование стали передаваться сборки разных компонентов, которые были несовместимы друг с другом. Искать совместимые сборки увлекательно, но утомительно. Поэтому мы ввели QR-коды начали прививать навыки QA-гигиены.
За качество отвечают все, а не только тестировщики
Первое правило гигиены – проверка на входе. Тестировщики пишут разработчикам «райдер» в виде смоук теста, которые разработчики должны самостоятельно пройти до передачи сборок в тест.
В этом случае тестировщики выступают в роли внутренних клиентов.
Плюсов сразу несколько:
Тестировщики начали раньше изучать требования и давать по ним обратную связь до окончания разработки. Без этого смоук тест не напишешь.
В тестирование перестали попадать несогласованные сборки.
Разработчики на этапе совместной отладки стали сами находить и исправлять ошибки. За счёт этого число возвратов задач уменьшилось в несколько раз.
Увеличилось число автотестов. Разработчики, которые ждут какого-то API, сами начали писать для него тесты, чтобы потом не удивляться, что API работает не так, как они ожидали.
Своего рода TDD.
Бюрократиш, практиш, гут
Можем показаться непопулярными, но ещё одно важное правило гигиены QA – это осознанная бюрократия.
Для новых функций нужно разрабатывать чек-листы, которые должны согласовать аналитики. Это уменьшает вероятность того, что в предрелизной суматохе мы забудем проверить что-то важное. Также это даёт возможность в любой момент оценить степень готовности релиза или спринта по степени прохождения актуальных чеклистов.
Автотесты должны иметь описание в виде тест-кейсов. Бытует мнение, что лучшая документация для кода – это сам код. Но не каждый тестировщик, аналитик или менеджер может разобраться в коде тестов, зато каждый разработчик умеет читать и писать по-русски (хоть и мечтает, чтобы слова подставлялись автоматически по табу). Поэтому хотя бы краткое русскоязычное описание, что и как проверяет тест, необходимо.
Если существующие функции изменяются, нужно актуализировать требования, чек-листы и тест-кейсы. Иначе команда QA может проверить новый релиз по старым документам и завести лишние баги. Разработчики изучат баги и поймут … , что это не баги! В итоге все вроде работали, а вроде и не работали.
Ограничения реализации должны быть зафиксированы до её передачи в тест. Иначе в тестировании будет та же чехарда, что при неактуальных требованиях: «Так не работает» – «Да и не должно» – «Как об этом можно догадаться?!» – «Я думал, это очевидно».
Напоследок
QA позволяет нам не захлебнуться в саппорте продукта. Но оптимальное соотношение качества и затрат на его развитие ускользает каждый раз, когда мы его пытаемся зафиксировать в своих регламентах. Продолжить попытки или смириться – это индивидуальный выбор каждой команды. Мы свой выбор сделали и упрямо прём вперёд :-) А как вы развиваете QA и вовлекаете в него продуктовые команды? Поделитесь в комментариях.