Думайте иначе и будете вознаграждены.

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

Крупнейшие и наиболее успешные ИТ‑компании привлекают реальных пользователей на каждом этапе разработки ПО от его концепции до релиза. Но большинству компаний есть к чему стремиться в области качества из‑за нескольких популярных заблуждений, лежащих в основе QA‑процессов. Построив карьеру тестировщика ПО и открыв собственную компанию по тестированию, автор статьи обнаружила, что стоит думать по‑другому, когда речь идет об улучшении качества продукта. Вот несколько мифов, которые она развенчала за эти годы:

Миф 1: Пользовательские истории обеспечивают лучшее качество

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

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

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

Миф 2: Из бета-тестировщиков получаются отличные QA-специалисты

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

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

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

Миф 3: Тестировщики прекрасно моделируют поведение пользователей

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

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

Миф 4. Высокое качество продукта не является приоритетом разработки

Скорость, присущая гибким методологиям разработки ПО, не должна негативно сказываться на качестве продукта. Некоторые компании экономят на тестировании, откладывая его на конец разработки, но полноценный контроль качества заслуживает бюджета и ресурсов всей команды разработчиков, и большинство компаний тратят не менее 31% своего ИТ‑бюджета на обеспечение качества и тестирование. Если ваши показатели заметно отличаются, стоит обратить внимание на организацию QA‑процессов.

Многие компании сейчас конкурируют исключительно за счет качества. Они понимают, насколько качество важно для их бренда, и просто не могут позволить тестировать свой продукт, только если на это останется время или бюджет. Если ваша QA‑команда перегружена, или рейтинг вашего приложения не улучшается, спросите себя: в какой миф о качестве вы все еще верите?