На этот раз, в апдейт вошли очень интересные дополнения:

1. Изменена работа с тест кейсами.

Раньше тест кейсы выкладывались вместе с инструкциями, часто в виде офисных файлов. В документе нужно было отмечать свои действия и писать  ID найденных багов на разных шагах. Теперь под работу с кейсами отведена целая секция проекта, в которой эти тест кейсы можно выбрать, отказаться от выбранных, заполнить по шагам, приложить допольнительные данные по результатам. Для шагов тест кейса прямо в платформе можно завести баг (появилась логическая связка), либо добавить баг для тест кейса целиком. Для тестировщиков выгода не очевидна, но есть. Снижается нагрузка на менеджера проекта, а значит реагировать на проблемы он будет быстрее… чисто теоретически. В целом изменение больше для менеджмента, а для тестировщиков несет только лучшую организацию работы. Тоже важно, но по сравнению с тем что было не очень критичное улучшение.

2. Доросли до тестовых циклов перепроверки фиксов. Если повезет, то можно попасть в группу людей, которые перепроверяют баги. Повезет – потому что, такая работа имеет КПД лучше, чем свободный поиск багов, при меньших тродозатрах. Вероятно, для того, чтобы попасть в такую группу багов нужно запостить немало. Критерии отбора не понятны, но обещают, что принцип работы в таких циклах будет схож с интерфейсом для тест кейсов. Мне идея нравится, хорошо бы теперь пощупать.

3. Произошло очень интересное изменение правил компенсации. Раньше оплата была условно фиксированной по типам багов. Условно, потому что рейт мог в любой момент поменяться на меньший, либо при нахождении чего-то значимого кастомер мог поощрить тестировщика и выписать бонус. Наибольшим рейтом чаще всего обладали технические баги. Из-за достаточно расплывчатой классификации и рейта множество ошибок заносились как технические. Спекуляция? О, да. Однако, только в вопиющих случаях тип бага менялся на правильный. Так же большинство такого рода багов были не слишком интересны кастомеру. Эта проблема более менее решалась стандартными стредствами. Если баг существовал, но был не слишком интересен, но при этом всё-таки в контексте тестирования, то его переводили в статус фидбека ($2-$3 рейт, против $6-$10 за технических). Теперь все рейты уравнены. К этому рейту кастомер (я так понимаю, что и менеджер проекта) сможет добавить $4, если баг окажется интересным, и $8, если кастомер от счастья заплачет. В целом оценка будет более чем субъективная, но, на мой взгляд, идея правильная и больше всё-таки ударит по Gold/Silver/Bronze тестировщикам.  Так как базовый рейт будет снижен, то процентный плюс “за рейтинг” будет также ниже.

Специальные Бонусы, MVT, оплата за тест кейсы остаётся без изменений.

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

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

Порядок в списке, не означает приоритет.

1. Бизнес- или девелоперская документация по продукту или проекту. Самый простой (когда есть) и распространённый способ, наровне со вторым – по готовому коду. Все знают – берём юзер мануал, RTO, ТЗ, продумываем сценарий, описываем шаги и реакции. Не самый эффективный вариант, если не практикуется TDD, потому что очень часто код меняется, что то добавляется, что то уходит и тест кейсы написанные ранее перестают быть актуальными. Даже поставленный процесс не гарантирует сохранения актуальности, а лишь уменьшает риск. Поэтому в таких тесткейсах чем меньше деталей, тем лучше – основной упор можно сделать на путь, который необходимо пройти и бизнес-критичных результатах.

2. По готовому коду – получили продукт и по тому как он работает пишем тест кейсы, убирая явно бракованные варианты поведения и ошибки. Попутно записываются баги. Есть риск того, что при тестировании будет проверена всего лишь техническая реализация, а не соответствие тому, для чего проект был сделан. Но это наиболее простой способ и основной в условиях бардака.

3. Из общения с разработчиками. По сути этот пункт должен быть первым в процессе работы, но на практике оказывается, что далеко не каждый разработчик способен рассказать о своей работе так, как нужно тестировщику. То есть рассказывает то он всё правильно, но только на другом языке. Поэтому часто это неэффективный вариант, но без него не обходится. Если же при написании тест кейсов с разработчиками общения про продукту не происходит, то стоит задуматься о смене стиля работы. К тест кейсам это отношения особо не имеет, но показывает расслоение команды на “тех” и “этих”.

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

5. Гайдлайны. Те, которые предоставляют Microsoft, Apple, Google и прочие производители средств разработки и исполнения приложений. Перекликается с четвёртым пунктом, но легче, – не требует глубокого знания области (понимания требует, но знание не существенно), тесткейсы на их основе легче аргументируются и лояльно воспринимаются разработчиками, дизайнерами и прочими любителями сделать фишечку в интерфейсе графическом или программном от которой пользователи впадают в ступор. Минус в том, что покрытие приличное ими не гарантируешь и проверяется соответствие каким то внешним условиям, а не соответствие продукта его основному предназначению. Так же гайдлайны часто очень детальные и трудно адаптируемые к ручному тестированию из-за своей точности, а вот для автоматизированного в самый раз.

6. Best practices. Адаптация чужого знания и опыта к какой-либо части разрабатываемого продукта. Заменяет гайдлайны, когда их нет. Плюсы – минусы теже.

7. С потолка. Иногда и так. Особенно в стартапах, когда не всегда и не все известно как должно работать. Например, как оценить новый геймплей? Функционально да, можно, а вот саму идеереализацию геймплея? Юзабилити тут ни при чем.  В итоге появляется договорённость о том, что мы считаем правильным. Это по сути источник для регрессионных тестов и тестов, которые позволяют оценить вектор изменения будущих версий относительно предыдущих (а это уже в юзабилити в том числе).

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

Мне давно уже было интересно то, как проводятся маркетинговые исследования при выводе продуктов на рынок. Но это всегда было на уровне “неплохо бы узнать, как-нибудь”. На удачу меня пригласили поучаствовать в таком исследовании, на что я с радостью согласился. Чисто теоретически я знал, что тоже самое, что делают при маркетинговых исследованиях нужно делать в тестировании и уж само-собой shareware, при появлении новых продуктов. Оказалось, что методика столь же удачно может быть использована на митингах в ИТ. За два часа я увидел насколько здорово ведущий исследования ведёт дискуссию участников, играет на эмоциях демонстрируя различные символы. С другой стороны описывать всё, что происходило сродни изобретению велосипеда, в литературе по маркетинговым исследованиям это всё есть, только почему то ни одна из книг для менеджеров ИТ (разумеется из тех, что я прочитал), не отправляет читателей даже к базовым понятиям маркетинга. А не помешало бы, всё-таки отстаивание своего мнения сродни продаже нового продукта на устоявшемся рынке.

Вторая встреча была в офисе компании Яндекс (практически офис мечты), там проходила встреча посвященная uTest. Первая в России вообще. Организатором, в очередной раз, стал Роман, о котором я уже писал несколько раз в контексте сообщества тестировщиков Санкт-Петебурга (я надеюсь, что в дальнейшем, когда я буду писать об интересных событиях в тестировании, проходящих в Питере я всегда буду ссылаться на двух, не побоюсь этого слова, активистов тестирования — Романа Твердохлебова и Алексея Лянгузова). Роман же вёл презентацию об основных понятиях в uTest, после которой началась сессия вопросов из зала.

К сожалению, никто не предупредил, что не только Рома будет отвечать на вопросы, но и желательно, чтобы все, кто работал с uTest, также приняли участие в обсуждении. Поэтому отвечать приходилось экспромтом и я совсем не уверен, что всегда подбирал правильные ответы к довольно сложным вопросам. Сам по себе crowdsourcing уже является определённой планкой, и удивительно (!), но большинство участников не знали об этом направлении.

Мне показалось, что многие надеялись на халяву в плане uTest — немного поработать и сразу безобразно обогатиться. Но, к счастью, модель uTest сильно ограничивает новых пользователей в возможностях — доступно мало проектов, есть ограничение на количество одновременно висящих неподтверждённых заказчиком багов и прочее. Всё это позволяет избежать оголтелого читерства. Это, кстати, был один из вопросов из аудитории — почему не заниматься перепостом багов других участников, либо за одним аккаунтом вести тестирование десятку человек, срывая таким образом банк наград на проектах. На него, к сожалению, нет однозначного ответа. С другой стороны uTest не ограничивает развитие участников. Существует система рейтинга, форум для того, чтобы показать себя и найти проекты по квалификации. Есть ещё ежеквартальные соревнования, с необычным для сегодняшнего времени принципом — призы получает несколько человек, которые считаются победителями, а не один единственный.

Так что основа успеха на uTest всё-таки именно в достаточно долгом и упорном труде. Я не имею ввиду то, что нужно проводить на uTest как можно больше времени. Я говорю о том, что подписываясь под участием в каком-либо проекте нужно всегда учитывать:

• Скорость работы. Чем больше ошибок будет найдено, тем лучше. (+1 очко опыта)
• Качество работы. Заказчик должен понимать правильно, что за ошибка была найдена и как её повторить. Чем больше релевантной информации, тем лучше. (+5 очков опыта)
• Ориентация на нужды заказчика. Это, между прочим, потрясающее преимущество uTest — что важно заказчику известно до начала тестирования. Фокус на этом с учётом скорости работы и её качества увеличивает шансы получения разнообразных наград (Level up).

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

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

Технические основы того, как начать работать на uTest доходчиво написал Феликс. К этому будет неплохо добавить то, как зарабатывать на uTest, потому что хотя ничего сложного в этом нет, но приходя на uTest в первый раз просто теряешься и не знаешь с чего же всё-таки начинать.

Черт подери, я так надеялся на футболку с зелёным человечком (судя по форуму были и такие где то), но, к сожалению, были только стильные чёрные с логотипом uTest.

Нам невероятно повезло, во-первых мы получили возможность контакта с Японским реселлером. Сложно сказать, что из этого получится, но рынок невероятно «вкусный». Во-вторых, alsedi.com неплохо проревьюили и указали на множество ошибок о которых я и не подозревал (об очевидных речи не шло). Удалось также договориться о тестировании других сайтов специалистом по электронной коммерции. Надо сказать весьма специфические тестирование, в нём нет определённо верного результата, весь тест строится на опыте человека, на его умении проанализировать тенденции, которые превращают посетителей в покупателей. Вообще для компаний, которые что-либо предлагают через сайт это может быть одним из наиболее приоритетных направлений тестирования. Маркетолог такими знаниями не обладает, хотя чаще всего именно маркетологи решают где и какие элементы должны быть расположены, так же частенько лезут в вопросы дизайна страниц. Результат не гарантирует при этом ничего и зачастую удачность решения зависит от случайности. В малой шароварке — это прослеживается очень хорошо.

В остальном по теме тестирования всё оказалось очень уж грустно, хотя и ожидаемо. В условиях небольших и средних шароварных продуктов тестирование не столь уж важно. Пользователи крайне лояльны, прощают многие ошибки, быстро пишут о проблемах в новых релизах. Как пример, совсем недавно сделал перевод одного из продуктов с Ansi на юникод, в результате поломалась функция связанная с паролем. Фактически любой пароль стал вот такого вида «h??????». В первый же день я получил больше сорока писем о проблемах с паролем (надо отметить, что использование именно этой функции не обязательно, но те кто начал её использовать с программой работать больше не могли, а она предназначена для частного использования в общем то). После исправления и рассылки новостей об исправлении я получил еще несколько десятков писем о проблемах при запуске программы, но уже по другой функциональности. Снова пришлось выпускать апдейт. И после всего этого ни один человек не потребовал назад свои деньги и гневных писем так же не было.

Завершало официальную программу трёхчасовое выступление Антона Карпенко. Он очень хорошо разбирается в тематике шароварки и продвижения продуктов, но из-за темперамента и уровня звука мне его слушать тяжело, поэтому его рассказ я слушал уже в записи. Надо сказать мыслит он свежо и то, что он предлагал на этой конференции не требует титанических усилий, в случае успеха сработает как вирусная реклама, хотя если бы было всё так просто все шароварщики были бы миллионерами. Фактически распространение в социальных сетях равносильно сабмиту, но менее контролируемо и менее прогнозируемо. С другой стороны в случае успеха… в общем то тоже не понятно, что будет.

Домой мы выехали в шесть утра, но потратили больше 20 часов для того чтобы добраться. По пути останавливались и бродили по лесам Белоруссии в поисках грибов (я нашел скелет лося), в России тоже останавливались для поискав, но уже без успеха, если не считать здоровенный зонтик.

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

Заинтересованные в релизе группы людей

Список вопросов неполный, но QA должны знать ответы хотя бы на них. Для этого, в первую очередь, потребуется отслеживать выполнение задач по разработке и тестированию. Существование трекера первый шаг к построению нормальной информационной системы.
Подойдет любая система трекинга, в которой можно реализовать такую структуру (я предпочитаю Atlassian Jira, для небольших проектов Eventum):

• Backlog – группа проектов в которой по версиям и продуктам разбиваются пожелания и требования бизнес стороны. Это не только спецификации (ТЗ), но и простые заметки, пришедшие от бизнес стороны в стиле «нужно сделать это, примерно вот так функционирует и выглядит». На основе таких «business story» можно построить спецификацию и согласовать с бизнесом.
• Development Project – Группа проектов по разработке конкретных продуктов. Основная часть задач появляется с привязкой к Backlog проекту. Это позволяет отслеживать соответствие требованиям бизнеса и начать работу QA еще до завершения разработки (что-то вроде Test Driving Development, но мягче).
• Feedback – Группа проектов для получения отзывов от клиентов и бизнес стороны по работе текущей версии и проблемам с ними связанным (но не для трекинга багов по разрабатываемой версии).
• QA – Группа проектов, привязанных к таким же проектам в Development Project. В них будет вестись трекинг задач, связанных с тестированием версии или общей работы, но не багов!
• Bugs – Группа проектов, привязанных к проектам в QA и Development Project. Здесь тестировщики создают все таски связанные с найденными ошибками и предлагают улучшения проектов.

Зачем нужно три проекта для QA? Для того, чтобы не создавать мусорной кучи. Feedback доступен не только тестировщикам (которые, по идее, знают о разрабатываемых продуктах больше остальных), но и бизнес стороне. Люди со стороны бизнеса имеют полное право не знать о том, что существует множество версий и множество компонент внутри продуктов, но должны иметь возможность сообщить о проблеме при работе. Для этого им нужно знать только что они делали и версию продукта, с которым они работали (а не всю систему), когда появилась проблема.

Причем, не важен тип решения (а пользователь может и не знать что там еще стоит за окном в которое он смотрит), разрабатываемого компанией:

• самостоятельное приложение;
• серверное приложение с доступом из стороннего (Web сервис, XML/HMTL сервер);
• клиентское приложение с доступом к стороннему (Debuggers, разнообразные сетевые клиенты);
• клиент-серверное приложение, с собственным сервером и клиентом (платформы с удаленным доступом);

Разобраться где конкретно ошибка и ошибка ли дело QA и разработчиков. Часто разработчики могут сделать это быстрее.

Тестировщики знают о продуктах компании больше и лучше понимают структуру проектов. Соответственно, могут указать намного больше данных при заведении ошибки. Для тестировщика требуется совершенно другое окружение и набор возможностей при заведении багов, чем бизнесу. Создание одного проекта приведет к тому, что либо будут проблемы у бизнес стороны, либо тестировщикам придется урезать вводимые данные. Так же, если записи бизнеса о проблемах не всегда являются прямым руководством к действиям разработчиков, то ошибки, найденные тестировщиками, должны как можно быстрее обрабатываться и в соответствии с серьезностью переноситься в план разработки или расстреливаться исправляться сразу.

Группа проектов QA позволяет отделить работу по тестированию от результатов. Для каждого релиза создается свой набор обязательных задач для проверки. В зависимости от проекта и версии список может меняться, адаптируясь под условия. Вместе с рутинными задачами в эти проекты могут быть добавлены задачи относящиеся к процессу тестирования. Например, автоматизация тестов, исследования программ и методик для тестирования.

Принципиальная схема процесса при такой структуре проектов выглядит так:

При использовании этой схемы Backlog объединяет в себе первичные требования бизнеса, общее обсуждение технической реализации или ТЗ (в зависимости от возможностей), проблемы из Feedback и Bugs, которые требуют много времени на исправление или переработки бизнес логики. Основные задачи в Backlog описывают большие куски работы, разбиение которых делается через сабтаски. Далее эта информация клонируется (или разбивается на части и клонируется) в проекты по разработке и добавляется в задачи по подготовки к тестированию в QA проектах (написание тесткейсов, переработка существующих тестов, автоматизация и так далее). После релиза в соответствующем проекте QA создаётся общая задача на тестирование, а конкретная работа выделяется в сабтаски. При нахождении ошибок при тестировании они описываются в соответствующем проекте Bugs и либо клонируются в Development Project, либо заносятся в Backlog для позднего исправления. Процесс запускается по новой… в идеале.

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