Интервью с Александром Жендинским, менеджером по тестированию программных решений

Александр Жендинский – директор подразделения по тестированию программного обеспечения. Александр является главным специалистом по качеству в Qulix Systems, отвечающим за установление и поддержание стандартов качества в компании. В его задачи входит наблюдение за бизнес процессами, которые влияют на результаты работы, и управление рисками.

Примечание:

VLE – Вера Леоник, PR-специалист Qulix Systems

AZH – Александр Жендинский

VLE: Каков твой опыт работы в QA?

AZH: Если начать издалека, то я из тех многих выпускников радиотехнических специальностей БГУИР-а, где готовят специалистов многостаночников – т.е. люди получают огромное количество информации, собрать и переварить которую в принципе невозможно, но в то же время там дают знания и развивают способности, позволяющие применить себя во многих областях, не связанных с радиотехникой. В область "высоких" IT технологий меня занесло довольно случайно, после того как я себя попробовал и техническим специалистом в сервис центре Nokia, и в крупных торговых компаниях, т.е. в областях далеких от тестирования ПО. Было это дай бог памяти: пять лет назад. Опыт работы с компьютером на тот момент был на уровне университетской программы (программирования у нас фактически не было), поэтому на первых этапах карьеры приходилось уделять много внимания не только полной отдаче себя работе и изучению великой профессии тестировщика, но и постигать все тонкости администрирования и работы с компьютером. Собственно старт у меня был очень резвый, со мной провели тренинги в течение одного дня в субботу, дали груду документации и в понедельник я уже тестировал систему для одного из белорусских заказчиков.

Было жутко интересно, хотя иногда немного стрёмно, что получить быструю консультацию иногда не получалось, так как от своих наставников я был на достаточном удалении - в соседнем здании. Работа тестировщика на самом деле очень увлекательна, не верьте тем, кто говорит, что это скучно и однообразно, так говорят плохие тестеры, которые собственно не тестеры даже, а так, "проходили мимо и зашли на огонек". Мой второй проект был настоящей школой жизни - проект с иностранными заказчиками, который проходил строго по RUP, с четко документированными внутренними процессами, отличным управляющим звеном, языковой практикой, коллективом настоящих профессионалов и т.д. Список достоинств этого проекта можно было бы перечислять не один час, за год участия на этом проекте я набрался знаний по тестированию, процессам построения работы и взаимодействия внутри команды, получил азы по управлению процессами и ресурсами. Эти знания собственно и сложили фундамент, на котором я сейчас строю работу нашего QA департамента.

VLE: Что в QA является самым сложным и наболевшим?

AZH: Из наболевшего - это однозначно отношение некоторых менеджеров к тестированию и QA в целом, многие до сих пор считают тестирование абсолютно второстепенной задачей, не понимают целей и задач по тестированию, считают, что это фактически избыточная трата денег на проекте и ужимают QA активности в рамки, которые не могут позволить качественно проверить разрабатываемую систему и в итоге выпустить первоклассный продукт. В то же время если открыть большинство западных книг по управлению проектами - то там подсчитано, что затраты на QA в рамках проекта должны в среднем составлять 60 - 80% стоимости проекта.

VLE: Известно, что в каждой профессии есть много историй и мифов, связанных с ней. Что ты можешь сказать об этом?

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

Первый миф: "QA = тестирование ПО".

На самом деле это не совсем так, сам процесс тестирования – это лишь часть процесса QA, т.е. "обеспечения качества". Львиная доля задач по QA это обеспечение качества процессов на проектах. Проект успешный лишь только тогда, когда все его составляющие подогнаны как в швейцарских часах, каждый четко знает свою ответственность, задачи и что делать, если…. Естественно и это не все, у QA много других составляющих, на перечисление которых уйдет много времени.

Второй миф: "тестировщиком работать проще, чем разработчиком, нужно гораздо меньше знаний".

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

VLE: Что является самым простым и на что вообще не стоит обращать внимание в QA?

AZH: Трудный вопрос, даже, наверное, применительно к QA не очень правильный. Что касается проверки систем и построения процессов, то внимание к мелочам должно быть "в крови" у хорошего QA-щика. На чтобы я посоветовал меньше обращать внимание, так это на выпады разработчиков и менеджеров, которые придерживаются мнения, что тестировщик - враг на проекте, отодвигающий сроки сдачи проекта, благо таких осталось немного. Но это и понятно, ведь перед этими людьми стоит абсолютно противоположная задача, у разработчика – создать, у тестировщика наоборот – разрушить.

VLE: Как ты сам пришёл в профессию?

AZH: Мне посчастливилось попасть в компанию Qulix на стадии, когда формализация процессов и шаблонов была еще на стадии доработки, мир тестирования в то время стремительно менялся, появлялось много новых методологий, и я естественно со всем рвением принимал участие во всем, что касалось QA подразделения. Было много страданий над новыми шаблонами, идеями и новаторствованиями, зато, когда они воплощались в жизнь и приходили хороши отзывы от коллег и заказчиков – это и было главное счастье, можно было с гордостью сказать – "вот тут и я наследил".

VLE: На всех ли проектах должны присутствовать тестировщики?

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

VLE: Как именно должна проходить работа над проектом и каков процесс тестирования?

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

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

VLE: Какие проблемы могут возникать в процессе работы в целом?

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

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

VLE: Что такое качество разработок?

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

VLE: Кого на твой взгляд можно считать идеально подходящим для профессии тестировщика?

AZH: На мой взгляд это человек с желательно профильным образованием (математика, программирование), обладающий логическим пространственным мышлением, высокой внимательностью к деталям, технически подкованный, коммуникабельный, последовательно излагающий мысли, грамотный с точки зрения русского и английского языка, на отлично понимающий методологии разработки и тестирования ПО. А вообще к любой профессии надо иметь призвание, поэтому в первую очередь хорошим тестером будет тот, кто получает от этой работы удовольствие!

VLE: Что предпринимается в Qulix Systems для обеспечения квалифицированного и качественного выполнения процесса тестирования программных решений?

AZH: Достичь высокой квалификации кадров позволяет ряд факторов наиболее важные из них это:

  • Во-первых, в компании очень внимательно относится к подбору кадров, поэтому уже на этом – самом первом этапе отсеиваются соискатели, которые не удовлетворяют нашим, достаточно высоким требованиям к квалификации и общечеловеческим качествам.
  • Как правило, для первостепенного обучения мы проводим ряд тренингов и назначаем новичка на "боевой" проект вторым (вспомогательным ресурсом) без проведения длительных курсов – это достаточно прижившаяся и оправданная практика, так как какие бы ни были крутые курсы и преподаватели, все равно, когда человек садится и начинает выполнять практическую работу – у него появляется огромное количество практических вопросов, которые по ходу разъясняет его ментор. Темп и качество обучения в данном случае гораздо выше, чем пройти длительный курс, а потом заново повторить его на практике. Далее, как и любая уважающая себя компания, мы много времени уделяем развитию специалистов, освоению ими нового инструментария и методологий, устранению пробелов в широко применяемых и распространенных технологиях. Для этих целей внутри компании разработан и постоянно обновляется набор семинаров, которые читают лучшие специалисты компании.
  • Кроме того, в нашем QA подразделении опробована и применяется практика подготовки статей на профильные темы непосредственно самими сотрудниками отдела. Все это выкладывает в базе знаний компании и обсуждается на собраниях отдела, лучшие практики опробуются на новых проектах и в случае успешного завершения испытаний применяются на постоянной основе.
  • Одна из важных составляющих, помогающих достичь нашим тестировщикам хорошей квалификации это разнообразие задач, выполняемых ими в рамках проектов. Мы стремимся к тому, чтобы каждый сотрудник отдела мог выступать и в ролях: функционального тестировщика, тест-дизанера, разработчика автоматизированных тестов, аналитика и технического писателя.
  • Еще одна из практик, применяемых в компании – это составление сотрудниками планов индивидуального развития на год. Данные планы обсуждаются и хранятся у менеджеров, которые способствуют развитию специалиста, назначая его на профильные проекты и направляя на соответствующие курсы, и, в то же время, осуществляют контроль, насколько сотрудник преуспевает в поставленных целях.

?VLE: Спасибо.

ВСЕ НОВОСТИ