Home

Международная конференция для специалистов по обеспечению качества программного обеспечения — SQA Days 2009 — прошла с 28 по 29 октября в Москве в рамках Международной восточно-европейской научно-практической конференции по программной инженерии (для специалистов по разработке программного обеспечения) — CEE-SECR 2009.

Портал Software-Testing.ru представляет серию интервью с участниками прошедшего мероприятия.

Приглашаем всех на SQA Days 7 в Харькове, 14-15 мая 2010.

Александр Александров: "Надо считать собственные недоработки, а не свои успехи"

Александр Александров (Luxoft, Москва), эксперт по управлению качеством программного обеспечения, управлению тестированием, анализу и совершенствованию инженерных процессов, кандидат физико-математических наук, доцент, старший научный сотрудник, внедренец практик CMM/CMMI.

Дедушка русского тестирования (пруфлинк).

Чем и как «дышит» нынешний тестировщик? Возьмем, для примера, Москву. Вот Алексей Баранцев говорит, что ощущаются какие-то изменения, но какие конкретно — еще никто не знает.

Тестировщики в Москве — это огромный пул людей, а я общаюсь с весьма ограниченным их количеством.

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

Впрочем... Есть резкий рост количества инструментов автоматизированного тестирования. Их становится много. Десять лет назад их было всего два — от Rational и от Mercury, а сейчас у нас в УЦ Luxoft только учебных курсов по этим инструментам штук десять; а есть еще большое количество инструментов, которые нашими курсами не охвачены.

И второе — это просто мнение, не считайте за истину — следствие того, что тестирование становится массовой профессией. И, как в любой массовой профессии, появляется «мода» и появляется «пена». Например, есть Мария Шарапова, которая играет в теннис. А есть Анна Курникова, которая в теннис не играет, но делает вид, что играет. Поскольку тестирование — дело ответственное, очень важно, чтобы все работали «по-взрослому», а не для вида и понтов типа «мы тоже проводим тестирование, как и все».

Я не уверен в том, что это тенденция.

И я не уверен, что это есть только в Москве.

Но этим сопровождается становление любой массовой профессии.

Как вы оцениваете «хорошесть» тестировщика?

Ох...

Формально — это человек, которые справляется со своими обязанностями. Или же — справляется лучше, чем ожидалось.

Кстати, у нас в УЦ Luxoft есть два курса: один посвящен поиску и найму на работу тестировщиков, в другом речь идет об основах тестирования не для тестировщиков. В них говорится про личные качества тестировщиков. Должны быть:

1. профессиональные знания;
2. умение переключаться;
3. стрессоустойчивость. Тестировщик — это тот человек, который регулярно сообщает плохие новости в проекте. Его, естественно, любить никто не будет, но очень важно себя позиционировать так, чтобы тебя слушали. Тебя могут ненавидеть, но то, что ты делаешь, должно иметь ценность для проекта;
4. умение доказывать собственную правоту. Не криками, а фактами, знанием проекта, предметной области, технологий, умением сделать для проекта то, что не могут сделать все остальные. Если у разработчиков не получается воспроизвести дефект, а ты приходишь и воспроизводишь его, и все видят, что это дефект — такие вещи очень важны.

Хороший тестировщик запускает систему, о которой все говорят, что она замечательно работает, и система падает. Падает потому, что у человека есть какое-то печеночное чувство, интуиция, которая позволяет найти дефект. Я не считаю, что я такой интуицией обладаю, но я знаю как минимум двух людей, которым, наверное, в момент рождения от Бога что-то перепало в тестировании. Вот к ним в полной мере применим термин «талант тестировщика».

Очень важно знать свои слабости, видеть свои недоработки, области для совершенствования, очень важно ориентироваться на успехи других — все это помогает профессиональному росту.

Если ты перестал расти — тебя обгонят. Надо считать не собственные успехи, а собственные недоработки. В этом смысле любая критика, любые замечания, любой консалтинг, любое ревью, любые негативные оценки со стороны мне существенно более интересны, чем благодарности и похвала.

Чтобы стать хорошим тестировщиком, надо читать уже существующие книги, или надо написать свои?

Боюсь, что если все станут писать свои, то это будут очень похожие книги. Если посмотреть книги, которые уже есть на русском языке — и написанные, и переведенные — там много повторов.

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

Но ведь — в одну книгу все сразу не впихнуть...

С другой стороны, сам факт появления книги по тестированию — всегда позитивное событие, потому что бесполезных книг (в том числе и по тестированию) не бывает.

Но встретить что-то принципиально новое в книгах по тестированию (за исключением книг по каким-то конкретным инструментам или методологиям) уже очень сложно. Возьмем, к примеру, итерационный подход. Итерация — это отдельный «каскад». При этом каскадную модель все ругают, но одновременно ею пользуются. Если что-то считают пороком, но продолжают этим пользоваться, то, может быть, это и не порок вовсе?

Помните книгу Гленфорда Майерса «Надежность программного обеспечения»? На Западе она в последний раз выходила в 1982 году. На сайте Amazon.com, где она продается, среди отзывов читателей я нашел такое выражение: «с момента ее последней публикации больше ни одной книги по тестированию не было написано».

Наверное, это справедливо, если вспомнить содержание всех книг по тестированию, которые с тех пор публиковались.

Может быть, «похожесть» приходит от того, что каждый, кто начинает писать книгу о тестировании, сперва рассказывает про основы — так, как именно он их понимает, — и лишь к середине или к концу книги подходит к теме, которая его и заставила все это писать?

Не всегда.

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

Не каждый начинает с основ. Рэкс Блэк начал буквально с каких-то определений, на нескольких страницах, но ведь... Но ведь, даже нет общепринятого определения тестирования!

Спросим у двадцати человек «Что такое тестирование?» и получим двадцать разных ответов — от «тестирование — это отладка» до «тестирование — это обеспечение качества продукта». А как тестировщик может обеспечить качество, если он ничего не меняет в продукте?!

Поэтому, если просто появляется на общем фоне еще одна книга, которая перепевает другие — ну, так это во всех областях бывает, это еще одно проявление моды и пены. Про основы программирования сколько раз пишут?

Достаточно просто написать учебник для начинающих. А для тех, кто уже находится на определенной ступеньке написать учебник — очень сложно. Тем более что книг уже есть много разных.

Подметил следующее: если у большой компании есть собственный учебный центр, скорее всего, у нее есть и собственный учебник. Может быть — отдельная книга. Может быть — брошюра местного значения. Но так или иначе — написанная собственными преподавателями. У учебного центра Luxoft есть собственный учебник по тестированию?

У Luxoft нет собственных учебников, у Luxoft есть собственный УЦ и уникальные тренинги.

У нас просто другая философия. Luxoft — компания с уникальной проектной экспертизой. В компании работает более 3000 человек, и выполняются проекты в самых разных линейках бизнеса. И, естественно, наши эксперты имеют собственные знания, которые материализуются в том числе и в учебных курсах.

Конечно, заманчиво прочитать упоминавшуюся книгу Рэкса Блэка и разработать на ее основе учебный курс. Но зачем? Ведь книга доступна, ее может каждый купить и прочитать. А мы создаем курсы по тем тонкостям и деталям, которыми владеем сами и которых в этой книге нет. Уникальность знаний, которые поставляет УЦ Luxoft, находится за пределами книг.

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

Я не говорю, что это «правильно для всех». Но мы так работаем.

Кстати, есть еще одно доказательство качества наших курсов – их воруют. Воруем не мы, воруют у нас. Значит, есть что-то, что никто кроме нас сделать не может. Что ж, мы создаем новые курсы достаточно часто …

Ваш доклад на SQA Days 6 назывался «Обучение и консалтинг: единство и борьба противоположностей». В чем их единство?

Этот доклад возник как ответ на вопрос «Мы проводим обучение сотрудников, но ничего не меняется. Почему и что делать?»

Мне кажется, что мы нащупали — может быть очевидную для всех, но я нигде такого не видел — связь обучения и консалтинга.

Обучение, как и любой посев, предполагает наличие вполне определенной почвы. Если этой почвы нет, то вы попусту бросаете зерно на асфальт. Как понять, есть ли почва?

Знаете проблему «неправильных учеников»? Это когда кто-то говорит «Я замечательный преподаватель, а ученики все тупые, совершенно не усваивают» – ну, так не бывает. В обучении, как и в любом проекте, надо понимать ожидания заказчика, представлять, что ему надо, и если то, что делается, слишком сложно для него, делать проще. Это первая проблема в обучении.

А вторая проблема связана с тем, что, например, наш учебный центр предоставляет два вида услуг — по обучению и по консалтингу. В первом случае нам говорят «Обучите тому-то и тому-то». Во втором случае нам говорят «У нас то-то не получается, можете нас этому научить?»

Иногда мы отвечаем: «Вас не надо учить — вы все это знаете, но применяете неправильно. Мы можем понять, в чем проблема, и порекомендовать, как знания применить». Это — инженерный консалтинг.

В докладе я, с одной стороны, препарирую то, как и чему мы учим на примере области Quality Assurance, а, с другой стороны, на основании реальных примеров пытаюсь показать, почему нередко надо переходить от обучения к консалтингу. А это фактически означает, что тренеры, которые проводят обучение, должны быть готовы и к консалтингу.

Корпоративное обучение?

Не обязательно.

Тренинг может быть и открытым. Приходят люди из разных компаний, вы им что-то рассказываете, а они говорят «Да, мы все это знаем, но у нас есть такие-то и такие-то проблемы. Вы нам все это рассказали, спасибо, конечно, но мы с чем пришли, с тем и ушли. А ведь нам наши проблемы надо решать». И вот тут обязательно надо понять — почему то, что им рассказывается, у них не работает? Почему нет той самой плодородной почвы для зернышка знаний? И что нужно сделать, чтобы оно появилось? И нужны ли им знания, которые они знают? И есть ли эти знания у них на самом деле?

Это важно и для тех людей, которые поставляют услуги обучения, и для потребителей подобных услуг. Может быть, не всегда нужно заказывать обучение? Может быть, надо заказывать консалтинг, который не сильно дороже, но он фокуснее, потому что он позволяет вам ответить на вопрос «Что надо делать?»

Я был сегодня на докладе, в котором предлагался свой подход к тестированию требований. Авторы утверждали: «У нас есть статическое тестирование, в том числе и тестирование требований, но оно нас не устраивает, поэтому мы сделали вот это». После пары вопросов стало ясно, что никакого статического тестирования у них нет. Просто они увидели, что что-то идет не так, что-то стали делать, а количество дефектов от этого не уменьшилось. Но главный вопрос — почему они не делают то, что надо делать и так, как надо делать? Не знают? Не умеют? Пробовали и не получилось?

При этом мы никому не навязываем свою точку зрения в виде директив типа «Делайте так, и все будет хорошо».

Мы никому не навязываем конкретные решения и инструменты. Мне кажется, что в области IT инструменты не играют ведущую роль. Пусть берется любой инструмент, и мы начинаем его использовать в проектах. Часть проектов выполняется успешно, часть — нет. Почему? И каков вклад инструмента?

На что похож консалтинг по итогам работы? Список инструкций, указания о том, что и как надо сделать?

Основной фокус обучения — осмысление. Если бы было можно после прочтения любой книги, прохождения любого тренинга сказать «Теперь я понимаю …» — это было бы здорово.

Консалтинг всегда заканчивается рекомендацией, в стиле «Мы считаем, что …».

Почему бы консультанту не взять на себя полную ответственность за конечный результат?

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

Иногда можно давать совершенно четкие указания, как это происходит в поликлинике. У вас что-то болит, врач посмотрел и сказал «вот вам лекарство». А как вы будете его принимать — врач уже не может проконтролировать.

Объединение SQA Days и SECR было призвано в какой-то мере решить кастовую разобщенность программистов и тестировщиков. По-вашему, это получилось?

Под кастовостью вы понимаете некое противопоставление, да?!

Я попробую ответить, но прошу учесть – мой личный опыт ограничен тем небольшим количеством мест, где я работал.

Компания Luxoft симпатична в том числе и командным духом. На корпоративном уровне практически никогда не было и нет никакой кастовости. Отдел тестирования в Luxoft существовал с первого дня. Тестировщики всегда рассматривались как «те же самые разработчики, только немного другие». В компании всегда были процессы, разнообразные роли — менеджеры проектов, аналитики, технические писатели, инженеры конфигураций, тестировщики, разработчики ... Если начинать «меряться хвостами», то меряться придется с большим количеством ролей. Чем разработчики с аналитиками меряться будут? А технические писатели с менеджерами проектов? Поэтому и не мерялись никогда.

Проблема противостояния возникает там, где изначально работа тестировщиков рассматривается как работа второго сорта. Не вспомогательная, какой она по сути является, а именно «второго сорта». В одной из московских компаний была такая практика — приходит человек устраиваться на должность разработчика. Ему говорят: «Разработчиком мы тебя пока не возьмем — знаний не хватает. Для начала возьмем тестировщиком в это же подразделение. Поработаешь полгода хорошо — мы тебя переведем в разработчики».

Вроде «Тестирование — ступенька в карьере программиста»?

Да! А с чего вдруг он себя хорошо проявит в этой должности? Он будет сидеть и считать дни, потому что он занимается не тем, чем хочет заниматься. Этого делать нельзя!

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

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

Если кастовость находит отображение в проектах, если замечанием тестировщиков начинают пренебрегать, просто потому, что они тестировщики — это вредно сказывается на проекте.

Тестировщики смотрят на объект тестирования, в первую очередь, глазами заказчика. Тестировщик скажет: «Ребята, вот здесь у вас плохо!» А ему ответят: «А где это написано? Это вообще не баг, это фича, вали отсюда!» Через два дня заказчик присылает письмо ровно про то же самое. Но заказчику никто не скажет «Вали отсюда!» — все берут под козырек и начинают исправлять. Но ровно это замечание три дня назад уже сделали тестировщики! Прислушались бы да исправили все это до того, как оно на глаза заказчика попадается...

Когда вас стали называть «Дедушкой русского тестирования»?

Это когда-то придумал мой коллега и друг Сережа Смирнов.

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

Интервью брал Алексей Лупан.

На постсоветском пространстве ежегодная конференция «Software Quality Assurance Days» (SQA Days) считается одним из крупнейших событий в области обеспечения качества программного обеспечения. Сайт конференции: www.it-conf.ru

Приглашаем всех на SQA Days 7 в Харькове, 14-15 мая 2010.