Контроль над качеством осуществляется многоступенчатой проверкой AutoCAD и начинается он не тогда, когда программисты написали код в виде кусочков программы или функции, а тогда, когда менеджеры по продукту и маркетологи определили, что надо делать. Мы проверяем качество на каждом этапе разработки AutoCAD. Как только маркетинг определяет необходимый функционал, мы проверяем MRD (англ. Marketing Requirement Document - документ с требованиями маркетинга) который они пишут, так как в нашем отделе в большинстве своем работают специалисты, которые хорошо знают AutoCAD и CAD индустрию в целом. Наши специалисты знают, для чего нужно использовать AutoCAD, будь то архитектура, дизайн, электрика, ландшафт и т.д. После просмотра MRD появляется видение того, насколько необходим и реализуем тот или иной функционал, предлагают внести изменения или другие пути решения вопроса. Все это происходит на концептуальном уровне и с этого все начинается. На следующем этапе, после того как вслед за маркетологами пришли дизайнеры и начали говорить о том, как должна быть работать определенная функция (через командную строку, диалог, ленту и т.д.), мы тестируем их спецификации и говорим о том, что это все правильно или наоборот, что что-то нужно изменить, говорим насколько пользователю «интересно» будет работать именно таким образом. Используя свой опыт в промышленности, мы пытаемся повлиять на то, каким образом будет выглядеть конечный продукт.

После этого начинается наша самая главная функция – проверять качество непосредственно программы, качество кода. Это делается несколькими способами. Во-первых есть так называемые тестировщики вручную или вчёрную (manual or black box testers) – это люди, которые знают программу и просто используют все только что реализованные функции и смотрят насколько они работоспособны, как они взаимодействуют с другими, уже имеющимися функциями в программе и т.д. Такого рода тестирование включает в себя то, как файлы сохраняются, как реализована поддержка версионности.

Кроме того у нас есть так называемые тестировщики вбелую для программных интерфейсов (white box or API testers). Это программисты, которые работают в отделе тестирования. Они проверяют функционал, который понадобится сторонним компаниям разработчикам, при создании всевозможных дополнений к AutoCAD. Они также смотрят на сам код и сообщают «ручным» тестировщикам, что конкретный участок кода может затронуть другой функционал, который необходимо будет проверить.

Это два основных направления проверки AutoCAD. Кроме этого есть еще очень большая, можно сказать, побочная часть проверки – это автоматизация. У нас автоматизировано до ста тысяч тестируемых случаев (test cases) проверки AutoCAD, и эта проверка прогоняется каждую неделю. Ручных тестов намного больше, и их количество зависит от того, какую функцию мы тестируем в данный момент, и как она взаимодействует с другими функциями. Вот все три основные проверки с точки зрения функций.

А после того, как специалисты напишут документацию, мы ее тоже проверяем и определяем насколько она соответствует действительности.

Если говорить о том, сколько сотрудников работает у нас в отделе – я бы предпочел не называть точную цифру. Скажу только, что это десятки людей.

В функции моего отдела входит тестирование платформы AutoCAD, также входит AutoCAD LT, DWG TrueView, AutoCAD for Mac – это с точки зрения платформы. Так же мой отдел занимается проверкой AutoCAD Architecture, AutoCAD MEP и AutoCAD Mechanical.

Отвечая на вопрос, скажу немного о том, как делается AutoCAD, чтобы он мог быть локализован - потому что перед тем, как его локализовать, нужно быть уверенным в том, что это возможно. Для этого к программе предъявляются специальные требования, и программисты знают, что им нужно делать, а мы это проверяем. То, что мы проверяем, называется глобализацией. В отличие от локализации, глобализация – это проверка программы на то, что она может быть успешно переведена на другие языки. К примеру, мы всегда вместе с английским AutoCAD проверяем несколько уже переведенных версий: немецкую, японскую, китайскую. Кроме того, периодически проверяются и другие языковые версии. Хочу сказать честно: в моем отделе не может быть специалистов, которые будут знать все эти языки, и мы не всегда можем со 100% точностью проверить все. Если мне не изменяет память, в моем отделе нет итальянцев, но мы все равно проверяем итальянскую версию, для того чтобы точно знать, что она будет работать. Замечу, что проверка перевода не входит в наши обязанности. Для такого рода проверки есть команда по локализации, которая этим занимается.

Я затрудняюсь сказать точно, какова доля. Мне неимоверно сложно будет назвать процент. Это и не 100% и не 0%, а где то между ними :). Мы уделяем очень серьезное внимание бета-тестированию, потому что, несмотря на профессионализм команды инженеров, мы никогда не сможем симулировать огромное множество вариантов установки нашего ПО на тысячах компьютеров с различной конфигурацией сопутствующих программ, настроек и т.д.

Хочу сказать честно, не всегда сообщения об ошибках, которые мы получаем от пользователей, позволяют нам воспроизвести их на внутреннем уровне. И это понятно – пользователи не являются профессиональными тестировщиками. Несмотря на это, мы рассматриваем абсолютно каждую проблему и ищем именно тех пользователей, которые, во-первых, используют AutoCAD в реальном проектировании, а во-вторых, на специальных конфигурациях, которые мы сами не смогли проверить.

Это очень серьезная часть проверок AutoCAD. Более того, внутри бета-программы есть разные уровни: есть обычная бета, где люди загружают ПО, и некоторые один раз посмотрят, а некоторые очень активно используют, взаимодействуют с нами на внутреннем бета-форуме. Есть следующий уровень бета, когда мы рекомендуем использовать предрелизную версию в конкретных проектах в компаниях бета-тестеров. С этими людьми мы работаем один на один, помогаем, если у них возникли какие-то проблемы. Иногда выпускаем для них текущие исправления (hot fix) и очень серьезно относимся к их замечаниям. С другой стороны, им легче объяснить нам суть проблемы, легче поставить правильные приоритеты.

Я работаю с одним человеком, который находится в Москве, и он один из лучших наших бета-тестеров, входит в программу «Gold beta tester» (золотой бета-тестировщик). Он предоставил много замечаний, которые очень помогли нам улучшить качество ПО.

Если говорить о программах, которые мы используем для тестирования, то большинство из них стандартные. Они специально были написаны для тестирования ПО, но мы их обернули в нашу внутреннюю оболочку, которую создали сами, чтобы полностью автоматизировать процесс тестирования и сделать его намного более эффективным. Насчет вопроса о системе – мы используем внутренние системы и внутренний процесс, который разработан годами и отлажен годами. Вообще, при разработке AutoCAD используется гибкая методология разработки систем (agile system development), которая применяется в некоторых случаях полностью, а в других – лишь частично. И мы являемся частью всей этой системы.

Интересный вопрос, потому что модная ныне гибкая методология разработки подразумевает, что люди сидят буквально в одном офисе или в одном большом помещении без перегородок и работают вместе. Не секрет, что AutoCAD делается в разных областях мира, и мы очень пытаемся сделать так, чтобы и тестировщики и программисты были вместе. Часто это получается, иногда этого не удается добиться (например, инженер-тестировщик находится в США, а специалист-программист в Сингапуре), тогда нужно искать подходы, чтобы эти специалисты эффективно работали совместно, несмотря на огромные расстояния. Для взаимодействия территориально разделенных специалистов мы используем Microsoft Communicator, который очень похож на Skype. Мы используем его постоянно. И кроме того постоянно обмениваемся сообщениями с помощью электронной почты. Возвращаясь к началу – мы очень тесно работаем с программистами, иногда буквально сидя рядом с ними, но к сожалению, не всегда это получается.

Взаимодействие происходит в рамках программы тестирования. Есть специальная программа для разработчиков, так называемая third-party developers, которая под эгидой Autodesk Developer Network позволяет обновлять имеющиеся программы до последних бета-версий и посылать разработчикам Autodesk сообщения об ошибках и пожелания по развитию программных интерфейсов. ADN в этом случае является связующим звеном между разработчиками и нами. А при необходимости мы работаем напрямую (это нечасто, но случается - особенно в случае «золотого бета-тестировщика»).

На нашем вебсайте есть специальная страница для обратной связи (feedback page), где желательно (но не обязательно) писать по-английски. После получения ошибки ее описание посылается по электронной почте группе людей, которые изучают проблему. (Стоит отметить, что мы получаем не только много пожеланий, но и… ненормативную лексику, на которую, честно говоря, совсем не хочется отвечать. Хотя с другой стороны, когда отвечаешь на сообщения, содержащие грубую лексику, и пытаешься написать интеллигентно, то в 99% случаев получаешь ответ: «ой, извините, я не думал, что это кто-нибудь прочитает».) После заполнения формы пользователь получает сообщение автоответчика с благодарностью и гарантией прочтения. Мы можем не ответить на каждое послание, но читаем мы 100% посланий. Когда есть конкретные проблемы, мы очень часто отвечаем и иногда просим дополнительную информацию у пользователей.

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

Я всегда прошу пользователей по возможности указывать конкретные шаги, которые привели к ошибке, пользуясь случаем, призываю к этому и читателей isicad.ru!

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

Я очень бы хотел сказать, что да, потому что тогда моя жизнь была бы легче. С каждым годом количество сотрудников растет. Связано ли это с ростом количества пользователей или усложнением самой программы или с ростом количества тестируемых продуктов – однозначного ответа нет. Все понимают, что количество сотрудников компании, в том числе и Autodesk, зависти от объема продаж и бюджета компании. Но также есть зависимость от окружающей обстановки: когда наступает кризис – тяжелые времена, когда подъем экономики – более легкие и все это идет по синусообразной траектории. Опять же, с того времени как я начал работать в Autodesk (это было четырнадцать лет назад), до сегодняшнего времени число сотрудников увеличилось.

AutoCAD имеет довольно налаженную систему работы и мы примерно знаем, что можем сделать, какого качества, и как быстро это будет сделано, т.е. мы имеем много так называемых контрольных точек (check points). И если в конкретной точке мы знаем, что запланированное достигнуто, то можем утверждать, что все будет в порядке и в конце. И весь процесс адаптируется с точки зрения достижения таких точек.

Что касается AutoCAD – есть выпуски лучше, есть выпуски хуже, но тем не менее весь процесс достаточно отлажен. А вот когда ты выпускаешь новое ПО – это всегда непротоптанная тропа, несмотря на колоссальный опыт в других проектах.

Самым интересным и неординарным был выпуск первой версии AutoCAD for Mac 2011. Это были абсолютно новые технологии, новые подходы, новые средства автоматизации. Все было новым и все это было очень интересным, но с другой стороны сбивается отлаженный процесс работы и поэтому приходится довольно сильно нервничать.

У нас есть специальная группа людей, которые этим занимаются. Мы уделяем этому вопросу (восстановлению поврежденных файлов) большое внимание, и при возникновении проблемы всегда стараемся восстановить данные. С каждым выпуском мы улучшаем функционал восстановления данных. Во всех случаях, когда программа завершается аварийно, целостность данных – это то, чему мы уделяем очень серьезное внимание. С точки зрения других программ – тестируя API, мы стараемся обеспечить как можно большую безопасность файлов, но это не всегда удается. Если мы не работаем с этими компаниями через ADN, мы не можем протестировать эти файлы, т.к. не имеем инструментов для тестирования именно этого функционала. Особенно это касается того ПО для изготовления DWG файлов, что не основано на использовании фирменных компонентов Autodesk.

В нашей команде подавляющее большинство тестировщиков составляют именно бывшие пользователи. Когда мы набираем команду, которая делает тесты вручную, мы выбираем не тех людей, которые знают, как тестировать ПО, а тех, которые знают сам AutoCAD. Перед нами всегда стоит выбор: тестировщик ПО или профессиональный пользователь ПО. Наши предпочтения всегда на стороне человека, который знает AutoCAD и индустрию в целом. Именно поэтому я был принят на работу в Autodesk. Именно мой опыт работы на АЗЛК, где я сначала выучил азы AutoCAD, а затем повысил свои знания до более профессионального уровня, помогли мне по приезду в Америку достаточно быстро найти работу, связанную с AutoCAD. Я записался в «профессиональный кружок по интересам», не имеющий отношения к Autodesk - AutoCAD User Group. Именно благодаря полученным навыкам работы на АЗЛК я нашел свою первую работу в Америке, а потом я нашел работу в Autodesk. Все это было заложено на АЗЛК.

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

Я не только думаю, я почти уверен, что будут серьезные изменения. Пять лет назад мы не могли себе представить, что мы будем на смартфонах делать такие вещи. Десять лет назад интернет уже был в полном разгаре, но я не думаю, что тогда было большое взаимодействие через сеть. Сейчас, в 2011 году все находится в облаках. Уверен, очень скоро будут полнофункциональные дизайнерские программы для смартфонов. Если через десять лет AutoCAD не будет для настольных ПК, а будет где-то в интернете или в мобильных устройствах – это будет уже другой продукт. Видя постоянно изменяющийся окружающий мир, мы все это изучаем, оцениваем, идет большая работа специалистов в этом направлении. Они рассматривают пожелания пользователей, мировые тенденции. Конструирование, на мой взгляд, более консервативная область, нежели интернет-разработки или мобильные разработки. Чертежи, сделанные двести лет назад, немногим отличаются от современных. Я уверен, что есть люди, которые до сих пор чертят на кульмане, но это не значит, что за этим будущее. Так же и здесь: если нужно будет перестать выпускать AutoCAD для ПК или изменить его для работы в интернете или написать что-то совершенно новое – все это будет рассмотрено и уже рассматривается.