Home

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

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

Алексей Лянгузов, ведущий тестировщик в команде в Sun Microsystems (Санкт-Петербург, Россия). Занимается вопросами совместимости языка JAVA.

Контекстное тестирование - это образ жизни думающих инженеров по тестированию

На SQA Days 6 я сделал доклад под названием «Контекстное Тестирование ПО: Практические Рекомендации».

Я уже девять лет в тестировании. Когда начал изучать подход контекстного тестирования вдруг понял, что практически все девять лет исповедовал этот подход. Хотел рассказать об этом тем кто еще не знает, и разъяснить его суть тем, кто еще не понимает. И хочется получить фидбэк от тех, кто понимает.

В твоей статье о контекстном тестировании сказано следующее:

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

Контекстное тестирование — ключ к успеху в тестировании?

Конестное тестирование подразумевает, что «в данный момент надо делать самые нужные вещи». И стараться делать максимально нужные и эффективные действия, которые принесут пользу.

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

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

За этим походом стоит целая школа, которую придумали Канер и Бах в начале девяностых.

Имеет ли смысл специализация в контекстном тестировании?

Целенаправленная - нет. По ней дипломы не дают.

Контекстное тестирование — это мировоззрение. Человек может применять его принципы в рамках любого процесса. В своей работе тестировщик применяет принципы и подходы из всех ныне известных школ тестирования, и просто больше тяготеет к одной из них, а не «принадлежит».

Возможен ли командный подход в области контекстного тестирования?

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

Почему ты - тестировщик?

Мне это нравится.

Я попал в тестирование потому, что там денег платили больше, чем на предыдущей работе. Сперва работал на  государственном предприятие «ЛОМО» (Ленинградское оптико-механическое объединение), там делали фотоаппараты, гироскопы, оптику — огромное, оборонистое предприятие. От работы там остались позитивные впечатления. Одно только знакомство с железобетонным водопадным процессом разработки ПО чего стоит!

Затем случилось так, что меня пригласили в Санкт-Петербургский филиал американской компании TogetherSoft на должность тестировщика ПО, в которой в то время работало много моих сокурсников. Честно говоря я и не думал быть тестировщиком (на ЛОМО я был писателем требований к продукту, и мне это нравилось и до сих пор нравится). Но оказалось, что работа в тестировании — это моя стезя.

А стать программистом намеревался?

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

Больше всего привлекает техническая сторона, ведь я — практик. И контекстное тестирование — оно практичное. Главное в тестировании это — само тестирование, а не его планирование и менеджмент.

Основной целью объединения двух конференций было «наведение моста между программистами и тестировщиками». По-твоему, это удалось?

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

Люди, которые исповедуют контекстный подход, больше нацелены на то, чтобы решать проблемы при разработке, а не создавать их.

В какой отрасли ты сейчас работаешь?

Последние пять лет я работаю в компании Sun Microsystems в Санкт-Петербурге. Группа работает над вопросами стандартизации языка Java (область JavaME, если быть точным). Существует спецификация для языка Java. Под это дело наши разработчики пишут тестовый сьют, а мы его тестируем. То есть, занимаемся conformance testing.

Конкретнее: ну, например, существует JAVA API (Application Programming Interface), для которого создана спецификация. И существует TCK — technology compatibility kit, большой набор тестов, которые проверяют, что продукт, разработанный на языке JAVA, соответствует этой спецификации. ТСК — это продукт и я его тестирую.

Компании, которые хотят реализовать эту спецификацию, должны прогнать эти тесты на своей реализации, и если все проходит успешно, они могут поставить на свою продукцию лэйбл JAVA, что подразумевает соответствие продукта предъявляемым требованиям. Если кто-то знает, что такое http://jcp.org, тот поймет о чем речь.

Ну вот, разработчики занимаются разработкой TCK, а мы ее тестируем. Например, такой-то метод должен возвращать такой-то ответ... Так что мое текущее занятие несколько уникально — в основном я тестирую тесты! Хотя я еще тестирую тестовые инструменты, используемые в наших продуктах. Некоторые из них находятся в свободном доступе, например, замечательный инструмент SigTest.

Очень техничная работа. У вас agile?

Нет. Некоторые команды работают по agile.

А ведь контекстное тестирование — дитя agile...

Может быть. Я с процессами agile не сталкивался.

Agile - это не процесс, это подход :)

При разработке продукта у нас есть четкий процесс, который установлен в Sun Microsystems – весь процесс выпуска продукта установлен, и сама разработка в рамках этого процесса занимает небольшой кусочек...

Поэтому с одной стороны — у нас очень документированный процесс.

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

Контекстное тестирование начинается с самого начала процесса тестирования. Это и определяет отправную точку того, как человек строит тесты, как он вообще подходит к тестировнию, к планированию работы, к ее выполнению...

Что-то вспоминается исследовательское тестирование...

Исследовательское тестирование иногда путают с контекстным тестированием.

А разница только в том, что:

1. исследовательское — это конкретная техника тестирования, это практика.
2. контекстное — это подход.

Исследовательское тестирование может существовать и отдельно от контекстного тестирования. Например, мне говорят «Вот тебе новая функциональность, ее надо протестировать».

Но как?

Может есть требования, может и нет.

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

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

А контекстное тестирование — это подход к тестированию ВООБЩЕ.

На примере — я могу получить от кого-то набор тестов, которые надо выполнить, чтобы проверить этот функционал. И сяду, тесты прогоню, а потом пойду домой.

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

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

И добрая классика тестирования по метрикам этим подходом никак не отчуждается?

От человека зависит, как будет построено тестирование.

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

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

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

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