Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи: https://mrslavchev.com/2018/11/26/hindsight-lessons-about-exploration-testing-documentation-think-outside-the-dox/
Перевод: Ольга Алифанова

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

Зачастую, когда я спрашиваю студентов, как бы они тестировали приложение, я получаю ответы вроде "Я сравню продукт с документацией или спецификацией". Логичным образом я задаю следующий вопрос – что, если спецификации нет, или продукт еще не создан?

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

Игра теней

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

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

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

Тестирование документации

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

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

Почему тестирование документации и спецификаций – хорошая идея?

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

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

Я полагаю, что самая важная причина для того, чтобы начинать тестирование как можно раньше и проверять документацию – это увеличение ошибок и сложности. Если в документации ошибка, то будет ошибочным это внедрять, а после этого – тестировать. То же верно и для сложности.

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

Документация "с душком"

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

Вот что я считаю важным помнить:

Длина

Она может варьировать, потому что артефакты бывают разных типов: некоторые из них – это юзер-стори, некоторые – техническая спецификация, иногда – руководство пользователя. Тут важно запомнить, что никто не будет читать длинный документ, если только этот человек не библиотекарь и не ученый. Причина тому чисто психологическая, не связанная с процессами или методологиями. Люди осторожно относятся к объему данных, который могут переварить.

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

Сложность

Возможно, я тривиален, но я использую эту цитату из Эйнштейна: "Если ты не можешь объяснить это простыми словами, ты недостаточно хорошо это понимаешь".

У нас ужасные проблемы со сложностью. Все рассказывают, в каком сложном окружении они работают, или какой сложный процесс у них налажен, или насколько сложное ПО они разрабатывают. И угадайте, что? Сложность – это отстой! Хотите знать, почему? Потому что ее никто не понимает, если только не тратит всю свою умственную деятельность на то, чтобы в ней разобраться (чего никогда не происходит).

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

Туманные формулировки

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

Туманная формулировка – это слово или скорее термин, у которого нет четко определенного значения, но который тесно связан с очень узким контекстом.

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

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

Хорошее решение –попросить кого-то взглянуть на документацию свежим взглядом. Постарайтесь найти того, кто не включен в ваш контекст, и спросите, достаточно ли ясно то, что вы написали.

Коллективные знания

Коллективные знания – это те знания, которые мы разделяем, если достаточно долго работали вместе. Это жизненно важная часть нашей коммуникации, которая помогает нам понимать друг друга практически без слов. Однако тут кроется огромная проблема – это знание "скрыто" и не подлежит документированию. На практике коллективное знание – это не знания, это спрятанное знание.

В норме то, что мы описываем этим термином – это то, что "все знают, потому что это здравый смысл", или "все поймут, как это работает, потому что это всегда было в нашей системе". Надеюсь, не нужно объяснять, почему это плохо.

Хороший способ излечить эту проблему – попытаться сделать вашу документацию максимально явной.

Вот и весь мой краткий список интересных вопросов по тестированию документации. С радостью прочитаю ваши советы в комментариях!

Обсудить в форуме