В agile-среде тестирование является важной частью каждого жизненного цикла программного обеспечения. То, как тестирование внедряется в фазы разработки проекта, называется QA-процессом.
Представьте себе ситуацию: только что стартовал новый проект, и заказчик просит включить в команду QA-инженера. Ни он, ни его команда разработки ранее не работали с QA, поэтому возникает множество вопросов — как у команды, так и у заказчика. И знаете что? Вам, как QA-инженеру, который присоединяется к команде, придется на них отвечать:
Как мы будем работать дальше? Будет ли QA блокировать наш прогресс и что произойдет с производительностью; замедлит ли QA нашу работу?
Что это за тикеты с багами, действительно ли я должен их фиксить?
Почему я должен позволить кому-то еще тестировать приложение? Я прекрасно обходился без них.
Во-первых, имейте в виду, что это совершенно нормально, если у них появятся все эти сомнения. Я в QA уже более 5 лет и за это время успела поработать над множеством проектов, и мне не раз приходилось отвечать на эти вопросы. Но для начала позвольте мне сказать следующее: внедрение QA в проектную команду не окажет негативного влияния на ее работу. Вы — необходимое дополнение к команде проекта, а не обуза.
Теперь перейдем к разработке QA-процесса.
Создание QA-процесса
1. Ввести роль инженера по обеспечению качества в проектную команду
Первым делом необходимо рассказать об обязанностях QA-инженера и о том, какой вклад он будет вносить в проект. Нужно четко объяснить, что роль QA-инженера заключается в том, чтобы помочь улучшить процесс, требования и, самое главное, качество разрабатываемого приложения. Важное замечание: разработчики по-прежнему будут принимать самое активное участие в тестировании качества приложения.
a) Чтобы подкрепить эти аргументы, необходимо обладать знаниями — это значит изучить все, что нужно знать о принципах, уровнях и видах тестирования. Не овладев уверенно основами, вы не сможете рассказать другим о том, чем вы занимаетесь, и доказать важность своей работы. В итоге это может затруднить внедрение QA-процесса в команду, а этого мы хотим избежать.
б) Во-вторых, вы должны с самого начала участвовать во всех активностях команды. В первую очередь это означает участие во всех скрам-митингах. Должна предупредить, что вначале, возможно, вы будете сталкиваться с ситуациями, когда команда не будет приглашать вас на некоторые встречи. Не позволяйте этому демотивировать вас. Будьте настойчивы, задавайте вопросы и предлагайте решения — и вскоре коллеги увидят преимущества вашего присутствия в команде.
2. Познакомиться с командой проекта
Если вы знакомы с agile методологией, то знаете, что у каждой команды своя динамика и свой подход к работе. А ключ к успеху? Вы уже знаете, что это адаптация.
За годы работы я понял, что общих правил знакомства с командой не существует — все зависит от коллег. Под новый проект обычно собирается новая команда, поэтому каждый раз при старте проекта вам, вероятно, придется создавать новый набор правил, чтобы определить желаемый тип отношений. Я советую всегда придерживаться дружеского подхода — он дает наилучшие результаты, по крайней мере, в моем случае. Это означает построение таких отношений с разработчиками, при которых вы можете открыто сказать им, что нашли ошибку, и они отреагируют на это положительно. Это также означает достижение такого уровня комфорта с владельцами продуктов, который позволит вам открыто обсуждать любые проблемы и улучшения. Владелец продукта должен быть вашим лучшим другом в проекте и верить в ваш подход — если вы, например, говорите, что пришло время для релиза, он должен доверять вашему решению. То же самое относится и к дизайнерам. Я всегда включаю их в работу над реализацией проекта, и если вижу, что какая-то часть дизайна не имеет смысла, инициирую обсуждение. Не бойтесь высказывать свое мнение — это часть работы. Но, как я уже сказал, всегда делайте это в дружеской форме.
Когда речь идет о динамике развития команды, важно также учитывать скорость (velocity) ее работы. Это повлияет не только на QA-процесс, который вы пытаетесь построить вместе с ними, но и на количество релизов. Например, если команда работает быстро, то имеет смысл выпускать релизы каждый день. В противном случае достаточно будет выпускать релизы раз в неделю.
3. Держите коллег в курсе происходящего
Каждая бага должна быть задокументирована в трекере, чтобы:
Не потерять ни одной баги.
Видеть статус каждой баги.
Оставлять видимые следы своей работы; мне нравится называть это «никаких багов под столом».
Пока команда не решит все баги, я предлагаю держать истории открытыми. Если решить их все невозможно, убедитесь, что, по крайней мере, решены все важные и критические ошибки. Чтобы помочь разработчикам сориентироваться, расставляйте приоритеты. В этой статье описано, как это делаем мы в компании COBE. Объясните разработчикам, что важно проводить регулярные сборки и иметь небольшие куски кода, которые можно быстро протестировать.
Еще один важный момент — адаптация трекера к проекту. Когда вы открываете трекер, должно быть сразу видно, что готово к тестированию. Поэтому не стесняйтесь добавить дополнительную колонку или метку, которая поможет увидеть, когда что-то готово. Иногда разработчик может сказать, что что-то готово, потому что оно работает на его компьютере.
Следует иметь в виду, что пока они не сделают сборку с включенной в нее фичей, это что-то не может считаться сделанным.
4. Релиз
Поскольку вы, как QA-инженер, больше всех тестируете приложение, именно вы знаете, когда наступит подходящее время для его релиза. Поэтому именно вы должны отвечать за релизы. Если по каким-либо причинам это не подходит для вашей команды, постарайтесь не ругаться по этому поводу. Просто убедитесь, что вы снимаете с себя всякую вину, если релиз не удался. Помните, что вы не можете контролировать то, за что не отвечаете.
Что теперь?
И напоследок: просто начните! В COBE мы любим повторять: «сделанное лучше идеального». Как и любая работа, разработка процесса идет по кривой обучения. На этом пути вы непременно столкнетесь с проблемами, но хорошая новость заключается в том, что вы также найдете и решения. Помните, что, изучив теоретическую часть, вы будете гораздо лучше подготовлены к любой ситуации. Вы справитесь!
Узнать больше о роли QA-инженера можно на открытых уроках:
26 июля в 20:00, «Практическое занятие: Симулятор» — узнаете, как выглядит типичный день тестировщика. Обсудим все от подготовки тестовых случаев до общения с командой разработки, и, конечно же, сам процесс тестирования. Регистрация
8 августа в 20:00, «Роль функционального тестировщика» — рассмотрим, какие есть роли в команде разработке и познакомимся с профессиональными функциями тестировщика. Регистрация
Встречи будут полезны всем начинающим тестировщикам и тем, кто интересуется этой профессией. Присоединяйтесь!