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