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

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

Вступление

За свою долгую карьеру, я получил большой опыт работы используя разные подходы и методики разработки 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 года я еще и скрам мастер.

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

Эпилог

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

Читать далее...

Инструменты vs Люди

Что важнее инструменты или люди?

Многие скажут, что люди, но они явно слукавят. Из своего опыта скажу, что не зная Selenium WebDriver, вы не попадете даже на первый раунд интервью на позицию тест автоматизатора веб приложений. Вас даже рекрутеры на linkedIn не найдут.

Поэтому рекомендую всем заниматься самообразованием, осваивать новые инструменты, продавливать их применение на проектах, где вы работаете. И, самое главное, следите за развитием отрасли и будьте в тренде!

Инструменты вторичны, но не зная их можно остаться за бортом, будь вы даже отличным специалистом.

Читать далее...

Так почему же пирамида?

Почему же все-таки пирамида тестирования? Не куб, не цилиндр, не шар, а именно пирамида? Постараюсь просто описать то, как я это вижу.

На сколько всем известно, тесты бывают разные. Возьмем в качестве примера функциональные и рассмотрим их на трех основных уровнях тестирования: модульном, интеграционном и системном.

Занимаясь системным тестированием, ты видишь уже готовое приложение. Берешь сторонний инструмент и пишешь тесты, оперируя внешними компонентами доступными конечным пользователям.

“Вводишь в поле слово, нажимаешь на кнопку, и не получая того, что ожидал, заводишь дефект. Пусть разработчики мучаются дальше. В особых случаях, лезешь в лог приложения, находишь конкретную запись об ошибке и прикрепляешь её в баг репорту.”

Вроде бы все хорошо, но не до конца… Именно этими мыслями я и хотел немного поделиться.

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

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

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

Читать далее...

Тестировщик.exit();

Когда-то говорили, что в профессию тестировщик низкий порог входа, что даже не имея специального образования можно устроиться, работать и получать неплохие деньги. Мне кажется сейчас это уже не совсем так, однако вопрос у меня другой:

- На сколько высок порог выхода из тестирования?

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

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

- Стоит ли игра свечь?
- Сможете ли вы бросить все и сменить профессию?
- На сколько просто уйти из тестирования?

Вы спросите:
- К чему все это?
Ответ прост:
- Быть может я готовлюсь к уходу, а может я просто подталкиваю, находящихся не на своем месте тестировщиков, сменить профессию :) Поживем увидим...

Читать далее...

Тестировщики в аджайле, аджайл тестеры - это опасные люди!

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

Мы можем слышать сотни лестных слов о гибких методологиях разработки, но все как всегда зависит лишь от профессионализма конкретных исполнителей. Дайте мне команду профессионалов, и я вам на ватерфоле «Ноктюрн сыграю». Не хочу продолжать говорить о всем аджайле, и даже не буду говорить за разработчиков, являсь тестировщиком расскажу что я думаю об аджайл тестировщиках и их проблемах. И сделаю я это в формате вопрос ответ:

Почему джуниор аджайл тестировщик хуже обезьяны с гранатой?

Джуниор тестироващик по умолчанию подразумевает под собой неопытного, неокрепшего, манкитестера. Для того, чтобы стать тестировщиком с большой буквы этого слова, его надо воспитать, направить и выпустить во взрослую жизнь. Набирая же в аджайл команду джуниор тестироващика, мы делаем тоже самое, когда китайского мальчика воспитывает белая европейская семья, он никогда не будет китайцем, т.к. все что он будет видеть – это европейские традиции и ценности. Таким образом, джуниор аджайл тестировщик – это непредсказуемое порождения аджайл команды: «Я его слепила из того, что было, а потом что было, то и полюбила».

Как стать хорошим аджайл тестировщиком?

Вопрос задан некорректно, необходимо спрашивать: «Как стать просто хорошим тестировщиком?». Во-первых, нужно обладать чертами характера и навыками присущими тестировщикам (в интернете много об этом говорится). Во-вторых, нужно научиться правильно работать, можно сказать, что нужно выработать в себе шаблон поведения, присущий именно тестировщику, деформировать свою личность, думать как тестировщик. Сделать это можно лишь общаясь с себе подобными, сидя в одной комнате с себе подобными, делая тоже самое, что и твои коллеги тестировщики, находясь под наблюдением наставника, который делает из вас именно тестировщика.

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

Влияет ли структура команды на тестировщика в аджайл?

Обычно тестировщики в аджайл интегрированы в команду, но я бы назвал это – изолированы в команде. Вы сидите вместе с разработчиками, общаетесь с ними, смеетесь, курите, пьете кофе. Короче отдаляетесь от своего тестировщицкого «Я», при этом незаметно меняя свой менталитет и становясь гибридом тестировщика и «ментального разработчика».

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

Куда расти тестировщикам в аджайл?

Что-то мне подсказывает, что особо-то и некуда. Максимум наберешь еще парочку полезных скилов, применишь пару новых видов тестирования, научишься программировать и т.д. Но как был тестировщиком, так и останешься, даже если тебе уже 45. При этом я не рассматриваю за рост переход тестировщик->разработчик или тестировщик->скрам мастер.

Конечно же, тут все будет зависеть от компании, на которую вы работаете. Даже там могут быть разные почетные ступни карьерного роста и плюшки к чаю.

Как сделать хорошо всем?

Хотите быть хорошим аджайл тестировщиком и приносить пользу – работайте, проявляйте инициативу, если вас не слушают, все равно пытайтесь - не стойте на месте. Ищите возможность расти дальше, идите вперед не думая ни о чем. Ваше развитие – это лишь ваша задача. Компании лицемерят, что они думают о вас. О вас может думать, в крайнем случае, ваш менеджер, т.к. от вашего выхлопа зависит его успех, компании в целом плевать на вас. Если им нужно будет сократить бюджет, вас уволят и не задумаются. Поэтому не теряйте время зря – читайте, осваивайте технологии, тестируйте новые навыки, и как только осознаете, что вам уже некуда расти – ищите новые высоты, идите туда где есть чему учиться. Только так вы сделаете хорошо всем.

P.S. И хватит читать бесполезные блоги – Работать! Работать! Работать!

Читать далее...

Поживем, увидим...

Все в жизни движется по спирали, и по всей видимости один из первых витков начинает сходиться.

Раньше, в самом начале эры software development программисты сами тестировали свой код и свои продукты. В крайнем случае этим занимались пользователи уже во время эксплуатации, всяких там alpha и beta версий. Многие этого уже и не помнят, но это было. Еще я успел застать это, работая программистом по распределению еще в самом начале 21 века.

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

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

Различия между программистами и тестировщиками постепенно стираются, и уже через 5-10 лет есть шанс вернуться в прошлое, где все мы - разработчики, будем тестировать свой код и продукты, так как мы это просто будем уметь в силу опыта, знаний и умений.

Что же будет дальше? А все пойдет опять по кругу… Опять начнут выделять тестировщиков, потом загонять их обратно и так далее и до конца времен…

Читать далее...

Сервис белых ворон…

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

1. Вы можете выполнять работу своих коллег по скрам команде?
2. Вы пишите код?
3. Вы фиксите баги?
4. Вы пишите модульные и интеграционные тесты?

Если все ответы «Да», то эта статья не про вас. Если хоть где-то вы ответили «НЕТ», то вы «Белая Ворона». Вы не такой как все, вы - «слабое звено». По необходимости, вы не можете заменить своего коллегу, чтобы помочь команде.

Работа тестировщика во многом зависит от того, что сделали разработчики. Давайте рассмотрим парочку небольших примеров – удачный и неудачный спринт.

Удачный спринт

• Начало спринта: разработчики пишут код, тестировщик готовится к тестированию.
• Середина спринта: разработчики выдали некоторые готовые фичи, тестировщик начинает тестировать, обкатывая свою стратегию и заводя новые баги.
• Конец спринта: разработчики выдали все и зафиксили все баги, тестировщик заканчивает тестирование и удовлетворенный качеством дает зеленый свет на релиз фич.

Неудачный спринт

• Начало спринта: разработчики пишут код, тестировщик готовится к тестированию.
• Середина спринта: разработчики все еще пишут код, тестировщик ждет выхода хоть чего-нибудь в тестирование, между делом, не в силах помочь разработчикам, занимается самообразованием или доделыванием чего-то, что было недоделано ранее.
• Конец спринта: разработчики ничего не успели сделать, тестировщик занимается тем же чем и занимался: у кого хватает самодисциплины работает, а кого нет – сидит и курит.

И тут вспоминается статья Джеймса Баха: «Test Jumpers: One Vision of Agile Testing», которая делает намек на то, что тестировщиков вообще не нужно жестко закреплять за командами. Их как лекарство нужно дозировано вводить в нужное время и в нужное место. Получается что-то на подобии тест сервиса. Нужен тестировщик – вот вам он. Нужно 2 - пожалуйста, если они есть в наличии. Возможно, это будет требовать больше менеджмента, но как по мне это лучше чем, когда кто-то сидит и ничего не делает, пока другие вкалывают за двоих.

Применяя «тест сервис» на практике, мы получим, что в случае с удачным спринтом, тестировщик будет работать на команду разработки полный спринт, выполняя последовательно задачи по подготовке и выполнению тестирования. В случае с неудачным, он будет работать лишь в начале, а дальше он уходит к себе для выполнения задач из бэклога своей команды тестирования.

В следующих статьях постараюсь более подробно описать работу тест сервисной команды.

Читать далее...