Проблемы тестирования в аутсорсинге

Опубликовал немножко злой пост о тестировщиках на их главном русском портале: software-testing.ru. Для тех, кто по каким-то причинам не читает этот портал, публикую копию тут на блоге. Оригинал тут!

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

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

«Человек не будет переживать за качество всего проекта. Он не встанет и не скажет, что проект не готов к выходу, даже если давление (в том числе и с моей стороны) будет высоко».

С моей стороны показалось странным, почему он (опытный руководитель проектов) обращает внимание именно на это, а не на профессиональные знания и опыт. Неужели читал Спольского про «smart and get things done»? Такая тема не могла быть не обсуждена дополнительно! И мы решили обсудить, какие же проблемы кроме этой Заказчик видит в нашем тестировании.

Получился вот такой список главных разочарований в тестировании со стороны Заказчика:

  • Нет ощущения, что продукт «мой».

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

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

(отступление) Знаю по себе, как относишься к багам «каких-то» продуктов или своего блога. Баги блога стараюсь фиксить быстро, чтобы моим пользователям было удобно! Если лежит хостинг – звоню и донимаю саппорт с целью «исправить и поднять». А если бы это был не мой продукт, то вполне возможно, что разрешил бы ему «полежать до завтра».

  • Нет понимания «достаточного» качества продукта.

На этом вопросе «плывут» многие из наших ребят во время собеседований (особенно синьор и лид уровней). Каждый проект имеет нужный (необходимый и достаточный) уровень качества. Именно по этому критерию тестировщик способен вынести решение: «Готов ли продукт к выпуску или нет». И эти критерии являются главным адвокатом тестировщика.  Заказчик и я были очень удивлены, что многие тестировщики уверены, что функцию выяснения «достаточного» уровня качества выполняет ПМ или Заказчик. Точно также решение о соответствии этому уровню качества (и релизу) принимает Заказчик.

  • Низкий порог входа в специальность и слабая конкуренция

Посмотрите вокруг и увидите, что тестирование – специальность, с которой многие люди начинают свою карьеру в ИТ. На самом деле порог входа самый низкий, так как прочитав книжку Канера и разобравшись хотя бы с одним баг-треккером можно претендовать на позицию :)unior Tester. А что самое парадоксальное, есть люди, которые работают несколько лет, так и не прочитав ни одной книги по тестированию.

Такой низкий порог позволяет людям, которые хоть что-то знают быстро расти и получается, что человек, который протестировал за всю карьеру 2-3 приложения (используя функциональное, регрессионное и UI тестирование) может стать Лидом. То есть не нужно особо напрягаться, чтобы вырасти карьерно. И почти никто не напрягается!

Вопрос от заказчика поставил меня в тупик: Как он (кандидат) может претендовать на лидскую роль, если не может толком объяснить что такое тест-дизайн? Как я могу доверить финальное решение о выпуске продукта такому человеку?

Правда, похоже на Индию?

  • Слабое понимание принципов построения программного обеспечения.

Этот пункт стал самым спорным. Никто не спорит, что тестировщику желательно это знать. Но почему Заказчик сделал упор именно на этом пункте?

На самом деле ответ прост: В основном onshore тестировщики (в силу молодости профессии) пришли или из программистов, или из аналитиков. И те, и другие классно знают основы дизайна систем. Поэтому они способны писать Unit tests и критически смотреть на дизайн компонентов системы и искать баги на этом уровне. В наших же реалиях люди с трудом (извините, пожалуйста, если написал про вас неправду) могут сказать какие компоненты системы и как взаимодействуют (хотя бы как работает http протокол).

Какие выводы можно сделать из беседы и из личного опыта:

Мы пока сильно не попадаем в «западное» понятие хорошего тестировщика. Их тестировщики – это люди, которые знают больше как в теории и практике тестирования, так и в программировании.

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

P.S. Читая статью многие подумают, что я пишу о каких-то неудачниках, которые по странному стечению обстоятельств попались мне на собеседование. Я бы тоже очень хотел так думать. Но при выборе резюме почти все кандидаты имели как минимум 4 года опыта.

P.S.S. Огромное спасибо тем ребятам, в основном из команды Paceart, которые помогли мне понять, что такое настоящие толковые тестировщики и научили меня правильным критериям оценки.


Jun 30th, 2011
  1. Genka
    Jun 30th, 2011 at 16:03 | #1

    Привет, Сергей!

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

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

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

    Заказчик: продукт готов?
    Тестеры: нет!
    Заказчик: у нас нет времени, мы обещали релиз еще вчера, срочно заканчивайте критичные баги и будем считать, что готов.
    Тестеры: но ведь он не готов…
    Заказчик: неважно, сейчас нам надо показать результат, а качество потом.

    В итоге через несколько подобных итераций (или даже нескольких лет подобных итераций) тестеры привыкают к тому, что их мнение слушают, но в итоге игнорируют, а потому особо не активничают, считая, что решение “готово – не готово” принимает ПМ.

    Вторая проблема: после нескольких подобных итераций, когда Заказчик о некоторых проблемах говорит, что они “не так важны для релиза”, у тестера понижается планка критичности (или как это лучше назвать?) и то, что считалось год назад важным, сегодня мы уже даже не упоминаем.

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

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

    Насчет низкого порога входа и понимания основ построения программ – согласен. Но у меня есть по этому поводу вопрос.
    У нас большинство стремится из тестеров выбиться куда-то (автоматизация, разработка и т.п.), а переход из девелопера в тестирование рассматривается как дауншифтинг (особенно учитывая, что зарплата у тестеров меньше, чем у программистов). Собственно, вопрос: а что, на Западе иначе?

    И напоследок пример из жизни. Как-то подрабатывал, писал скрипты для небольшой американской конторы, которая искала тестера, который бы занимался в том числе автоматизацией. Так вот, все кандидаты, по словам человека, который их собеседовал, оказались “тупые как индюки, ничерта кроме record & play не знает, а считает себя Senior” (дело было в Сан-Франциско, так что думаю, что недостатка кадров там нету). В общем, как говорится, случаи бывают разные…

    • Jun 30th, 2011 at 20:46 | #2

      Спасибо за большой коммент :)
      Как я и писал, я очень уважаю тестеров и за них всегда стою горой, поэтому весь пост не в обиду всем “братьям по багтрекеру”

      Закачик решает свои проблемы. То, что он забивает иногда на качество – его риск.
      Вы когда приходите к врачу, и он вам говорит, что “хорошо бы подлечиться”, то вы же не бросаетесь сразу в больницу. Вы начинаете выяснять варианты, а как бы туда не попасть. Вы принимаете решение для себя. Вот и Заказчик принимает его для себя.
      Доктор же не начинает жаловаться после 5-го пациента, что “все равно никто не идет в больницу, зачем им предлагать?”. Не хотел бы я быть в “руках” такого доктора.
      Умение гнуть свою линию – является признаком профессионала. Умение гнуть линию в нужное время – признак дорогого профессионала :)

      По поводу карьеры тестр-разработчик и обратно. В штатах например есть много хороших людей, которые ушли в тестеры из программеров. И зарабатывают очень хорошие деньги, потому что занимются не манки-тестами, а умеют эффективно тестить продукт (ключевое слово эффективно == хорошо за маленькое время).

      И на последок, коммент на историю из жизни: Таких Синьоров и у нас навалом :) А Сан-Франциско – дело такое, там тоже эмигранты и прочие “понаехавшие” :)

  2. Jun 30th, 2011 at 20:35 | #3

    Сергей, я буду коротко и по одному вопросу =)

    “1. Нет ощущения, что продукт «мой».” – а дается ли тестировщику та власть над проектом, что он может себя чувсвовать хозяином? как?

    • Jun 30th, 2011 at 20:47 | #4

      Felix

      Вот хлебом вас не корми, дай побыть хозяином!
      Хозяин – прежде всего ответсвенность, взвешенность в принятии решений, а потом уже свобода в принятии этого решения.
      Вы не рискуете своими деньгами, а “похозяйничать” Вас пусти :). Власть нужно заслужить, например проффесионализмом… см. ответ про доктора выше!

      • Jul 12th, 2011 at 20:21 | #5

        Это называется “Давать ответственность без рычагов управления ситуацией”…

  3. Jun 30th, 2011 at 22:37 | #6

    2Genka
    А понятие “готов” согласован с заказчиком? А цели билда на уровне бизнес-модели понятны и осязаемы?
    И я скажу, как человек, выступавший заказчиком – “дурацкими ситуациями” не всегда на нашей стороне идиотизм :) А вот непонимания смысла происходящего, причем не только из-за инфоголода, но и из-за процессов и квалификации исполнителя – навалом :)

    >> особенно учитывая, что зарплата у тестеров меньше, чем у программистов

    ой-вэй… простите, но даже в мире оутсорсинга это не совсем так.

  4. Jun 30th, 2011 at 22:39 | #7

    +100500, “профессиональное доверие” никто не отменял.

    а если исполнитель не может сам решить проблемы масштаба бизнеса – фигли ему власть в руки давать?

  5. Jun 30th, 2011 at 22:46 | #8

    и вообще, ИМХО, статья не о тестерах, а о “частичке боли за процессы и людей” в нашем оутсорсинге :)
    то же самое можно сказать и о разработчиках – в среднем слабая инженерная подготовка, слабые навыки работы с требованиями, почти никакое абстрактное проектирование, неумение работать бизнес-целями и предметной областью проекта.

  6. Jul 4th, 2011 at 07:18 | #9

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

  7. Nicholas
    Jul 15th, 2011 at 02:46 | #10

    А я бы сказал что процессу разработки не хватает палки каралки за отсутствие качества (законодательной, морально-этическо-профессиональной итп)

    Отсюда и все вопросы про тестировщиков.

Leave a comment