Меня зовут Виталий Котов и я работаю в компании Badoo. В одной из предыдущих статей я рассказывал, что у нас есть некий интерфейс, который помогает взаимодействовать с автотестами как тестировщикам, так и разработчикам.
Не раз и не два меня просили рассказать о нём подробнее.
Под катом я (наконец!) расскажу о том, как писал этот интерфейс и что он умеет. Расскажу о фичах, которые прижились, и о тех, которые оказались невостребованными по тем или иным причинам. Возможно, некоторые идеи вам покажутся интересными, и вы тоже задумаетесь о подобном «помощнике».
Если концепции, которые я демонстрировала на примере, вам незнакомы, то это нормально, и я полагаю, что приведенные ниже шаблоны помогут вам тестировать. Они объединяют уроки, полученные мною в процессе тестирования API.
1. Фокус: работа с ограниченным пониманием
Тестируя исследовательским методом, вы нацелены на предоставление ценности путем наименьших затрат. Так как вы изучаете продукт последовательно, послойно, слои нужно выбирать с умом. На вопрос, с чего начать тестировать, нет единственно верного ответа, но для этого существуют неплохие кандидаты.
Я оттачивала свои навыки исследовательского тестирования, изучая продукты через графический интерфейс. Я практически слышу, как продукт шепчет мне "Нажми сюда… Введи что-нибудь другое… Смотрела ли ты в логи?"
Исследовательское тестирование – это системный подход к выявлению рисков и обучению в процессе тестирования. Шепот, который мне слышится – это эвристики, основанные на многолетнем опыте и знаниях, как смоделировать продукт подходящим образом, чтобы выявить важную для заинтересованных лиц информацию. Продукт стимулирует мое воображение, а я – воображение разработчиков, когда тестируют они. Им тоже чудится шепот "Тестировщика здесь так и подмывает сделать вот это… и именно это он и сделает", и они тестируют намного лучше.
Нередко бывают ситуации, когда необходимо быстро получить тестовые данные для проверок. И если таких данных нет под рукой, на помощь приходят они — сервисы генерации.
Представляем вашему вниманию небольшую подборку полезных инструментов, которые мы используем в нашей работе.
Как выбрать инструмент в экосистеме, которая генерирует фреймворки быстрее, чем плодится зерг, и убивает их с энтузиазмом Дарвина на амфетаминах?
JavaScript, возможно, неоптимален для многих команд, но для большей части нашей отрасли он неизбежное зло. StackOverflow оценивает его как наиболее популярный язык программирования в течение последних пяти лет. Лет десять назад тестирование компонентов JavaScript шло сбоку-припеку и отдавалось на ручное тестирование. Сегодня это уже не побочная платформа, крутящая веб-виджеты, а ключевая часть потока бизнес-операций. Это означает, что большинству команд нужно очень серьезно подходить к вопросу тестирования JavaScript.
Недавно я проводил опрос с целью узнать о предпочтениях и опыте разработчиков в разрезе JavaScript-тестирования. Типичная для всей экосистемы тирания выбора была довольно очевидной. Я получил 683 ответа, и оказалось, что люди пользуются более чем 50 фреймворками тест-автоматизации. При такой сборной солянке ни у кого нет времени на детальное исследование всех вариантов. Однако широта выбора также вызывает вопрос, нет ли в природе чего-то лучшего, нежели то, что мы сейчас используем. Как же выбрать правильные инструменты для так часто меняющегося фреймворка?
Существует практически бесконечное множество антивирусов, их версий и комбинаций настроек. Ничто в мире не совершенно, поэтому иногда они могут перестараться и, например, заблокировать нужные файлы, в безопасности которых мы уверены. Подобные проблемы совместимости могут повлечь за собой заметный отток пользователей. Чтобы не допустить такого в конечном продукте, есть тестировщики. +
Антивирусы могут просто не давать корректно работать законно купленной игре из-за подозрений на вирусы или даже их реального присутствия (такое тоже случается). Например, из-за отсутствия контроля за безопасностью на ПК разработчика, вирус может попасть в игровой билд, который позже скачают пользователи. Шансы невелики, но подобная оплошность всегда очень сильно бьет по репутации продукта и компании в целом, может повлечь за собой утечку информации о пользователях. «Подозрительные» файлы в игре могут быть помещены в «карантин», а то и просто удалены. Антивирус может блокировать установку ПО или ограничить его доступ в интернет. Например, во время наших тестов COMODO, клиент игры удалялся самим антивирусом после его закрытия. То есть пользователь мог купить игру, спокойно запустить и даже поиграть, а потом просто не обнаружить ее у себя на ПК. Также сильно распространена проблема с обнаружением троянских программ в клиенте игры, установленном на абсолютно чистом ПК. В нашем случае это происходило на Qihoo 360 Total Security Essential с любыми параметрами защиты.
Так уж сложилось на практике, что самые главные инструменты для специалиста в сфере тестирования ПО - это его зоркий глаз, пытливый ум и интуиция. Тем не менее, жизнь тестировщика "и опасна, и трудна", и чтобы её сделать несколько комфортнее, существует ряд замечательных инструментов. И как раз о таких инструментах будет данный доклад.
Сидел я как-то раз, работал, и внезапно (ну, как обычно) один из наших проектных менеджеров возник передо мной с вопросом:
- Не можешь ли ты помочь с нашим внутренним проектом?
- Конечно, почему нет! – сразу же откликнулся я.
Я только начинал свой путь в QA, и многого еще не знал, но если опытный сотрудник просит твоей помощи, что еще остается сделать?
Он представил меня другим членам команды, и они рассказали мне о приложении, которое оказалось очень интересным. А затем произошло вот что! Оказалось, что фронтенд еще не готов, и поэтому тестировать придется через API.. и я задумался, а что такое API вообще, как мне это тестировать? И что еще хуже, они, судя по всему, думали, что этот вид тестирования – совершенно рутинная задача, и не особо вдавались в подробности. К тому же я сделал худшее, что можно сделать в этой ситуации – побоялся попросить советов и помощи.
К счастью, они прислали мне рекомендацию, какие инструменты лучше всего использовать для тестирования через API, а также полную документацию на продукт (в Swagger, с этим я тоже раньше не сталкивался). Инструментом был Postman. Поначалу я боролся с ним методом проб и ошибок, но затем наши отношения наладились. Теперь я благодарен за этот опыт – я люблю Postman и постоянно его использую. В этой статье я хочу показать вам, почему работать с Postman очень легко и выгодно.
Выступление Иры Винокуровой на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Программисты пишут в студии. Версии хранятся в дженкинсе. Баги ведутся в редмайне, а тест-кейсы вообще лежат в Тестлинке… Знакомо? Так было и у нас. А потом все изменилось. На смену старой студии пришла новая, да не одна. А с TFS в придачу. Как и у нас, во многих офисах стоит Visual Studio. Многие команды разработчиков пользуются TFS для разработки проектов. Но немногие знают, что в этом во всем есть бонусное место для тестировщиков. О том, как можно использовать TFS для тестирования, что такое Test Manager и как с ним работать, почему все удобнее держать в одной системе — я попытаюсь рассказать в своем докладе на примерах.
