Home

Мы публикуем расшифровку круглого стола, посвящённого вопросам тестирования и обеспечения качества, который состоялся в рамках ежегодной конференции SECON 2008 в Пензе.

Алексей Баранцев, модератор (ИСП РАН): Давайте начнем наш круглый стол, посвященный тестированию и обеспечению качества программного обеспечения. Согласно решению программного комитета на этой конференции нет ни одного доклада, посвященного тестированию, потому что если бы они были, то это была бы целая сессия, посвященная тестированию. Вместо этого было решено использовать более интенсивный формат круглого стола, где вы сможете пообщаться с нашими экспертами, задать им вопросы.

Я буду вести этот круглый стол. Меня зовут Алексей Баранцев, я работаю в ИСП РАН, но здесь я представляю общественную организацию портал Software-Testing.Ru. Почему я веду круглый стол? Если Вы читали сказки К.С. Льюиса «Хроники Нарнии», там есть такое место – лес между мирами. Так вот я как раз такой человек, который не принадлежит ни одной тусовке полностью. Я одновременно занимаюсь научной деятельностью в области тестирования, работая в академическом институте, руковожу командой тестировщиков более чем из 20 человек, которая работает над заказными коммерческими проектами, одним из главных заказчиков у нас является компания Вымпелком, и я же представляю общественную организацию – портал Software-Testing.Ru, проповедую важность и нужность тестирования.

Сейчас давайте познакомимся с нашими экспертами.

Дмитрий Еманов (координатор разработки СУБД FireBird): Добрый день, господа, меня зовут Дмитрий Еманов, я являюсь техническим координатором разработки проекта FireBird. Здесь я для того, чтобы поделится нашим опытом обеспечения контроля качества в больших проектах. Что представляет из себя наш проект? Это разработка на C++, кроссплатформенная разработка. Достаточно большое  количество кода, при этом большая часть кода унаследована, самые старые модули датируются 1984 годом. Так что контролировать качество всего этого хозяйства непросто. Что же мы для этого делаем?

Основной инструмент тестирования – это QMTest Framework. Это регрессионное и функциональное тестирование. Почему мы используем именно его? Нам в каком-то смысле повезло, у нас нет графического интерфейса, всё взаимодействие с пользователем происходит через API, соответственно достаточно просто формализовать все входы и выходы, всё преобразуется к текстовому протоколу, а QMTest как раз и обеспечивает сравнение текста с эталоном. Тестирование у нас двухуровневое. Первый уровень – это тестирование нашего API, а дальше, обеспечив работоспособность этой части, мы гоняем тесты на SQL, результаты выгружаем в текстовый файл и там происходит сравнение с эталоном.

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

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

Также используем средства нагрузочного тестирования и практикуем code review, у нас есть выделенные люди, которые проверяют каждый commit по логам и имеют право наложить вето на любое изменение в коде. Мы используем JIRA –трекер для организации работы команды, в нём организуется релизный цикл проекта и организуется взаимодействие команды разработчиков с командой QA и командой packager'ов релизов.

Тестирование у нас происходит для каждой платформы, на которой мы выпускаем продукт. На данный момент у нас написано более 600 тестов, это наверное не охватывает функциональность целиком, может быть 70-80%, хотя мы стремимся к большему покрытию. Тесты для новой функциональности пишут кодеры,  которые эту функциональность реализуют, а для зарегистрированных в трекере ошибок тесты пишут сотрудники QA-команды.

Максим Яремко (руководитель российского офиса разработки компании EastCost): Добрый день, меня зовут Ярёмко Максим. Несколько слов о том, чем сейчас занимается наша компания. Мы делаем систему управления производством, которая используется в цикле автоматизации производства вентиляционного оборудования. Система написана на .Net Framework 2.0, общее время разработки составило более трёх лет. Первый год мы работали вообще без QA. Но потом мы столкнулись с ситуацией, в которую, наверное, попадает большинство разработчиков – есть живая система, которую нужно как-то поддерживать. В этот момент у нас и назрела необходимость написания каких-то тестов и организации автоматизированного тестирования.

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

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

Такая ситуация длилась примерно полгода, за полгода привели систему в состояние пригодное для тестирования и сейчас уже с этим проблем нет. Далее мы сделали тесты для legacy-кода, то есть для кода, который мы получили в наследие, он написан на C++. Мы смогли написать обёрточки на C# и писали тесты с использованием этих обёрточек.

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

Следующее, что мы начали делать, это приёмочное тестирование, когда программа тестируется по принципу «чёрного ящика», то есть пишутся скрипты, которые нажимают кнопочки, вводят данные в поля ввода и так далее. Для этого мы пытались использовать бесплатный инструмент AutoIt, ноне очень успешно, потому что он отказывается работать с нестандартным интерфейсом. Чтобы справиться с этим, мы написали публичный API и тестировали систему с помощью этого API. Пользовательский интерфейс вызывает этот API, и мы из своих тестов тоже вызываем тот же самый API. Это не совсем принцип «чёрного ящика», но близко к этому.

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

Инструменты, которые мы используем. NUnit, с ним знаком наверное каждый, кто пишет на .Net. Resharper, очень удобный инструмент, и достаточно недорогой. Он предназначен для рефакторинга в основном, но это также очень удобный инструмент для unit-тестирования. Для mock-объектов используется библиотека NMock 2.0, и совсем недавно мы нашли библиотеку Mocks 2.2, которая не очень известна, в книжках про неё не пишут, но она оказалась гораздо удобнее NMock, и сейчас мы пользуемся этой замечательной библиотекой, и тем, кто начинает пользоваться mock-объектами, я рекомендую использовать именно её. Ну и для тестирования инсталляции используется AutoIt 3.2. В принципе, AutoIt можно использовать и для регрессионного тестирования, если у вас пользовательский интерфейс, основанный на стандартных элементах.

Илья Молтянинов (руководитель отдела веб-разработки компании BIT Creative): Добрый день, коллеги! Меня зовут Илья Молтянинов, я работаю в компании BIT Creative, являюсь руководителем команды разработчиков. Я бы хотел рассказать о том, как устроен процесс тестирования и обеспечения качества в нашей команде, и каким опытом я могу поделиться. Что делает наша компания? Мы разрабатываем интернет-проекты разного уровня сложности на языке PHP, мы делаем как маленькие сайты, так и то, что называется порталами, делаем большие и сложные приложения. Кроме того, мы пишем на PHPсобственный фреймворк (CMS). И всё это должно проходить через какой-то процесс тестирования и обеспечения качества. Мы используем модульное тестирование на PHP, пытаемся использовать методологию TDD, то есть делать модульные тесты до того, как пишем код. Не всегда это получается, но мы очень стараемся, и я могу поделиться опытом внедрения этого хозяйства. Подробнее про это можно почитать на сайте http://wiki.agiledev.ru/. Для модульного тестирования мы используем инструмент SimpleTest плюс написанный нами инструмент limb_unit. Вот про это я хотел бы поговорить – про модульное тестирование, про то, как его организовывать, какие технические подходы бывают.

Мы также разрабатываем приёмочные тесты для больших приложений, используем Selenium. Процесс непрерывной интеграции включает у нас автоматизированный процесс тестирования, выполняются все тесты, какие написаны, и модульные и приёмочные. После этого выполняется создание сборки продукта с последующим выкатом на сервер. Для этого у нас есть собственное решение, несмотря на то, что существуют стандартные решения, можем поговорить об их плюсах и минусах, я могу рассказать, почему мы их не используем. Есть ещё такая разновидность тестирования как нагрузочное тестирование, которое очень важно для веб-проектов. На сайт приходит большое количество пользователей, и он должен с честью и достоинством держать нагрузку, не давать сбоев, обслуживать пользователей с минимальным количеством отказов. Это сама суть веб-приложения. Для того, чтобы это обеспечить, на этапе тестирования или приёмки необходимо делать нагрузочное тестирование. Я могу рассказать, с какими трудностями мы столкнулись в этой области и как мы с ними справились.

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

Зоя Павлова (ведущий тестировщик пензенского отделения компании HeadHunter): Здравствуйте, меня зовут Павлова Зоя, компания HeadHunter. В нашем проекте HeadHunter Live мы используем для обеспечения качества модульные и интеграционные тесты, функциональные тесты, практикуется code review и работа в парах. Проект разрабатывается уже более двух лет. На данный момент команда разработки насчитывает 5 человек, из них двое тестировщиков. В основном наши тестировщики занимаются тем, что автоматизирует все, что можно автоматизировать. Для автоматизации наших функциональных тестов мы используем такие инструменты как jWebUnit, это обёртка для инструмента HttpUnit, очень лёгкие тесты получаются, в частности у нас написан тест, который совершает рекурсивный обход всех ссылок в веб-приложении, которое тестируется. Но у него есть минусы – он не стартует реальный браузер, использует эмулятор, это не всегда хорошо, в частности плохо поддерживается JavaScript. Поэтому основная масса тестов, а их у нас около 500, написана с использованием инструмента Selenium. Тесты на Selenium выполняются достаточно долго, поэтому для ускорения мы используем Selenium Grid. Он позволяет распараллелить тесты, и время выполнения резко сокращается, с семи-восьми часов мы сократили примерно до трёх. Также перед выпуском релиза мы практикуем ручную проверку. Мы проходим по чек-листу и проверяем то, что по каким-то причинам мы не сумели автоматизировать.

Алексей Баранцев: Большое спасибо нашим экспертам. Но прежде, чем вы начнёте задавать им вопросы, давайте проведём маленький опрос. Вы, наверное, уже видели, организаторы опубликовали на сайте конференции информацию о составе аудитории, но давайте на всякий случай ещё раз проверим. Есть в аудитории тестировщики , те кто занимается тестированием? (поднимается 5-6 рук). Разработчики, кто программирует? (поднимается около 80% рук). Руководители, менеджеры проектов? (соответственно, поднимается около 20% рук). Заметьте, что перед вами в роли экспертов сидят тоже в основном не тестировщики. Собрались программисты и менеджеры, чтобы обсудить задачи тестирования. Интересно. Хорошо, давайте выделим две темы. Во-первых, разработчикам, которые пишут код и сами же его проверяют, наверное будет интересна тема модульного тестирования. Во-вторых, разработчикам в повседневной жизни постоянно приходится иметь дело с тестировщиками, поэтому предлагается обсудить также этот вопрос – как разработчики живут вместе с тестировщиками, как им удаётся сосуществовать в одном проекте.

Игорь Катыков, Fujitsu Services, Казань: У меня вопрос к Дмитрию, Максиму и Илье. У вас в команде есть выделенные тестировщики или программисты сами пишут тесты?

Дмитрий Еманов: В нашей команде есть один человек, который занимается исключительно тестированием на базе сбора требований, а также отвечает за customer support, и один тестировщик, который всё автоматизирует, а остальные программисты пишут модульные тесты.

Максим Яремко: Как я уже сказал, у нас обязанности распеределены, разработчики пишут тесты для новой функциональности, а тестировщики для багов. У на два человека выделено исключительно для QA, плюс два на код-ревью. Разработчики, то есть вся остальная команда, пишут тесты для новой функциональности.

Илья Молтянинов: У нас ситуация практически аналогичная. Разработчики непосредственно при разработке продукта пишут модульные тесты для того кода, который они разрабатывают, тест является спецификацией и его успешное прохождение является условием приёмки. Для стадии приёмочных тестов у нас есть один выделенный человек, который только этим занимается. Для нас этого достаточно.

Алексей Баранцев: давайте проведём ещё один небольшой опрос. В зале есть разработчики, которые не пишут тесты, не занимаются разработкой модульных тестов для своего кода? А кто занимается разработкой тестов? Примерно поровну.

Вопрос: В дополнение к предыдущему вопросу – каков должен быть, по вашему мнению, процент выделенных тестировщиков для успешности проекта?

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

Максим Яремко: Хочется ещё одну мысль добавить. Есть однозначная метрика, которая определяет, что тестирования точно не достаточно. Это когда, например, в версии 2.5 какой-то баг был исправлен, а в версии 2.7 он опять появился. Это говорит о том, что тестирование в команде явно плохо построено.

Дмитрий Еманов: У нас тоже практика отталкивается от бюджета. Мы пытаемся найти баланс между существующими финансовыми возможностями по найму новых тестировщиков и обязанностями тестировщиков. У нас основная проблема с обязанностями тестировщиков заключается в том, что мониторить трекер и писать новые тесты по обнаруженным дефектам это не такая большая нагрузка, это может быть, скажем, один баг в день, иногда один баг в неделю, в самом худшем случае бага три в день. Но наша особенность в том, что  выпускается порядка 8-10 релизов в год, каждый релиз тестируется вручную QA-сотрудниками, и каждый релиз тестируется под каждую платформу, которых около десяти, вот этот объём работ уже достаточно высок. Мы смотрим: если люди справляются – мы не нанимаем больше тестировщиков, если не справляются – пытаемся как-то перестроить наш режим работы либо выделить бюджет на дополнительных тестировщиков. Сейчас у нас четверть команды занимается QA на полную ставку, а если учитывать ревьюверов и тех, кто косвенно связан с этим, то получится где-то 50%.

Алексей Баранцев: Зоя во время представления сказала, что у них из пяти человек двое тестировщиков, то есть соотношение тоже примерно такое же получается. Но хочется ещё уточнить – учитываете ли вы при этом те расходы, которые у разработчиков уходят на разработку тестов? Они ведь тоже у вас пишут тесты. Тестировщики тестируют, и разработчики тоже тестируют. На разработку, выходит, времени вообще не остаётся.

Илья Молтянинов: Тут ситуация двоякая. Если разработчик пишет тесты и эти тесты успешно проходят, в коде остаётся меньше ошибок, и тестировщикам получается работы меньше.

Елапонский Михаил, СофтИнвест: Мы в нашей компании занимаемся разработкой операционной системы под веб, это синтез Python как серверной части и JavaScript-библиотеки ExtJS на клиенте. Для приёмочного тестирования вы используете все Selenium. А Selenium ориентирован на то, чтобы находить элементы по id. ExtJS генерирует id и раздаёт их элементам случайным образом. Как можно  привязать приемочные тесты к интерфейсу, написанному таким образом?

Зоя Павлова: Selenium поддерживает не только адресацию элементов по id, также можно использовать CSS-селектор или поиск по XPath, они позволяют точно определить элемент по другим свойствам, не обязательно по id. Например, по тексту или по значению какого-то атрибута.

Моисеев Илья, Липецк, StormSystems: стоит ли программиста загружать разработкой unit-тестов? Во-первых, мотивация падает, во-вторых программист иногда, мне кажется, некомпетентен, чтобы определить качество теста, потому что он видит решение задачи в своём русле, а тестировщик смотрит как бы со стороны заказчика и может увидеть то, что разработчик просто не увидит.

Максим Яремко: Есть разница между приёмочными тестами, которые тестировщики должны писать, и unit-тестами, которые пишут программисты. Unit-тесты пишутся именно для упрощения жизни программистов. Необходимость в дебаге практически исчезает. И сам код становится более понятным – если мы добавим некоторые требования на тесты, например, чтобы тест был не более десяти строк, то такие тесты приведут к простоте кода. И программисты, когда это увидят, будут сами писать эти тесты. У нас сейчас, наверное, ни один программист уже не может писать код без тестов, это то, к чему мы пришли за два года. Unit-тесты упрощают жизнь программистов в первую очередь, а не тестировщиков и заказчиков. А приёмочные тесты уже пишутся людьми, которые специально этим занимаются.

Вопрос: Допустим, я пишу какой-то код, который что-то пишет, удаляет, изменяет в базе данных. Я должен запустить тест, который проверит, что всё правильно, а потом ещё должен откатиться назад. Как ваши программисты это решают?

Максим Яремко: Тут всё достаточно просто, всё решается с помощью Моков. Подразумевается, что база данных работает правильно, и с помощью моков или заглушек проверяется вызов, который приложение делает в базе данных.

Илья Молтянинов: Я в какой-то мере противник мок-объектов, их нужно использовать в разумных пределах. Я поделюсь опытом, как это делаем мы. Когда мы тестируем какой-то модуль или класс, который занимается записью в базу данных, мы тестируем полностью приложение. Для этого поднимается инстанс тестовой базы данных. Это реальная база данных, но изолированная от базы данных основного приложения. Туда мы загружаем fixture, для этого есть масса различных инструментов. То есть мы организуем начальное состояние системы и запускаем тесты. Тут есть тоже свои минусы, иногда это сложно и долго, но у нас это не занимает много времени, мы очень быстро можем поднять тестовую базу с окружением очень похожим на рабочее.

Вопрос: Как у вас выполняется code review?

Дмитрий Еманов: У нас эта практика активно используется. Мы сначала ее не применяли, потом решили попробовать, и, честно говоря, сами были приятно удивлены результатом. После первой недели или месяца использования было найдено очень большое количество, может быть не критических багов, то различных недочетов, недоработок, сомнительных моментов в коде и так далее. Поэтому мы это перевели на постоянную основу. Как это происходит технически. У нас есть система контроля версий CVS, для каждого коммита пост-скриптом на сервере генерируется стандартный diff с окружением в 10 строк, он отправляется в специальный список рассылки, который вычитывается код-ревьюверами.

Этого уже достаточно чтобы отследить какие-то вещи по стилю кода, принятому в команде, определить какие-то логические ошибки, связанные с неправильным использованием переменных или выражений. Кстати, у нас не только код-ревьюверы вычитывают этот diff, все разработчики этим занимаются, при наличии у них времени, просто не всем это вменяется в обязанность, но добровольная практика такая есть. А код ревьюверы только этим и занимаются. Естественно не всегда возможно по окружению в 10 строк понять, что же именно поменялось, в этом случае они загружают к себе актуальную версию модуля и проводят ревизию, проверяя полный контекст. Это требует от ревьювера досконально знания всего кода. Для каких-то проектов это может быть проблемой, когда есть четкое распределение обязанностей, когда один отвечает за одну подсистему, другой за другую. У нас специализация по подсистемам тоже есть, но, тем не менее, каждый из ключевых разработчиков является экспертом по всему коду, и ревьюверы выбираются из числа таких. Так один из наших ревьюверов работает в проекте с самого начала, то есть он уже 8 лет занимается этим кодом, и мало кто знает систему лучше его. Именно поэтому они адекватны в принятии решений и у них есть право вето. Если он сказал, что ты написал хрень, то ты ему будешь доказывать, что ты не баран, что ты написал правильно, и очень часто оказывается, что именно ты оказываешься неправ, а не он. И это успешно работает, как оказалось.

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

Илья Молтянинов: Я так понимаю, что нам важнее результат, чем качество, так? Когда проект очень быстрый, обычно есть готовый набор инструментов, который позволяет этот проект быстро построить. И тут есть два момента. Первый – это тестирование самого инструмента, который помогает построить проект. И второе – это реализация самого проекта. Так?

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

Илья Молтянинов: Если нам нужно быстро выкатить продукт, чтобы просто понять, работает он или нет, тут лучше делать минимальное тестирование. Потому что если вы потратите много времени на приемку и качество, много времени на разработку, а продукт выйдет с рынка через неделю, значит, вы массу времени потратили зря. Значит, нужна итеративность. То есть вам нужно обеспечить минимально качество такое, чтобы пользователи, зайдя на сайт, не начали сразу плеваться и жаловаться, что всё глючит. В этом случае никакие ваши заверения о том, что вы скоро всё поправите, не сработают. Что я могу в данном случае предложить? Я предлагаю обозначить минимальный набор функционала для первого выпуска продукта, чтобы понять, выстрелит он или нет. Если продуктом начинают пользоваться, мы начинаем увеличивать набор фич, увеличивать покрытие тестами.  Если продукт будет реально работать, будет приносить прибыль, то мы будем вкладывать дополнительные средства в разработку. Вот так и будем двигаться маленькими шагами.

Игорь Катыков, Fujitsu Services, Казань. Раз уж мы на конференции HeadHunter, то интересен карьерный вопрос. Мы, компания Fujitsu Services, в данный момент занимаемся открытием нового направления – тестирование как сервисы. То есть нам отдают проект сторонние разработчики, мы тестируем и отдаём обратно. Какое обучение нужно  для тестировщиков, какие сертификаты полезны, проходили ли ваши тестировщики обучение? И второй вопрос – как искать тестировщиков, так как в программистком сообществе бытует мнение, что тестировщик – этот как бы «недопрограммист», то есть тот, кто не смог стать программистом? У меня другое мнение, когда тестируется огромные сложные проекты, где высокий уровень ответственности, получается, что тестировщику нужно знать очень много и уметь очень много, гораздо больше, чем программисту.

Дмитрий Еманов: Небольшое замечание на тему сертификатов – у нас в нашей команде не только тестировщики не имеют сертификатов, у нас и разработчики их не имеют. И это отнюдь не мешает создавать успешный продукт.

Алексей Баранцев: Давайте проверим, проведём небольшой опрос – здесь разработчиков много, есть в аудитории разработчики, у которых имеются сертификаты? (поднимается 5-6 рук). Ну, вот видите, почему к тестировщикам следует относиться иначе? Разработчики прекрасно работают без всяких сертификатов, тестировщики тоже.

Про мотивацию. Я себя считаю тестировщиком. Работаю в этой области уже 14 лет. Я тестировщик и этим горжусь. У меня в команде 25 человек, мы занимаемся предоставлением сервисов по тестированию. Как мы ищем тестировщиков? Мы приходим, скажем, на HeadHunter или на какой-то другой сайт, где публикуются резюме, ищем там людей, которые хотят работать программистом, и вербуем их в тестирование. Мы рассказываем, какая это классная и интересная работа, что программирования им там будет не меньше, а иногда даже больше, чем если они станут разработчиками, и при этом гораздо больше простора для творчества. Потому что разработчику говорят – вот тебе ТЗ, пиши код. А тестировщику ставят амбициозную задачу – пойди туда не знаю куда, принеси то не знаю что. Ему нужно самому придумать, как это всё реализовать, как сделать все эти «моки», «стабы» и другие заглушки, как сделать искусственное окружение, надо разработать эмуляторы систем, которых не хватает. Это удивительно творческая работа.

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

А во-вторых, действительно тестировщики должны обладать неким другим складом ума, знаний, характера, чтобы лучше вылавливать баги. Действительно есть люди, которые от рождения уникальные тестировщики, и они даже не должны быть хорошими программистами. У нас есть один замечательный бета-тестер, который не входит официально в команду, но которого мы очень любим. У него написана какая-то своя программа, которая использует наш сервер. Так вот – он пишет логику таким извращённым способом, что нормальный человек даже читать его код не может. Но при этом он находит такие баги, что мы готовы ему деньги платить, лишь бы он продолжал писать свой код таким извращённым образом. И это просто бета-тестер, у него свой бизнес, а нам он просто добровольно бесплатно тестирует софт. Это вообще уникальный персонаж, он в production ставит альфа-версии, а потом сам с бубном пляшет вокруг, чтобы это всё заработало. Я что хотел сказать – что склад ума у человека такой, что он может подойти к решению задачи совсем с другой стороны, и он может поставить продукт в такую ситуацию, которую наши тестировщики пропускают мимо, а он способен на этом акцентировать внимание. Вот такие люди как раз очень хорошо идут в тестирование.

И ещё – не обязательно тестировщиков ограничивать только тестами одного вида – unit-тестами, функциональными или регрессионными. Очень интересная область это нагрузочное тестирование. Это такая область, где некоторые могут хорошо себя реализовать. Грамотно составить нагрузочные тесты – это тоже часто программирование. Особенно когда идут сравнительные тесты с конкурентами, тут тоже нужны определённые навыки и таланты. Этим мы зачастую подкупаем людей, убеждая заниматься тестированием. Они не ограничены в какой-то одной области. Они могут учить код с перспективой дальше перейти в класс разработчиков. Они имеют возможность разрабатывать любые виды тестов, какие им заблагорассудится. У нас есть практика тестирования системы на дуракоустойчивость, когда, например, серверу на сокет передаётся всякий мусор, когда кто-то гадит в разделяемую память и тому подобные вещи. Сервер должен всё это как-то пережить. Это очень интересная работа для разработчиком с хакерским складом ума.  Главное не ограничивать тестировщика, дать ему возможность самовыразиться в любой из областей.

Вопрос: Как у вас обстоят дела с документацией? Кто документирует код, есть ли документация на всю систему? Допустим, приходит новый разработчик, а система сложная, и нет никого, кто понимает всю её логику. Иногда 90% времени уходит просто на то, чтобы понять, что происходит. Кто отвечает за документацию, до какого уровня детализации она доходит?

Максим Яремко: Основная проблема у нас – как новому человеку разобраться в системе в целом, потому что в системе очень сложная производственная логика. Как вариант – он едет в Америку, там идёт на заводы и смотрит, как система применяется. А с кодом достаточно просто разобраться – сели вместе, посмотрели. Моя позиция в том, что документация на код не нужна, если есть хорошие тесты плюс есть возможность пообщаться.

Вопрос: Тогда у вас возникает другая проблема – в организации всегда должны быть один-два гуру, которые знают всё, и если завтра они разворачиваются и говорят вам «до свидания», вы нанимаете новых программистов, но им очень сложно разобраться в системе.

Максим Яремко: Да, у нас была такая проблема год назад, когда от нас ушёл человек, который занимался всем, что связано с 2D-графикой. Там был свой движок, и вообще было много всего написано. Но так как код был достаточно аккуратно написан, мы взяли девушку, где-то в течение месяца она во всём разобралась, и сейчас она работает уже абсолютно спокойно. Ещё раз скажу – если код написан хорошо и грамотно, и плюс к нему написаны нормальные тесты с хорошим покрытием, то разобраться со старым кодом не проблема.

Вопрос: Кто у вас следит за качеством кода?

Максим Яремко: Когда мы начинали, у нас была политика code review, она продержалась достаточно долго, но сейчас мы от неё отказались, потому что команда у нас маленькая и все программисты достигли того уровня, когда качество кода по определению хорошее.

Вопрос: То есть у вас есть какие-то корпоративные стандарты?

Максим Яремко: У нас нет такого списка, в котором было бы написано, что надо делать так-то и так-то. Есть соглашение о названиях переменных, названия функций. Есть стандарты кодирования, как, например, фигурные скобки расставлять, чтобы весь код одинаково выглядел, за ними автоматически следит инструмент. А такие стандарты, что, например, какие-то паттерны должны использоваться, код должен быть объектно-ориентированный, методы должны быть короткие – это сейчас по умолчанию приемлется всеми программистами. А новые люди, которые приходят, они входят в эту команду, и так как мы достаточно часто практикуем парное программирование, они тоже достаточно быстро начинают писать в том же стиле.

Вопрос: Но ведь на всё это требуются ресурсы. У меня вопрос – как убедить заказчика в том, что надо провести тестирование, что надо создать документацию? Как вы их к этому мотивируете?

Максим Яремко: Да, по нашему опыту, заказчики реагируют на это плохо, поэтому мы поступаем просто – заказчик не посвящается в эти подробности, просто повышается ставка, вот и всё.

Вопрос: Да, а теперь допустим, что соседняя фирма пришла и сказала, что готова сделать то же самое в два раза дешевле, но вы заранее знаете, что они сделают это хуже?

Максим Яремко: Это философский вопрос. Грамотный заказчик, если он проработал с одной командой достаточно долгое время, вряд ли он будет её менять. Какой смысл менять команду, когда ты ею полностью удовлетворён, пусть даже тебе предложили в два раза дешевле? Грамотный заказчик понимает, что просто так в два раза дешевле не может быть ничего.  сильно дешевле хороший продукт не сделаешь.

Алексей Баранцев: Я хочу аналогичный вопрос адресовать Дмитрию – как проблемы с текучкой людей решаются в open source проектах? Ведь там люди хотят – приходят, хотят – уходят, их ничто особо не держит, кроме энтузиазма. Что делать, когда уходит ключевой разработчик?

Дмитрий Еманов: Это риск, не только для коммерческих компаний, но и для open source проектов тоже. У нас где-то лет пять-шесть назад была ситуация, когда полностью сменилась команда разработчиков, за исключением одного-двух человек. Да, это проблема, но как я уже говорил, у нас ключевых несколько, и они на уровне экспертов владеют кодом. То есть в случае ухода одного они могут поддерживать код в живом состоянии, и они могут обучать приходящих новых людей. Теоретически, есть шанс, что уйдут все ключевые разработчики, но с тем же успехом это может произойти в любой компании. Я не вижу здесь большой разницы между коммерческой компанией и open source. Единственное, что можно отметить – у нас ротация кадров по определению более активная, потому что не все участники проекта оплачиваются в полной мере. Мы делаем ставку на контрибьюторов, у них ротация достаточно большая, но структура проекта построена как раз так, чтобы выжить в любом случае.

Алексей Баранцев: Ну вот, организаторы подают мне знак, что пора завершать наше обсуждение. Напоследок хочется пожелать, чтобы вы, какую бы вы позицию ни занимали в своей компании, относились к вопросам качества так, как будто это ваша компания, как будто вы её владелец, и качество ваших продуктов жизненно важно для успешности вашей компании. Спасибо всем!

Обсудить в форуме