Исповедь скрам тестера

Дорогие читатели, прошу прощения за долгое молчание в эфире. Все никак не мог собраться с мыслями. Однако теперь постараюсь начать новый цикл статей о тестировании в аджайл  командах, а точнее командах работающих использую гибкие методологии.

Вступление

За свою долгую карьеру, я получил большой опыт работы используя разные подходы и методики разработки WATERFALL, RUP, KANBAN, SCRUM, а также BARDAK c переходом в скрамоподобный WATERFALL.

Скажу вам откровенно, работать приходилось действительно гибко. Если в "до аджайловские" времена, были минуты отдыха в качалке или на турнике, то работая в скрам команде не часто есть возможность, лишний раз голову от монитора оторвать. (Вы все еще хотите быть аджайл тестировщиком, тогда я продолжаю).

Митинги

Особое внимание я хочу уделить активностям, без которых аджайл не аджайл, скрам не скрам, канбан не канбан - это митинги. Их тут много, начиная от ежедневных стендапов, оценке задач в бэклоге (Estimation sessions), уточнением необходимых деталей с владельцами продукта (Refinement/Grooming  sessions), и заканчивая ретроспективами. Главное понять и простить, что все они - это часть работы, и что нельзя недооценивать их важность. При этом главное - нельзя нарушать регламент (но это уже тема другой статьи). Мы все являемся заложниками ситуации.

Если со стендапами все ясно - взял микрофон и сказал, что делал, что сделал, что делать будешь, нужна ли где-то помощь и передаешь микрофон дальше, то у митингов по оценке задач своя специфика.

Как вы - тестировщик, можете что-то оценивать разработчикам?
- Не поверите, можете и должны.

Если даже вы не знакомы с кодом, вы знаете функциональность, вы знаете влияние и зависимости разных частей системы. Это и есть то, что вы должны озвучить. В дальнейшем, изучив код (об этом еще будет сказано много слов дальше), вы сможете давать более точные оценки.

Каждая фича состоит из кода, а код состоит из кода фичи и кода тестов. Ваша задача, как тестировщика, убедить всех в том, что для фичи просто модульных, интеграционных и ручных тестов не всегда достаточно, что надо еще иногда и автоматические функциональные тесты писать, и как может оказаться в дальнейшем, их писать будете только вы.

Ретроспектива - это митинг, где вы можете выразить восхищение успехами команды, а также сказать, что вас раздражает больше всего. И поверьте мне, это рабочий инструмент, если его правильно применять. Но для этого нужна сплочённая команда и  желание улучшать рабочий процесс, также атмосферу в команде. Один человек может мало что изменить, если остальным это не нужно. Если вы работаете в команде заботящейся о своей велосити и репутации, вам повезло. 

Спринт Демо - это ещё один митинг, к которому придется привыкнуть. Как тестировщик или QA, вы отвечаете за качество, и для ваc удачная презентация - это показатель вашей успешной работы, можно сказать, момент истины! Вы показываете то, что сделали людям, которые заказывали те или иные фичи. И тут всегда приятно провести все без заминки и увидеть довольные физиономии "заказчиков". На моей практике были разные демо, но недовольных заказчиков не было. (Грамотный домонстратор всегда может обойти проблемные места при показе, и наоборот акцентировать внимание на хорошо работающей функциональности)

Процесс разработки

В каждой команде, куда бы вы не пришли, процесс разработки будет свой. Я не буду заострять внимание на процесс анализа требований, а также правильность и полноту их описания, разговор пойдет только о разработке и места в нем тестирования.

В некоторых командах тестировщикам выдают в тестирование собранный продукт. Где-то тестировщики участвует в самой разработке. В моей последней компании, я как QA был вовлечён в работу с момента Код Ревью. Именно мне была поручена почетная и ответственная задача merge into mater. Но не просто нажатие кнопки Merge, а участие в самом ревью кода, анализе покрытия тестов, функциональное тестирование изменений, финальный approve и сам merge. Далее небольшой регрешн тест мастера и перевод истории в Done. 

Другой, немаловажной моей задачей, было создание пакета, который в последствии уходил в вышестоящие environments, где его тестировали уже другие люди, ответственные за свои участки работы.

Побочные активности

Так как в скраме ролей много, а людей не всегда хватает, то это считается нормальным работать в разных ролях. Так вот мне повезло больше всех :) Из-за того, что "наша служба и опасна и трудна, и на первый взгляд как-будто не видна", да еще из-за моей дружбы с исходным кодом после покрытия юнит тестами основной части кода, мне перепала роль первого главного подмастерья для наших разработчиков -  я начал фиксить баги, которые сам и находил.

Дальше больше. В один не очень прекрасный день, наш скрам мастер сказал, что уходит. Так как замены ему на тот момент не было, наше руководство, уговаривало меня "временно, пока не найдут нового" стать скрам мастером. Так вот уже почти 1.5 года я еще и скрам мастер.

Имея трёх в одном, мои боссы очень счастливы. Часто удивляются, когда я говорю, что мне это не совсем по душе, и что это отражается на качестве работы. Но менять ничего не хотят, ведь проект то в целом катится, вроде даже как на гору, а не с неё...

Эпилог

Скрам хорошая штука, где вы можете попробовать себя в разных ипостасях. Можете даже найти себя, если еще не определились с тем, чем же хотите заниматься. Здесь вы можете влиять на процесс - в хороших командах, ваш голос всегда будет услышан и учтён. Тестирование же в Скраме это сложная работа, требующая знаний в программировании, настройках окружения, процесса разработки, автоматизации тестирования и постоянного стремления к перфекционизму. Не всегда у вас будет время для прогона полного набора тестов. Именно поэтому вы должны четко понимать как компоненты взаимодействуют друг с другом на разных уровнях для того, чтобы найти и запустить достаточный, а не избыточный набор тестов.