среда, 3 октября 2012 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Да, комбинаторика порой не оставляет шансов протестировать все )

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

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

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

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

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

    Ошибочно считать, что затраты на поддержку тест сьюта не меняются если мы гоняем на одном конфиге и на десяти. Растут. Больше, чем в десять раз, как правило.

    Я бы выбрал подход, когда мы четко определяемся что и как тестируем. Функцуиональность - одним набором тестов на одной конфигурации.
    Верстку, совместимость - другим набором тестов на многих конфигурациях.

    Пост хороший, спасибо.

    ОтветитьУдалить
    Ответы
    1. Спасибо за комментарий.

      Возразить, в общем нечего, остается только согласиться ).

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

      Безусловно нужно четко понимать, что и как мы тестируем. И - какие методы у нас сработают, а какие нет. И еще - какие есть традиционно проблемные точки.

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

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

      Удалить