Loading...

Тестировщик новой формации (ТНФ)

  • Это карта про МИССИЮ Тестировщика новой формации (ТНФ)

  • «Тестировщик - главный АДВОКАТ пользователя»

    • Адвокат - защищает интересы своего клиента

    • КАКИЕ интересы пользователя / заказчика защищает тестировщик?

      • Функционал решает ПРОБЛЕМУ пользователя

      • Функционал удобный в использовании

      • Функционал «НЕ глючит»

      • Функционал выдан пользователю в нужное время (в срок)

    • КАК при производстве ПО могут быть нарушены интересы пользователя?

      • Аналитик не узнал / не понял, в чём ПРОБЛЕМА пользователя

      • Аналитик понял проблему, но придумал РЕШЕНИЕ, которое не решает / частично решает эту проблему

      • Придуманным функционалом будет неудобно пользоваться

      • Аналитик не смог получить от пользователя / стэйкхолдеров качественный ФИДБЭК на своё решение

      • Аналитик не смог донести своё решение до разработчиков и тестировщиков

        • Разработчики поняли по-своему

        • Тестировщики поняли по-своему

        • «Авторская приёмка» от Аналитика. Откуда взялась эта практика?!

          • Изначально исходят из 2-х предположений:

            • Разработчики могли реализовать не то, что задумал аналитик!

            • Тестировщики не до конца знают, что задумал аналитик!

          • На самом деле...

            • НИКТО до конца не знает, что задумал аналитик

          • Это вопиющий СИМПТОМ того, что что-то не так в процессе разработки

      • На вход к разработчикам и тестировщикам приходят "сырые", некачественные требования (описанное решение)

        • Недостаточно проработаны детали

        • Многое осталось лишь в «голове» у Аналитика

        • Требования можно по-разному интерпретировать

        • Редко учтены (до начала разработки) архитектурные ограничения

        • Факторы, ухудшающие качество требований:

          • Время, которое даётся на анализ - НЕ позволяет сформировать достаточно проработанные требования

          • Уровень аналитиков - НЕ позволяет сформировать требования с ясной концепцией, лаконично сформулированные

          • Аналитик работает в одиночку - у него нет диалога («варится в собственном соку»)

            • при попытке дать самому себе обратную связь (шизофрения, раздвоение личности)

            • при попытке всё учесть - «паралич анализа»

            • может не заметить очевидных вещей

            • может много времени потратить на анализ «ошибочной» ветки

            • ...

        • И вот разработчик получает на вход такие требования...

          • Необходимо много итераций для выяснения концепции, деталей...

            • на ходу «мутируют» Требования

          • Многое из того, что «прояснили», НЕ фиксируется

          • Всё равно часть Требований Разработчик интерпретирует по-своему

          • Когда Разработчик начинает кодировать, у него НЕТ чётких критериев, когда функционал уже готов

            • когда он (разработчик) может со спокойной совестью передавать код в тестирование

          • Разработчик много времени тратит на то, чтобы представить себе КАК это должно работать (построение ОБРАЗА продукта)

            • И это хороший разработчик!

            • А плохой - начинает кодировать в стиле: «так... посмотрим во что это всё выльется...»

            • Кстати, основная проблема при освоении TDD - это то, что Разработчики не привыкли сразу чётко определять конечный образ продукта / функционала

      • В процессе разработки не понятно, успеваем или нет... следовательно, нет возможности во-время откорректировать планы

      • Этап тестирования и баг-фиксинга...

        • Растягивается...

          • (выходит за рамки плана)

        • На выходе слабого качества продукт / функционал

        • Почему?

          • Мало времени...

            • На этот этап выделяется мало времени

            • И от этого малого времени пытаются "откусить", когда разработчики не успевают доделать функционал

              • (используют как "буфер" при неуспевании в разработке)

            • Что "съедает" время на этом этапе?

              • Выяснение, баг это или фича

                • Во время разработки разработчики договорились с аналитиком об изменении требований, а тестировщик не в курсе

              • Часто этап начинается с багов уровня Blocker и Critical

                • Невозможно продолжать тестирование

                • Меньше времени останется на поиск и правку багов с меньшим уровнем

                  • Соответствующее качество на выходе

              • В первой волне правятся не только самые приоритетные баги

              • Баг-репорты не "конфетки"

              • Возникает необходимость в серьёзной переработке кода

          • Всё тестирование "приехало" в конец

          • При правке багов - постоянный импакт (регресс)

          • Часть багов уже по-нормальному не починить, т.к. нет времени менять архитектуру

      • Главное не доделали, а не особо нужное - реализовали

      • Функционал реализовали, и... стэйкхолдеры должны придумывать, как разработанный функционал:

        • продать

        • настроить

        • внедрить

    • КАК тестировщику защитить интересы пользователя?

      • надо на разных этапах «ДРАЙВИТЬ» процесс разработки в интересах пользователя

      • КАК «драйвить» процесс разработки в интересах пользователя?

        • Постоянно возвращать фокус внимания команды на пользователя, его интересы

          • Нужно, чтобы кто-то постоянно напоминал участникам процесса о пользователе...

            • Как он пользуется системой?

            • Как он будет пользоваться новым функционалом?

            • Удобно ли ему будет пользоваться новым функционалом?

            • Решает ли новый функционал его проблемы?

          • Постоянно искать информацию (аккумулировать), КАК пользователь работает / будет работать с системой

            • впр: Кто может быть источником информации?

              • Как работает сейчас?

                • Пресэйл

                • Аналитик внедрения

                • Service Request

                • Энхансмент (пожелание на доработку)

                • Инженер поддержки

                • Продуктовый аналитик

                • (?) Эксплуатационная документация

              • Как будет работать?

                • Пресэйл

                • Аналитик внедрения

                • Продуктовый аналитик

                • Конкурсная документация

                • Обучающая документация / Курсы

                • Презентационные материалы

                • Энхансмент (пожелание на доработку)

                • Мы, “влезшие в шкуру” пользователя

          • Почему участники процесса со временем теряют фокус на пользователе и его интересах?

            • Думать о интересах пользователя - сложно и проблематично (возникает множество «неудобных» вопросов)

        • Постоянно пытаться узнать / понять как пользователь работает (будет работать) с системой, и использовать это...

          • для выявления КАТЕГОРИЙ пользователей, чьи интересы мы в 1-ую очередь защищаем?

          • чтобы «ВЛЕЗТЬ В ШКУРУ» пользователя

            • представить себе КАК пользователь будет пользоваться разрабатываемым функционалом

            • тогда можно обоснованно предполагать, как пользователь будет работать с функционалом

          • чтобы при анализе концепции и требований уметь определить, оптимальное ли решение проблемы пользователя выбрано

          • использовать для АРГУМЕНТАЦИИ при защите интересов пользователя

            • при анализе требований и концепций

            • в описании БАГ-ов

          • источник КОНКРЕТИКИ для тестовых сценариев

            • в т.ч. показательная тестовая конфигурация (похожая на действительность)

          • для выявления ПРИОРИТЕТОВ (важности)

            • какие баги не позволяют пользователю получить конечный результат?

            • базовых сценариев работы системы у заказчика

              • действия пользователя

              • действия системы

              • обрабатываемые данные

            • какие тест-кейсы прогонять в 1-ую очередь?

          • чтобы понимать на сколько найденный баг критичен

            • выдавать разработчику в первую очередь приоритетные баги

          • . . .

        • ВЫЯВЛЯТЬ на уровне анализа требований следующие ПРОБЛЕМЫ:

          • НЕ ПРОЯСНЕНА (не выявлена) ПРОБЛЕМА, которую должен решить разрабатываемый функционал

            • Вся команда должна однозначно понимать целевую задачу пользователя

          • новый функционал НЕ РЕШАЕТ (не до конца решает) ПРОБЛЕМУ пользователя

            • (пользователь, используя функционал, не может решить целевую задачу)

          • придуманный функционал не соответствует (противоречит) концепции

          • новый функционал ПОРОЖДАЕТ новые ПРОБЛЕМЫ

          • в требованиях не прописаны (не продуманы) все альтернативные сценарии

          • в требованиях не прописаны сценарии, когда «что-то пошло не так»

          • в требованиях есть неоднозначности и противоречия

          • в требованиях отсутствуют «очевидные» на взгляд аналитика вещи...

            • которые разработчик может интерпретировать на свой лад

            • которые разработчик может не реализовать (так как они для него не очевидные)

          • функционал будет неудобен в использовании

        • Быть гарантом того, что участники процесса правильно поняли друг-друга

          • Выявлять «неочевидности» и «недосказанности» в требованиях

            • (в противном случае, разработчик может их интерпретировать на свой лад)

          • С помощью сквозных тест-кейсов (и не только сквозных) вырабатывать общее понимание:

            • того, как должен работать разрабатываемый функционал

            • того, как пользователь будет работать с функционалом

          • Аналитик может положиться на то, что тестировщик не хуже него знает, КАК должен работать функционал (как его задумал аналитик)

            • значит минимизируется количество «квестов» («футбола») между разработчиком, тестировщиком и аналитиком из серии «баг это или фича»

            • часть вопросов от разработчиков из серии «как здесь должно работать» будут направляться не аналитику, а тестировщику

      • ЧТО НУЖНО, чтобы у тестировщика БЫЛА возможность «драйвить» процесс разработки?

        • Участники процесса должны позволить тестировщикам существенно воздействовать на процесс

        • Участники процесса должны захотеть помощи от тестировщиков

        • ДЛЯ ЭТОГО необходимо...

          • Сменить основную парадигму...

            • НЕ КРИТИКОВАТЬ

            • вместо этого...

              • СТРАХОВАТЬ

              • ПРОЯСНЯТЬ

              • инициировать ДИАЛОГ

                • Для чего нужен диалог?

                  • Прояснять...

                  • Выявлять...

                  • Катализировать решения...

                • Что для диалога нужно?

                  • ПРЕДМЕТ диалога - ВОПРОСЫ

                    • «А правильно ли я тебя понял, что...?»

                      • (провоцирующий вопрос)

                    • «Какое поведение системы мы ждём в таком-то случае?»

                    • «Как пользователь будет действовать в такой-то ситуации?»

                    • Шикарный вопрос - это вопрос на основе тест-кейса

                      • или тест-комплекта

                      • при условии, что тест-кейс: читабельный, лаконичный, конкретный

                  • Стремление ПРОЯСНЯТЬ (а не критиковать)

                • Что нужно, чтобы с тобой шли на диалог?

                  • чтобы участники диалога ощутили «профит» от диалога

                  • например:

                    • у участника что-то прояснилось

                    • участник чувствует страховку

              • для этого...

                • быть ПРОАКТИВНЫМ

                • быть КАТАЛИЗАТОРОМ

                • проявлять ЭМПАТИЮ

                  • внимательно слушаем

                  • сначала пытаемся понять логику собеседника

                    • уточняющие / проясняющие вопросы

                      • позволяют собеседнику понять, что ты его понял (услышал)

                  • только потом к понятому подходим критически (анализируем)

                    • критические вопросы (дух «уточнения» лучше оставить)

          • Каждый участник процесса должен получить свой ПРОФИТ от работы тестировщика

            • именно, конкретные участники, а не вся команда проекта / продукта

            • ПРОФИТ для аналитика

              • (психология) Тестировщик не критикует его, а страхует

                • аналитику не надо «защищаться»

              • тестировщик на ранних стадиях выявляет следующие проблемы (таким образом СТРАХУЯ аналитика):

                • были забыты интересы пользователя

                • концепция не решает проблему пользвателя

                • придуманный функционал не соответствует (противоречит) концепции

                • при написании требований что-то было упущено

                • в требованиях есть неоднозначности и противоречия

                • Блин, но это же проблемы аналитика, скажете вы! Почему мы должны помогать ему их решать?

                  • Да, можно сказать «такая у него работа», свесить лапки и ждать «идеальную» спеку

                  • по аналогии с адвокатом...

                    • это всё равно, что адвокату полностью положиться на внимательность, объективность и усердие следователя от обвинения

              • тестировщик минимизирует вероятность того, что:

                • разработчик «неочевидности» и «недосказанности» интерпретирует на свой лад

                • на этапе тестирования готового функционала будут найдены баги / недоработки аналитики

                  • аналитику не придётся оправдываться / краснеть перед руководством и разработчиками

              • аналитик может положиться на то, что тестировщик не хуже него знает, КАК должен работать функционал (как его задумал аналитик)

                • значит минимизируется количество «квестов» («футбола») между разработчиком, тестировщиком и аналитиком из серии «баг это или фича»

                • часть вопросов от разработчиков из серии «как здесь должно работать» будут направляться не аналитику а тестировщику

              • аналитик, ощущая страховку со стороны тестировщика, может избежать «паралича анализа», пытаясь всё-всё учесть

            • ПРОФИТ для разработчика

              • после доработок требований по результатам тест-анализа разработчик получает на вход более проработанные требования

                • отпадает множество потенциальных вопросов / уточнений

              • «богатые» сквозные тест-кейсы (СТК)

                • разработчик может разобраться, как с функционалом будут работать пользователи

                • хороший критерий готовности работающего полезного функционала

              • хороший тест-комплект - это прекрасные идеи для комплекта юнит-тестов / интеграционных тестов

              • разработчик может положиться на то, что тестировщик хорошо знает, КАК должен работать функционал (как его задумал аналитик)

                • значит минимизируется количество «квестов» («футбола») между разработчиком, тестировщиком и аналитиком из серии «баг это или фича»

              • придётся меньше «чинить» багов / недоработок аналитики

                • меньше разрушается архитектура - отпадает необходимость приделывать «костыли»

              • тестировщик выдаёт разработчику в первую очередь приоритетные баги, так как знает, КАК пользователь будет пользоваться функционалом

              • хорошо описанные баги

                • не надо по-напрасну напрягать мозг, чтобы понять, что же там имел ввиду тестировщик

            • (!) нужно им помочь сделать свою работу как можно лучше

          • Всё это повлечёт за собой уважение и доверие со стороны членов команды