Альфа-тестирование КОМПАС-3D v19
«Альфа», которую построил КОМПАС
Вы наверняка слышали про тестирования в индустрии компьютерных игр. А в инженерном ПО? Думаю, вряд ли. Это неудивительно, потому что рынок инженерного ПО довольно закрытый, как и наши заказчики. Как вообще тестируют программные продукты? Есть UX-тесты (отчасти этим мы и занимаемся на альфа- и бета-тестах). Есть А/В-тестирование, но мы не используем этот метод в чистом виде, так как не предлагаем пользователям несколько разных новых КОМПАСов. Тестеры оценивают новую версию, сравнивая ее с той, которую они используют в профессиональной деятельности.Еще недавно видел пример классического альфа-тестирования на канале «Наука» в программе «Большой скачок». Речь шла о бионических протезах и их первых испытателях. Участники берутся тестировать протезы, полностью заменяющие руку или часть ноги. Это наверное не очень приятно, но люди, которые об этом рассказывают, излучают оптимизм. Эти разработки уже на альфа-стадии позволяют ощутить невероятное. Человек сам пробует завязывать шнурки, ощущает силу сжимания пальцев, которых у него нет, – благодаря сенсорам тактильные ощущения возвращаются в нервную систему.
Всё это к тому, что альфа- и бета-тестирование может быть организовано по-разному. У кого-то вообще нет «альфы», и это никак не сказывается на качестве итоговой версии продукта. У нас в АСКОН альфа-тестирование – это выкатка, как правило, еще не завершенного продукта на обзор ограниченного, скажем так, привилегированного круга пользователей. Поэтому мы называем «альфу» закрытым тестированием. Приглашенные эксперты оценивают основные задумки и дают разработчикам реакцию.
Поскольку альфа-тестирование проводилось задолго до выпуска версии, у нас была возможность включить в финальный релиз большое количество изменений, вдохновленных приглашенными экспертами. Результаты тестов не выявили необходимости кардинальных изменений интерфейса и логики работы, задуманных дизайнером и аналитиками. Но всё равно после тестирования мы внесли много изменений. Например вернули убранные режимные кнопки в правом углу, которые отвечают за выход из эскиза. Изначально дизайнер интерфейса сказал, что их не будет. Но тестеры всех потоков убедили, что такого инструмента не хватает.
Отмечу, что альфа-версия 17-го КОМПАСа не была полностью стабильной. Хорошо, если программа работала стабильно в большинстве сценариев, большего тогда не требовалось. Это был продукт для проверки краеугольных решений.
Альфа-тестирования 18-й и 19-й версий уже были другими. Мы представили стабилизированный продукт. Все решения были практически в законченном виде, и времени до выпуска финальной версии было не так много, но все равно мы могли внести некоторые изменения разной степени значимости.
Зачем вообще проводить пользовательскую «альфу», и чем она отличается от беты
До появления «альфы» мы проводили только бета-тестирование – выкладывали версию на публичных ресурсах. Некоторые компании проводят альфа-тесты в таком дистанционном формате, но не публично: вот есть преданные пользователи какой-то игры, которые обещают, что никому никогда не передадут тестовый дистрибутив (признавайтесь – передавали хоть раз?). Им дают ссылку на скачивание, они пытаются пройти пару уровней. Но при таком сценарии теряется возможность живого наблюдения разработчика за пользователем. В этом варианте «альфа» – всего лишь еще одна ступень на этапе стабилизации продукта.На нашем альфа-тестировании мы непосредственно наблюдаем за тем, что делают пользователи. Через ServiceDESK письма или отзывы могут не передать того, что мы увидим на тестах воочию. Например, я смотрю на одного из тестеров – он в какой-то задумчивости. Он, скорее всего, решит возникшую проблему, но вряд ли напишет потом, почему задумался в тот конкретный момент. А на альфа-тестировании я подхожу – и мы начинаем разбираться. Оказалось, что ему тяжело найти что-то в настройках, и я понимаю, что это реальная эргономическая проблема.
Смысл в непосредственном контакте, наблюдении своими глазами, подталкивании пользователей к воспоминаниям и мыслительному процессу – скорее всего, они не сгенерировали бы столько идей и предложений, кейсов самостоятельно.
Про методику напарничества
Суть в том, что за каждым пользователем закрепляется аналитик от команды разработки, который отслеживает его действия и реакции в режиме реального времени, записывает все сложные моменты при взаимодействии с системой. Мы по очереди запускаем заранее подготовленные сценарии, смотрим за тем, что делают тестеры, затем обсуждаем – чаще всего в режиме очень оживленной дискуссии.
Методика родилась, когда мы готовились к тестированию 17-й версии. Нам было важно, чтобы пользователи получили опыт взаимодействия с новым интерфейсом, а мы бы могли оценить этот опыт.
В итоге появился такой алгоритм:
- Пользователи тестируют КОМПАС по предложенному нами сценарию, чтобы добиться одинакового результата путем выполнения примерно одинаковых действий.
- Наблюдатели (аналитики, тестировщики АСКОН) фиксируют затруднения и проблемы.
Что и как тестируем
Тестирование каждой версии проходит по разным сценариям. Для v17 мы делали инструментальные замеры: количество кликов, пробег мышки. Это было важно для оценки нового интерфейса. На тестировании v18 открывали сборки в старой и новой версиях,чтобы визуально оценить разницу в быстродействии систем. В этом году выдали на суд пользователей новую функциональность, которая вошла в 19-ю версию.Обычно мы предлагаем свои модели, синтетически созданные под тестирование отдельных сценариев. Но обязательно просим привозить пользователей свои. Главной новинкой КОМПАС-3D v18 было быстродействие, поэтому пользователям, конечно, было интересно попробовать всё на своих сборках. От одного из участников мы услышали: «У меня перестроился чертеж, который на моих глазах никогда не перестраивался. Он был создан в 13-й версии, с тех пор никто его не мог перестроить».
Еще во время тестирования 17-й версии было важно пройти несколько этапов моделирования: создать эскиз, выполнить разные операции, как можно шире охватить «деревья». Каждый сценарий готовит аналитик. Обычно тот, кто проектирует определенную функциональность, подбирает и соответствующий тестовый пример. При прохождении сценария мы не оцениваем «шаг влево, шаг вправо» как провокацию . Это, наоборот, приветствуется. Лучше пусть что-то случится здесь, мы это заметим и исправим до релиза.
Какие ошибки принимаются
Квоты на количество ошибок нет, но мы делим их на группы и рассматриваем в зависимости от степени важности.1. Критические ошибки
Проблемы, при которых пользователь никаким способом не может получить необходимый результат. Конечно, если возможность достижения такого результата нами заявлена. Аварийные завершения работы программы относятся к этой же группе.Если пользователь привез модель, а она у нас «окривела» – мы ее изучим и поправим ошибки, их тоже можно отнести к критическим.
2. Неудобства
Например, кнопка не в том месте или недостаточно информативное сообщение. Это не стоп-проблема, но она может быть важной. Такие неудобства мы ранжируем, оцениваем трудоемкость и исправляем всё, что можем позволить себе исправить с учётом ресурсов и времени, которыми мы располагаем.3. Предложения
Такие предложения пользователи обычно фиксируют в ServiceDesk или привозят на семинары и форумы, которые проводит АСКОН. Мы их соотносим с имеющимися планами, опять же оцениваем трудоемкость. Эти изменения уже относятся не к исправлению ошибок, а к планированию версий или крупных апдейтов.
Идеальный альфа-тестер
В первую очередь, идеальное альфа-тестирование не состоится без грамотного альфа-тестера. Что это за человек? Альфа-тестер должен быть терпеливым, внимательным и въедливым. Хорошо, если во время тестирования он может вслух комментировать ход своих мыслей. Это очень полезно, когда на тестировании ты сидишь рядом, а человек комментирует то, что делает, – понимаешь, в каком месте он задумался. Это человек с «внутренним магнитофоном». Если мы остановились на каком-то месте, то мы можем «отмотать», и он всё повторит. Это бывает полезно, если вылезает какая-то критическая ошибка и её нужно воспроизвести.Наши альфа-тестеры обладают большим практическим опытом инженерной работы. Такой опыт есть и у тестировщиков АСКОН, но приезжающие на «альфу» специалисты – это активные пользователи КОМПАС, они смотрят на систему со своей колокольни. Это профи в самых разных отраслях: приборостроители, «железячники», кораблестроители, авиастроители. Если люди с перечисленными качествами собираются вместе, то продуктивность будет на высоте. Еще очень полезны творческие инженеры, у которых процесс протекает вне шаблона. Иногда это приводит к «случайному» нахождению серьезных проблем.
Если говорить о самом тестировании – идеальным считается то, которое проводится своевременно. Когда есть возможность качественно отработать обратную связь и внести изменения. А еще, если тестеры заявляют: «Да, это то, что мы хотели». Это особенно важно и приятно. Нам, кстати, говорят не только приятные вещи. Я понимаю, что это часть работы, и не принимаю как что-то личное.
Самое классное, когда я вижу в глазах пользователей интерес. Все они зарабатывают себе на жизнь с помощью КОМПАС, они создают вещи, которые летают, ездят, плавают...
В прошлом работал конструктором и, посещая экспериментальный цех, иногда испытывал потрясение. Там создают автомобиль, которого недавно еще не было: ты видишь железки, которые только недавно чертил, – а они вот уже, «живые» стоят. У нас в АСКОН то же самое, только в увеличенном масштабе. Мы создаем не просто программу, а инструмент. С его помощью люди, которых я вижу, в частности, на альфа-тестировании, создают реально существующие вокруг нас вещи. И им это интересно, они готовы делиться своими наработками и опытом с нами, общаться. Они не пытаются что-то приукрасить. Даже если тестеры говорят вещи, которые можно воспринять как обидные, они заинтересованы не в том, чтобы кого-то уколоть, а в том, чтобы сделать свою работу продуктивнее – через донесение до нас своей конструкторской «боли».
В общем, самое интересное в альфа-тестировании – люди. Когда видишь, какие вещи они создают в КОМПАС, – получаешь драйв и силы для работы.