Предыстория
Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?
Несколько месяцев назад я сама сменила работу и попала в английский проект, в котором никогда раньше не было QA. Сам проект существует давно. Как часто бывает, компания, в которой много денег, купила компанию, в которой денег поменьше, но есть клиенты. В итоге, крупная компания получила новых клиентов и минус одного конкурента на рынке. Мой проект получил смену менеджмента и принципов управления.
В первые же дни знакомства с новой командой, я услышала честный недоумевающий вопрос одного из разработчиков Лондонского офиса «А что ты будешь здесь делать?»
По правде говоря, придя в этот проект и за несколько дней оглядевшись по сторонам, я, как и моя коллега, поначалу немного впала в ступор. Не потому что я не знала, что делать. Скорее, я не знала как грамотно себя вклинить в сложившиеся здесь устои. Команда разработчиков замечательно существовала без тестировщиков. Они использовали канбан, принципы continuous delivery, бесстрашно, спокойно и уверенно деплоили на production почти каждый день, даже по пятницам. А все потому, что у них было прекрасное покрытие автотестами. Пожалуй, лучшее, что я когда-либо встречала. Ревьюя пулл реквесты друг друга, они не стеснялись подсказывать друг другу какие еще автотестов добавить. Автор текущего изменения сам деплоил свою работу на production, а значит, полностью сам нес ответственность за свою работу. И он ее нес, несмотря на то, что на проекте появилась я … и перед деплоем неплохо было бы услышать и мое мнение.
Но все же, разумеется, процесс не был безупречным: бывало, что разработчики не понимали требований, пропускали баги и довольно часто на стороне заказчиков случались какие-то проблемы, которые требовали принятия мер.
Столкнувшись с необходимостью определения моего положения в команде я тоже пошла к руководству. Только диалог наш был выстроен совсем иначе, не так как у моей знакомой.
Организация работы QA Инженера
Задаем нужные вопросы
Итак. На диалог я созвала руководство и ведущих разработчиков проекта. Есть одно замечательное правило менеджмента, о котором я, конечно же, забыть не могла: озвучивая проблему, озвучивай и вариант ее решения, хотя бы один.
Тем не менее, у меня было два вопроса, ответы на которых я знать не могла. С них проще всего и было начать.
Первый вопрос. Что из себя представляет структура организации, а именно кто над кем стоит и кто за что отвечает?
В идеале у компаний должна быть иерархично представленная схема иллюстрирующая структуру компании. Но я нахожусь не в идеале, поэтому было важно выяснить к кому с какими вопросами и предложениями можно идти.
Второй вопрос. Компания ввела в проект QA Engineer, каковы их ожидания относительно меня, какие цели они преследовали открывая эту позицию?
Когда ответ очень конкретизирован, это во многом определяет фронт работы. В моем случае ответ содержал много общих размытых фраз, которые я восприняла как «делай, что хочешь, но чтобы у нас все было хорошо».
На этом первая часть дискуссии закончилась.
Обсуждаем план действий
Вторая часть обсуждений, и пожалуй, наиболее важная, представляла собой презентацию моего плана работы и ее обоснование. Мне нужно было получить благословение вышестоящих лиц для беспрепятственного внедрения себя и своей деятельности в проект.
Приятно очевидно, что умные книжки и теория существуют не на пустом месте, поэтому я вооружилась познаниями, полученными при подготовке к сертификации ISTQB, когда-то из любопытства прочитанными книгами по теории тестирования и Скраму, пропустила это все через сито десятилетнего опыта работы и составила пилотный проект для QA Strategy.
Тезисно обсужденный с руководством и всесторонне им поддержанный, позже он обрел формат официального документа компании. Дальше я хочу поделиться идейными рекомендациями для составления такого документа. Они сложились как квинтэссенция предыдущего опыта и пройденного пути на текущем проекте. И, пожалуй, я в виде цитат перепечатаю сюда некоторые фрагменты в первозданном мной виде: на английском языке. Уверена, что для каждого QA Engineer составление подобного плана станет ключевым ответом на вопрос «Как организовать свою работу»
Формируем QA Strategy
1. Введение в Quality Assurance
Напомните/впервые познакомьте с термином Quality Assurance. Поверьте, у вас в команде полно людей, которые очень смутно представляют себе, что это такое. Совсем общие определения можно позаимствовать из википедии. Тактично обозначьте, что присутствие команды QA на проект не означает, что вся ответственность за качество работы теперь перекладывается только на них:
Testing is a part of QA. It allows us to determine the level of quality of the feature(s) that we are assessing.
It is not the sole responsibility of testers to carry out QA. The entire team can and should contribute to ensure a high level of quality of the products and services being delivered.
2. Введение в QA Strategy
Подготовьте к тому, о чем дальше люди будут читать.
The Testing Strategy is an evolving document detailing the processes and way we are going to ensure the quality of our product going forward.
Озвучьте контент. Это может быть как просто оглавление, так и более тезисные предложения. Здесь упомяните о существовании Подхода к тестированию (Test Approach), Процессов тестирования (Test Process), Стратегия создания автотестов (Test Automation Strategy) и необходимости Тест плана (Test Plan).
Важно. Обозначьте временной интервал пересмотра этого документа. И проект и процессы в компании развиваются, этот документ не должен превращаться в динозавра. Поэтому запланируйте дату, когда ваша стратегия будет пересмотрена и изменена. По-моему, шести месяцев для того, чтобы вернуться с новыми мыслями вполне достаточно.
3. Test Approach
Что такое подход к тестированию? Немного отстранившись от объемной официальной формулировки этого определения, я позволю себе упростить его до тезиса, что это «базисные мысли, с которыми мы каждый день приступаем к работе». Запишите здесь: что есть двигатель вашего прогресса?
Классика жанра и хорошо работающие подходы – это «действующий на опережение» (proactive) и «основанный на рисках» (risk-based).
We will be adopting a proactive and risk-based testing approach.
Proactive — This means that the test design process is initiated as early as possible in order to find and fix the defects before the build is created.
Risk-based — This means that we will organize our testing efforts in a way that reduces the level of product risk when the system ships. According to the ISTQB syllabus «Risk-based testing is the idea that we can organize our testing efforts in a way that reduces the residual level of product risk when the system ships. Risk-based testing uses risk to prioritize and emphasize the appropriate tests during test execution, but it's about more than that. Risk-based testing starts early in the project, identifying risks to system quality and using that knowledge of risk to guide testing planning, specification, preparation and execution. Risk-based testing involves both mitigations — testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects — and contingency — testing to identify workarounds to make the defects that do get past us less painful. Risk-based testing also involves measuring how well we are doing at finding and removing defects in critical areas»
Когда мы говорим про опережение, мы, в первую очередь, должны говорит о контроле качества спецификации требований. Менеджеры, которые составляют спецификации элементов очередного цикла разработки, в большинстве своем мыслят как простые пользователи системы, в то время как логика мыслей разработчиков существует в другом измерении. Во-первых, не раз я видела такое, что разработчик, читая спецификацию, не может перевести ее на язык программирования. Например, не может сопоставить упомянутого в спецификации пользователя с существующими в системе ролями/правами доступа. В итоге он может подобрать наиболее подходящую, по его личному мнению, роль, которая окажется не той и придется возвращать функциональность в работу позже и терять время; либо задать вопрос менеджеру, который, быть может, ушел в отпуск и снова терять время в ожидании. QA Engineer это та замечательная прослойка между заточенным на пользователя менеджером и технически мыслящим разработчиком, особенно, если QA Engineer не пренебрегает бело ящичным тестированием. Именно мы способны понять менеджеров и перевести их мысли разработчикам. Вовремя.
Тестирование, основанное на рисках, имеет под собой интересные формальные методы оценки рисков проекта и рисков продукта. Очень здорово уметь их применять на практике. Но лично мне никогда не хватает времени расписывать вероятности возникновения, тяжесть их последствий и т.п. и рассчитывать риски по всем правилам. Здесь я полностью полагаюсь больше на свое чутье и здравый смысл. При тестировании или покрытии автотестами зоны риска (то чему нужно уделить первое и основное внимание) в большинстве своем:
- непосредственно разработанная функциональность
- смежные и взаимодействующие с ней области
- коммерчески важная функциональность
- то, что чаще всего ломается
- обратная совместимость (если, например, изменили формат метаданных, будут ли существующие данные успешно функционировать)
4. Test Process
Расскажите, какой методолгической последовательности работы вы рассчитываете придерживаться. Я не стала изобретать ничего сложного, а взяла идею из ISTQB и пользуюсь.
Если пойдете по моему пути, ознакомьтесь с последовательностью работы, которую рекомендуют авторы ISTQB, осознайте то, какие шаги вы будете выполнять и как. Начинаем мы с планирования и контроля. Эти двое живут вместе, т.к. на основе мониторинга своей же деятельности, планы могут регулярно перекраиваться. Дальше идут работа с документацией и написание тест кейсов, их ввод в эксплуатацию (задействование спланированных тестовых данные и подходящего окружения), завершение тестирования и уборка за собой (удалить временные файлы и т.п.)
We will use the test process outlined in the Foundation level ISTQB syllabus: Test Planning and Control, Test Analysis and Design, Test Implementation and Execution, Evaluating Exit Criteria and Reporting, and Test Closure Activities.
5. Responsibilities
Обозначьте свои и чужие обязанности на поприще повышения качества продукта. Донесите свою миссию.
Во-первых, акцентируйте снова, что каждый член команды сам по себе тестировщик, все тестируют то, чего они касаются. Написал код – протестируй его.
Во-вторых, разъясните и уясните направление своего постоянного развития. QA Инженер — главный эксперт по функциональности продукта: знает, как и что работает, способен объяснить, как и что нужно тестировать. Он – человек, который предугадает эксплуатационное поведение заказчика, а значит, не позволит развиться серьезным проблемам.
В-третьих, обозначьте способ взаимодействия с менеджерами и разработчиками. Например, остановитесь на Three amigos agile approach
Collaboration between Business, Development and QA
a. Business — What problem are we trying to solve?
b. Development — How might we build a solution to solve that problem?
c. Testing — What about this, what could possibly happen
6. Testing Levels and QA Automation Strategy
На сегодня этот раздел у меня стал отдельным самодостаточным документом. Но на уровне организации зарождающегося QA процесса в команде, обозначьте какие виды тестирования кто будет исполнять. Что будет выполняться вручную, что автоматизироваться и по какому принципу. Кто за какие автотесты отвечает.
Например, на текущем проекте я пишу только end-to-end тесты, бесперебойная работа которых стратегически важна с точки зрения бизнеса. При этом я смотрю пулл реквесты разработчиков и при необходимости даю рекомендации о покрытии тестами. Все остальные (юнит, интеграционный, нагрузочные и т.п) — это работа разработчиков. На предыдущем проекте — нагрузочное тестирование было на мне, а интеграционные тесты я писала наравне с разработчиками.
7. Feature workflow
Сегодня мой проект работает по Скраму, используя двухнедельные спринты. Поэтому у меня есть пошагово прописаный документ жизненного цикла для каждой Story.
Какой бы методологии не придерживался проект, опишите, как шаг за шагом делать ежедневную работу. Если выше мы говорили больше о тактике действий, то здесь должны быть четкие указания, что сначала, что потом.
Например, мой вариант такой
The workflow below details the process that we will adopt internally.
1. Get story before planning session
2. Create a checklist according to acceptance criteria and the description
3. Note unclear details/questions
4. Clarify questions on planning
5. Update the checklist
6. Highlight any dependencies and how you're going to overcome them
7. When the story is in Review check if acceptance criteria are covered by autotests
8. Encourage developer to cover all acceptance criteria with autotests or do it yourself
9. When the story is ready for testing perform manual testing using the checklist
10. Create bugs for the story if they exist and return the item to development
11. When bugs are fixed perform manual testing using the checklist again
12. Check if all autotests are passed
13. Create a task for implementing additional integration autotests if it is needed
14. Move story in QA Passed state
8. Test Plan
Выберите вид Тест Плана, платформу на которой вы будете ее хранить и цель его существования. Обеспечьте способ любому желающему туда заглянуть.
На данном проекте мой Тест План — это набор чеклистов для каждой Story. При имеющемся уровне автоматизации пока этого достаточно.
На прошлом проекте Тест План использовался для основательного ручного тестирования и как идейный базис для грядущих автотестов.
Если у вас много ручных тестов, тест кейсы пишите подробно, так, чтобы любой новый QA инженер, придя на проект смог их выполнить самостоятельно.
Как работать с документом
Написать весь этот план и эффектные слова это очень здорово. Начальство оценит, не сомневаюсь. Но есть один важный момент существования этого документа. Это честные ответы на вопросы для кого и для чего все это написано?
Прописывая каждое предложение, хорошо бы задумываться над вопросами: «Я, действительно, хочу так работать?», «Я, действительно, буду воплощать это в жизнь на проекте?»
Если оба ответа положительны, уверенно печатать дальше.
Если один из ответов – «Нет», по-моему, это верный знак не вешать на себя ненужных обязанностей.
Если один из ответов – из ряда «Пока не знаю», пусть пока живет на ваших страницах.
У меня такие моменты оставались в списке того, что первым делом будет пересматриваться через несколько месяцев.
Свой документ я, в первую очередь, писала для себя. У меня случаются моменты, когда я отступаю от описанных процессов и даже немного иду им вразрез. Приспосабливаться к ситуации, чтобы эффективно использовать ресурсы здесь и сейчас – это нормально. Но в преобладающем большинстве своем, при обычной рутинной работе, мой документ – это мой путеводитель. Не раз убеждалась, имеющийся план/стратегия в любой сфере всегда приближает к желаемым результатам быстрее и с меньшей болью, чем его полное отсутвие. Желаю Вам строить свою работу легко и эффективно!
Перед самой публикацией статья была сильно сокращена, уж больно большой она показалась мне для Песочницы. Буду рада продолжить эту тематику позже. Тем не менее, я всегда рада развиваться, если есть что-то о чем я совершенно забыла, пожалуйста, напишите мне в комментарии.
Спасибо!
Автор: Qualsolife
