Пресейловая оценка проекта по нагрузочному тестированию

Как делать технический пресейл сложных проектов по нагрузочному тестированию.

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

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

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

Задача

Задачи оценки, если коротко:

Сформировать понимание относительно методологии тестирования (в голове должна сформироваться «методика в кратком изложении»).
Прикинуть, сколько времени уйдёт на разработку.
Выявить явно проблемные участки и заложить время на некоторые риски.

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

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

Например, безобидная задержка в предоставлении рабочих учётных записей предприятия повлечёт простой команды (из 3-х человек) и выльется в несколько десятков «килорублей». Таким образом мы выставляем приемлемую цену и стимулируем Заказчика обеспечить нам все условия, чтобы зависящие от него риски не сработали. Если всё равно цена слишком высока, то по согласованию с Заказчиком можно сократить объём работ (например, количество тестов, количество тестовых сценариев), но нельзя сокращать трудозатраты на разработку того, что делается точно. Если после всего цена всё равно слишком высока (это не скупой Заказчик, это менеджеры, которые мало заложили средств на НТ), то дальше только сокращать рентабельность. Тут уже не надо переживать, что проект уйдёт конкуренту. Пусть лучше конкурент понесёт убытки, а не мы.

Объект тестирования

Желательно узнать официальное название тестируемой системы, точную версию, в общих словах узнать предназначение, которому служит система в бизнесе Заказчика. Часто специалисты Заказчика не знают полного названия системы — тогда его должен узнать пресейл-менеджер. Коммерческое предложение, в котором система названа некорректно, сразу настораживает Заказчика, заставляя его усомниться в компетенции Исполнителя.

Цели тестирования

Выяснить, какой результат хочет получить Заказчик при помощи НТ. Исходя из этого, сформировать цели тестирования, например:

проверка готовности системы к вводу в эксплуатацию (для новых систем или новых версий/релизов имеющихся систем);
исследование стабильности работы системы под нагрузкой;
выяснение, как будет вести себя система на нагрузке, ожидаемой через год;
выяснения запаса по количеству работающих пользователей на данном оборудовании;
внедрение процесса регрессионного НТ (регулярное тестирование релизов);
сравнение производительности системы на оборудовании Х и Y;
…

Вообще от целей проекта зависит очень много, цели всегда должны быть зафиксированы однозначно, согласованы и должны быть всем-всем-всем понятны. Частенько случаются Заказчики которые сами не знают чего хотят, тогда помогайте формулировать цели. Не подписывайтесь под абстрактные цели, требуйте конкретики. Не подписывайтесь под то, что нет четкой возможности выполнить, например: увеличение производительности в 2 раза или экстраполяция результатов тестирования.

Будьте начеку, заявленные цели могут не соответствовать реальным. Да, такое встречается в нашей практике, например: цель — утопить в крови отдел разработки и вывесить голову главного разработчика на пику перед офисом, не стоит воспринимать буквально.

Архитектура системы

Выяснить список используемого системного ПО, платформенного ПО (названия, версии), верхнеуровневые компоненты системы, внешние системы и интеграционные связи. Составить схему системы или словесное описание. Выяснить, какие компоненты надо будет эмулировать (например, пользователи, внешние системы).

Будте дотошны. Заставьте их рисовать схемы взаимодействия. Иногда забытые взаимодействия с внешними системами неожиданно появляются в процессе рисования схемы. Каждая стрелочка на схеме взаимодействия имеет Имя и Фамилию.

Оценка разработки тестовой модели

Для систем, нагружаемых пользователями, например, типичные двух- и трёхзвенные приложения:

Выяснить топ операций пользователей, создающих основную нагрузку на систему. Для этого запросить статистику по операциям (для эксплуатируемых систем). Для систем, не находящихся в промышленной эксплуатации, либо в случаях, когда статистику по операциям собрать невозможно, запросить экспертную оценку у специалистов Заказчика. Если статистика не предоставлена, узнать, на ком будет сбор статистики в случае старта проекта. Бывает, что Заказчик сам готов предоставить статистику и составить профиль, тогда в ограничения проекта нужно записать, что тестируются только операции из предоставленного профиля. Если же нет, то это становится отдельной задачей для нас и добавляется в трудозатраты.
Выяснить протокол, который используют пользователи для подключения к системе (HTTP, JDBC и т.д.) для операций из п. 1.
По возможности пройтись по бизнес-процессу с точки зрения пользователя (по операциям из п. 1). Оценить количество и сложность действий пользователя (количество полей ввода, количество экранов, количество ролей в бизнес-процессе).
Определить, не используются ли в системе решения, которые потенциально могут затруднить разработку скриптов, например, Java-апплеты, генерирующие трафик, объекты ActiveX и тому подобное.
Определить, потребуется ли передача данных между скриптами (например, когда в цепочке бизнес-процесса присутствуют этапы, на которых требуется «знать» определённые сведения (к примеру, подача заявки на кредит и проверка результата)).
Если возможно, произвести пробную запись активности пользователя на планируемом инструменте НТ. Оценить сложность трафика. В случае сомнений забрать трафик с собой (если вы на территории Заказчика) и посоветоваться с коллегами. Ахтунг: Siebel CRM, веб-приложения на Oracle ADF и прочая экзотическая «нечисть».

Для систем, нагружаемых другими системами (интеграционные шины, Middleware):

Тот же вопрос касательно статистики: есть ли у Заказчика понимание о том, какие операции будут входит в нагрузочный тест. Если есть, то добавляем этот список в ограничения. Если нет, то добавляем задачу по сбору статистики.
Узнать протоколы по которым взаимодействует тестируемая система с внешними системами (SOAP, JDBC, NET8, DCOM и т.д.). Если из предыдущего пункта есть понимание об операциях, которые войдут в профиль, можно ограничиться только ими, в противном случае желательно узнать про все сценарии взаимодействия. Не будет лишним запросить примеры взаимодействия, особенно если сомневаетесь. За одно узнаете насколько быстро Заказчик отвечает на технические вопросы.
Определить, требуется ли определённая логика в передаваемых данных, например, есть взаимосвязи между некоторым сообщением и последующими сообщениями, есть ли в системе ограничения, которые не позволят корректно обработать произвольные данные. Если есть (а как правило, есть), то стоит сразу задуматься о способе обхода этих ограничений. Ими могут быть: выгрузка реальных продуктивных данных и повторная их отправка в ходе теста, формирование сообщений с подстановкой данных по определённым правилам (всяческие ID из определённых справочников).

Думайте об этом, когда закладываете по пол дня на скрипт.

Оценка подготовки пулов данных

Здесь должны быть рассмотрены следующие аспекты:

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

Оценка разработки эмуляторов внешних систем

Выяснить, возможно ли для целей НТ поднять реальные копии внешних систем. Для систем, копии которых создать невозможно, выяснить количество таковых, а также:

наименование и версию системы;
используемый протокол общения с тестируемой системой;
какая сторона является инициатором взаимодействия;
какова интенсивность взаимодействия.

Если Заказчик говорит, что у него уже есть эмулятор внешней системы, ненавязчиво поинтересуйтесь у него: какую нагрузку он выдерживает, имеются ли у него исходники, и сколько лет назад они его запускали?

Тестовый контур

И тут мы плавно подходим к главному вопросу, есть ли у Заказчика тестовый контур и какой. Если тестового контура нет, то сложность проекта повышается в разы. Тут нужно учитывать, что организация тестового контура дело хлопотное и долгое, не говоря уж о том, что дорогое. И бывает, что Заказчик хочет пойти по пути наименьшего сопротивления и протестировать все на продакшене. Для тех кто так делает — в аду на 4-м круге ждут особые задания. Обычно я объясняю, что чем ближе тестовый стенд к продакшену, тем точнее будут результаты. Идеал — 100% соответствие, в некоторых случаях можно 60%, но надо понимать, что проводить нагрузку на контуре в 10% от продуктивного толку мало. Если нагрузочного стенда нету, то мы можем помочь с его организацией, арендой железа или развертыванием тестового окружения в облаке. Часто мы делаем оценку для нескольких вендоров и предлагаем выбор.

Оценка генерации данных

Выяснить, требуется ли генерация данных. Как правило, для полноценного НТ генерация требуется в следующих случаях:

система новая и не наполнена данными;
требуется прогноз поведения системы через год (два, три), когда объёмы вырастут.

Обсудить, кто будет генерировать данные: заказчик или мы. Если мы, то нужно узнать:

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

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

Обезличивание данных

Тут мы спрашиваем, нужно ли? Если нужно, то кто будет делать? Суть вот в чем, если в тестовом контуре несколько подсистем, то все может оказаться сложнее, чем кажется на первый взгляд. А если еще требуется согласование с «безопасниками, «то перед вами откроется чудный дивный мир переписки с СБ.

Лицензионные вопросы, количество VU

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

Вариант с разбиением на этапы

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

Этап разработки методики
Этап разработки инструментария
1-я итерация тестирования
2-я итерация тестирования

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

Вообще, очень многие компании (особенно с недостаточным уровнем зрелости ИТ) страдают гигантизмом, т.е. хотят внедрить сразу все виды тестирования сразу на все системы и еще DevOps. А потом удивляются — что так дорого? Так делать не надо, слона едим по частям.

Если очень сильно хочется повысить качество всех ИТ систем, можно попробовать сделать центр компетенций по тестированию, в который постепенно подключать системы на сопровождение.

Вовлеченность Заказчика

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

Особенно бдите, когда вы делаете проект на субподряде, тут могут возникнуть дикие орг. риски из-за конфликтов подразделений и лаги по согласованиям всего.

Удаленка

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

Проектные Артефакты

Иногда, по причинам исторически сложившимся многие Заказчики привыкли к определенному виду отчетов, методик и прочих проектных артефактов. Стоит уточнить, не нужно ли оформление по ГОСТ, нет ли желания использовать наши классные красивые шаблоны документов? А не сделать ли мощную презентацию для Бизнеса по окончанию проекта? Выясняем сколько и каких артефактов получится и на каких этапах.

И хотя проектные ожидания больше должны волновать сейлов, часто именно вам придется пояснить Заказчику, в каком виде он получит ответ на свой вопрос. Будет ли результатом проекта удобный инструмент и фреймворк, с которым можно жить и тестироваться долгие годы, или разовый маленький отчет на 2 странички.

Защита оценки

Это тоже надо уметь и в любое время дня и ночи объяснить, почему нельзя записать этот скрипт за 2 часа и аргументированно пояснить зачем нужен и что значит каждый этап. Ведь в чем задача менеджера, который сидит напротив вас? Отжать вас по стоимости и срокам, и если уж и ввязываться в нагрузочное тестирование, то сэкономить как можно больше. С другой стороны жабу можно придушить, если есть уверенность, что вы шарите в теме, реально погружаетесь в задачу и готовы действительно ее сделать. Заказчик на самом-то деле ужасно боится, что придут какие-нибудь горе-студенты, и через 3 месяца окажется, что ну… как бы это помягче — окажется что ничего не вышло: Исполнитель растворился в неизвестном направлении, а время безвозвратно потеряно.

Ваша задача, обосновать почему, и ответить уверенно на любые странные вопросы.

Итак FAQ:

- Компания Y сделает это в 2 раза дешевле! 
- Серьёзно? Они точно поняли объем задачи? Может быть у них есть особый тип проектов сделать "на от***ись", и они вас кинут, как только поймут, во что ввязались.

- Нам надо сделать это к "Называет нереальный срок"
- Ваша команда готова выходить в выходные?

- А что если мы проведем нагрузочное тестирование силами пользователей? 
- А что если для устранения дефектов производительности вам потребуется провести 10 итераций?

- Чем вы лучше ваших конкурентов? 
- Тут вы выдаете заготовленный бодрый спич, про то какие вы молодцы.

- Менеджер нам не нужен
- Организационные риски, табели, эскалации, план и сроки проекта отслеживаете сами, а мы будем работать как по аутстафу.

- У нас всего ХХХ денег на этот проект
- можем сократить кол-во скриптов и кол-во тестов до YYY, остальное вынести в опциональные этапы.

- Кто ваша команда?
- Тут открывается дверь и входит команда проекта. Неплохо познакомить Заказчика с командой.

- Какие гарантии, что технология рабочая?
- Можем сделать небольшой платный пилот.

- Дайте нам скидку ХХХ
- И тут встает сейл и достает миниган.

Заключение

Иногда, в процессе интервью вам может показаться, что Заказчики — злонамеренно врут, но нет, обычно они просто добросовестно ошибаются. Почему так? Очень просто, вы общаетесь с менеджером, который думает, что знает, что хочет и знает, как работает система. Да, возможно, это так и было когда-то, но чаще всего его знания устарели, или относятся к какой-то одной части системы (мы то знаем, что системы большие и часто меняются и да заказчиков может быть несколько). Желательно перепроверять данные из нескольких источников, больше «курите документацию», общайтесь с технарями.

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