[Тестирование IT-систем, IT-стандарты, Учебный процесс в IT, IT-компании] Управляемое тестирование: с чего мы начинаем, чтобы не было мучительно больно
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, Хабр! В поисках формата для рассказа о практиках тестирования я обратилась к гуглу с запросами “с чего начинать тестирование ПО” и “как подготовиться к тестированию ПО”. И нашла статьи о том, что нужно уточнять требования, применять техники и т. д. Хм… А что, если “составляющими контроля качества ПО” и даже в своем роде глоссариями в том самом поиске и стали стандарты и производные об этапах STLS? Да, все это необходимо – но недостаточно, подумала я.
И если вы, при наличии всех процессов тестирования,
● выводили в PROD не то, что протестировали;
● тестируете не то, что нужно;
● находите баги в PROD, которых точно нет в тесте;
● вынуждены много раз тестировать одно и то же из-за процессных сбоев
– знайте, эта статья для вас.
Велосипед не едет, если у тестирования нет основы. В статье я хочу рассказать, что мы предварительно настраиваем, чтобы тесты были достоверными, эффективными и предсказуемыми.
DISCLAIMER
1. Перечисленное ниже является структурой “предподготовки”, а не готовым шаблоном. Инструменты, подходы, процессы представлены на правах примеров. По уму они должны выбираться исходя из особенностей проекта и продукта. Эти кейсы подходят большой линейке, но не всей (особенно боюсь поднять халивар на тему GIT flow). В любом случае, буду рада обсудить другие кейсы и особенности проектов в комментариях.
2. Наличие “предподготовки” позволяет обеспечить тестирование высокого уровня, но не гарантирует его. Однако при наличии базовых настроек гораздо проще отследить, где проседает тестирование, и принять меры.
3. Я намеренно опустила некоторые преднастройки, которые сильно зависят от принятого на проекте тестирования. Например, если в компании Х принято тестировать продукт серым ящиком, то очевидно, что в качестве преднастройки должен быть организован доступ к тестовым средам. Постаралась выделить самые главные, которые подходят большинству.
Коммуникации
Хорошо выстроенные коммуникации позволяют превратить формальные проверки в клиентоориентированное тестирование.
РОЛИ В ПРОЕКТЕ
Мы выделяем 5 значимых ролей для тестировщика со следующим предназначением:
1. Разработчик – поставляет информацию об алгоритме фичи. Это не вопрос “что тестировать”, его мы не задаем. Знание механизма дает возможность применить техники тест-дизайна на промежуточных шагах и отловить не очевидные дефекты;
2. Аналитик/Дизайнер – поставляет информацию о бизнес-процессе пользователя и конкретных требованиях. Является последней инстанцией в спорных вопросах с разработчиком о работе продукта;
3. Руководитель продукта/Заказчик – формирует содержание релиза. Лучше всех знает, как должны работать и выглядеть фичи, является последней инстанцией в спорных вопросах о продукте с аналитиком;
4. Поддержка – поставляет информацию о качестве выпущенного релиза. Настоящий кладезь знаний о том, как именно используется продукт;
5. Руководитель проекта – отвечает за графики работ, балансирует между содержанием, качеством и сроками каждой поставки. От него мы получаем информацию о первостепенных задачах и должны информировать об угрозах поставки: проблемах, блокирующих тестирование, нестабильной версии, критических дефектах. Понятно, чтобы не стать мальчиком, которого съели волки, нужно говорить о реальных рисках.
Тестировщик может хорошо проверять требования и сам продукт на соответствие нуждам конечного пользователя, когда все проектные роли найдены и с ними налажен инфообмен: о бизнес-процессах “как есть” и “как нужно”, алгоритме реализованного, условиях использования продукта и “как получилось”. Сложность поиска ролей в том, что в IT часто Должность не совпадает с Исполняемой ролью. Иногда требуется проявить настойчивость, чтобы найти все, и результаты стоят затраченных усилий.
ИНФОКАНАЛЫ
Через инфоканалы тестировщики поддерживают общий контекст с командой и получают существенную часть информации от ролей. По умолчанию, на проектах есть следующие инфоканалы:
● Daily Meeting – на созвонах с командой тестировщик слышит и может сам уточнить что придет в тест, может поднять сложный вопрос сразу к нескольким ролям, например, аналитику, разработчику и руководителю проекта.
● Рабочие чаты – наполняются тематическими каналами. На всех проектах есть канал, в который включена рабочая группа. В него тестировщики дублируют ссылки на заведенные дефекты и решают проблемы, блокирующие тестирование. В случае производственной необходимости вводятся дополнительные каналы, например с аналитиками или дизайнерами. Так тестировщики сокращают длину коммуникаций и вовремя получают актуальную информацию.
● Почтовые пересылки – это регулярные отчеты о событиях на проекте, обычно автоматизированные. В том числе и отчеты о ходе и результатах тестирования.
Признаки хорошо настроенных инфо каналов:
● тестировщик в курсе событий: какие требования актуальны, на каком шаге разработки находится релиз и когда придет в тестирование,
● знает как обсудить оперативные вопросы, чтобы быть услышанным: фичебаги и предложения по улучшению, блокеры в тестировании, требования к продукту со стороны тестирования.
В обратном случае тестировщики превращаются в бук — “почему раньше не сказали!” и “ну я же говорил(а)!”
Среда тестирования
Правильно настроенные среды позволяют обеспечить достоверное тестирование и отсутствие реворков у тестировщиков.
Обычная инфраструктура в 2 тестовых среды – DEV для функционального тестирования и TEST для регрессионного тестирования, и одна боевая для работы конечного пользователя PROD. В этой конструкции есть по крайней мере 4 риска выпускать баги и генерировать реворк тестировщикам вне зависимости от содержания тестирования.
• В DEV environment – попадают изменения ПО, законченные разработчиком. В некоторых случаях в ней можно найти не все фичи текущего релиза, но парочку из будущих. В данной среде тестировщики проверяют релиз пофично и рисков выпустить не то, еще нет. Есть реворк, если разработчики передают в тестирование незавершённые фичи много-много раз (1).
• В TEST environment – должны быть собраны все фичи текущего релиза и ничего лишнего. Здесь тестировщики проверяют релиз целиком, прогоняют регрессионное тестирование. При неправильном устройстве процесса разработки тестировщики встречают ту же картину, что и на DEV сред – это первая угроза срыва сроков релиза, а в запущенных случаях – и качества (2). Не внесли, что планировали, добавили что-то лишнее – регресс начинается со стабилизации релиза, сопровождается серьезным реворком тестировщиков. Если же TEST среда настроена не так, как PROD, возможно столкнуться с ситуацией “баг не воспроизводится в TEST’е” (3).
• В PROD environment — поставляется оттетсированный продукт, в нем должна быть актуальная версия продукта + все изменения, проверенные тестировщиками. Но если PROD за время тестирования обновился, а TEST нет, и процедура деплоя в PROD очень сложная и вся выполняется вручную, то конечные пользователи с большой вероятностью увидят не то, что было проверено тестировщиками (4).
ТЕСТОВЫЕ КОНТУРЫ
Тестовый контур – программная среда для проведения предварительных испытаний продукта, т. е. тестирования. Дефекты из-за различия в средах встречаются у конечных пользователей не каждый релиз, зато при их появлении команда потратит немало усилий на локализацию, а возможно даже выпустит несколько хотфиксов “вслепую”.
Мы следим за идентичностью следующих характеристик:
● конфигурация интеграций и служебных приложений;
● дистрибутивы ОС, языка разработки, служебных приложений;
● одно-/ многонодность;
● протокол передачи данных;
● авторизация между всеми приложениями.
Правильно настроенная среда для тестирования исключает риск №3, описанный выше.
Модель ветвления: правила обновления и поставки изменений исходного кода
Как было показано, неорганизованная поставка изменений в среды, генерирует реворк в тестировании и непредсказуемые дефекты в PROD. В качестве базовой модели мы используем GIT Flow, адаптированную под реалии проекта. Это исключает риски №1, 2, 4.
Инструменты управления
Любые инструменты управления процессами помогают контролировать и влиять на ход работ без “чайка-менеджмента” и избыточных коммуникаций. В тестировании мы используем оба – систему управления задачами и дефектами (Jira, TFS, RedMine, etc.) и систему управления тестами (Zephyr Scale, TestRail, QASE, TestLink, etc.).
Цель подготовительных работ:
● встроить workflow тестирования в общий производственный процесс в системе управления задачами;
● настроить workflow тест-дизайна и исполнения тестов в системе управления тестами.
WORKFLOW В СИСТЕМЕ УПРАВЛЕНИЯ ЗАДАЧАМИ
Ниже пример простейшего workflow для выполнения работ по “тестированию изменений” (красный цвет) и “регрессионному тестированию” (серый цвет) в системе управления задачами.
В примере представлено всего 2 типа работ с участием 2 ролей. В тестировании выделяется следующий минимум:
● тестирование изменений
● регрессионное тестирование
● заведение и ретест дефектов
В зависимости от проекта и продукта реестр работ может быть увеличен. Добавлены другие регулярные работы:
● анализ требований;
● модульное тестирование;
● системное тестирование;
● установочное тестирование;
● дымовое тестирование PROD.
Или совсем индивидуальные для проекта, например обработка результатов UAT (Beta- тестирования).
В результате настройки workflow тестировщик в любой момент времени понимает объемы активных и надвигающихся работ, а также их приоритеты. Видит общую картину и может своевременно подготовить вопросы в случае отклонения факта от плана.
WORKFLOW В СИСТЕМЕ УПРАВЛЕНИЯ ТЕСТАМИ
Ниже пример простейшего workflow написания и выполнения тестов в рамках тестирования изменений (красный цвет), организованные в виде тест-кейсов, в команде без выделенного тест-менеджера.
В примере 2 этапа типовой работы “тестирования изменений”, декомпозированные на шаги написания и выполнения тестов. Помимо представленных шагов выделяются:
● ревью тест-кейса тест-менеджером;
● уточнение тест-кейса;
● создание и актуализация прогона;
● выполнение прогона;
● генерация отчета о тестировании.
В результате настройки workflow тестировщик в любой момент времени может сказать, что протестировано и сколько осталось, и какие актуальные проблемы есть на данный момент.
Заключение
Превалирующая доля настроек находится на стороне команды, которая возможно не понимает или не хочет понимать, для чего они нужны. Я видела, как команды проходили 5 стадий принятия при внедрении development workflow. Хотя, казалось бы, уже много лет известно, как утвержденная модель ветвления повышает качество совместной разработки.
Внедрение таких изменений можно поделить на этапы:
● Инициация: найти и убедить главных за коммуникации, тестовые среды, инструменты управления на проекте;
● Разработка: описать изменения, по возможности без сложных терминов и с красочными картинками. Выложить материалы в общий доступ, дальше они будут вспомогательными.
● Внедрение: обеспечить руководителей и, при необходимости, проектную команду консультациями.
● Контроль: дать команде время на формирование привычки. Около месяца контролировать и восстанавливать договоренности в случае отклонений.
Так, у нас в ICL Services на большом количестве проектов, чтобы не преодолевать сопротивление и не растягивать “преднастройку” на каждом из них, перечисленные мною практики выведены на уровень стандартов направления – “Best practices”. Это набор регламентов со ссылками и примерами, приоритизированные по важности. Практики с приоритетом Strongly обязывают руководителей проектов внедрять их сразу, на старте проекта. Все практики, описанные в данной статье относятся именно к этому типу.
Мое мнение – даже если проекту много лет, на нем давно есть тестирование, но хромают — коммуникации, тестовые среды или инструменты управления, не стоит это терпеть. Это хороший повод перетрясти договоренности, потому что потери от плохих условий тестирования измеряются в деньгах, времени, скорости выгорания специалистов и накапливаются каждый день.
===========
Источник:
habr.com
===========
Похожие новости:
- [LaTeX, Управление продуктом, Софт, IT-компании] Обновление МойОфис 2021.02. Пишите формулы и математические выражения в текстовом редакторе
- [Карьера в IT-индустрии, Финансы в IT] 300+ IT-вакансий от Альфа-Банка
- [Разработка веб-сайтов, JavaScript, IT-стандарты, VueJS, TypeScript] Vue 3: CompositionAPI + Typescript эксперименты
- [Тестирование IT-систем, Go, Tarantool] Как я сократил код для нагрузочного тестирования в три раза
- [IT-инфраструктура, Серверное администрирование] Не диспансеризация, а чекап: как мы формализовали проведение аудитов инфраструктуры
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений, Тестирование игр] Регрессионное тестирование на Scrum-проектах: руководство по проведению
- [Разработка робототехники, Робототехника, Финансы в IT, Транспорт, IT-компании] Hyundai завершила поглощение Boston Dynamics
- [Программирование, Учебный процесс в IT, Карьера в IT-индустрии, История IT, Биографии гиков] Пятьдесят лет на стезе программирования. Часть I. Начало пути. Отчий дом и Казанское суворовское военное училище
- [GitHub, Софт, IT-компании] Microsoft случайно опубликовала документ с названием Windows 11
- [JavaScript, Учебный процесс в IT, Удалённая работа] История о том, как я иду к должности JS разработчика через обучение на курсах в Skillbox
Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_itstandarty (IT-стандарты), #_uchebnyj_protsess_v_it (Учебный процесс в IT), #_itkompanii (IT-компании), #_icl_services, #_testirovanie_po (тестирование ПО), #_testirovanie (тестирование), #_itinfrastruktura (ит-инфраструктура), #_blog_kompanii_icl_services (
Блог компании ICL Services
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_itstandarty (
IT-стандарты
), #_uchebnyj_protsess_v_it (
Учебный процесс в IT
), #_itkompanii (
IT-компании
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:20
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Привет, Хабр! В поисках формата для рассказа о практиках тестирования я обратилась к гуглу с запросами “с чего начинать тестирование ПО” и “как подготовиться к тестированию ПО”. И нашла статьи о том, что нужно уточнять требования, применять техники и т. д. Хм… А что, если “составляющими контроля качества ПО” и даже в своем роде глоссариями в том самом поиске и стали стандарты и производные об этапах STLS? Да, все это необходимо – но недостаточно, подумала я. И если вы, при наличии всех процессов тестирования, ● выводили в PROD не то, что протестировали; ● тестируете не то, что нужно; ● находите баги в PROD, которых точно нет в тесте; ● вынуждены много раз тестировать одно и то же из-за процессных сбоев – знайте, эта статья для вас. Велосипед не едет, если у тестирования нет основы. В статье я хочу рассказать, что мы предварительно настраиваем, чтобы тесты были достоверными, эффективными и предсказуемыми. DISCLAIMER 1. Перечисленное ниже является структурой “предподготовки”, а не готовым шаблоном. Инструменты, подходы, процессы представлены на правах примеров. По уму они должны выбираться исходя из особенностей проекта и продукта. Эти кейсы подходят большой линейке, но не всей (особенно боюсь поднять халивар на тему GIT flow). В любом случае, буду рада обсудить другие кейсы и особенности проектов в комментариях. 2. Наличие “предподготовки” позволяет обеспечить тестирование высокого уровня, но не гарантирует его. Однако при наличии базовых настроек гораздо проще отследить, где проседает тестирование, и принять меры. 3. Я намеренно опустила некоторые преднастройки, которые сильно зависят от принятого на проекте тестирования. Например, если в компании Х принято тестировать продукт серым ящиком, то очевидно, что в качестве преднастройки должен быть организован доступ к тестовым средам. Постаралась выделить самые главные, которые подходят большинству. Коммуникации Хорошо выстроенные коммуникации позволяют превратить формальные проверки в клиентоориентированное тестирование. РОЛИ В ПРОЕКТЕ Мы выделяем 5 значимых ролей для тестировщика со следующим предназначением: 1. Разработчик – поставляет информацию об алгоритме фичи. Это не вопрос “что тестировать”, его мы не задаем. Знание механизма дает возможность применить техники тест-дизайна на промежуточных шагах и отловить не очевидные дефекты; 2. Аналитик/Дизайнер – поставляет информацию о бизнес-процессе пользователя и конкретных требованиях. Является последней инстанцией в спорных вопросах с разработчиком о работе продукта; 3. Руководитель продукта/Заказчик – формирует содержание релиза. Лучше всех знает, как должны работать и выглядеть фичи, является последней инстанцией в спорных вопросах о продукте с аналитиком; 4. Поддержка – поставляет информацию о качестве выпущенного релиза. Настоящий кладезь знаний о том, как именно используется продукт; 5. Руководитель проекта – отвечает за графики работ, балансирует между содержанием, качеством и сроками каждой поставки. От него мы получаем информацию о первостепенных задачах и должны информировать об угрозах поставки: проблемах, блокирующих тестирование, нестабильной версии, критических дефектах. Понятно, чтобы не стать мальчиком, которого съели волки, нужно говорить о реальных рисках. Тестировщик может хорошо проверять требования и сам продукт на соответствие нуждам конечного пользователя, когда все проектные роли найдены и с ними налажен инфообмен: о бизнес-процессах “как есть” и “как нужно”, алгоритме реализованного, условиях использования продукта и “как получилось”. Сложность поиска ролей в том, что в IT часто Должность не совпадает с Исполняемой ролью. Иногда требуется проявить настойчивость, чтобы найти все, и результаты стоят затраченных усилий. ИНФОКАНАЛЫ Через инфоканалы тестировщики поддерживают общий контекст с командой и получают существенную часть информации от ролей. По умолчанию, на проектах есть следующие инфоканалы: ● Daily Meeting – на созвонах с командой тестировщик слышит и может сам уточнить что придет в тест, может поднять сложный вопрос сразу к нескольким ролям, например, аналитику, разработчику и руководителю проекта. ● Рабочие чаты – наполняются тематическими каналами. На всех проектах есть канал, в который включена рабочая группа. В него тестировщики дублируют ссылки на заведенные дефекты и решают проблемы, блокирующие тестирование. В случае производственной необходимости вводятся дополнительные каналы, например с аналитиками или дизайнерами. Так тестировщики сокращают длину коммуникаций и вовремя получают актуальную информацию. ● Почтовые пересылки – это регулярные отчеты о событиях на проекте, обычно автоматизированные. В том числе и отчеты о ходе и результатах тестирования. Признаки хорошо настроенных инфо каналов: ● тестировщик в курсе событий: какие требования актуальны, на каком шаге разработки находится релиз и когда придет в тестирование, ● знает как обсудить оперативные вопросы, чтобы быть услышанным: фичебаги и предложения по улучшению, блокеры в тестировании, требования к продукту со стороны тестирования. В обратном случае тестировщики превращаются в бук — “почему раньше не сказали!” и “ну я же говорил(а)!” Среда тестирования Правильно настроенные среды позволяют обеспечить достоверное тестирование и отсутствие реворков у тестировщиков. Обычная инфраструктура в 2 тестовых среды – DEV для функционального тестирования и TEST для регрессионного тестирования, и одна боевая для работы конечного пользователя PROD. В этой конструкции есть по крайней мере 4 риска выпускать баги и генерировать реворк тестировщикам вне зависимости от содержания тестирования.  • В DEV environment – попадают изменения ПО, законченные разработчиком. В некоторых случаях в ней можно найти не все фичи текущего релиза, но парочку из будущих. В данной среде тестировщики проверяют релиз пофично и рисков выпустить не то, еще нет. Есть реворк, если разработчики передают в тестирование незавершённые фичи много-много раз (1). • В TEST environment – должны быть собраны все фичи текущего релиза и ничего лишнего. Здесь тестировщики проверяют релиз целиком, прогоняют регрессионное тестирование. При неправильном устройстве процесса разработки тестировщики встречают ту же картину, что и на DEV сред – это первая угроза срыва сроков релиза, а в запущенных случаях – и качества (2). Не внесли, что планировали, добавили что-то лишнее – регресс начинается со стабилизации релиза, сопровождается серьезным реворком тестировщиков. Если же TEST среда настроена не так, как PROD, возможно столкнуться с ситуацией “баг не воспроизводится в TEST’е” (3). • В PROD environment — поставляется оттетсированный продукт, в нем должна быть актуальная версия продукта + все изменения, проверенные тестировщиками. Но если PROD за время тестирования обновился, а TEST нет, и процедура деплоя в PROD очень сложная и вся выполняется вручную, то конечные пользователи с большой вероятностью увидят не то, что было проверено тестировщиками (4). ТЕСТОВЫЕ КОНТУРЫ Тестовый контур – программная среда для проведения предварительных испытаний продукта, т. е. тестирования. Дефекты из-за различия в средах встречаются у конечных пользователей не каждый релиз, зато при их появлении команда потратит немало усилий на локализацию, а возможно даже выпустит несколько хотфиксов “вслепую”. Мы следим за идентичностью следующих характеристик: ● конфигурация интеграций и служебных приложений; ● дистрибутивы ОС, языка разработки, служебных приложений; ● одно-/ многонодность; ● протокол передачи данных; ● авторизация между всеми приложениями. Правильно настроенная среда для тестирования исключает риск №3, описанный выше.  Модель ветвления: правила обновления и поставки изменений исходного кода Как было показано, неорганизованная поставка изменений в среды, генерирует реворк в тестировании и непредсказуемые дефекты в PROD. В качестве базовой модели мы используем GIT Flow, адаптированную под реалии проекта. Это исключает риски №1, 2, 4. Инструменты управления Любые инструменты управления процессами помогают контролировать и влиять на ход работ без “чайка-менеджмента” и избыточных коммуникаций. В тестировании мы используем оба – систему управления задачами и дефектами (Jira, TFS, RedMine, etc.) и систему управления тестами (Zephyr Scale, TestRail, QASE, TestLink, etc.). Цель подготовительных работ: ● встроить workflow тестирования в общий производственный процесс в системе управления задачами; ● настроить workflow тест-дизайна и исполнения тестов в системе управления тестами. WORKFLOW В СИСТЕМЕ УПРАВЛЕНИЯ ЗАДАЧАМИ Ниже пример простейшего workflow для выполнения работ по “тестированию изменений” (красный цвет) и “регрессионному тестированию” (серый цвет) в системе управления задачами.  В примере представлено всего 2 типа работ с участием 2 ролей. В тестировании выделяется следующий минимум: ● тестирование изменений ● регрессионное тестирование ● заведение и ретест дефектов В зависимости от проекта и продукта реестр работ может быть увеличен. Добавлены другие регулярные работы: ● анализ требований; ● модульное тестирование; ● системное тестирование; ● установочное тестирование; ● дымовое тестирование PROD. Или совсем индивидуальные для проекта, например обработка результатов UAT (Beta- тестирования). В результате настройки workflow тестировщик в любой момент времени понимает объемы активных и надвигающихся работ, а также их приоритеты. Видит общую картину и может своевременно подготовить вопросы в случае отклонения факта от плана. WORKFLOW В СИСТЕМЕ УПРАВЛЕНИЯ ТЕСТАМИ Ниже пример простейшего workflow написания и выполнения тестов в рамках тестирования изменений (красный цвет), организованные в виде тест-кейсов, в команде без выделенного тест-менеджера.  В примере 2 этапа типовой работы “тестирования изменений”, декомпозированные на шаги написания и выполнения тестов. Помимо представленных шагов выделяются: ● ревью тест-кейса тест-менеджером; ● уточнение тест-кейса; ● создание и актуализация прогона; ● выполнение прогона; ● генерация отчета о тестировании. В результате настройки workflow тестировщик в любой момент времени может сказать, что протестировано и сколько осталось, и какие актуальные проблемы есть на данный момент. Заключение Превалирующая доля настроек находится на стороне команды, которая возможно не понимает или не хочет понимать, для чего они нужны. Я видела, как команды проходили 5 стадий принятия при внедрении development workflow. Хотя, казалось бы, уже много лет известно, как утвержденная модель ветвления повышает качество совместной разработки. Внедрение таких изменений можно поделить на этапы: ● Инициация: найти и убедить главных за коммуникации, тестовые среды, инструменты управления на проекте; ● Разработка: описать изменения, по возможности без сложных терминов и с красочными картинками. Выложить материалы в общий доступ, дальше они будут вспомогательными. ● Внедрение: обеспечить руководителей и, при необходимости, проектную команду консультациями. ● Контроль: дать команде время на формирование привычки. Около месяца контролировать и восстанавливать договоренности в случае отклонений. Так, у нас в ICL Services на большом количестве проектов, чтобы не преодолевать сопротивление и не растягивать “преднастройку” на каждом из них, перечисленные мною практики выведены на уровень стандартов направления – “Best practices”. Это набор регламентов со ссылками и примерами, приоритизированные по важности. Практики с приоритетом Strongly обязывают руководителей проектов внедрять их сразу, на старте проекта. Все практики, описанные в данной статье относятся именно к этому типу. Мое мнение – даже если проекту много лет, на нем давно есть тестирование, но хромают — коммуникации, тестовые среды или инструменты управления, не стоит это терпеть. Это хороший повод перетрясти договоренности, потому что потери от плохих условий тестирования измеряются в деньгах, времени, скорости выгорания специалистов и накапливаются каждый день.  =========== Источник: habr.com =========== Похожие новости:
Блог компании ICL Services ), #_testirovanie_itsistem ( Тестирование IT-систем ), #_itstandarty ( IT-стандарты ), #_uchebnyj_protsess_v_it ( Учебный процесс в IT ), #_itkompanii ( IT-компании ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:20
Часовой пояс: UTC + 5