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

Автор: Сергей Бережной

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

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

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

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

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



Читать дальше

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

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

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

Читать дальше

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

Впрочем, компетенция не лишняя, да.

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

1. Лидер группы контроля качества не принимает решения о выпуске. Он лишь предоставляет информацию о текущем качестве и, если он хороший спец, то еще и дает тренд.
2. Говорить о плохом качестве иногда рискованно для карьеры. Люди это интуитивно чуствуют. И молчат. (Если что, то у меня есть ма-а-асса баек на эту тему.) Для того, чтобы начали говорить должен измениться менеджмент. Не тестировщики. Давайте подождем еще лет 10-20, а потом вернемся к этому вопросу.

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

------------------------------------------------------------

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

О кей, вернем вопрос ПМ-ам. Вы сами то пишете профиль качества продукта до начале проекта? Вообще-то это ваша работа, ребята. Ну хорошо, хорошо. Как минимум ваша работа этот профиль утвердить. Вместе с планом обеспечения и контроля качества. До инициации проекта.
Не все ПМ так делают?!?! Звиняйте хлопцы, какков поп, таков и приход.

работают несколько лет, так и не прочитав ни одной книги по тестированию.

Назовите в процентах:
а) во скольких вакансиях указано пожелание о чтении книг?
б) на скольких собеседованиях спрашивают о прочитанной литературе?
в) в каких компаниях условия окончания испытательного срока и изменения категории привязаны к изучению образовательных материалов?

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

И пожалуйста. Распечатайте и повестьте у себя над столом:

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

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

И каждое утро повторяйте как мантру в течениии года.

То что они не читают - это проблема ... Вопрос залу: "Чья?"

------------------------------------------------------------

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

Логично. Объявите в компании, что тестировщик не получит приставку "ведущий", если не будет писать требования к ПО. Или не станет по совместительству программистом, или СА, или ДБА, или проектировщиком GUI.
Но лучше аналитиком + проектировщиком GUI. Отличная связка для инженера-тестировщика.
Вы еще этого не сделали? Тогда чему вы удивляетесь?!?!

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

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

2. Нет инженеров по контролю качества ПО. Тестировщики ПО есть, а инженеров по контролю качества ПО - нет.
С этим борюсь. Тренингами статьями, докладами.

PS. Сергей, хотите круглый стол устроим? Я с вашей статьей согласен, но копать надо дальше.

А почему "в аутсорсинге"?

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

Что-то как-будто про совсем другую реальность рассказали... Где всё так просто и легко (поделитесь, кто знает)?

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

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

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

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

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

4. Слабое понимание принципов построения программного обеспечения.
Тут давайте опять вернемся к тому, кто и как работает в компании. Часто ли разработчики зовут тестировщиков при обсуждении дизайна будущей системы? Нет? Так откуда же тестировщику тогда знать, что и как там работает? А часто люди компетентные делятся знаниями на внутрикорпоративных семинарах или блогах итд? Или они всегда заняты? А у многих ли есть такие семинары или даже блоги? А книги фирмы покупают, хотя бы как премии? А на конференции отпускают (дело даже не в оплате, а просто не пускают ибо должен батрачить или конференция не профильная - для программистов, а не для тестировщиков)?

Мы пока сильно не попадаем в «западное» понятие хорошего тестировщика. Их тестировщики – это люди, которые знают больше как в теории и практике тестирования, так и в программировании.
А вот это вообще не соотвествует действительности. В нашей стране, точнее во всех странах СНГ, много квалифицированных тестировщиков. А вот опыт работы с зарубежными коллегами, не говоря уж о Индии/Китае - лично у меня вызывает много вопросов в проф. компетенции большинства тамошних товарищей. Ну а стоят они там как минимум раза в 4 дороже. Это не значит, что в америке или европе нет хороших тестировщиков, да полно наверняка и многие из них - русские, украинцы, белорусы, индусы, китайцы, чехи и прочие, которые туда переехали.

@ SALar

Отличный ответ. Есть только 1 вещь, с которой я не согласен практически принципиально.

Я пишу, что заказчик видит эти проблемы и озвучивает. В своем же ответе вы все сделали, чтобы "обвинить" внешние факторы: менеджеров, процессы и т.д. Вы конечно правы, что это часть проблемы, вот только не во всем виновато "окружение".
Сказать что "нет плана по обеспечению качества, потому что менеджер его не попросил" выглядит по-детски. Это профессионализм.

Внешние причины обвинять легко. Менять себя - тяжело.

В остальном, правильные мысли направленные на то, как изменить отношения клиента к нашим тестировщикам

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

после этого уже слово за ПМ-ом
либо он допускает такие убытки - и апдейт идет с багом, или нет.

т.е. каждый отвечает со своей стороны.
по хорошему, когда от всех отделов есть добро - стартует апдейт.