среда, 16 февраля 2011 г.

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

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

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

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


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



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


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

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

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

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

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

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

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

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

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

4 комментария:

  1. В статье нет ни выводов ни постановки, непонятно, зачем она была написана.
    Чтобы заявить, что границы существуют?

    ОтветитьУдалить
  2. > boring...
    yeah...

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

    ОтветитьУдалить
  3. Статья не содержит ничего нового (во всяком случае, для меня) ни с точки зрения теории, ни с точки зрения практики.
    Похоже, автору просто захотелось проPRиться.

    ОтветитьУдалить