Сами описания ошибок можно посмотреть на сайте сообщеста Common Weakness Enumeration.

Попался на этом, вовсе не джуниор, а самый настоящий, матёрый тимлидер.

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

Список вопросов неполный, но 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 для позднего исправления. Процесс запускается по новой… в идеале.

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

Когда я пришел в компанию, у меня был довольно большой опыт в ведении тестирования (как части QA) и разработки программ. Опыта управления процессом, в котором задействовано много людей и разные команды, практически не было. Фактически, на тот момент «картина мира» для меня выглядела так.

Мифическая организация разработки

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

В большой компании, выпускающей крупные продукты, с разделенными географически офисами (сюда можно включить оффшорные компании и местные (domestic) филиалы компании), эта схема разбивается вдребезги. Всё оказалось намного сложнее. Бизнес сторона не всегда может что-либо спланировать или четко сказать, что нужно сделать. Изолированность оффисов приводит к недостатку коммуникаций и не пониманию реальной ситуации и потребностей. А о технической документации вообще задумываются редко, особенно когда речь заходит о взаимодействии связанных, но разных частей системы (лучший пример клиент-серверная архитектура). А помимо пресловутого треугольника существует еще множество разнообразных служб и подразделений: Application Management, Системные администраторы, Backoffice, поддержка клиентов и пользователей и бог знает кто еще. И все, даже новенькая уборщица, имеют свой собственный взгляд на то, каким должен быть финальный продукт. Шутки шутками, но в реалиях действительно существует множество людей, прямо или косвенно использующих финальный продукт, имеющих разные взгляды на разработку и качество продукта. В результате всего этого, при отсутствии продуманного менеджмента, через некоторое время, возникает хаос. Часто, в этот момент владельцы или топ-менеджеры задумываются о тестировании и Quality Assurance.

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

• нерегулярное или несвоевременное оповещение руководства о проблемах и статусе тестирования в целом;
• не совсем корректное и эмоциональное общение с членами процесса, которых я по каким-либо причинам считал профанами или бездельниками, но это противоречило мнению руководства;
• слишком большой упор на скурпулезное документирование в разработке;
• негибкость и непрозрачность процессов тестирования;
• не всегда четкий план и сроки тестирования;
• недостаточное количество метрик для оценки качества релизов;

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

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

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

«Указанные данные устаревшие, плюс все платежи мы принимаем только через сайт! В автоматическом режиме»

Деньги обещали добавить, но это слабое утешение, поскольку не понятно, а все остальные варианты платежей актуальны ли? Для многих компаний это может обернуться банкротством. Так что веб тестировщикам, пожалуй, стоит проверить чек листы – есть ли в них проверка актуальности финансовой информации?

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

Причины этого бага, скорее всего, в том, что сначала обрабатывается синтаксис wiki, а потом вызывается обработка URL в тексте, соответственно и все ссылки с “++”, “__”, также могут быть обработаны неправильно, либо искажены.