Здравствуйте, с вами команда Intvideo. Меня зовут Дмитрий, я являюсь PM'ом в этой компании. Мы хотели бы поделиться с Вами нашими успехами и трудностями, которые нам пришлось пройти за 3 года существования проекта. С этой целью я попросил поведать об этом одного из основателей проекта, Черногубова Евгения. Далее рассказ от его лица.

История очень интересная, расскажу все и даже больше, но все по порядку.

О проекте

Идея проекта принадлежит моему приятелю, с которым мы знакомы еще со школьного возраста. Сегодня мы партнеры.

Сервис Интвидео транслирует видео-опросы.
Видео-опрос – это рекламный видеоролик с онлайн-опросом в конце. Он объединил в себе преимущества самого продуктивного вида рекламы — видео-рекламу и анкету интернет-опроса.

Сервис интересен как пользователям, так и рекламодателям.

Для пользователей — не сложная регистрация, после которой можно начать пользоваться сервисом и зарабатывать. При этом, чем детальнее заполнен профиль, тем больше оплачиваемых видео-опросов он будет получать. Время участия оплачивается из расчета $3,60 в час. Кроме этого, дополнительный доход приносит партнерская программа, благодаря которой, пользователь зарабатывает процент от участия в видео-опросах, приглашенных им пользователей. Регистрация в проекте возможна только по коду приглашения, поэтому каждая рекомендация учитывается при начислении комиссионных.

В этом посте я опишу свои исследования, которые мне пришлось проделать, когда на проекте стал вопрос об автоматизации тестирования. Проект представляет собой веб-сайт, клиентская часть которого написана на Flex, а серверная — на Python(Django).

Выбор средств для автоматизации

Для начала рассмотрим путь от начала, который я прошел, прежде чем остановился на связке Java + Selenium + FlexMonkium. А это:

• Selenium + Sfapi
• Ranorex
• FlexMonkey
• Selenium + FlexMonkium

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

Молодые специалисты, прейдя на первый проект в своей жизни, воспринимают все традиции по ведению тестовой документации и тестированию как эталон, так как у них нет опыта и им не с чем этот процесс сравнить. Взяв за основу какой-либо стиль дизайна отчета об ошибке, при смене места работы на собеседовании могут возникнуть споры при ответе на вопрос: «Расскажите нам про дизайн баг-репорта», т.к. у команды, в которой вы хотите работать стиль описания может отличаться. Здесь важным моментом является не угадать этот самый стиль, а озвучив свой и услышав в его адрес критику, уметь обосновать свою точку зрения.