Привет, меня зовут Елена Рукавичникова, я Head of QA и преподаватель курса “Функциональное тестирование ПО” в IT Academy. Свыше 7 лет я погружена в мир тестирования, принимая участие в более чем 20 увлекательных проектах.
Когда-то я выступала на конференции с данной темой и решила поделиться ею с вами.
Независимо от того, сколько уже было сказано на эту тему, каждый из нас имеет свой уникальный опыт и взгляд, который может внести ценный вклад в общий диалог.
На первых годах у меня был довольно быстрый карьерный рост и в этой статье я хочу поделиться с вами одним из ключевых подходов, который способствовал моему стремительному карьерному продвижению. Будучи сама на старте и пройдя через этот опыт, я с уверенностью могу подтвердить его эффективность и полезность.
Иногда мы можем легко увязнуть в повседневных задачах, связанных с обеспечением качества программного обеспечения.Однако, если ограничить своё мышление только назначенными обязанностями, мы рискуем упустить более широкую картину и понимание того, как наша работа влияет на весь проект.
Если вы не видите куда идет ваш проект, что важно пользователю, что важно заказчику, вам будет сложно предложить какие-то улучшения для проекта. Именно здесь вступает в действие системное мышление.
Системное мышление - это способность видеть за пределами отдельных задач и понимать, как они вписываются в общий контекст проекта. Речь идет о распознавании взаимосвязей различных компонентов и заинтересованных сторон и о том, как они влияют на успех программного обеспечения.
Давайте рассмотрим несколько сценариев, чтобы проиллюстрировать важность системного мышления в инженерии тестирования качества.
Пример №1
Планирование тестирования функции
Представьте, что вам поручено протестировать новую функцию для масштабного проекта. Традиционный подход может включать фокусировку только на самой функции и создание тестовых случаев, специфичных для её функциональности. Хотя это необходимо, системный мыслитель идёт дальше.
Он рассматривает более широкую систему, в которой фича функционирует. Он исследует взаимозависимости между функцией и другими компонентами, такими как интеграции с существующими модулями или потенциальное влияние на пользовательский опыт. Таким образом, системный мыслитель может выявить дополнительные тестовые сценарии, обеспечивающие всестороннее охватывание и выявление возможных проблем, связанных с взаимосвязями в системе.
Пример №2
Приоритизация исправления ошибок
Как инженер тестирования качества, вы сталкиваетесь с большим количеством сообщений об ошибках от пользователей или заинтересованных сторон. Традиционный подход может включать обработку каждой ошибки как отдельного инцидента и исправление их по отдельности. Однако, системный мыслитель подходит к этому по-другому.
Он понимает, что ошибки часто являются следствием скрытых системных проблем, а не отдельных инцидентов. Вместо простого исправления сообщенных ошибок он углубляется, чтобы определить корневые причины. Это может включать анализ взаимодействия различных модулей или изучение потенциальных проблем в требованиях или коммуникации. Решая эти корневые причины, он не только устраняет сообщенные ошибки, но и предотвращает появление подобных проблем в будущем.
Пример №3
Сотрудничество с командами разработки и поддержки
В типичном проекте инженеры QA тесно сотрудничают с командами разработки и поддержки. Традиционное мышление может приоритизировать плавный переход и индивидуальную производительность команды. Однако, системный мыслитель понимает ценность сотрудничества и его влияние на общее качество программного обеспечения.
Он активно стремится понять цели и проблемы других команд и осознает, как его работа соотносится с этими целями. Содействуя крепкому общению и сотрудничеству, системный мыслитель может выявить потенциальные узкие места, оптимизировать процессы и в конечном итоге повысить эффективность всего жизненного цикла разработки.
Системное мышление в инженерии QA выходит за рамки выполнения только непосредственных обязанностей. Оно предполагает принятие всестороннего взгляда на проект, понимание взаимосвязей между различными компонентами и осознание общих целей и задач заинтересованных сторон.
Если говорить подробнее об определении корневых причин проблемы (root cause analysis), существует довольно простая, хотя и на первый взгляд, техника "5 почему". Эта техника была разработана основателем компании Toyota, Сакити Тоёдой, для решения производственных задач.
Основной принцип метода заключается в последовательном задании пяти вопросов "почему", чтобы раскрыть глубинные причины возникновения проблемы. Рассмотрим несколько реальных примеров, чтобы лучше понять его применение в контексте мануального тестирования.
Пример №1:
Проблема: Повторяющиеся дефекты после исправления.
Почему? разработчик не тестирует исправления
Можно тут остановится и сказать разработчику тестировать исправления и работать быстрее. Но что, если пойти дальше:
Почему? у разработчика не хватает времени на тест
Почему? много задач в спринте по исправлению багов
Почему? фичи доставляются плохо описанными отсюда функционал с багами
Почему? бизнес-аналитики не стали тратить время на описание валидации полей считая это очевидной задачей, однако не учли что разработчик еще Джуниор.
Пример №2:
Проблема: Много багов-дубликатов.
Почему? сторонние тестировщики не проверяют наличие уже заведенных багов
Можно тут остановится и указать на необходимость поиска багов по ключевым словам перед их заведением. Но что, если пойти дальше:
Почему? тестировщики не в курсе что эту фичу уже протестировали
Почему? на борде не отмечено прохождение фичи другим тестировщиком
Почему? менеджмент решил перестраховаться и фичи тестируются по два раза разными командами
Отсюда дубликаты и двойная работа. Дальнейшее выяснение причин переходит в компетенцию менеджеров.
Пример №3:
Проблема: Пропустили баг.
Почему? не было времени на полный регресс
Можно тут остановится и решить вопрос овертаймами. Но что, если пойти дальше:
Почему? включили новую фичу во время спринта
Почему? оказалось что клиент хотел по-другому
Почему? не привлекли на более ранних этапах, когда согласовывали, как будет реализована функциональность
Здесь, вы могли заметить, две проблемы: недостаточное тестирование и включение фичей в текущий спринт. Однако первопричина решает обе эти проблемы.
Как видите, развитие навыков системного мышления может принести значительные преимущества в вашей работе в качестве инженера QA. Вы сможете предлагать более эффективные улучшения, определять потенциальные риски и вносить свой вклад в общий успех проекта. Глядя за пределы своих обязанностей и понимая общую систему, вы станете ценным специалистом в тестировании что повлияет на ваш карьерный рост.
Так что, в следующий раз, когда будете работать над проектом, не забывайте думать шире своих обязанностей. Примите системное мышление и откройте новые возможности для улучшения качества программного обеспечения и достижения успеха проекта.
Если вам интересна эта тема, я напишу продолжение про техники анализа проблем.
iggr63
Это конечно сильно:)