Проектирование и оформление

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

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

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

Старая поговорка гласит - "За двумя зайцами погонишься, ни одного не поймаешь". Говоря современным языком, мы нарушаем главный принцип эффективного решения задач - сосредоточение единовременно на одной задаче и сокращение временных затрат на переключение контекста. Думаю, все сталкивались с ситуацией, когда описывая провекру, допускаешь какую-либо ошибку в тексте, программа автоматически подсвечивает ее... На автомате пошли в интернет, узнали как написать слово правильно и почему. Вернулись к документу. "Что я там писал? Ах, да, и еще была идея проверить. Забыл. Значит не так важно, вспомню потом".

На приведенной ниже схеме моя попытка пояснить какие активности относятся к проектированию, а какие к оформлению:

Итак, все же какие плюсы дает данный подход:

• За счет разделения задач сокращается потеря времени, сил и нервов на переключение между контекстами;
• На фазе проектирования дизайнер сосредоточен на выявлении тестовых случаев, что приводит к более качественному анализу требований к системе и снижает вероятность пропуска важных проверок;
• Что важно, данный подход позволяет не зарываться в детали, и последовательно идти от общего к частному. Этому способствует как постоянный фокус на целях проектирования, так и используемый инструментарий (рисунки, схемы, таблицы принятия решений, maind map и т.д.);
• Упрощается процесс обсуждения и мозгового штурма с более опытными коллегами. Собраться и обсудить мысли, зафиксированные в виде схем или примеров гораздо проще, чем всем участникам ознакомиться с многостраничным текстовым документом, внести свои предложения и затем скрупулезно править. Кстати, вносить исправления в тот же mind map в разы удобнее и быстрее;
• Оформление дизайна становится более грамотным. Сосредоточение на целях и критериях качества формализации позволяет критически относиться к тексту, использовать более информативный стиль изложения, осознанно употреблять термины;
• Наличие четкой обратной связи между этапами - сложности при оформлении в подавляющем большинстве случаев свидетельствует о необходимости вернуться к проектированию и предпринять меры по улучшению разработанной структуры. Один из самых распространенных случаев - невозможность придумать краткое и емкое наименование тестового сценария или отдельной проверки. Обычно это свидетельствует о проблемах в разработанной структуре тестов и необходимости внести коррективы.

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

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

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

Финальным шагом в приготовлениях будет определение зон проектирования (т.е. разделение исходных требований на небольшие логически завершенные блоки) и временного интервала, отведенного для проектирования. Ограничить себя по времени очень важно, т.к. нет предела совершенству и можно попросту "застрять" пытаясь как можно более тщательнее проработать состав тестов. Лучше провести несколько коротких итераций, количество которых впрочем так же должно быть ограничено.

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