Из интервью с Максимом Крамаренко — руководителем команды разработки TrackStudio, иерархической системы управления задачами
Маленькая команда и большой продукт: каким образом осуществляется тестирование TrackStudio и его саппорт?
У нас нет своей команды тестировщиков. Перед выпуском бета-версии мы инсталлируем новую версию системы на свой сервер и активно используем несколько недель. Параллельно разработчики занимаются тестированием с применением средств покрытия кода (code coverage), мы устраиваем соревнования «кто быстрее достигнет заданного уровня покрытия».
Когда становится понятно, что мы сами в разумное время больше находить ошибки не можем, мы выпускаем бета-версию. После этого помощь пользователей в нахождении ошибок становится определяющей.
Особенность нашей ситуации в том, что
— с одной стороны, у нас самих плохо получается находить ошибки, так как обычно они специфичны для конкретной конфигураций TrackStudio. Клиенты разрабатывают конфигурации самостоятельно, проверить поведение системы на всех возможных конфигурациях мы физически не можем.
— с другой стороны, если клиент обнаруживает ошибку, то часто она носит локальный характер и проявляется только у этого клиента.
Несколько раз мы сталкивались со следующим явлением: крупная компания-клиент перед внедрением TrackStudio решает провести полное тестирование системы силами своего отдела тестирования. В результате они находят несколько ошибок, мы их исправляем и в дальнейшем у этого клиента все работает стабильно. В то же время на интенсивность потока ошибок со стороны других клиентов это тестирование практически никак не влияет – у них другие конфигурации и другие проблемы.
Саппортом и общением с клиентами обычно занимаюсь я сам, это позволяет лучше понимать запросы пользователей. Технически у нас ничего интересного нет – форум, e-mail, телефон. Прямой доступ в нашу TrackStudio мы пользователям не даем по идейным соображениям.
ТDD и автотесты?
Нет, автоматические тесты не применяем. Пробовали, но ничего хорошего из этого не вышло. Причины такие:
Разные части TrackStudio очень сильно сильно взаимосвязаны. Например, работа правил оповещения по e-mail сильно зависит от работы фильтров, настроек правил доступа, пользовательских скриптов. Ситуации когда что-то перестает работать «совсем» у нас возникают редко (т.к. даже обычное создание задачи затрагивает работу значительной части кода TrackStudio), а вот проблемы только на какой-то конкретной конфигурации пользователя бывают часто. Моделировать такие ситуации в тестах довольно трудно, а поддерживать эти тесты в актуальном состоянии – еще труднее.
Мне кажется, TDD хорошо работает в проектах, реализующих какой-то стандарт (XML-парсер, HTTP-сервер), когда спецификации достаточно жесткие и редко меняются. В нашем случае никаких жестких спецификаций нет, по согласованию с пользователями правила поведение системы может периодически меняться, а небольшие изменения кода могут повлечь очень значительные изменения в тестах.
Тут один момент важный — под конфигурациями я понимаю не столько СУБД/ОС/сервер приложений/браузер, сколько непосредственно конфигурацию TrackStudio.
Например, как организовано дерево задач, пользователей, какие триггера, как права назначены, какие фильтры, в каких случаях отправляются оповещения по e-mail, и т.п. Практика показывает, что многие наши клиенты используют конфигурации намного сложнее, чем мы сами (например, запомнился один клиент у которого было 8 процессов с количеством состояний от 30 до 50 каждый).
Чтобы это проверить нам нужна не только реальная база клиентов, но и use cases типа:
— при добавлении задачи тут этот пользователь должен получить оповещение, а этот — нет.
— по такому ключевому слову должна находится эта задача.
и т.п.
Конечно, мы подобное тестирование делаем, но обычно каждый релиз тестируется (нами) всего на 2-х конфигурациях, а у клиентов у каждого что-то свое.
Тут чисто комбинаторная проблема: вариантов разных комбинаций прав, настроек фильтрации, процессов может быть очень много и проверить всё — сложно.
Причем если в языках программирования можно написать формальные тесты (программы, которые должны всегда выполняться и выдавать какой-то результат), то у нас все не так строго — правила поведения периодически меняются и переписывать десяток тестов из-за копеечной правки не хочется.
НравитсяНравится
Если у вас большинство проблем связано с конфигурацией, то и надо копать в сторону конфигурационного тестирования. Не так давно читал, как организовано тестирование Phyton’a, рекомендую. И что мешает сделать реальные тестовые стенды, а не пытаться эмулировать?
НравитсяНравится
По поводу выделенных тестировщиков — да, был такой этап, продолжался месяц или два. Дело кончилось тем, что тестировщики все протестировали, нашли какие-то ошибки, но в какой-то момент перестали находить ошибки (скажем, поиск новой ошибки занимал 2-3 дня). Возникало впечатление, что теперь все ок, выпускали очередную бету и нам продолжали приходить ошибки от пользователей, как и раньше.
Мне кажется, что от постоянного «штатного» тестировщика толку было бы не очень много, гораздо полезнее было бы брать тестировщика для выполнения разового тестирования (новый человек, свежий взгляд). Но дело это довольно затратное, т.к. много времени уйдет просто на изучение особенностей продукта.
Возможно, это особенность именно коробочных продуктов, когда разнообразие конфигураций железа и софта у пользователей очень большое и значительная часть проблем вызвана именно этим.
НравитсяНравится
Да, если соль в конфигурациях, которые или сложно, или невозможно полностью сэмулировать, то обычные тестировщики пасуют — они ведь вгрызаются в сферу работы функционала ВООБЩЕ, проверяя логические переходы между состояниями, например, и этим ограничиваются.
Ваш пример отлично дополняет картину мира тестирования. Для приличия в обществе тестировщиков полагается декларировать, что «ну разве можно без тестировщиков? Без тестировщиков будет плохо…» А ведь действительно можно выпускать продукт без отдельно поставленных тестировщиков, просто всю работу по тестированию будет выполнять кто-то другой — или разработчики, или пользователи, если это не очень-очень критично — выпускать софт зная, что пользователи могут столкнуться с трудностями.
Ну, и веяние последнего времени — снижение цены ошибки. Выпускался бы софт на дисках без возможности быстрых фиксов — без отдельной команды растерзаторов софта было бы сложно жить 🙂
НравитсяНравится
Вполне возможно, что в данной ситуации отдел тестирования и не нужен. Как я понял, тестирование распределяется между разработчиками и пользователями. Если пользователи не против, то, действительно, зачем тратить ресурсы на довольно дорогое удовольствие — тестирование? Хотя сразу возник ряд вопросов к Макхсиму Крамеру… в смысле к Максиму Крамаренко. Например, пробовали они вообще использовать выделенных тестировщиков? Проводили сравнение, выгодности такого вложения средств? Или данное решение было принято логически, на основе собственных суждений?
Сразу вспомнился один из докладчиков на ADD:
Докладчик: …благодаря этому мы сможем почти полностью сократить отдел тестирования!
Из зала: а кто вам тест-кейсы пишет для автотестов?
Докладчик: *понуро* тестировщик
Докладчик: мы вообще вряд ли когда-либо полностью избавимся от тестировщиков, к сожалению… или к счастью.
Знаю, многих, особенно начинающих, тестировщиков может зацепить фраза «у нас нет своей команды тестировщиков». Не стоит переживать 🙂 Никто не собирается отнимать у вас ваш кусок хлеба. Даже данный продукт усиленно тестируют, но тестируют люди, которые данный продукт покупают.
НравитсяНравится
Это просто один из видов тестирования под названием «Протестировано на пользователях!» Встречается неоднократно. Необходимость оснащаться собственной командой тестировщиков может появиться, если процесс разработки идет враздрай, чего у них, судя по тексту, не наблюдается.
К тому же, какая-то фаза тестирования у них присутствует непременно, пусть и своими силами.
НравитсяНравится