Как заслужить доверие заказчика при передаче проекта новой команде тестирования?
•Download as PPT, PDF•
0 likes•1,124 views
Доклад Германа Варгина на конференции SQA Days-17, 29-30 мая 2015 г., Минск www.sqadays.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Как заслужить доверие заказчика при передаче проекта новой команде тестирования?
Similar to Как заслужить доверие заказчика при передаче проекта новой команде тестирования? (20)
More from SQALab
More from SQALab (20)
Как заслужить доверие заказчика при передаче проекта новой команде тестирования?
- 1. Software quality assurance days 17 Международная конференция по вопросам качества ПО sqadays.com Минск. 29–30 мая 2015 Варгин Герман Валерьевич T-Systems Rus. Санкт-Петербург, Россия Как заслужить доверие заказчика при передаче проекта новой команде тестирования
- 2. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? О чем поговорим Что такое передача проекта новой команде тестирования? Какие бывают проблемы при передаче? Способы решения проблем Выводы
- 3. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Зачем нужна передача проекта? Аутсорсинг проектов Открытие офиса в другой стране Изменения в законодательстве Другие причины
- 4. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Проблемы
- 5. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Недружелюбные коллеги
- 6. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Чужие тест кейсы
- 7. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Сложность проекта
- 8. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Недоверие заказчика Заказчик привык к своей команде Заказчик действует по принуждению Заказчик не знает новую команду Старые коллеги давят и влияют на мнение заказчика
- 9. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Решение проблем
- 10. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Визуализация результатов Конспект, минутки Матрицы трассировки Метрики, графики Скриншоты
- 11. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Оповещение о найденных дефектах
- 12. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Тестирование в режиме Testflag Использование заглушек Выполнение внутренней бизнес логики
- 13. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? E2E тестирование: Testflag=0
- 14. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Обновление тест кейсов Согласуйте план обучения Создайте папку с тестами для тренировок Заведите таблицу ответственности Собирайте метрики по тренингам Участвуйте в анализе тестов
- 15. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Тесты для обучения
- 16. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Еженедельные отчеты Responsible person Functionality Total TC Total Executed Total ex. in % Tester 1 Name 1) Authorization 2) Emails 3) Services 268 192 74% Tester 2 Name 1) Business process 197 197 100% Tester 3 Name 1) Reporting 2) News 217 201 92% Tester 4 Name 1) Automation 2) Performance 870 338 39 % Tester 5 Name 1) Automation 2) Performance 870 410 47%
- 17. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Забудьте о личных обидах
- 18. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Общение с коллегами Съездить в командировку Добавить в копию заказчика Предложить коллегам новые инструменты Узнать контактные данные партнерских систем
- 19. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Выводы Все время нужно быть нацеленным на результат Доверие заказчика сложно заслужить Доверие заказчика очень просто потерять
- 20. Как заслужить доверие заказчика при передаче проекта новой команде тестирования? Вопросы? german.vargin@t-systems.ru vargin.german@gmail.com gvargin https://www.linkedin.com/profile/view?id=159116867 http://vk.com/vargin.german Спасибо за внимание!
Editor's Notes
- 1) Мы рассмотрим различные примеры переходов IT проектов от одной команды тестирования к другой. Я расскажу о своем личном опыте 2) Я расскажу о проблемах, с которыми сталкивался я в своем проекте. 3) Я предложу варианты решений вышеперечисленных проблем 4) Сделаем выводы, я постараюсь ответить на ваши вопросы
- Аутсорсинг – простой пример, когда одна компания при расширении проекта не может нанять десяток специалистов по тестированию, и заключает договор со сторонней компанией. Часто крупные IT компании открывают центры разработки в других странах таких как Китай, Индия, Россия. Обратный случай. Компания уже открыла проект в иностранном офисе. (например проект разрабатывает сервисы компьютерной безопасности). Может выйти закон о том, что подобные сервисы можно разрабатывать только внутри страны. И в таком случае компании придется выполнять передачу проекта Любые другие причины: внезапное увольнение сотрудников, желание заказчика, риски и т д
- С одной стороны, если мы состоим в команде, принимающей проект, то у нас все хорошо. Но, как показывает практика, получить проект и заслужить доверие заказчиков очень сложно. Возникает ряд проблем, с которыми не всегда просто справиться. Я разделяю эти проблемы на три типа. 1) Проблемы, связанные с коллегами, которые раньше занимались проектом 2) Проблемы, связанные со сложностью системы, процессов, качеством требований и т д 3) Проблемы связанные непосредственно с заказчиком
- Если проект разрабатывался несколько лет и накопилось множество тест кейсов, то изучение, обновление займут много времени. Пока мы изучим и обновим все тест кейсы, ситуация в проекте может поменяться
- В крупных проектах бывает множество партнерских систем. У каждой системы есть свои ответственные люди, которых вы не знаете. Сторонние партнерские системы могут быть недоступны во время тестирования вашей системы Доступ к сторонним системам часто запрещен или ограничен
- Заказчик давно работает со своей командой, привык к ней и пережил много релизов. Он знает их сильные и слабые стороны. О вас заказчик почти ничего не знает. Часто бывает так, что начальство нашего заказчика требует замены команды без его согласия. Если возникнут конфликтные ситуации, то скорее всего заказчик будет на стороне своих проверенных коллег (даже если они не правы)
- Теперь от проблем перейдем к их решениям. Я начну с проблем, связанных с заказчиком, потому что считаю, что они самые важные.
- Заказчик любит визуализацию. Когда вы проходите тренинги, участвуете в митингах – составляйте минутки. В моем проекте мы конспектировали абсолютно все. После каждого тренинга составлялся Word документ, где было описано кто проводил тренинг, кто в нем участвовал, какие задавались вопросы, какие были ответы. Если это был мастер класс, то мы повторяли все действия и делали скриншоты. Была создана папка, куда все тренинги сохранялись и заказчик мог в любой момент посмотреть и оценить качество этих тренингов. Мы составили различные матрицы трассировки, по которым было видно соответствие человек / функциональность / тест кейсы / требования / дефекты и т д Визуализируйте метрики, составляйте графики. Такие вещи часто легче воспринимаются заказчиком, чем простые слова или списки При тестировании мы всегда сохраняли скриншоты выполнения большинства тестовых шагов в тестах. Во-первых это помогло нам в следующих релизах, когда надо было вспомнить что-то, или сравнить результаты с предыдущим релизом. Во-вторых при возникновении спорных вопросов (Как это раньше работало?) у нас всегда был конкретный ответ.
- Сразу после заведения нового дефекта, автор пишет письмо на всю команду о дефекте. Обычно это пересылка автоматического письма из баг-трекинговой системы. Это дает возможность быть в курсе абсолютно всех найденных дефектов в проекте. Избегаем дубликатов. Позволяет заказчику видеть активность и прогресс новой команды. Кол-во найденных дефектов возрастает в процентном соотношении, важность дефектов растет и т д Вовремя узнаем о недоступности сторонних систем, блокирующих тестирование
- Мы предусмотрели возможность тестирования внутренней бизнес логики при недоступности сторонних систем. Использование заглушек (например mock в Soap UI при тестировании веб сервисов) Особый функционал нашей системы, в которой она принимает данные от всех провайдеров, выполняет свои бизнес правила, но не отправляет данные дальше.
- В крупных системах, например той, что разрабатывается в моем проекте – использование простых заглушек нежелательно. Дело в том, что наша система состоит из сложного приложения (B2B system), десятков веб сервисов, базы данных и пользовательского интерфейса. На данной схеме описана последовательность действий, которая происходит при создании заказа в нашей системе. Синим выделены компоненты, которые разрабатыаются внутри моего проекта. Когда тестировщик создает новый заказ в системе (стрелка 1), то приложение сначала отправляет запросы во внутренние веб сервисы, а затем начинает работать с внешними веб сервисами, которые разрабатываются в других проектах. Если никаких проблем не возникло, тестовые данные верны, то B2B отправляет заказ в партнерскую систему. Этот заказ может обрабатываться от нескольких минут, до нескольких дней, в зависимости от сложности заказа, доступности других систем и т д. Когда получен ответ от партнерской системы, B2B возвращает ответ пользователю. Естественно, такие сценарии обязательно нужно проверять перед релизами. Но, когда тестировщик только знакомится с системой, изучает ее бизнес логику, апдейтит все тест кейсы, такой подход к выполнению тестов займет слишком много времени. Поэтому наши разработчики нам помогли и сделали возможность тестирования нашей системы в режиме TestFlag.
- Мы выявили разные разделы функциональности и вместе с заказчиком назначили приоритет. В QC был создан отдельный TestSet, в который входили все тесты. Новая команда постепенно их выполняла, обновляла и по-тихоньку менялся TestSet регрессионного тестирования На каждую функциональность был назначен инженер по тестированию, отвественный за нее. Также был назначен backup
- В QC мы сразу создали папку Training для обучения. Папка включает в себя абсолютно все тесты, которые выполняются в каждом нашем релизе. Заказчик в любой момент может посмотреть прогресс обучения, узнать статус выполнения. В то же время эти результаты не повлияют на его метрики по текущему релизу.
- Каждую неделю мы отправляли таблицу следующего вида. Когда транзишен закончился, заказчик попросил нас отправлять такие же таблицы, чтобы следить за прогрессом выполнения тестов во время релиза.
- Командировка может помочь сблизиться с коллегами и растопить лед. Но нужно быть очень аккуратным и деликатным Если коллеги не отвечают, или отвечают слишком размыто, мы добавляем в CC заказчика. Коллеги использовали просто SSH клиент для анализа логов. В командировке я предложим им использовать opensource инструмент, который позволяет фильтровать логи, выполнять поиск, красиво подсвечивать ошибки и т д. Коллеги, которым понравился инструмент стали “лучшими друзьями” Узнавайте контактные данные всех служб поддержки. Тестеров, разработчиков, аналитиков сторонних систем. Запрашивайте доступ, просите добавить вас в копию писем