Границы и края

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

Так, приглядываясь к рискам, которые могут возникнуть в работе, проще всего сперва посмотреть на крайние значения. Кстати нередко вокруг таких крайних значений ломаются копья в различных спорах на тему тестирования (и вообще разработки ПО). Несколько примеров:

Все тесты должны быть описаны так, чтоб их мог выполнить человек с улицы
против
Мы тестируем, а не мараем бумажки

Просто дайте нам приложение, и мы его проверим
против
Чтобы начать тестирование, нам нужны следующие N артефактов: спецификация по стандарту XXX, …

Тут такая странная проблема, я над ней два дня бьюсь. Нет, баг еще не забивал и с разработчиками не общался, завтра еще поисследую
против
Я проблемы не исследую, пусть разработчики этим занимаются. Я описал, что видел, этого достаточно

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

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

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

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

Но это еще не все границы, с которыми приходится иметь дело, и, наверное, не самые интересные.

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

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

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

Удачи вам, четких границ и нестрашных проблем вокруг них.

40 и 90

Как и многие, однажды я задумался о звучании чисел 40 и 90 в русском языке. Почему они — «сорок» и «девяносто», а не «четыредесять» и «девятьдесять»? В том же английском языке все честно: forty и ninety. И у нас вроде бы должно быть так же, если сравнивать с другими числами: «пятьдесят», «семьдесят». Что не так с этими двумя?

Наверняка я не знаю, конечно; разные есть версии на этот счет. Приведу те, что мне самому кажутся интересными и правдоподобными.

40. В христианстве вообще и православии в частности число 40 играет заметную роль — начиная с потопа, длившегося сорок суток, и заканчивая Христом, проповедовавшим сорок месяцев. Православие, как известно, пришло на Русь из Византии, и долгое время службы велись на греческом языке. Оттуда и позаимствовалось звучание числа «четыредесять», и вытеснило постепенно родной вариант.

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

Впрочем, речь не о числах, интересно другое. Замеченная «странность мира» (нелогичные названия чисел) позволила по-новому взглянуть на числа и связь их названий с историей. То есть, заметив странное и покопав в этом направлении, я узнал что-то новое.

Странности мира — отличный источник знаний о мире.

Дефекты продукта — отличный источник знаний о продукте.

Есть куча других, более официальных, что ли, источников информации о продукте. Требования и спецификации, диаграммы и собственно код; много всего интересного, что можно изучать, анализировать и сравнивать друг с другом и действительностью. Однако, это все, в том или ином смысле, — документы. А обнаруженный дефект — он живой и светится. Особенно когда дефект нетривиальный, вызывающий искреннее изумление. Код не все станут читать; требования расскажут, что мы хотим сделать, но не расскажут как. Зато дефект наглядно продемонстрирует неожиданные выверты внутренней логики приложения. Или — не очень наглядно. Но появится повод поинтересоваться, а чего оно вообще так себя ведет?

Черный ящик становится серым (или, если угодно, полупрозрачным) как раз от желания понять, что происходит. Простой и понятный дефект такого желания не вызовет — для этого требуется что-то удивительное, меняющее картину мира и представление о приложении. Ведь пока все идет «нормально», особого желания лезть в кишки продукта и не возникает: и так примерно понятно, что там за логика, и вообще — неинтересно. Но когда приложение выделывает коленце, и оказывается, что «в действительности все не так, как на самом деле», — тогда-то и рождается настоящий исследователь. Он вгрызается в логи, смотрит наконец в код, зудит над ухом у разработчиков, пока ситуация не прояснится.

С опытом, конечно, знаний о продукте становится больше, и, соответственно, удивительного поведения — меньше. Привычка — страшное дело. Хотя если порой суметь посмотреть на давно привычное непредвзято, можно опять же узнать что-то новое. Наверное, это будет не такое открытие, скорее — интересный нюанс, дополняющий общую картину. Но тоже полезно.

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

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

Отчасти поэтому и нужны тестировщики — они смотрят на продукт по-своему.

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

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

Удачи вам, удивительных дефектов и интересных открытий.