Действующие лица:

● JUNIOR — решивший стать аналитиком начинающий боец;

● MIDDLE — системный аналитик, который «понюхал пороху», получил опыт на
нескольких проектах и начал осознавать всю глубину профессии;

● SENIOR — аналитик с богатым опытом разнообразных проектов, большим
количеством навыков и теоретической подготовкой;

● LEAD — эксперт и профессионал в области системного анализа, обладающий,
помимо прочего, хорошими управленческими навыками и лидерскими
качествами;

● ООО «Наша команда» — компания-исполнитель, отвечающей за проектирование и аналитику;

● АНО «Госорган» — организация клиента.

Этап тестирования — барабанная дробь всего проекта: это, как говорится, радость, с сединою на висках. Момент, когда заказчик впервые видит свою систему целиком.Конечно, он и раньше, в процессе согласовывал ее небольшие кусочки и части. Но полная картина до сих пор оставалась за кадром. И вот он — момент. По эпичности и курьезностиего можно сравнить разве только с приемкой платья невесты из ателье, где, под чутким руководством подружек, родственниц и прочих сочувствующих портные и закройщики конструировали ЭТО. Один день мама невесты с тетей Любой обсуждали рукав, другой — жених просил увеличить декольте, бывали и полные собрания всех участников, где
утверждали цвет. При этом, у каждого из них в голове сложился свой образ того, как в итоге должно выглядеть платье, и самое главное — невеста в этом платье. Маме онапредставлялась аристократичной балериной, жениху — кино-дивой с формами, а тетя Люба хотела видела племянницу укутанную в пышные розочки.

Проектом «платье» занимались: LEAD-модельер и команда его закройщиков — SENIOR, MIDDLE, JUNIOR. На предыдущих этапах они фиксировали все пожелания исостыковывали их c объективной реальностью: концепцией свадьбы, комплекцией и типажом невесты, сезоном бракосочетания, сроками и… бюджетом. Стыковка мечты с реальностью — всегда компромисс. И только после того, как он принят, начинается пошив (разработка). Но беда в том, что человек так устроен: он склонен помнить только то, что ему нравится. И поэтому, к моменту сдачи реального платья, мечта о платье идеальном начисто вытесняет из сознания все достигнутые договоренности. Короче, тетя Люба в ожидании розового куста, мама — балерины, а жених — Мерлин Монро.

И вот, под волнительные вздохи к зрителям выходит невеста… Нужно ли говорить, что результат физически, объективно не может соответствовать ожиданиям всех. И даже некоторых. И начинается холивар. Цель каждого из заказчиков — заставить модельеров срочно добавить в платье недостающих розочек, рюшечек и бусинок, чтобы максимально приблизить его к своей мечте (а мы помним, что она у всех разная). Задача модельеров — отбиться от этих икон стиля и не позволить превратить хорошую вещь в Франкенштейна.

Так вот, архитектурный проект и его решение были созданы на предыдущем этапе. А значит здесь их роль заключается в том, чтобы контролировать строительство. LEAD-архитекор контролирует заказчика, чтобы тот вдруг не решил возвести бассейн вместо жилого дома. А SENIOR бригадиров, которые отвечают за свои участки. Старшего — MIDDLEа и младшего — JUNIORа. Бригадиры здесь выполняют самый большой объем работ: они полностью обеспечивают деятельность строительно-монтажной бригады материалами, чертежами и другими ресурсами. Контролируют сроки работ и качество результата, постоянно принимая массу мелких, но значимых решений, которое требуются в моменте.

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

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

Итак, одна из групп аналитики компании ООО «Наша команда» проектировала и
участвовала в этапе разработки CRM-системы для ООО «Заказчик». На этапе тестирования аналитики столкнулись с полным отказом заказчика от всех своих показаний. Ни о какомприеме речи, в принципе, не шло. «Мы такого не просили» — был единственный ответ на все попытки презентоваться. Аналитики обиделись и ушли в туман. Хитрый PM предложил моей команде денег и всенародной славы. Мы, по-дурости, согласились. И началось.

Войдя в проект, мы поняли, что:
— заказчик ненавидит нас, нашу систему, и в принципе устал;
— на все про все у нас месяц.
Первая, и самая вероятная гипотеза, что документация «не задалась» оказалась
ошибочной — ТЗ было почти идеальное. Вторая гипотеза, что система не работает по ТЗ… тоже не подтвердилась. Случай экзотический. 3 дня команда проверяла и перепроверяла все. И все работало. Но тут нас пригласили на очередную демонстрацию наблюдателями — и прояснилось. При идеальном исполнении, подача была чудовищная. Во-первых, не было живого, понятного сценария **, примеры на User1 Client1 Case1. В переговорке присутствовали все заинтересованные лица***, то есть, около 20 человек. И спустя 10 минут, все эти люди, наглухо запутавшись в абстрактных «юзерах» и «клиентах», начинали кипеть и ругаться друг с другом, используя систему, как повод повыяснять
рабочие отношения. Все было ясно. Никакого иного результата, кроме скандала, такая презентация и не могла дать.

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

Дальше процесс пошел как по маслу: всем все понятно, и никто не кричит. Таким
образом, за месяц мы прошли этап тестирования и перешли к внедрению системы. ООО «Заказчик» доволен. PM ООО «Наша команда» доволен. Нам выдали кубок Хогвардса.

Сначала, они, по заданию LEADа искали несоответствия:
— читали 160 страниц ТЗ;
— ручками проверяли весь функционал системы;
— не веря самим себе, отчитывались о том, что все работает.
После того, как старшие товарищи сходили на встречу:
— JUNIOR и MIDDLE выпрашивали у злющего заказчика живые данные и вносили их в систему;
— подробно и высокохудожественно расписывали сценарии каждого подразделения, умащивая их ссылками на разделы ТЗ.
Когда дело пошло на лад, им добавилось еще счастья:
— фиксировать результаты тестов, комментарии и пожелания заказчиков.

На этом этапе JUNIOR и MIDDLE, вообще обычно, имеют возможность по-настоящему проявить себя. На тестировании они выполняют порядка 80% от общего объема задач инарабатывают свои навыки. Но главное, здесь у них формируется глубокое понимание системы: того, как принятые на этапе проектирования решения превращаются в конечный продукт.

Сначала:
— также изучали ТЗ и функционал на несоответствия, но на более высоком,
концептуальном уровне (является ли полученный результат CRM-системой в принципе).

В общем, веселились ребята. Их деятельность на этапе Разработки закрыла 70% общего объема запланированных работ.

После того, как присутствие на встрече вскрыло проблему формата приемки:
— составили план, как за месяц в корне изменить ситуацию (написать приемочные тесты, составить график и т.д.).

Далее SENIOR взял на себя координацию выполнения плана:
— детализацию сценариев для подразделений;
— курирование работы JUNIOR и MIDDLE.

LEAD занялся налаживанием отношений по принципу «разделяй и властвуй»:
— составил сценарий для руководителей, чтобы выключить лицо принимающее решения из конфликтного предмета;
— отдельно пообщался с каждым руководителем подразделения об его ожиданиях относительно системы;
— составил резюме этих ожиданий в связке с ТЗ;
— при помощи резюме и ТЗ доказал заказчику отсутствие проблем в реализации.

После того, как все подготовительные работы были проведены, SENIOR и LEAD утвердили у заказчика свой план. А дальше спокойно реализовали его, закрыв, таким образом, этап тестирования.

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

Напоминаю, что выше мы описали организацию работы с функциональным тестом. Он универсален, потому что он есть всегда. Но, помимо него, существуют и другие. В сети и литературе большое количество материалов по видам тестирования и их назначения. С Богом!

10е место: Придерживаться той позиции, что тестирование — это черная работа, не достойная Богов и Богинь проектирования.

9е место: Во время теста идти на поводу у несогласных и превращать презентацию в холивар.

8е место: Никогда не фиксировать результаты теста. Это вообще на всех этапах надо запретить.

7е место: Не вставлять ссылки на документацию. Потому что заказчик помнит все наизусть — зачем в человеке сомневаться.

6е место: Презентовать сценарий с множеством альтернативных ответвлений: хороший шпион должен уметь запутать следы.

5е место: Сделать тест бесконечным: подробности ведь очень важны и хорошо
запоминаются, особенно на 3м часу демонстрации.

4е место: Собрать всех и показать им все! Бухгалтеру очень важно, как работают юристы. Он может дать кучу дельных советов.

3е место: Быть уверенным — заказчик помнит все, о чем вы договаривались. Его
ожидания полностью соответствуют документации.

2е место: В топку связанные сценарии! Нужно показать все функции отдельно. Лучшая месть заказчику — наглядная демонстрация, что вся его деятельность бессмыслица.

1е место: Использовать только абстрактные данные: Test 1 User 1. Чем меньше понимает заказчик, тем веселее!

* Обращаю внимание для тех, кто не читал вводную статью: навыки суммируются при повышении квалификации. Это значит, что LEAD имеет все навыки SENIOR, MIDDLE и JUNIOR. SENIOR — навыки MIDDLE и JUNIOR и т.д.

**Живой сценарий — набор действий в системе, который моделирует реальную рабочую ситуацию заказчика.

***Заинтересованные лица — представители заказчика, которые могут влиять на проект, его результат и отдельные задачи.