Фон Недавно одна моя знакомая, QA Engineer, долгое время работавшая в вялотекущем проекте, где ее обязанности были строго определены, сменила работу и устроилась в только что запущенный проект. Посидев пару дней без указанных выше задач и откровенно заскучав, она обратилась к руководству с вопросом «Что мне делатьЭ» на что получила многозначительный ответ: «Организуйте свою работу».
А потом впала в ступор: «Как этоЭ» И действительно, как? Несколько месяцев назад я сам сменил работу и оказался в английском проекте, в котором раньше никогда не было QA. Сам проект существует уже давно.
Как это часто бывает, компания с большими деньгами купила компанию с меньшими деньгами, но с клиентами.
В результате крупная компания получила новых клиентов и минус одного конкурента на рынке.
Мой проект получил изменение в управлении и принципах управления.
В первые же дни знакомства с новой командой я услышал честный, недоуменный вопрос от одного из разработчиков лондонского офиса: «Что вы собираетесь здесь делатьЭ» Честно говоря, когда я пришел на этот проект и несколько дней огляделся вокруг, я, как и мой коллега, сначала впал в некий ступор.
Не потому, что я не знал, что делать.
Вернее, я не знал, как здесь грамотно вклиниться в сложившиеся устои.
Команда разработчиков прекрасно обходилась без тестировщиков.
Они использовали Канбан, принципы непрерывной доставки и бесстрашно, спокойно и уверенно разворачивали производство практически каждый день, даже по пятницам.
А всё потому, что у них было отличное покрытие автотестами.
Возможно, лучшее, что я когда-либо встречал.
Просматривая пул-реквесты друг друга, они без колебаний говорили друг другу, какие еще автотесты следует добавить.
Автор текущего изменения сам развернул свою работу в производство, а значит, нес полную ответственность за свою работу.
И он это пронес, несмотря на то, что я участвовал в проекте.
и перед развертыванием было бы неплохо услышать мое мнение.
Но все равно, конечно, процесс не был безупречным: случалось, что разработчики не понимали требований, пропускали ошибки, нередко возникали какие-то проблемы на стороне заказчика, требующие принятия мер.
Столкнувшись с необходимостью определить свое положение в коллективе, я пошел и в руководство.
Только наш диалог был построен совсем по-другому, не так, как у моего друга.
Организация работы QA Engineer
Задавать правильные вопросы
Так.Я собрал руководство и ведущих разработчиков проекта для диалога.
Есть одно замечательное правило менеджмента, которое я, конечно, не мог забыть: озвучивая проблему, озвучивайте вариант ее решения, хотя бы один.
Однако у меня возникло два вопроса, ответы на которые я не мог знать.
С них было проще всего начать.
Первый вопрос.
Какова структура организации, а именно: кто над кем стоит и кто за что отвечает? В идеале компании должны иметь иерархическую диаграмму, иллюстрирующую структуру компании.
Но у меня не идеальная ситуация, поэтому важно было узнать, к кому с какими вопросами и предложениями обращаться.
Второй вопрос.
Компания ввела в проект QA Engineer, какие от меня ожидания, какие цели они преследовали, открывая эту вакансию? Когда ответ очень конкретен, это во многом определяет объем работы.
В моем случае ответ содержал много общих расплывчатых фраз, которые я воспринял как «делайте, что хотите, но чтобы у нас все было хорошо».
На этом первая часть обсуждения завершена.
Обсуждаем план действий
Второй частью обсуждения, и, пожалуй, самой важной, была презентация моего плана работы и его обоснование.Мне нужно было получить благословение начальства, чтобы беспрепятственно внедрить себя и свою деятельность в проект. Приятно очевидно, что умные книги и теория не существуют в вакууме, поэтому я вооружился знаниями, полученными при подготовке к сертификации ISTQB, прочитав когда-то книги по теории тестирования и Scrum из любопытства, пропустил все это через сито.
с десятилетним опытом работы и составил пилотный проект QA Strategy. Тщательно обсужденный с руководством и полностью поддержанный им, он позже принял формат официального документа компании.
Далее хочу поделиться идеологическими рекомендациями по составлению такого документа.
Они сложились как квинтэссенция предыдущего опыта и пути, пройденного в рамках текущего проекта.
И, пожалуй, перепечатаю здесь в виде цитат некоторые фрагменты в исходном виде: на английском языке.
Я уверен, что для каждого QA-инженера составление такого плана станет ключевым ответом на вопрос «Как организовать свою работу».
Формирование стратегии обеспечения качества
1. Введение в обеспечение качества
Напомнить/впервые ввести термин «Обеспечение качества».Поверьте, в вашей команде полно людей, которые имеют весьма смутное представление о том, что это такое.
Можно позаимствовать очень общие определения.
Тактично обозначьте, что наличие на проекте команды QA не означает, что вся ответственность за качество работы теперь переложена исключительно на них:
Тестирование — это часть QA. Это позволяет нам определить уровень качества оцениваемых функций.Проведение контроля качества не является единственной обязанностью тестировщиков.
Вся команда может и должна способствовать обеспечению высокого уровня качества поставляемых продуктов и услуг.
2. Введение в стратегию обеспечения качества
Подготовьтесь к тому, о чем люди будут читать дальше.
Стратегия тестирования — это развивающийся документ, подробно описывающий процессы и способы, которыми мы собираемся обеспечивать качество нашего продукта в будущем.Озвучивайте контент. Это может быть как простое оглавление, так и более абстрактные предложения.
Здесь упомяните о существовании подхода к тестированию, процесса тестирования, стратегии автоматизации тестирования и необходимости плана тестирования.
Важный.
Укажите сроки пересмотра этого документа.
А проект и процессы в компании развиваются; этот документ не должен превратиться в динозавра.
Поэтому назначьте дату, когда ваша стратегия будет пересмотрена и изменена.
На мой взгляд, полгода вполне достаточно, чтобы вернуться с новыми мыслями.
3. Тестовый подход
Каков подход к тестированию? Немного отступив от объемистой официальной формулировки этого определения, позволю себе упростить его до тезиса, что это «основные мысли, с которыми нам приходится работать каждый день».Запишите сюда: что является двигателем вашего прогресса? Классика жанра и хорошо работающие подходы – «проактивные» и «рискованные».
Мы будем применять упреждающий подход к тестированию, основанный на риске.Когда мы говорим о экспедировании, в первую очередь надо говорить о контроле качества технического задания.Проактивный.
Это означает, что процесс проектирования тестов начинается как можно раньше, чтобы найти и исправить дефекты до создания сборки.
Риск-ориентированный — это означает, что мы организуем наши усилия по тестированию таким образом, чтобы снизить уровень риска продукта при поставке системы.
Согласно программе ISTQB, «Тестирование, основанное на рисках, — это идея, согласно которой мы можем организовать наши усилия по тестированию таким образом, чтобы снизить остаточный уровень риска продукта при поставке системы.
Тестирование на основе рисков использует риск для определения приоритетов и выделения соответствующих тестов во время выполнения тестов, но речь идет не только об этом.
Тестирование, основанное на рисках, начинается на ранних этапах проекта, выявляя риски для качества системы и используя эти знания о рисках для планирования, спецификации, подготовки и выполнения тестирования.
Тестирование, основанное на рисках, включает в себя как меры по смягчению последствий (тестирование, позволяющее снизить вероятность возникновения дефектов, особенно дефектов с высоким уровнем воздействия), так и тестирование на случай непредвиденных обстоятельств (тестирование на случай непредвиденных обстоятельств), позволяющее выявить обходные пути, позволяющие сделать дефекты, которые все-таки проходят мимо нас, менее болезненными.
Тестирование, основанное на рисках, также предполагает измерение того, насколько хорошо мы справляемся с поиском и устранением дефектов в критических областях».
Менеджеры, оформляющие спецификации на элементы следующего цикла разработки, по большей части мыслят как простые пользователи системы, тогда как логика мыслей разработчиков существует в другом измерении.
Во-первых, я не раз видел, что разработчик, прочитав спецификацию, не может перевести ее на язык программирования.
Например, он не может сопоставить пользователя, упомянутого в спецификации, с существующими в системе ролями/правами доступа.
В результате он может выбрать роль, наиболее подходящую, по его личному мнению, но она окажется не той и ему придется потом возвращать функционал в работу и терять время; или задать вопрос менеджеру, который возможно ушёл в отпуск и снова теряет время на ожидание.
Инженер по обеспечению качества — это замечательный промежуточный этап между менеджером, ориентированным на пользователя, и разработчиком с техническим складом ума, особенно если инженер по обеспечению качества не пренебрегает тестированием «белого ящика».
Мы — те, кто способен понять менеджеров и донести их мысли до разработчиков.
В течение.
Тестирование, основанное на рисках, имеет интересные формальные методы оценки рисков проекта и продукта.
Очень здорово иметь возможность применить их на практике.
Но лично мне никогда не хватает времени описать вероятности возникновения, тяжесть их последствий и т. д. и просчитать риски по всем правилам.
Здесь я полностью больше полагаюсь на свои инстинкты и здравый смысл.
При тестировании или покрытии зон риска автотестами (чему необходимо уделить первое и основное внимание) в большинстве своем:
- непосредственно разработанный функционал
- смежные и взаимодействующие области
- коммерчески важный функционал
- что чаще всего ломается
- обратная совместимость (если, например, изменился формат метаданных, будут ли существующие данные успешно функционировать)
4. Процесс тестирования
Расскажите, какой методической последовательности работы вы предполагаете придерживаться.Ничего сложного я не придумал, а взял идея от ISTQB и я использую его.
Если вы пойдете по моему пути, ознакомьтесь с последовательностью работ, рекомендованной авторами ISTQB, поймите, какие шаги вы будете выполнять и как.
Начнем с планирования и контроля.
Эти двое живут вместе, потому что.
На основе мониторинга собственной деятельности планы могут регулярно перекраиваться.
Далее идет работа с документацией и написание тест-кейсов, ввод их в эксплуатацию (с использованием плановых тестовых данных и подходящего окружения), завершение тестирования и уборка за собой (удаление временных файлов и т.п.
).
Мы будем использовать процесс тестирования, описанный в программе ISTQB базового уровня: планирование и контроль тестирования, анализ и проектирование тестирования, реализация и выполнение тестов, оценка критериев выхода и отчетность, а также действия по закрытию теста.
5.Обязанности
Опишите свои обязанности и обязанности других людей в области улучшения качества продукции.Сообщите о своей миссии.
Во-первых, еще раз подчеркну, что каждый член команды сам по себе тестировщик , каждый проверяет то, к чему прикасается.
Написал код — протестируйте.
Во-вторых, прояснить и понять направление вашего дальнейшего развития.
QA Engineer – главный эксперт по функционалу продукта : знает, как и что работает, умеет объяснить, как и что нужно тестировать.
Это человек, который прогнозирует оперативное поведение заказчика, а значит, не допустит развития серьезных проблем.
Третий, назначать способ взаимодействия с менеджерами и разработчиками .
Например, остановитесь на Гибкий подход «Три друга»
Сотрудничество между бизнесом, разработкой и контролем качества а.Бизнес.
Какую проблему мы пытаемся решить? б.
Разработка.
Как мы можем найти решение этой проблемы? в.
Тестирование.
Что насчет этого, что может произойти?
6. Уровни тестирования и стратегия автоматизации контроля качества
Сегодня этот раздел стал для меня отдельным самодостаточным документом.А вот на уровне организации зарождающегося процесса QA в команде обозначьте, какие виды тестирования кем будут выполняться.
Что будет делаться вручную, что автоматизировано и по какому принципу.
Кто за какие автотесты отвечает. Например, на текущем проекте я пишу только сквозные тесты, бесперебойная работа которых стратегически важна с точки зрения бизнеса.
При этом я смотрю пул-реквесты от разработчиков и при необходимости даю рекомендации по тестовому покрытию.
Все остальное (юнит, интеграция, нагрузка и т.д.) — дело рук разработчиков.
В предыдущем проекте нагрузочное тестирование было моей обязанностью, и я писал интеграционные тесты вместе с разработчиками.
7. Рабочий процесс функции
Сегодня мой проект работает по Scrum, используя двухнедельные спринты.Вот почему у меня есть пошаговый документ жизненного цикла для каждой истории.
Какой бы методологии ни придерживался проект, опишите, как выполнять повседневную работу шаг за шагом.
Если выше мы говорили больше о тактике действий, то здесь должны быть четкие указания о том, что первично, а что потом.
Например, мой вариант такой
В приведенном ниже рабочем процессе подробно описан процесс, который мы будем применять внутри компании.1. Узнайте историю перед планированием сеанса 2. Создайте контрольный список в соответствии с критериями приемки и описанием.
3. Отмечайте неясные детали/вопросы.
4. Уточните вопросы по планированию 5. Обновите контрольный список 6. Выделите любые зависимости и способы их преодоления.
7. Когда история находится на рассмотрении, проверьте, охватываются ли критерии приемки автотестами.
8. Поощряйте разработчика охватывать все критерии приемки автотестами или делать это самостоятельно.
9. Когда история будет готова к тестированию, выполните ручное тестирование, используя контрольный список.
10. Создать ошибки для истории, если они есть, и вернуть предмет в разработку.
11. Когда ошибки исправлены, снова выполните ручное тестирование, используя контрольный список.
12. Проверьте, все ли автотесты пройдены 13. Создайте задачу на реализацию дополнительных интеграционных автотестов, если это необходимо.
14. Переместите историю в состояние QA Passed.
8. План тестирования
Выберите тип Тест-плана, платформу, на которой вы будете его хранить, и цель его существования.Предоставьте возможность каждому изучить это.
В этом проекте мой план тестирования представляет собой набор контрольных списков для каждой истории.
Учитывая нынешний уровень автоматизации, этого пока достаточно.
В последнем проекте План тестирования использовался для тщательного ручного тестирования и в качестве идеологической основы для будущих автоматизированных тестов.
Если у вас много ручных тестов, пропишите тест-кейсы подробно, чтобы любой новый QA-инженер, пришедший на проект, мог выполнить их самостоятельно.
Как работать с документом
Писать весь этот план и эффективные слова – это очень круто.Руководство это оценит, я не сомневаюсь.
Но есть один важный момент в существовании этого документа.
Это честные ответы на вопросы, для кого и зачем все это написано? При написании каждого предложения хорошо бы подумать над следующими вопросами: «Действительно ли я хочу так работатьЭ» , «Смогу ли я действительно воплотить это в жизнь в проектеЭ» Если оба ответа положительны, продолжайте печатать уверенно.
Если один из ответов «Нет», на мой взгляд, это верный знак не брать на себя лишние обязанности.
Если один из ответов относится к категории «Пока не знаю», пусть он пока поживет на ваших страницах.
Для меня такие моменты остались в списке того, что будет первым, что стоит пересмотреть за несколько месяцев.
Прежде всего, я написал свой документ для себя.
У меня бывают моменты, когда я отклоняюсь от описанных процессов и даже немного иду против них.
Это нормально – адаптироваться к ситуации, чтобы эффективно использовать ресурсы здесь и сейчас.
Но для подавляющего большинства во время обычной рутинной работы мой документ является моим путеводителем.
Я не раз убеждался, что существующий план/стратегия в любой сфере всегда быстрее и с меньшими болями приближает к желаемым результатам, чем его полное отсутствие.
Желаю вам строить свою работу легко и эффективно! Непосредственно перед публикацией статья была сильно сокращена; для «Песочницы» это казалось слишком длинным.
Буду рад продолжить эту тему позже.
Однако я всегда рад развитию, если есть что-то, о чем я совсем забыл, напишите мне в комментариях.
Спасибо! Теги: #qa #управление качеством #стратегия обеспечения качества #стратегия тестирования #тестирование ИТ-систем #управление разработкой #управление проектами
-
Блокчейн Не Всесилен
19 Oct, 24 -
Обзор Azure-Iaas № 16 (Май)
19 Oct, 24
