В эти выходные было какое-то магическое скопление конференций, на каждой из которых я был бы не прочь оказаться, но выбор пал на QA Fest 2016. Я уже третий год участвую в этом мероприятии и хотел бы отметить усилия организаторов: благодаря их энтузиазму и постоянной работе мы имеем еще одну крупную конференцию для тестировщиков в Киеве помимо более технической Selenium Camp. В этом году ребята сделали отдельный день для начинающих свой путь QA инженеров, на основной же день собралось больше 700 специалистов. Это очень и очень неплохой результат. Так держать!
Из докладов мне запомнился отличный практический отчет от Анастасии Асеевой “Роль тестирования в Devops” о комплексном подходе к обеспечению и контролю качества, который позволил им существенно сократить расходы на поиск и исправление дефектов, ускорил разработку и поставку бизнес функциональности, а также сделал весь процесс более прозрачным и предсказуемым. Хоть название доклада об этом и не говорит. 😉 Мы пригласили Настю выступить с тем же докладом на нашей конференции XP Days Ukraine 2016 и выделим ей 2 слота, чтобы все можно было рассказать и показать без бешеной спешки.
(далее…)
Осталось всего 2 недели до завершения работы над программой конференции XP Days Ukraine 2016. Много докладов уже принято программным комитетом, достаточно много еще в стадии рассмотрения. 3 октября будет опубликовано полное расписание.
В связи с расширением тематики конференции, ко мне часто обращаются с вопросом: “а будет ли полезно посетить доклады тестировщикам?”. Вопрос на самом деле очень интересный и неоднозначный. Ведь докладчики не говорят о тест-дизайне, инструментах тестирования, тест-менеджменте и прочих полезных для “тестировщика” темах. И тут, для ответа, необходимо знать, какую более широкую роль выполняет на проекте конкретный “тестировщик”. Ведь тестирование – это активность, которая делается с какой-то целью (в большинстве случаев для контроля качества).
Я продолжаю серию анонсов своих выступлений на конференциях этой осенью. Очередным в хронологическом порядке будет визит 1 октября на конференцию QA Fest 2016, посвященную вопросам качества и тестирования. Разработчики на подобные мероприятия, к сожалению, приходят редко, а выступают еще реже. Тем не менее, тематика QA мне всегда была очень близка и любима. Достаточно посмотреть сколько докладов я делал в прошлом на эту тему за последние несколько лет:
Я вот все озадачиваюсь одним интересным вопросом. Ведь вроде как уже давно в нашу жизнь пришли Agile подходы, разработчики начали писать тесты, много и на разных уровнях, заказчики начали более внимательно относиться к качеству и брать на себя часть работы тестировщиков, многие команды стали сильно заботиться о качестве кода и даже жить без тестировщиков. Почему об этом не говорят на встречах и тусовках тестировщиков? Почему на конференциях для тестировщиков так мало докладов и выступлений на тему интеграции тестировщика с разработчиками, их совместной работе, распределении обязанностей в свете изменений?
Я несколько раз выступал на конференции SQA Days и каждый раз был чуть ли не белой вороной – единственным разработчиком (именно реальным разработчиком, а не в прошлом), который делал доклад. Да и среди участников разработчиков мной было замечено немного. Почему так происходит? Во всех веселых историях про разработчиков и тестировщиков первые всегда выставляются в дураках. И некому защитить альтернативную точку зрения. А как же интеграция и совместная работа?
А за границей все гораздо более радостно. Много докладов об автоматизации как от разработчиков так и от тестировщиков. Мало докладов о ручном тестировании во всех его формах. Инструменты часто представляют разработчики а не тестировщики. Что же у нас то так все несовременно?
Я уже на третью конференцию для тестировщиков пытаюсь подать свой доклад “Бытовая классификация тестировщиков с точки зрения разработчика” и его не берут в программу. 🙁 Тестировщики часто говорят о противостоянии и конфликтах с разработчиками. Но ведь есть команды, где все живут в мире и согласии. Видимо что-то тут не так? Я хочу поговорить о том, как тестировщиков видят сами разработчики. В докладе будет проведена забавная классификация. Кроме известного всем тестировщика-обезьянки будут представлены тестировщик-муха, тестировщик-нацист, тестировщик-панда и многие другие герои. Вы сможете лишний раз задуматься над тем, как вас видят со стороны и, возможно, изменить ситуацию к лучшему. Доклад может быть полезен не только тестировщикам, но и менеджерам проектов, лидерам команд. Вы сможете быстрее распознавать те или иные шаблоны поведения тестировщиков и принимать меры по повышению уровня командной работы.
Я пока думаю где еще его можно было бы рассказать, чтобы целевая аудитория была более соответствующей и смеялась над очередной шуткой формата “разработчик сказал, что это не баг а фича”. Чтобы открыть глаза та то, как выглядят тестировщики с другой стороны, с точки зрения разработчиков. Без осознания этой правды очень тяжело работать вместе. Ведь совместная работа должна основываться на прозрачности и доверии с обеих сторон.
Так что ждите в ближайшее время на одной из сцен Украины или ближнего зарубежья! Заглянем по ту сторону правды… 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Давно мы ничего не проводили публичного в Харькове. Андрей Дзыня решил приехать туда в июле одновременно с докладом на встречу сообщества и тренингом Agile Testing. Встреча запланирована на 19 июля и пройдет под флагом вопроса “HOW TO MANAGE TESTING IN DYNAMIC WORLD: Practical Approach”. Тренинг пройдет 19-20 июля.
Что крутого в этом тренинге и почему я настоятельно рекомендую его посетить всем тестировщикам? Я уже давно повожу тренинг QA в Agile, в котором освещаю процесс постановки процесса тестирования со стороны менеджера, лидера команды, разработчика. Уже наверное ни для кого не секрет, что мы научились разрабатывать без тестировщиков, распределяя эту роль между остальными членами команды. Андрей же в своем тренинге рассматривает процесс тестирования изнутри, со стороны тестировщика. При этом в программе есть как процессные вещи (планирование, работа с требованиями, коммуникация в команде, демо, командные практики) так и сугубо практики тестирования (автоматизация, приемочное тестирование, скриптовое и исследовательское тестирование, инструменты и подходы к тестированию в Agile). Таким образом этот тренинг очень сбалансирован и дает участникам общее представление о роли, целях и подходах к работе тестировщика в Agile проекте.
Если сказать кратко, то этот тренинг учит тем вещам, которые позволяют тестировщику оставаться желанным и полезным специалистом даже для команд, которые справляются на первый взгляд без тестировщиков. Еще одна отличительная особенность тренинга – наличие множества практических сессий. Андрей ухитрился сбалансировать программу и давать возможность попробовать большую часть знаний на практике. Благодаря этому описанные подходы усваиваются гораздо лучше. Вы можете ознакомиться с детальной программой тренинга и убедиться в этом самостоятельно.
Стоимость участия в двухдневном тренинге составляет 2000 гривен (обед включен). Регистрация уже открыта!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Недавно у меня появился аккаунт на Хабре и я опубликовал на статью “Не обманывайте своих заказчиков”. Было много обсуждений в комментариях и я решил сделать более детальное рассмотрение данной темы.
Я достаточно много занимаюсь не только разработкой, но и постановкой процессов, в том числе тестирования. И всегда несколько скептически относился к ручному тестированию, точнее к той его части, которая отвечает за «обеспечение работоспособности существующей фунциональности» (в простонародье регрессионное тестирование). Что же плохого в этом тестировании и почему многие компании его тогда используют?
Проблема достаточно несложная, но ее суть не лежит на поверхности. Представьте себя на месте заказчика. Вы приходите с набором требований к исполнителю, в данном случае будем рассматривать в роли исполнителя команду разработки. Вы договорились о всех деталях с командой и она готова начать работать над вашим продуктом. Вы как умный и опытный заказчик грамотно расставили приоритеты и выдаете команде требование за требованием в правильном для бизнеса порядке. Вроде пока все звучит неплохо и ситуация не напоминает проблематичную.
Но вот проходит месяц-другой и выясняется неприятная деталь — на тестирование тратится все больше и больше времени. Оно вполне логично — ведь готовой функциональности в продукте становится все больше и надо постоянно контролировать, что она по-прежнему работает. Это эффект называется «регрессионная спираль смерти» (термин подсмотрен в выступлении Макса Дорофеева «Обезьянки против Роботов»). Эта спираль развивается со временем и становится все шире и шире. И если раньше тестировщики успевали «пробежаться» по продукту за несколько часов, то вскоре на это начинает уходить несколько дней.
Все очень просто — отдавая заказчику «готовую» работу мы не даем ему способа бесплатно и легко контролировать ее работоспособность в будущем. Утрируя, это может звучать так: «Мы закончили работать над X, Y и Z. Но уже через пару недель есть шансы, что они перестанут работать нормально…» Но как же так? Ведь заказчик заплатил за полное завершение работ. Как же ему теперь быть? Ему предлагается очень простое решение — плати нам постоянно дополнительную плату за то, что мы будем контролировать работоспособность на протяжении жизни продукта.
Получается, что стоимость одной конкретной функциональности будет продолжать расти на протяжении всего проекта. И чем быстрее работает команда, тем быстрее будет расти стоимость затрат на поддержание регрессии. Это же нечестно! В жизни бы мы никогда не согласились на такое. Представляете, вы заказываете ремонт, а вам предлагают платить дополнительные деньги за то, чтобы при работе над кухней не развалилась гостиная…
Почему же при всей ущербности подобной модели она не перестанет применяться? Тут есть несколько причин:
При этом, во многих современных продуктовых компаниях к такого рода затратам относятся скептически и не поддерживают идею ручного регрессионного тестирования. В таких компаниях нет позиции monkey тестировщика, так привычной для рынка аутсорсинга.
Для того, чтобы работать честно, надо пересмотреть «критерии готовности» команды разработки и расширить их наличием автоматизированных приемочных тестов. Перед работой над определенной функциональностью хорошая команда (заметьте, я не использовал слово Agile) задает заказчику вопросы о том, как функциональность должна работать и как заказчик будет проверять готовность. Это и есть процесс формирования приемочных критериев. Они представляют из себя мини-контракт между заказчиком и командой на реализацию этой функциональности.
Речь идет о работе над требованиями на очень короткий срок — обычно одна итерация. Если заказчик не может на такой срок сформулировать требования во всех деталях и ответить на все вопросы, то у вас уже проблемы. Работа над приемочными тестами помогает выявить их на самой ранней стадии.
Не стоит ожидать от заказчика, что он придет и выложит вам приемочные критерии на блюдечке. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор критериев на практике. Главное чтобы не приходилось в процессе разработки делать предположения и обращаться к “здравому смыслу”. Это очень опасно и может привести к переделкам и недовольству заказчика.
Дальше хорошая команда снабжает эти критерии приемки конкретными примерами, данными и «прикручивает» к работающему продукту. Таким образом, добавляется возможность с помощью приемочных тестов в любой момент времени проверить, работает ли та или иная функциональность в продукте после любых изменений. Запустить эти автоматизированные приемочные тесты может любой, обычно они добавляются к Continuous Integration серверу и запускаются на каждое изменение или в ручном режиме.
Почитайте как работает на примере одной команды командное написание приемочных тестов и про эволюцию необходимости таких тестов к запуску в облаке.
Но ведь есть же модульные тесты? Зачем еще раз делать ту же работу? Модульными тестами хороший разработчик покрывает код, чтобы убедиться, что его точечная идея для класса, функции, метода или их связки работает правильно. К сожалению, модульные тесты не способны обеспечить проверку даже возможности запуска приложения, не говоря уже о его функциях. Плюс, приемочные тесты написаны на языке, понятном заказчику, в отличии от модульных тестов. Если искать связь, то модульные тесты рождаются из приемочных, в то же время играя роль приемочных тестов на уровне кода.
И теперь никто не тратит время на ручное регрессионное тестирование. Это время тратится на исследовательское тестирование, на помощь команде разработки завершить свою работу вовремя и с высоким уровнем качества, на обеспечение работоспособности канала донесения требований от заказчика к команде разработки. Заказчик при этом имеет под рукой мощный инструмент контроля качества и работоспособности своего продукта, при этом понимая, что заплатил за это не напрасно.
Кто-то может подметить, что понадобится время на написание и поддержку такого рода автоматизированных тестов. Затраты на написание конечно же включаются в оценки выполнения работ по разработке. А вот стоимость поддержки будет зависеть напрямую от уровня команды. Грамотно написанные тесты будут основаны на правильных инструментах и фреймворках, которые абстрагируют тестовую логику от деталей вашего продукта и дают возможность изменять что-то только при серьезных изменениях в продукте. И пусть себе требования на здоровье меняются, но скорее всего не вся функциональность перепиливается каждую неделю, особенно в большом проекте.
Не все легко покрыть автотестами. Но из моего опыта, люди зачастую просто не знают, не хотят или не умеют этого делать. Для веб проектов есть Selenium, для совершенно произвольных есть Sikuli. А еще уйма специализированных инструментов. Можно замечательно с помощью Selenium тестировать UI (расположение элементов, верстку, отработку JavaScript). Советую посмотреть мое выступление на одной из конференций по поводу подобного тестирования. В разделе материалов можно найти больше на эту тему. Если не получается протестировать через конечный пользовательский UI, то можно тестировать API бизнес логики. Это все равно будет лучше чем ничего. Тогда ручное тестирование может быть сосредоточено больше на тестировании UI слоя.
Есть еще одно преимущество от наличия таких тестов – возможность делать рефакторинг. Рефакторинг — последовательность изменений, которая изменяет внутреннюю структуру программы без изменения ее внешнего поведения. При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом.
Эти же тесты придут вам на помощь и на этапе сопровождения. На этом этапе часто меняется только часть функциональности, а остальная должна продолжать работать стабильно. И вот тогда польза от приемочных тестов колоссальная. Мало того, по ним можно понять как должна была работать та или иная часть приложения. Потому что доменные знания теряются за документами, в которых устаревают практически моментально.
Задумайтесь, стоит ли продолжать обманывать своего заказчика. Или лучше работать так, чтобы можно было гордиться результатами своего труда, при этом убирая максимум скучной ручной работы и оставляя только интересную творческую составляющую? Если вы выбираете второй подход, то вам нужно обеспечить прозрачность и расписать все плюсы и минусы на самом раннем этапе. На более поздних этапах вводить описанное в статье тестирование может быть гораздо труднее и затратнее.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
В последнее время не хватает времени на полноценные статьи. Это связано с подготовкой конференции Selenium Camp 2013. Мы впервые проводим конференцию в двухдневном формате и поставили себе целью собрать интереснейшую программу для тестировщиков-автоматизаторов и просто любителей Selenium/WebDriver. Поэтому пока другие активности несколько приостановлены… 🙂
Недавно появился отголосок конференции SQA Days #12, которая в этом году проходила в Минске. Организаторы опубликовали видео докладов и я могу поделиться своим выступлением. Оно как обычно было посвящено автоматизации тестирования, в этот раз пользовательского интерфейса. Вот запись:
А вот и презентация доклада:
Смотрите на здоровье и набирайтесь знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
«Каждый человек – индивидуум»
Многие ученые пытались разделить людей на группы, чтобы можно было как-то классифицировать каждого человека. Это гороскопы, психотипы, все различные типы личности (по Юнгу, Майерс-Бриггсовскому, Хорни, Лоурэна, Кречмера и других).
Я не хочу сейчас рассуждать о правильности и неправильности каждого из подходов. В любом случае, на все 100% невозможно определить тип человека, так как на это влияет неимоверное количество всевозможных факторов. А полученная информация меняется настолько динамично, что формализованный тип перестанет отражать реальность спустя год, месяц, неделю или даже при изменении контекста.
В этой статье я хочу поделиться своими мыслями по определению типа и стиля работы тестировщика, опираясь на личные наблюдения и два источника, которые помогли оформить это в виде статьи (это PAEI модель Ицаха Адизеса, и статья Джонатана Кохла о Exploratory Testing).
Определим 4 «основных» стиля работы тестировщика программного обеспечения: Learner, Intuit, Systematic, Automator.
Learner – стиль, при котором тестировщик проявляет все возможные средства самообучения, чтобы получить как можно больше знаний, которые он сможет применить для решения поставленной задачи.
Intuit – стиль, при котором тестировщик использует свое внутреннее чутье для определения требуемых действий на выполнение поставленной задачи.
Systematic – стиль, при котором тестировщик непрерывно собирает полученную информацию в некую систему, которую сам и определяет.
Automator – стиль, при котором тестировщик использует всевозможные инструменты для автоматизации своей работы чтобы защитить себя от повторяющихся действий.
Наложим PAEI модель Ицаха Адизеса, где каждая составляющая может присутствовать в трех типах:
БОЛЬШАЯ БУКВА – доминантный навык;
Маленькая буква – начальный уровень развития навыка;
«-» (прочерк) – навык отсутствует вовсе и не применяется.
Можем получить наборы разных типов, например:
-I-a – тестировщик руководствуется только интуицией во время тестовой сессии и использует минимально простой сценарий с возможностью подстановки тестовых данных. Это позволяет ему по максимуму использовать свой творческий потенциал чтобы сфокусироваться на поставленной задаче.
LiS- – тестировщик, который схватывает новую информацию на лету и пытается «разложить все по полочкам». Он хочет видеть полную картину происходящего и сохранять иллюзию контроля. Он слушает свой внутренний голос для поиска новых идей и тут же добавляет их в свою систему.
L-sA – тестировщик, который быстро обучается и применяет последние технические навыки для максимальной автоматизации своей работы. При этом не доверяет необоснованным порывам и эмоциям.
Бывают же случаи, когда человеку очень хочется верить в то, что его любимый навык у него доминантный, но что-то не дает на 100% согласиться с этим. Для таких случаев, на одном из тренингов по Exploratory Testing, мы договорились применять знак ?. Который означает, что человек стремиться повысить уровень владения этим навыком.
Список можно продолжить, описывая всевозможные комбинации, а их 81. Но цель статьи – ознакомить с идеей и подходом для определения кодов самостоятельно.
Эта методика может помочь для:
Эти примеры вовсе не говорят о том, что нужно в лоб спрашивать каждого тестировщика «какой у тебя код?». Лучше попытайтесь проанализировать и понять какой код подойдет этому человеку. Для этого можете придумать практические задачи и посмотреть, как человек будет их решать. Какими инструментами, вспомогательными средствами он пользуется, да и вообще, чем он будет руководствоваться в момент принятия решений.
Как можно улучшить эту методику? Чтобы более широко развить эту тему можно попытаться описать каждую из комбинаций кода и проводить аналогии с реальной жизнью. Может быть, какой-то из стилей придется убрать или заменить на другой чтобы более четко отразить этот код. Давайте будем практичными в этом отношении и попробуем поэкспериментировать.
Когда мы определимся с кодом, можно будет подумать о разного рода тестах, пройдя которые можно будет приблизительно получить свой стиль. Но лучше всего быть предельно откровенным с самим собой и попытаться определить код для себя, а затем спросить у коллеги, согласен ли он с вашими выводами.
Эта статья – лишь попытка формализовать мои мысли за время наблюдений и работы тестировщиком. Эта тема очень широкая и потребует немалого времени для ее полного изучения, раскрытия и находится далеко за пределами области разработки программного обеспечения.
Но, пока есть базовая теория, постарайтесь подумать и решить, каким же стилем обладаете вы?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Эта статья – вольный пересказ статей Майкла Болтона на тему, что не является исследовательским тестированием.
Зачастую, люди, которые ленятся разобраться с принципами, которые заложены в подход исследовательского тестирования, попадают под разного рода сомнения. В этой статье мы детально разберемся в самых частых заблуждениях относительно исследовательского тестирования.
Что не так с этой трактовкой? Давайте представим как происходит процесс тестирования по так называемому “туру”. Любимый пример Джеймса Виттакера (автора книги Exploratory Software Testing):
Вы турист, летите на самолете в Лондон, чтобы отправиться за покупками. Вы читаете карту и отмечаете места, в которых хотели бы побывать, при этом рассчитываете маршрут и время, чтобы успеть в каждый магазин. По прилету в Лондон вы начинаете следовать намеченному плану. Вы заходите в каждый магазин, следуя своему маршруту. Выбираете вещи, некоторые покупаете, некоторые нет. Также находите бракованные вещи и показываете их менеджерам магазина. И так далее пока не дойдете до последнего магазина, или пока у вас не закончатся деньги.
Давайте спроецируем это пример на тестирование. Что получается? У нас есть набор чекпоинтов, быть может чеклист end-2-end набор тестов, который указывает нам на порядок выполнения действий. Не нужно долго думать, чтобы ответить на вопрос “На что похоже такое тестирование?”. Конечно же – это скриптовый подход к тестированию.
Каким должен выглядеть процесс, чтобы он был похож на исследование? В первую очередь нам нужна цель. Говоря о Лондоне, целью может быть – купить красивое пальто или зонт. А где, в каком магазине и в какое время – не важно! Главное – результат. Что использовать для этого – дело сугубо индивидуальное. Кто-то может составить план, кто-то может доехать до центральной улицы и спрашивать у прохожих дорогу к ближайшему магазину одежды, а кто – банально зайти в первый попавшийся магазин и купить первое попавшееся на глаза. У каждого тестировщика свой стиль тестирования. И это правильно! Главное – это достижение цели, конечного результата. В этом разрезе, тестировщик более похож не на туриста, а на исследователя, который ищет пути решения поставленной проблемы.
Бред, вранье и полная чушь! Одно из самых частых заблуждений относительно исследовательского тестирования. Чаще все встречается у неграмотных Agile тестировщиков. Как вы можете заниматься исследованием лишь один раз в неделю? А чем же вы тогда занимались остальное время – тестировали? Нет, тогда вы не тестировали – вы проверяли на соответствие (checking). Исследовательское тестирование – всеохватывающий процесс, это подход к тестированию, а не одна из доступных техник. В пример этого заблуждения можно принести всем известные Agile квадраты.
Очень глупо было размещать Exploratory Testing в квадрате Q3. Почему? Давайте подумаем, можем ли мы делать исследования на этапе написания unit-тестов? Можем. Разработчики тоже могут исследовать код приложения, чтобы написать больше тестов. Проведение code review тоже можно отнести к исследованиям. Тоже самое касается остальных типов тестов. Например, вы можете записать в режиме исследования скрипт для нагрузочного тестирования, используя BadBoy. И запускать его при помощи JMeter с разными типами нагрузок. Кому интересно детальное опровержение этой матрицы – посмотрите выступление Элизабет Хендриксон на последней конференции CAST.
Если вы когда-то услышите эту фразу – смело ругайте этого человека. Какие инструменты можно применять для проведения исследовательского тестирования? Да любые! Это и скриншоттеры, и рекордеры, и логгеры. Используя автоматизированные скрипты можно подставлять разные массивы данных и тем самым заниматься исследованием системы автоматически, конфигурируя текстовые или xml-файлы. Тот же Selenium IDE и прочие record-and-play инструменты могут облегчить работу тестировщику во время проведения тестовой сессии.
Еще одно из часто упоминаемых заблуждений. Быстрые проверки или, как их еще принято называть, quick tests могут проводиться как в исследовательском, так и скриптовом режимах. Для примера скриптового подхода, вы можете описать набор smoke или sanity тест кейсов для вашего приложения и тестировать по ним. В исследовательском тестировании же можно использовать мнемоники и туры для проведения быстрого тестирования. Но обратите внимание, что не все туры бывают быстрыми, и не все быстрые проверки – это туры. Полный список – на сайте Майкла Болтона.
Напоследок – самое сладкое заблуждение, которое полно необоснованных убеждений. Все тестировщики, по долгу службы, привыкли к стандартному течению обстоятельств. Читаем требования, пишем тест кейсы, ждем пока разработчики что-то напишут и уже по этим тест кейсам приступаем к тестированию. Я не говорю, что тестирование по тест-кейсам это плохо. Напротив, в некоторых контекстах без них никуда: медицинское, авиа, банковское ПО. Но везде должен быть разумный предел того, что документировать, а что – нет. Самый ценный совет, который можно здесь дать – “Документируйте только то, что нужно”. Узнайте у членов вашей команды, менеджеров – какие документы им нужны, чтобы контролировать выполнение ваших обязанностей без постороннего вмешательства? Подумайте сами, какие документы вам необходимы для проведения тестирования. Но всегда держите в голове – “Keep it simple”. Кстати, то же самое имелось ввиду в Agile манифесте “Working software over comprehensive documentation”. Тестировщику нужно заниматься тестированием, а не администрированием процесса, точно так же как программисту – написанием кода, а не спецификаций. Но везде должен быть баланс. Если для поддержания рабочего процесса необходим документ – лучше его написать. В исследовательском подходе к тестированию документировать можно что угодно и сколько угодно. Главное договориться о том, что должно попасть в отчет тестовой сессии и какие сценарий следует формализовать.
Будьте готовы принять вызов и отстоять точку зрения о правильном исследовательском тестировании. Приводите примеры из своих контекстов. Задавайте вопросы и критикуйте, ведь этих пяти примеров может быть недостаточно, чтобы полностью ответить на вопрос “Что не есть Exploratory Testing?”
Хотите научится применять этот подход на практике? 26-27 октября в Киеве будет проходить тренинг “Exploratory Testing”. На множестве практических заданий под руководством опытного тренера вы освоите исследовательское тестирование и сможете применять его в своей работе.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
25 сентября я принял участие в онлайн конференции Chief ConfeT&QA с докладом “Почему тестирование занимает так много времени”. Теперь я могу смело опубликовать материалы доклада, потому что по результатам зрительского голосования он занял первое место. Мой доклад выбрало больше 50% проголосовавших участников. Спасибо всем, кто за меня голосовал. Я рад, что сумел донести до вас полезные мысли.
На этот доклад меня вдохновила статья Болтона, которая в далеком 2009 году заставила меня пересмотреть взгляды на тестирование и помогла в дальнейшем избегать очень многих проблем: часть 1, часть 2. С тех пор эта тема является обязательным блоком моего тренинга “QA в Agile”.
О содержании доклада говорить нет смысла – проще просто его посмотреть. Есть версия слайдкаста:
Есть вариант видео:
Участники задавали много вопросов. Ответы на самые интересные я приведу тут:
Вопрос: Работали ли вы когда-нибудь тестировщиком?
Нет, я не работал тестировщиком. Но мне не раз приходилось ставить процесс тестирования на проекте с нуля, а также много-много раз консультировать компании по вопросам тестирования и проводить тренинги на эту тему.
Вопрос: Николай, так вроде бы это ты тот человек, у которого в проекте нет тестировщиков. Два предположения, это только предположения или все таки опыт?
От вас ничего не утаить. 😉 Да, на текущем проекте мы уже 3 года живем без тестировщиков. Параллельно с этим и до этого проекта мы работали совершенно разными составами команд и там было разное количество тестировщиков. Все, что я рассказываю, из личного опыта. К сожалению, не всегда приятного. 🙂
Вопрос: Где написание/поддержка тесткейсов?
В данном докладе оно не рассматривалось, потому что тут у меня тоже немного другие подходы и это отдельная тема для долгого обсуждения.
Вопрос: Как эстимировать работу тестировщика? Имеется в виду, что время на работу очень сильно зависит от качества работы девелоперов.
Если вы не делаете оценки в стиле Agile, то в тестировании вы полагаетесь сугубо на интуицию и попытки обезопасить себя буферами времени. В Agile команде вы не оцениваете тестирование как активность, вместо этого вы оцениваете насколько сложно/долго команде сделать ДО КРИТЕРИЯ ГОТОВНОСТИ определенную функцию продукта. А кто и как в команде будет что делать вас мало интересует. Тестирование должно оставаться в рамках каждой задачи, а не быть отдельной фазой в этом процессе. Посмотрите в материалах выступлений мой старый доклад “QA в Agile”.
Вопрос: Обычно верификация багов, найденных на данной итерации, переносится в следующую итерацию и нагрузка планируется, чтобы таких завалов не было.
О! Это очень долгая тема. У меня несколько другое отношение к понятию бага. Детальнее можно прочитать в этой статье.
Вопрос: Как-то непонятно. Неужели в планировании не было учтено, что вообще найдут баги?
Учтено то может и было, но как учесть сколько найдут. Это ведь зависит от разработчиков. Можно использовать накопленную за большой срок статистику, но ее еще надо накопить. И от колебаний в 20-30% она не защитит (на примере второй команды, которая делала мало багов). А это значит, что тестирование может не влезть в итерацию и снова проблемы…
Вопрос: А разве тестировщик виноват в том, что так много багов?
Ни в коем случае. Виноваты разработчики. Вина тестировщика в том, что он не “обеспечил качество” в процессе разработки. Для этого он должен был на этапе планирования помочь разработчикам понять правильно требования, обеспечить как можно раньше (желательно до реализации) весь набор приемочных критериев и тестов, смотреть на ранние результаты работы разработчика до конечной сдачи работ и т.д.
Вопрос: Кажется, хорошо так себя мотивировать, но рассчитывать на отсутствие дефектов – странно.
Так я не призываю на это рассчитывать. Над этим надо работать. Настоящая работа QA инженера – не допустить дефектов. Работа тестировщика (QC инженера) – проверять работу продукта, когда на его качество уже не повлиять. Поэтому мне ближе QA инженеры, часто в лице разработчиков. 🙂
Вопрос: Хорошее качество кода будет стоить достаточно дорого, дороже чем долгое тестирование. И часто заказчик выбирает именно долгое и более дешёвое тестирование и ре-тест, чем оплатить дорогущих девелоперов.
Долгое тестирование не улучшает качество кода. Его приходится все равно исправлять вашим дорогущим программистам, а чем позже они это сделают, тем больше времени (читать денег заказчика) они потратят. Гораздо дешевле не допустить плохого кода, чем его потом исправлять. А особенно ситуация усугубляется в случае большой ручной регрессии.
Вопрос: Понятно, что внедрившись ранее – ошибок будет меньше. И все же, как это спасет от того, что ошибки таки есть и “производительность” по сравнению с идеалм меньше в 5 раз?
Ну вот тут от вас и зависит как сделать чтобы “меньше” означало не в 5 раз, а на 5-10% к примеру. 🙂
Вопрос: Код ревью – не панацея. Ревьювить можно отступы и стилистику написания кода. На дев машине никто не гарантирует стабильность и следовательно время будет тратиться больше, что тоже не даст достаточный профит.
Из моего опыта, ревью кода устраняет огромное количество проблем, если оно делается обязательным для каждой задачи. В моих проектах это так уже больше 5 лет. В результате, мы можем работать без тестировщиков и выпускать отличный продукт, которым, без преувеличений, пользуются миллионы людей и множество компаний. Но для этого надо знать, как правильно делать ревью. Об этом мы рассказывали не раз в докладе “Code Review”, запись которого можно найти в материалах выступлений. По поводу стабильности на машине разработчика – тут все зависит от его стиля разработки. Если он работает, разбивая задачу на законченные куски, то с чего тут взяться нестабильности? Да и речь идет о первичном тестировании, которое не должно быть слишком детальное. Его задача – найти быстро наиболее видимые проблемы.
Вопрос: Вопрос к тебе как к разработчику. Внедрив инженерные практики наши разработчики стали еще хуже себя вести, теперь они отдают продукт еще позже, потому что хотят сделять конфетку. В результате в конце итерации просто нет времени на тестирование. Есть такой эффект?
Я на этот вопрос отвечал уже после доклада. Возможно, команда не понимает сути Scrum и как в него вписывается тестирование. Также, возможны случаи перфекционизма, когда инженерные практики существуют только ради факта применения инженерных практик. В нормальном процессе описанного эффекта быть не должно.
Вопрос: Что делать, если тебя “не пускают” в ранние этапы?
Для вас это означает, что вы не можете влиять на качество, а значит, предсказать продолжительность тестирования. Вам надо продать идеи руководству, команде, менеджерам. Продажа никогда не была простым делом. Но без нее никуда. Отличное место для продажи – это ретроспектива (у вас же она есть?). Давите на “больные мозоли”, забрасывая идеи по избеганию проблем. Предлагайте попробовать и делайте все от вас зависящее, чтобы команда в этих попытках не разочаровалась. А для этого вам важно полностью понимать какие могут быть подводные камни и как их обходить.
Вопрос: Какие есть реальные примеры коротких циклов обратной связи, что конкретно надо применять?
Писал об этом чуть выше. Договаривайтесь с разработчиком о разбиении его работы на стадии и раннем легковесном тестировании результатов. Обсуждайте с ним тестовые сценарии, чтобы он вложил их в модульные тесты.
Вопрос: Автотесты “глупые”, да, они много покрывают, но! Всегда есть “непокрытые2 участки, которые не заметили сразу. Как же не проверить еще раз в регрессии?
Автотесты глупые, но вы же умные. 😉 Нашли непокрытые участки и расширили набор автотестов. Автотесты должны пополняться постоянно из других активностей тестировщика, когда он видит, что повторная проверка уже попахивает роботизацией человека. 🙂
Вопрос: Если регрессию нельзя автоматизировать, то что тогда?
Тогда вы в печальном положении. Регрессионная спираль смерти вас все равно нагонит. Вы можете облегчить боль за счет хорошего покрытия модульными тестами и облегченного тестирования в регрессии (например, по чеклистам вместо тестовых сценариев).
Вопрос: Что делать в ситуации когда разработчики отдают новый функционал на тестирование за несколько часов до демо? Тестирование на локальных машинах не всегда возможно и не всегда имеет смысл (тк могут быть блокировки).
Тут важно понять, что для вашей команды входит в состояние ГОТОВО, которое согласовано с заказчиком. Если это полностью протестированный функционал, который готов к заливке на живые продакшен сервера, то выкатывание его за пару часов до демо не имеет смысла. Его ведь не успеют протестировать. Поэтому надо менять процесс разработки. Обсудите эти проблемы на ретроспективе.
Вопрос: А как насчет эксплоратори в регрессии?
Я только за, но делать его нужно в определенные запланированные моменты. Проверки основные стоит автоматизировать, чтобы регрессию можно было делать сотни раз за итерацию и она не допускала ошибок.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
