Многие Стратегии, Многие Модели

В ряде случаев тестировщики (особенно те, что помоложе, и не пуганные длинные проектами) пытаются свести свою деятельность к сверке документации с получившимся продуктом. У этого подхода есть ряд огромных плюсов:

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

Продолжать можно долго. Только у всего этого есть две фундаментальные проблемы:

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

Ведь как пишется софт.

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

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

На самом деле проблема в большинстве случаев выглядит не так как на картинке. Ведь у вашего софта наверняка больше одного потребителя. Например у магазина по продаже рогов и копыт могут быть следующие:

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

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

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

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

Все что описано в документации обозначим вторым кружком (предполагаем что документация не совсем поганая и все же хоть что-то да решает/удовлетворяет):

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

Тут впору бы вспомнить законы Арнольда о технической документации:

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

Это упрощенно. 

Если сложно, то основная проблема не только (и не столько) в неполноте и несвоевременности, но еще и в том, что всегда существуют неявные требования и баги в самой документации.

И вот, по этой самой документации пишется продукт:

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

Все три кружка при этом не статичны, а двигаются, растут и уменьшаются во времени и пространстве. Потому что мир в котором мы живем тоже на месте не стоит.

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

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

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

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

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

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

И то и другое требует уже третьего набора навыков - умения моделировать отказы в продукте и создавать тесты для их обнаружения (почитайте что-нибудь про FMEA, например).

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

"...лучше провести побольше различных видов тестирования на достаточно  хорошем уровне, чем один или два провести идеально..."

Cem Kaner, James Bach, Bret Pettichord, 

"Lessons Learned in Software Testing"

John Wiley & Sons, Inc., New York 2002