Тестирование продукта — вещь занимательная. Всегда узнаешь много нового, сам участвуешь в процессе создания и созидания, да и вообще, расширяешь кругозор.
Почему же в названии статьи звучит «игра». Да, всё просто! Как и в любой игре, приходится проявлять всё своё мастерство, все свои навыки и знания, чтобы протестировать продукт.
Чем хорош продукт? Почему с ним так интересно работать? Зачем его вообще тестировать? И другие вопросы могут возникать в голове, когда начинаешь работать в продуктовой компании. Здесь нет внешнего заказчика, который будет диктовать условия. Здесь нет ограничений по функционалу. Есть только цель: сделать продукт лучшим на рынке. И качество — неотъемлемое условие ее достижения.
Работа над продуктом — это разработка и тестирование, а еще бизнес-анализ, дизайн, маркетинг и продвижение продукта на рынке. Кто бы ни участвовал в процессе, это всегда будет тесное взаимодействие всех компонентов при производстве продукта, в одиночку не справиться.
Говорят, что программисты и тестировщики живут, как кошка с собакой. Только это полностью домашние питомцы, которые любят друг друга, но в некоторых случаях могут и повздорить. Это неразлучные команды, совместная работа которых не прекращается на протяжении всей жизни продукта.
Итак, поиграем...
При зарождении продукта задача часто звучит как «сделайте, чтобы было хорошо». И тестировщик, в процессе анализа требований и сопутствующей документации, начинает разбираться, что такое «хорошо». Он определяет критерии, утверждает полученные результаты у постановщика задачи, разъясняет разработчику, проверяет разработку на соответствие ожидаемому результату и, при необходимости, отправляет продукт на доработку.
И если программист следует определенному алгоритму, у него есть точный кейс для тестирования его программы, то тестировщику необходимо проявлять фантазию. Описанный в техническом задании функционал никоим образом не может отразить всё то разнообразие вариантов использования, которое можно ожидать от пользователя при работе с программой.
Игра становится все интереснее и интереснее.
Так как заявленный функционал явно попробуют использовать не по назначению, тестировщику заранее приходится проверять десятки и сотни вариантов использования доступных возможностей. Здесь открывается безграничное поле для ваших фантазий: можно исследовать (кто-то может и захочет сказать «ломать», и это тоже правда) пользовательский интерфейс, можно смотреть, как работают внутренние функции программы, а если это клиент-серверное приложение, то почему бы не «пощупать» сервер, а если позволяет здоровье вашего оборудования, то можно потестировать безопасность продукта. Для тестировщиков это будет звучать как: GUI и Usabiblity тестирование, функциональное тестирование, автоматизированное, нагрузочное, регрессионное, кроссбраузерное (для web-приложений) и т. п.
Допустим, что продуктом является web-приложение. Тогда всё начинается с тестирования дизайна и удобства использования. Дизайнеры — творческие люди, хотя и в продукте разбираются. А вот протестировать совместимость с уже существующим функционалом надо обязательно до начала разработки. После реализации новой функции наступает момент явного тестирования графического интерфейса, вот здесь и становятся очевидными огрехи, незамеченные на этапе проработки дизайна. Для новых возможностей приложения обязательным будет этап функционального тестирования. Этот и другие шаги будут повторены ещё много раз до выхода продукта в свет.
Новая функция попадает в большое приложение? Значит обязательно регрессионное тестирование. Слишком долгий процесс? Тогда на помощь придут Selenium и автотесты. Конечно же, на первоначальном этапе разработка автотестов слишком времязатратна. Только в перспективе это позволит избавиться от рутины и уделить больше времени тестированию новых возможностей продукта.
Web-приложение — это очень удобно для пользователя. Везде, где доступен интернет и есть устройство с браузером, можно получить все данные из программы. Правда, есть нюанс — в разных браузерах функционал может вести себя по-разному. Спасает ситуацию кроссбраузерное тестирование.
Продукт развивается, функционал растет — игра начинает напоминать интеллектуальную стратегию. На помощь приходит автоматизация. Если в начале разработки продукта это были unit-тесты, то теперь пришла пора автоматизировать действия пользователя, т. е. эмулировать их поведение в программе. Минимально необходимо, чтобы заявленный функционал работал правильно. Максимально — чтобы все варианты нажатия кнопочек, перехода по вкладкам, щелчки мыши в разных точках программы не привели к неверным результатам работы, а тем более краху.
Продукт развивается. Игра набирает обороты.
Становится ясно, что нужна версия для мобильных платформ (исключение составляют приложения, явно предназначенные для смартфонов). Наступает очередной этап игры. Делаем мобильную версию. А это другие технологии, размеры, вычислительные мощности. Полученный до этого опыт работы с продуктом очень помогает в тестировании базового функционала. Того функционала, который заявлен в техническом задании. Только варианты использования мобильных приложений уже другие. Ура! Убедиться, что всё вычисляется правильно, не составляет большого труда. А вот разобраться с огромным разнообразием мобильный девайсов — задача поинтереснее. Опять открывается огромнейшее поле для проявлении фантазии тестировщика. Ещё много новых инструментов будут освоены.
Мобильные приложения обычно разрабатываются для двух наиболее популярных на рынке платформ — iOS и Android. Последняя обычно в авангарде, новый функционал сначала разрабатывается и запускается для Android, а затем подтягивается на «яблочную» платформу. Это связано с более сложными механизмами разработки под iOS.
Здесь и проявляются все особенности мобильного тестирования:
Никаких симуляторов — только мобильники. Неиспользование эмуляторов/симуляторов в тестировании мобильных приложений приводит к тому, что тестовая среда не отличается от той, в которой окажется продукт после выхода на рынок и попадания в руки конечному пользователю. Это позволяет наиболее качественно производить тестирование интерфейса пользователя (UI testing).
Проверка работы приложений при различном типе и скорости связи (Wi-Fi, мобильный интернет, отсутствие связи). Обязательна проверка работы в offline режиме, при этом акцент делается на сохранности данных, вся собранная информация должна оперативно передаваться на сервер при установлении соединения и синхронизироваться с web-приложениями без ошибок.
Большое количество версий платформ и вариаций их сочетания с ОС различных марок телефонов (особенно актуально для Android) порождает огромную вариативность возможного поведения приложений. Физически предусмотреть все случаи невозможно. Для оптимизации результата при тестировании используются классы эквивалентности и другие методы сокращения количества тестируемых конфигураций.
За всей этой красотой, легко доступной пользователю, в некоторых продуктах может скрываться невидимый сервер. Он на всём протяжении развития продукта развивается по своим законам. Конечный результат работы сервера легко проверяется в клиенте. А вот чтобы оценить работу внутренних алгоритмов, порой тестировщикам приходится прибегать к помощи программирования. Такой вариант позволяет лучше узнать продукт, а также прокачаться в языках и технологиях.
Самым удобным вариантом тестирования будет встроенная в сервер поддержка скриптовых языков (например, TCL, Lua, Python). Тогда нет необходимости в написании больших программ для глубокого анализа. Достаточно написать или модифицировать скрипт и запустить его на сервере, без перезагрузки самого сервера.
Если для клиента мы проверяем удобство использования и правильность расчётов, то для сервера нам необходимо проверить, как он справляется с максимальной нагрузкой. Для этого выполняется нагрузочное тестирование. Лучшим вариантом будет возможность сервера выдерживать подключения от миллиона пользователей, но такое возможно только в облачных технологиях. Значит нужно понять сколько подключений может контролировать один сервер. Конкретные цифры помогают, как разработчикам, так и тестировщикам, проектировать, программировать и тестировать облачные сервисы.
Раз есть сервер и клиент, значит существует и протокол обмена данными между ними. Хорошо если это SDK (Software Development Kit), тогда снова расширяем свой кругозор в продукте и программировании. Но даже при наличии обычных http запросов или просто TCP соединения, есть с чем поиграть. Любое взаимодействие можно проверять на безопасность и на нагрузку. А знание модели OSI/ISO никто не отменял.
И вот у нас уже огромный многофункциональный гигант. Раз продукт востребован на рынке столько времени, значит он решает свои задачи. А раз до сих пор решает свои задачи, значит он довольно-таки универсален. На этом этапе связь между программистами и тестировщиками становится по-настоящему прочной. Любой сбой этой связи приводит к ухудшению качества продукта.
С развитием продукта развиваются и все привлечённые к его разработке люди: программисты, аналитики, дизайнеры, тестировщики , суппортеры, маркетологи. Все просто: разработка продукта позволяет выстраивать внутренние процессы именно так, как это удобно участникам. Нет внешнего заказчика, который будет навязывать вам свое видение организации работы, выбор используемых технологий, сроки выполнения задач. Важны развитие продукта и его популярность среди клиентов. А это все зависит от качества.
Всё вышеописанное можно найти в компании Gurtam в дружной команде тестировщиков. Разные виды тестирования и языки программирования помогают нам обеспечивать высокое качество выпускаемых продуктов. Присоединяйтесь к нашей дружной компании, чтобы сделать мир лучше.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.