100500 конфигураций.

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

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

Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).

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

Начнем с относительно простой ситуации, когда заказчик и покупатель у нас один. Этот случай проще, так как мы можем довольно точно узнать, как [будет] настроена его система, и отбросить остальные варианты. Даже в этом случае возможны проблемы: не всегда удается в тестовой лабе воспроизвести масштаб и сложность боевой системы. Ок, давайте тестировать в «похожем окружении».

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

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

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

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

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

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

Тут тоже, конечно, есть важный момент, и далеко не один. У крупного клиента могут случиться свои проблемы, и лабу он не предоставит. Или предоставит, но доступ туда будет такой заковыристый, что тестировать невозможно. Или пообещает сам протестировать, и не успеет вовремя дать фидбек. А в случае массовой беты – можно утонуть в непрофессиональных багрепортах, не разобраться в приоритетах найденных багов, пропустить «явно невероятную» проблему в релиз. В любом случае, запуская бету, подумайте, когда и какую обратную связь вы ожидаете, как вы собираетесь с нею работать, и как результат беты может повлиять на текущие планы по выпуску продукта.

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

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

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