Объёмы тестирования платёжного ПО.

Собственно описание ситуации.
Полтора года работаю тестировщиком в харьковской компании, которая занимается разработкой всего спектра программных решений для работы банков в одной платёжной системе. Среди прочего разрабатываем ПО для осуществления финансовых операций с помощью чиповых карт на POS- и PC-терминалах, а также для оплаты чиповыми картами в Интернет-магазинах, которые поддерживают оплату чиповыми картами упомянутой платёжной системы.
Т.е. имеется 3 проекта: POS-терминал, PC-терминал, распределённый Интернет-терминал и я отвечаю за их тестирование. Это мой первый опыт в тестировании (до этого 2 года был разработчиком на Delphi\Oracle в своём вузе).

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

По плану руководства с мая 2010-го года во все эти проекты начали вноситься одни и те же функциональные возможности (готовится предложение банкам) - назовём их "функционал Х2". На Интернет-терминале, в отличие от PC и POS-терминалов не были реализованы некоторые функции (назовём их "функционал Х1") ввиду отсутствия в них необходимости, однако реализация функционала Х1 является необходимым условием для реализации функционала Х2, т.е. весьма упрощённо говоря Х2 без Х1 не имеет смысла и не работает.

Таким образом функциональные возможности Интернет-терминала довольно сильно расширились и соответственно выросли объёмы тестирования. Понятно, что вырастает и необходимое тестовое покрытие на всех проектах.

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

Так вот, на данный момент Интернет-терминал проходит терминал сертификацию в НБУ, а "железяки" только готовятся к этому. Сроки по сдаче продукта на сертификацию были затянуты на 2 недели. С "железяками", чувствую, будет то же самое.

К чему я это всё описываю. Всё чаще со стороны (около полугода) руководства становится вопрос "А чё ж так долго-то?".

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

Складывается впечатление, что наш гендиректор наш часто не понимает специфики работы нашего отдела:
Несмотря на все наши объяснения он таки делает вид (оговорка - мне так кажется), что непонимает того, что наш отдел занимается лишь контролем качества. За сроки выхода продукта в его представлении почему-то отвечает только наш отдел. И никого не интересует, что один из разработчиков часто даёт некачесвенный билд, который практически сразу же уходит к назад на доработку. Разработчики святы по определению :) - это наш отдел портит всю работу. Я не витаю в облаках - я понимаю, что у отдела тестирования самое политически невыгодное положение. :)

Мы с моим непосредственным руководителем как можем без технических деталей объясняем почему сроки могут смещаться, но никого это не интересует.
Самостоятельно могу сократить лишь проверку регрессий на Интернет-терминале, чтобы убедиться, что базовые фичи работают и получить время на проверку нового. Решил пока использовать Python+AutoIT, поск. денег на платные инструменты у нас выделять не жаждут. Ос


Поскольку стену непонимания на высшем уровне мы уже отчаялись проламывать, то у меня остро стоят вопросы:
1. Можно ли обходиться без полной проверки такого рода терминального ПО, и после внесения изменений проверять лишь наиболее критичный функционал, ориентируясь на вероятности возникновения у клиентов рисков, связанных с неполадками в нём? Или же
2. Гнуть свою линию и не сдавать ПО в эксплуатацию до момента завершения тестирования всей функциональности по всему списку проверок.

1-й вариант, конечно, больше удовлетворит начальство и клиентов. Да чего там - и меня тоже :), но как-то стрёмно становится. Если полезут некритичные ошибки, это тоже мало кому понравится и надо будет в который раз объяснять руководству очевидное: цену получения продукта в заданный срок с учётом ограниченности ресурсов.

Что скажете, коллеги?

Вариант 1й конечно соблазнителен в вашем случае, но в случае неполадки вы же будете виноваты. Думаю нужно стоять на варианте 2, в таком случае не будет риска и все довольны, начальство нужно уметь уговорить. Рекомендую почитать: Рекс Блэк "Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование" там в примерах описано как оценить риск и уговорить начальство правильно тестировать продукт.

Вариант 1й конечно соблазнителен в вашем случае, но в случае неполадки вы же будете виноваты

Я как раз об этом и сказал :)

А за книгу благодарю. Недавно был на книжной балке и заинтересовался - теперь точно приобрету почитать.

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

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

Приведу пример. Идёт процесс тестирования новых версий ПО для POS- и PC-терминала. Утро четверга, до конца недели 2 дня, за которые процесс тестирования планировалось завершить (с учётом того, что отвлекаюсь на вопросы поддержки). К нам вбегает взъерошенный менеджер и спрашивает: "Слушай, а когда вы отправите клиенту N версию с фичей X?". Текущую версию ждут клиенты, которые к концу недели ожидают увидеть заказанные доработки. Новую же фичу планировалось добавить в начале следующей недели и, проверив, отправить клиенту билд по готовности, но не позже конца следующей недели, о чём я менеджера и известил. Сроки были оговорены заранее с моим руководителем и со мной, а тут новая вводная. Как позже выяснилось, гендиректор на просьбу клиента пообещал ему новые сроки. Мой руководитель вопрос уладил, но эта ситуация не единична.
Возможно, коллеги, вы скажете, что можно было постараться вписаться в срок или как-то по другому обыграть ситуацию. Не отрицаю - может и можно, но мне важно было описать один из принципов отношений.
Есть ли какие-то способы повлиять на это?

P.S. Я смотрю, что мой вопрос уже отклонился от области тест-менеджмента. Может стоит его перенести в другой раздел?

А кто ответственен за выпуск продукта? Как этот человек относится к тестированию и к качеству релизов?

Сложно ответить не зная всей структуры и механизма, но то что сроки оговариваются с клиентом это правильно, накидка на тестирование должна быть в любом случае, но фичу X клиент не должен ждать пока вы протестируете весь функционал, да и если он будет расти, то всё вы протестировать все-рано не сможете, вам нужно правильно построить политику тестирования: что и когда тестировать. Допустим сделали фичу X1, я думаю, что вы должны протестировать ее и область вокруг нее, то на что она может повлиять, то же самое с фичей X2, 3 и т.д.

А кто ответственен за выпуск продукта?

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

то что сроки оговариваются с клиентом это правильно, накидка на тестирование должна быть в любом случае

Может я как-то нечётко формулирую, но ситуация как раз и состоит в том, что участились случаи, когда мы и знать не знаем, о том, что кто-то там с кем-то договорился о сроках - нам их спускают сверху без предварительного включения в план и обсуждения. Вслед за этим новой заявке выставляют наивысший приоритет, а затем интересуются в духе "А что ж вы не сдали до сих пор доработки A, B, C?". А именно они и были отложены в сторону при получении новой заявки с наивысшим приоритетом. Я хочу, чтоб меня правильно понимали - у меня нет цели выставлять высшее руководство глупцами и показать какой я умный. Просто складывается впечатление, что у него есть некое недопонимание ЖЦ ПО. Как его устранить и нужно ли это делать - уж и не знаю теперь.

фичу X клиент не должен ждать пока вы протестируете весь функционал

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

вам нужно правильно построить политику тестирования: что и когда тестировать

Нужно :) стоит начать с оценки рисков, как и было указано ранее?

Нужно :) стоит начать с оценки рисков, как и было указано ранее?

Думаю да, при том вам нужно оценивать каждую конкретную задачу, и делать это нужно на начальном этапе, а не когда уже все оговорено и сделано.

и делать это нужно на начальном этапе

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

и делать это нужно на начальном этапе

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

На этапе планирования, если у вас есть такой этап разработки.

и делать это нужно на начальном этапе

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

На этапе планирования, если у вас есть такой этап разработки.

А, понятно. Благодарствую за ответы.
А что скажете по поводу учёта выхода в свет тестовых версий ПО? Стоит ли или может остановиться приёмочных тестах?

Может я как-то нечётко формулирую, но ситуация как раз и состоит в том, что участились случаи, когда мы и знать не знаем, о том, что кто-то там с кем-то договорился о сроках - нам их спускают сверху без предварительного включения в план и обсуждения. Вслед за этим новой заявке выставляют наивысший приоритет, а затем интересуются в духе "А что ж вы не сдали до сих пор доработки A, B, C?". А именно они и были отложены в сторону при получении новой заявки с наивысшим приоритетом. Я хочу, чтоб меня правильно понимали - у меня нет цели выставлять высшее руководство глупцами и показать какой я умный. Просто складывается впечатление, что у него есть некое недопонимание ЖЦ ПО. Как его устранить и нужно ли это делать - уж и не знаю теперь.

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

Получив указание выполнить некую заявку с наивысшим приоритетом, вы донесли до руководства, что ее выполнение вызовет сдвиг сроков выполнения доработок А, В и С на такое-то время в связи с тем-то и тем-то (оригинальный план работ приложен; план, учитывающий сверхприоритетную заявку приложен)? Вы убедились в том, что руководство поняло, что вы хотите до них донести? Руководство дало добро на сдвиг сроков выполнения доработок ради выполнения высокоприоритетной заявки? У вас есть подтверждение сдвига сроков доработок, документальное или хотя бы устное?

Прокомментируйте пожалуйста.

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

А на оснований чего, коль не секрет? Мне кажется, что ёё - хоть отбавляй. Возможно, я могу не замечать проблем в форме её подачи.

Получив указание выполнить некую заявку с наивысшим приоритетом, вы донесли до руководства, что ее выполнение вызовет сдвиг сроков выполнения доработок А, В и С на такое-то время в связи с тем-то и тем-то (оригинальный план работ приложен; план, учитывающий сверхприоритетную заявку приложен)?

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

Вы убедились в том, что руководство поняло, что вы хотите до них донести? Руководство дало добро на сдвиг сроков выполнения доработок ради выполнения высокоприоритетной заявки?У вас есть подтверждение сдвига сроков доработок, документальное или хотя бы устное?

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

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

Но даже задокументированные следы таких решений и указание на их наличие порой не спасают от вопросов типа "А почему не готова фича Х" (а именно по ней и были отложены работы в жертву приоритетной заявке).