Comments 17
Интересный материал, прочитал с удовольствием :)
Приятно видеть, что тестировщик грамотно может разложить задачу по полочкам.
Однако есть один вопрос, а именно,
почему тестировщик выполняет роль аналитика бизнес требований + РМ, тем более уже по факту реализации задачи? :)
Ведь для того и создана иерархия передачи и согласования информации, чтоб каждый в ней исполнял свою роль.
Попробую расписать процесс, как его вижу я со своей колокольни.
Прошу сразу камнями не закидывать, так сказать мнение автора может не совпасть с вашим.
И надеюсь, что мое видение будет вам полезно в работе.
По правильному, аналитик перед разработкой создает спецификацию того, что требуется создать.
Он создает это не просто так, а для того, чтоб разработчик мог "не думать" и делать то, что написано.
Сказано 4 ножки у табурета и высота в 2 бутылки 0.5 Кока-колы - делаем 4 ножки и высота в 2 бутылки.
Не сошлось - вопрос к спецификации.
Причем делает он ее не абы как, а подробно, детально прописывая все, что потребуется знать разработчику и РМ.
"Таким образом мы, в первую очередь, спасаем команду от бесконечного цикла доработок, если вдруг выяснится, что заказчик хотел не пластмассовую табуретку, а резной деревянный табурет с бархатной подушечкой." - т.е. тут спасает не тестировщик обычно, а именно аналитик.
Справедливости ради, именно на этом этапе тестировщик уже должен подключаться к проекту и формировать "карту тестирования", особенно, если речь идет о методологии TDD (которая в РФ, правда, применяется редко).
Собственно об этом же вы пишите позже: "Тебе не нужно переживать, всё ли ты учёл при проверках, если ты уже набросал себе план проверок!"
Следом идет роль РМ, который по сути должен получить подтверждение от Заказчика, что это действительно тот стул, который имел ввиду заказчик.
"От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?" - должен спрашивать РМ у заказчика.
Мнения разошлись - спецификация уходит обратно к аналитику.
Мнения сошлись - информация идет на уровень ниже.
Подтверждением, что это уровень ответственности именно РМ является и ваша фраза:
"Разумеется, бывают ситуации, когда на многие вопросы мы не сможем получить ответы, потому что заказчик сам не знает точно, что он хочет, а команда дружно пилит MVP", ведь в этом случае решение принимает руководитель проекта и это называется "Принято менеджерское решение".
Далее начинается уровень Разработчика.
1) На тестирование не должен попадать нефункциональный продукт.
Вообще и ни при каких обстоятельствах.
Для этого существуют автотесты, например.
Все это зона ответственности разработчика, так как нефункциональный продукт - это, говоря проще, нерабочий продукт.
У вас этот пункт зафиксирован как:
"Для начала, проверим соответствие базовым требованиям и обмерим табурет линеечкой — соответствуют ли реальные габариты тому, что было в задании?"
Это зона ответственности Разработчика.
2) Если продукт передан в тестирование, то разработчик уже провел проверку на соответствие ТЗ и убедился, что "у стула 4 ноги".
Иначе будет то, что вы описываете как:
"Зафиксируем отклонения, если они есть (в последствии бизнес-аналитик или владелец продукта ознакомятся с этими отклонениями и дадут свой вердикт — допустимо это или нет)."
Т.е. несоответствие бизнес-требованиям на этапе сдачи продукта в предрелиз/эксплуатацию.
И хорошо, если расхождение ожидание-реальность не очень большое.
После этого действительно наступает уровень Тестировщика.
Фактически он выступает в роли "Альфа-юзера".
Расписывать подробно не буду, суть вы описываете абсолютно верно.
Однако мне кажется уместной такая последовательность тестов:
1) Smoke Testing (проверка наличия всех объектов согласно описанию)
2) Functional Testing (верность перехода по кнопкам, как пример)
3) Integration Testing (корректность межмодульного обмена данными)
4) Regression Testing (при необходимости)
5) Load Testing (здесь возможна совместная работа с DevSecOps)
6) Stress Testing (здесь возможна совместная работа с DevSecOps)
7) Security Testing + Fuzz Testing (здесь возможна совместная работа с DevSecOps)
8) UI Testing (тут под вопросом, должен ли это тестировать тестировщик или Дизайнер, например)
Почему важна именно такая последовательность теста?
На примере стула:
Мы проверяем, что стул есть и он похож на стул (Smoke Testing).
Мы проверяем, что на нем действительно можно сидеть (Functional Testing).
Мы проверяем, что ножки не скользят на мокром полу (Integration Testing).
Мы проверяем, что пятая ножка стула не мешает сидеть (Regression Testing).
Мы проверяем, что стул выдержит 1 толстого человека (Load Testing).
Мы проверяем, что стул выдержит 4 толстых человека и сломается на 5-м (Stress Testing).
Мы проверяем, что в стул никто не сможет вставить прослушку (Security Testing) и даже если мы на стул посадим не человека, а кошку - стул выдержит (Fuzz Testing).
Если стул выжил - можно оценить стоит ли его покрасить в розовый цвет (UI Testing).
Касательно Документации.
Ее отсутствие - критично в 100% случаев, если речь идет о групповом проекте.
Пройдет квартал - никто не вспомнит как и что работает.
Вы верно описали, что
"Если быть предельно откровенными, отсутствие документации не блокирует релиз и не мешает нам выдать табурет заказчику сразу же, как только будут устранены все дефекты."
Однако далее это превращается в техдолг, который в 99% случаев не даст погасить сам Бизнес в лице РМ.
Задача Бизнеса - получать максимальную прибыль и "написание документации вне проекта" противоречит основам бизнеса...к сожалению.
Потому документацию всегда надо писать сразу до сдачи проекта и учитывать это время на уровне формирования сроков сдачи.
Отмечу, что если
"Помимо всего прочего, в будущем, если по каким-то причинам у табурета станет меньше ног или отвалится сидение, мы сможем доказать, что на предыдущих этапах всё было в порядке и мы следили за качеством изделия."
, то это защитит лишь репутацию тестировщика.
С точки зрения заказчика ПО и Бизнеса - продукт не работает, а почему не столь важно.
ЭПИЛОГ
Принимаю, что у вас тестирование действительно проходит именно так, как вы описали.
В каждой компании свои исторические нормы и правила работы с входящей информацией.
Однако, если бы я увидел, как тестировщик на моменте сдачи продукта начинает уточнять требования к продукту, то я бы задал очень неприятный вопрос бизнес-аналитику :)
Ведь именно его задача сделать так, чтоб никто не нервничал, а исполнял то, что написано "свыше" :)
Надеюсь, что комментарий был полезен ;)
Я с вами полностью согласна. Всё вами сказанное справедливо и отлично отражает картину того, как должен выглядеть процесс разработки в идеале :)
Более того, я слышала о компаниях, в которых примерно так всё и происходит, и участие тестировщика в разработке ограничено именно этапом, когда хорошо проанализированная и готовая задача приходит в тест.
Но по моему опыту, такую тщательную подготовку требований и хороший анализ могут себе позволить зрелые компании, процессы в которых слаженно работают не первый год.
А бывают молодые компании и стартапы, в которых команда только набирается, а продукт разрабатывается в очень сжатые сроки. В таких командах, к сожалению, описанный вами подход - непозволительная роскошь. Там и процессы могут быть не отстроены на старте, и бизнес не готов играть по правилам разработки, а потому переобувается на ходу. В таких случаях приходится вешать картинку с идеальным циклом разработки на стену, как напоминание, к чему стремимся - но в моменте делать так, как требует текущая реальность.
Случается такое, что задача, переданная в разработку, прилетает в середине спринта (тогда она имеет риск прийти к тестировщику на анализ уже выполненной). В лучшем случае - аналитик получает бизнес-запрос, посвящает разработке требований текущий спринт (по факту, если аналитик на проекте один - то и того меньше), и к следующему спринту уже выдаёт требования, по которым ведётся разработка. Да, на ПБР и грумингах команда может ознакомиться с задачей и задать какие-то вопросы, если видит дыры. Но всё это не спасает от того, что тестировщик садится смотреть текущие задачи и находит ещё пачку вопросов к описанным требованиям.
И вот в таких условиях тестировщик участвует во всех этапах работы над задачей - и тестирует требования, и задаёт вопросы, и проверяет соответствие результата требованиям, и, собственно, проводит тестирование. Можно было бы, конечно, отругать аналитика за поверхностные требования, а разработчика - за то, что сам не проверил, работает ли его функционал, но какой в этом смысл, если бизнес ждёт фичу ещё вчера, и это не единственная ожидаемая фича?
Я очень хочу верить, что любой не загнувшийся стартап рано или поздно перестанет быть стартапом, построит стабильные процессы (и коммунизм), научит бизнес быть последовательным в хотелках и заживёт хорошо и спокойно. Но для начала этому стартапу надо "взлететь" - а это уже другая история :)
Случается такое, что задача, переданная в разработку, прилетает в середине спринта (тогда она имеет риск прийти к тестировщику на анализ уже выполненной).
Это как?
Есть и другой вариант, когда тестировщик подключается в пару к аналитику на этапе работы с требованиями: контролирует качество требований (что б потом не было сюрпризов) и заранее начинает проектировать тесты (параллельно разработке; а приемочные тесты - даже до разработки, они самые высокоуровневые). Больше того, разработчики могут получить тесты в качестве иллюстрации требований.
Так что призываю тестировщиков подключаться раньше, чем "описанная и разработанная задача пришла в тест"
Спасибо, сохранил ваш комментарий себе в заметки! Достойно отдельной статьи!😎
Далее переходим к более практическому этапу — юзабилити-тестированию. Здесь нам предстоит проверить, насколько хорошо табурет справляется со своими прямыми обязанностями. Начнём с позитивных тестов:
Табурет устойчиво стоит на ровном полу?
На табурете можно сидеть?
Этих требований же не было в ТЗ.
Зачем тогда их проверять?
Это неявные требования, подразумевающиеся по умолчанию.
Если у вас будет задача "Добавить в модальное окно кнопку "Закрыть"", само собой разумеющимся будет завязать на эту кнопку функционал закрытия модального окна.
Так и в данном примере - если мы разработали табурет, то ожидается, что на нём можно будет сидеть. Иначе для чего мы вообще его делали?
Падаждити. Вы же сами пишете:
От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?
Разве заказ табурета не является неявным требованием к тому, что заказчику нужен табурет? Разве это не подразумевает по умолчанию, что ему нужен именно табурет?
Если нет - то как вы решаете, какие из неявных требований по умолчанию подразумеваются, а какие - нет?
(вдруг заказчику нужен безногий табурет для арт-инсталляции или для цирковых номеров?)
Уточнение того, что именно нужно заказчику - это работа с требованиями, так сказать, на основе печального опыта - финализировать договорённости, что мы общаемся на одном языке с заказчиком, и когда он говорит о табурете, он имеет в виду именно табурет, а не какой-то другой объект для сидения.
(Предупреждая вопрос о релизе и внезапном осознании, что заказчик хотел компьютерное кресло - такое тоже бывает. На берегу договорились об одном, но к моменту релиза бизнес осознал, что хотел совсем другого. Но это отдельная история.)
То есть, уточняя параметры изделия (табурет и его характеристики), мы определяем, какой именно табурет мы должны изготовить. А далее, из этого уже определяем неявное - для чего он нам нужен: для сидения на кухне или для исполнения цирковых номеров.
Но вообще, ваше замечание справедливо, и по-хорошему, если мы не являемся компанией, которая специализируется строго на изготовлении мебели для дома (а потому нам в принципе не могут заказать какой-то специализированный табурет с необычным функционалом), то уточнять нужно не только параметры табурета, но и его предназначение: для чего он - сидеть, стоять, жонглировать.
Спасибо за заметку!
Это к вопросу у предыдущем комментарии про первичную работу аналитика и затем уже работу разработчика с тем, что подразумевается по умолчанию.
Потому что очень часто требования заказчика звучат как-то в духе: "Ну сделайте там обычный сайт, с меню и с картинками“
Вы делаете меню сверху, а он оказывается меню хотел отдельно свёрнутая в модальном окошке, что требует полной переработки заново.
>> От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?
>> (вдруг заказчику нужен безногий табурет для арт-инсталляции или для цирковых номеров?)
Аналитик, "собрав" требования (ФК, НФТ, пользовательские, ...) к табуретке, по хорошему должен еще и сформулировать бизнес-требования: "а какую, собственно, проблему вы будете решать с помощью той штуки, которую заказываете?"
Здесь может быть дискуссия. А что если заказчику нужен табурет, чтобы на нем стоял фикус? По хорошему то что вы пишете, это этап тестирования требований, а не кода. Там должно быть написано: на табурете должна быть возможность сидеть /Кнопка "Закрыть" должна закрывать модальное окно. Иначе вам может показаться, что "подразумевалось", что кнопка "Удалить" должна удалять объект, а она должна заставлять деда мороза танцевать и это часть игрового привлечения клиентов на сайте )
На месте нетерпеливого менеджера, я бы задал много вопросов PM и аналитикам по итогам такого проекта.
В реальной жизни, к табурету срочно прибили бы доску чтобы сделать спинку, и начали бы сдавать компьютерное кресло. Если у исполнителей есть совесть, то струганную.
Твой труд обязательно дам прочитать коллегам, отлично описано "как должен думать взрослый, добросовестный тестировщик".
Можно ли поставить табурет ножками вверх? Можно ли после этого сидеть или стоять на табурете приличными способами?
А зачем нам тестировать стоит ли табурет вверх ножками? и тем более можно ли на нем сидеть? По опыту - тестирование часто заводит именно такие дефекты (табурет не стоит на 1 ножке, если 15 раз нажать на одну из них подряд)))) зачем? Есть инструкция пользователя как в икее - табурет ставь на 4 ножки. Поставил вверх ногами или на одну? ну извини )) Зачем тратить время разработки и править такие дефекты?
Увы. Но любой предмет может быть использован "непредметным" способом. Это может привести к проблемам в безопасности. Это может привести к неожиданным эффектам.
Беда современных инструкций — это куцее изложение того, что "для того, чтобы сделать то-то и то-то, надо сделать то-то". Нет вводного раздела с описанием того, а что это за предмет, что в принципе с ним можно сделать. Надо же понимать, что ты делаешь! Мы должны знать, чего ожидать в случае, если мы (случайно или намеренно) произведём определённую последовательность действий.
Довольно любопытно прочитать такой бойкий концентрат.
Но какой из этого может быть вывод?
Наерное, лучше всего будет с самого начала иметь некий общий для разных сторон документ, в котором всё расписывается "от печки", начиная с базовых понятий, продолжая методологией разработки и завершая принципами реализации. Это как отчёт о НИР. Каждый этап работы над проектом — раздел отчёта. И все всё будет ясно на каждом этапе.
Тестируем обычную табуретку: руководство для нетерпеливых менеджеров, или Как работает тестирование