QA-outsourcing. Особенности и тонкости

Сложно не сталкиваться с аутсорсингом занимаясь разработкой ПО. Либо часть кода написана в теплых странах, либо дизайн был получен издалека, либо поддержка продукта лежит на плечах партнеров. Фактически, каждый этап производства может быть вынесен за пределы компании и передан в заботливые руки аутсорсинг-провайдеров. Не является исключением и обеспечение качества программного продукта (QA-outsourcing). Вот о том, как сделать этот процесс проще и понятнее и пойдет речь в этой статье. Мнение автора основано на собственном опыте работы как в составе аутсорс-команд, так и в составе компании — заказчика услуг внешнего тестирования.

Как и в других случаях, мысль о работе со сторонней QA-командой имеет под собой вполне определенную почву. Для небольших команд этой почвой может быть отсутствие выделенных тестировщиков. Особенно это ощутимо для небольших shareware продуктов, где команда состоит из самого же автора идеи. Наличие же своей тестовой лаборатории, тоже не всегда дает 100% уверенность. Задачи множатся, дедлайны давят, а рук не хватает. И, наконец, даже в самой спокойной обстановке и при полном достатке ресурсов остается место стороннему аудиту. Это может быть как проверка продукта на широком парке платформ и конфигураций, или использование новых методик и подходов. Взгляд со стороны может открыть абсолютно свежий пласт проблем.

Итак, в первую очередь, необходимо поставить перед собой ясную и понятную цель привлечения сторонних специалистов. Если будет угодно — SMART-цель. Тем самым, заранее прибрав некоторую часть проблем при общении, а также застраховав себя от ложных ожиданий. Поскольку аутсорс-команда не в силах найти всех проблем и обеспечить Абсолютное Качество.

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

Определившись с целью, можно перейти к следующим шагам подготовки. Поскольку ваш продукт будут проверять люди с ним незнакомые, и при этом возможно находящиеся в другой стране, а то и на другом континенте, то с продуктом их придется познакомить. В простом случае поможет справка о программе, список триальных ограничений, changelist. Говоря проще, информация доступная пользователям. В менее тривиальных проектах, нужна более серьезная документация. И тем глубже и серьезней, чем глубже должны быть найдены проблемы. Готовить документацию придется, и лучше это сделать заранее, дабы не терять времени в дальнейшем. Ведь ее всё равно запросят.

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

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

Отдельно стоит остановиться на географии. Фактическое расположение аутсорсеров может заметно повлиять на результаты работы с ними. Язык, особенности менталитета, разница во времени могут, как упростить, так и усложнить работу. Работаете на западном рынке — отдайте предпочтение местным жителям, они скорее могут, заметят специфические недоработки, из-за океана таковыми не кажущиеся. Да и лишний пруфинг (proofing) текста носителем языка не вредил ещё ни одному продукту. C другой стороны, команде из вашего города всегда можно назначить встречу и оперативно решить ряд вопросов и, таким образом, например, справится с отсутствием документации по проекту.

Справившись со всем вышеперечисленным, можно задуматься и о финальной части. Получение результатов и оплата. Этим пунктам стоит уделить серьезное внимание и не откладывать их в долгий ящик. Дедлайн, объемы работ, сумма и методы оплаты должны быть оговорены и согласованы заранее. Учтите риски, оговорите формы отчетности, подберите подходящие обеим сторонам платежные механизмы. Тем самым будет готова почва для плодотворной работы, а может и для долговременного сотрудничества. Обе стороны смогут получить желаемое и попрощаются, пожав друг другу руки. Пусть и виртуально.

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


27 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
2 Николай Скотынянский

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

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

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

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

Я ответил на вопрос?

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

2Лина — в вашем случае можно и попробовать.2BAndrik — может и так, если есть хороший техпроцесс.Имею интересный опыт: полтора года работал попеременно то в Нью-Йорке, то в Киеве. Два месяца там — два здесь.Заказчик из штатов.Была возможность сравнить — и ответственно заявляю, что рядом с заказчиком все происходило не в пример быстрей и веселее.Коммуникационное трение резко снижалось — при том что и в Киеве разговаривал с американцами каждый день на планерке и вдобавок регулярно вне ее. Скайп — великое изобретение. Организация была поставлена очень хорошо — по крайней мере на порядок лучше, чем я до тех пор видел.И вот пойди ж ты — расстояние все же играло очень существенную роль.2Кирилл Гончарук -, а что вас смущает? Я — умею и стремлюсь развиваться и дальше.Свою работу делаю лучше, чем окружающие. Задачи смежников тоже могу сделать сам. Как правило хуже и медленней, чем они -, но умею ведь.IT, Database Administration, Infrastructure Team, Support, QA, Continious Integration, Build and Release Management — все эти части хорошо себе представляю. Причем не «вообще» -, а как они функционируют именно у нас. Регулярно помогаю, особенно в части CI и Build Management. Прочим помогать часто не нужно — работа и так хорошо налажена.Не говоря уже собственно о программировании. Проект немаленький, полсотни программистов (наверное, уже больше — никогда их не считал). Три больших команды и четыре маленьких.Десятки мегабайтов кода (и это — в основном довольно лаконичный Питон, на Яве или Шарпе было бы на порядок больше). И тем не менее я в нем довольно свободно ориентируюсь, а изменения в ключевых подсистемах и архитектуре постоянно отслеживаю — и если идет «не туда» — стараюсь корректировать направление движения.Естественно, код отдела, в котором я непосредственно работаю — знаю лучше всего. А свой код — так особенно:) Но это не значит, что я сижу в своей песочнице и за ее пределы даже не выглядываю. Есть у нас на фирме один работник, постоянно повторяющий девиз: «Меньше знаешь — крепче спишь». А довольно многие вслух его не произносят -, но неуклонно следуют.Это — не мой путь. «Уметь самому» нужно по следующим причинам: — чтобы лучше представлять общую картину, и иметь возможность на нее влиять. Дьявол — он в деталях. — сильно упрощается взаимодействие между подразделениями. Пояснять, думаю, не нужно. — легче избежать ситуации «лебедь, рак и щука». Но гарантировать ничего нельзя, конечно... — пресловутые взаимоотношения. Когда я помог Пете, а Петя в свою очередь когда-то помог мне — это здорово объединяет (получше тимбилдингов, но и они тоже очень и очень полезны). В результате когда я в следующий раз к Пете подойду со своей проблемой — он весьма внимательно меня выслушает и изо всех сил постарается помочь. Знаменитая петля обратного эффекта. К тому же это просто по человечески приятно. — имею возможность постоянно и довольно быстро обучаться новому у спецов своего дела, причем очень малой ценой. Конечно, я до этих спецов не дорасту, да и цели такой не ставлю. Все же программирование — это мое все. Но немного расширить свой горизонт познания — очень полезно. — на стыках периодически возникают интересные возможности. Когда смежники не могут выйти за рамки -, а мы даже не догадываемся, что у них есть затруднения, которые мы можем решить на «раз-два-три», немного переделав код. И это тоже может быть большой проблемой. (К слову, мой друг относительно недавно таки нашел свое призвание.Он довольно таки посредственный художник (двухмерка и в основном трехмерка). Креатива не хватает. И такой же посредственный программист. Плюс еще твердые знания по верстке, теории цвета, трехмерной математике, шейдерам и постэффектам — короче говоря, универсал.С руками и ногами взяли на специально для него созданную должность Technical Artist, где он себя наконец смог реализовать по полной программе. Влад, как я понимаю, счастлив. А его работодатели довольны не меньше, ибо таких редких спецов днем с огнем...) — «лапшу на уши» вешать не смогут — что очень ценно. — повышается ценность лично меня как сотрудника на данной конторе (немаловажная мелочь). — наконец, это просто очень приятно. Хочется работать! Прийти на следующий день (единственно огорчение для меня — как сова рано просыпаться не люблю) и снова заняться любимым делом, получая в ответ новую порцию удовольствия.Я ответил на вопрос?

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

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

2 Андрей Светлов

Наверное, пишу очевидное: бесполезно нанимать «спецов на нагрузочное тестирование» если нет четкого представления задачи.

Ситуация: представление есть, чёткое требование от заказчика есть, а выполнить работу некому. Ну нет квалифицированных кадров в «глубинке»:) Вопрос: Что разумнее сделать? Ответить заказчику, что мы не можем этого предоставить или дать альтернативу, как QA аутсорсинг, например?

2Лина.Если работа будет выполнена качественно и довольно быстро — то почему бы и не заплатить.Особенность в том, что вы должны уметь выполнить такое тестирование сами. Или хотя бы очень хорошо представлять, как это делается.Это единственный известный мне способ организовать работу, сделать ее хорошо и при этом остаться довольным.Иначе начинаются всякие неприятные вещи: исполнитель ленится, заказчик не может внятно сформулировать требования или хочет малореального и пр. — нужное подчеркнуть, недостающее вписать. Зато итог закономерен: все участвующие в процессе стороны крайне раздражены и думают уже не совсем о том, как лучше исполнить контракт.Наверное, пишу очевидное: бесполезно нанимать «спецов на нагрузочное тестирование» если нет четкого представления задачи. Спецы могут быть сколь угодно хороши -, но с неадекватным/неподготовленным заказчиком ничего не получится. Верно и обратное.

Вообще тут можно долго общаться, выискивая «плюсы» и «минусы» аутсорсинга. Вот, для меня лично, важен вопрос КАЧЕСТВА предоставляемого сервиса. Вот например, нет у нас в городе хороших специалистов по нагрузочному тестированию, что делать? Есть два выхода — инвестировать деньги и время в их обучение (а этого, как правило, нет) или заплатить померную сумму за качество в нормальные сроки. Я выбиру второе:)

Резюмируя вышесказанное качественный продукт можно получить, как внутри команды, так и используя внешние ресурсы. Как уже писалось выше Андреем и Александром все зависит от управления проектом.

Полностью согласна!

Интересно насколько часто встречается QA-outsourcing в нашей стране — именно случай, когда задачи отдаются не своим же, украинцам/русским, а заграницу?

Очень даже встречаются, а в вопросах юзабилити тестинга — так тут вообще без «заграницы» не обойтись. Всё дело в типе и размахе проекта. Если проект не только для украинцев/русских, но разработан ими и дизайнер тоже отсюда, как заказчит может получить гарантию, что из-за разного менталитета нет провтыков?

Если тестировщики знакомы с аналогичным ПО компании-конкурента и не ленятся создавать improve-отчеты — это очень помогает.

Вот хоть убейте — не верю в качественный QA «на стороне»

У первых работа сделана, когда «всё работает», а у вторых — когда «найден баг».

Судя из обрисованной ситуации проблема не в QA, если рассматривать аутсорс в общем, то для получения качественного сервиса достаточно четкого понимания со стороны заказчика того, что конкретно ожидается от провайдера услуги. И в данном случае QA не исключение. Определите KPI, четкие интерфейсы, драйверы и главное входы и выходы процесса и получите законченный, целостный сервис. А относительно качества, сроков и возможных привлекаемых ресурсов тут у аутсорса гораздо больше возможности и гибкости, чем любого локального решения. Резюмируя вышесказанное качественный продукт можно получить, как внутри команды, так и используя внешние ресурсы. Как уже писалось выше Андреем и Александром все зависит от управления проектом.

Да в том-то и дело, что все эти «100%-е покрытия тестами кода», «адекватные и точно знающие чего они хотят заказчики», «чёткое ТЗ» и многое другое не имеет ничего общего с реальной жизнью и лишь хорошо смотрится на бумаге на тестовых примерах. И это не только в аутсорсе.

Как и любой другой абсолют. Но это не отменяет необходимости в документации, проведении тестов, использовании баг-трекера и версионного контроля кода. Это вещи которые нужны и к ним надо стремиться. Естественно, внося коррективы с учетом проекта, заказчиков и окружение.Хотя бывают и адекватные заказчики, и ход на 100% покрыт тестами. Не забываем, что бывают разные проекты и разные люди.

Полной спецификации по продукту не бывает и быть не может

Какой именно спецификации? Бизнес-требований, функциональных требований или юзабилити? Да, описать поведение продукта во всех возможных ситуациях и средах нельзя. Но это и не нужно. Спецификации требований описывают то, что ожидается от продукта, без каких возможностей он никому не нужен, ограничения и т.д.Так что сарказм здесь не уместен.

Вот хоть убейте — не верю в качественный QA «на стороне»

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

Коли не має специфікації або принаймі чіткого списку функціональності яку повинен мати продукт, то як його тестувати?

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

У первых работа сделана, когда «всё работает», а у вторых — когда «найден баг».

А что такое «нормальная проектная команда»?

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

Это команда в которой менеджмент следит за отношениями внутри коллектива. Если и у разработчиков и у тестировщиков приоритет «побыстрее спихнуть» работу друг на друга — это, в первую очередь, ошибка проектного менеджера, он не донес цели проекта до всех членов команды. Или не следил за подбором людей в команду.А если в команде все видят основную цель и она общая («выпустить качественный продукт») то подобные дискуссии (#) просто не будут возникать.

А что такое «нормальная проектная команда»?

Разработчик: "Тестировщикам надо показать, что они дело делают, вот они и сабмитят баги, которые на самом деле фичи. И вообще не так тестируют! «Тестировщик: «Разработчики офонарели! Куча багов, а они на них забивают! »

Это как-то напоминает разработку «детский сад». В нормальной проектной команде таких вопросов возникать не должно.

Да в том-то и дело, что все эти «100%-е покрытия тестами кода», «адекватные и точно знающие чего они хотят заказчики», «чёткое ТЗ» и многое другое не имеет ничего общего с реальной жизнью и лишь хорошо смотрится на бумаге на тестовых примерах. И это не только в аутсорсе.

Полной спецификации по продукту не бывает и быть не может.Тем более на момент постановки задачи и начала работы над ней.Никогда живьем не видел зверя по имени «сферический конь в вакууме».

Вот хоть убейте — не верю в качественный QA «на стороне». Быть может, потому что не видел.Знаю, как нелегко делать outsource программистам — возникает миллион проблем, не предусмотренных первоначальным соглашением.Пробовал создать отдел QA на моей работе лет пять назад — было такое фиаско, что я полностью в тестерах разочаровался. Сейчас понимаю, что мог бы все построить -, но и нам, программистам, пришлось бы поднапрячься, чтобы сделать хорошую среду для QA тестов.Полтора года прошло, как обрел веру опять на новой работе. Спорю с ними, бывает поругиваю втихую (уверен, это взаимно — случалось, что небольшие изменения в программе приводят к переписыванию сотни-другой тестовых сценариев).Но — зауважал и оценил.Наш QA весьма хорош -, но он сидит в одном с разработчиками офисе. И общается постоянно. Удаленный вариант на сегодняшний момент не представляю вообще (быть может, мне предстоит еще раз удивиться?) Тем не менее Все еще уверен, что «ручное» тестирование на поток ставить невозможно — сил не хватит, и тестеры — не идеальные роботы с бесконечным терпением.В лучшем случае это приведет к тому, что баги будут обнаружены через...надцать недель после релиза.К слову, у нас внутренний релиз каждую неделю, и раз в месяц — новая версия продукта.Поэтому тестеры пишут сценарии, которые автоматически гоняет каждую ночь тестовый кластер — одному компу не успеть.Неприятности начинаются, когда этот кластер выдает серию провалившихся тестов — и они попадают разработчикам.Садись, бери кофе, запускай сам — и когда поймешь в чем дело — тащи тестера. Чтобы выяснить — тест о себе слишком много думает, или программа неадекватна. Бывает и третий вариант — все правы, но тест предполагает функциональность итерации, которая будет через два месяца — так что извините.Долго, муторно -, но иначе еще хуже (по крайней мере как я сейчас это дело вижу).Тестеров у нас намного меньше чем программистов — поскольку все автоматизировано. Они тесты пишут, а не по кнопкам тыкают.Кстати, если у вас нет юнит-тестов, continious integration, functional & regression tests — живые тестеры вам не нужны. Это мое убеждение на текущий моментP.P. S.Пребывая в чудесном статусе «эксперта по Питону и сопутствующим технологиям» имею очень много разных сложных задач, не требующих (к счастью, ибо выматывает) взаимодействия с QA. Но когда приходится — их поддержку очень сильно ценю.

Интересно насколько часто встречается QA-outsourcing в нашей стране — именно случай, когда задачи отдаются не своим же, украинцам/русским, а заграницу?

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

  • Коли не має специфікації або принаймі чіткого списку функціональності яку повинен мати продукт, то як його тестувати??? методом тику? Як в такому випадку оцінити роботу QA? Для компанії виконувати тестування за таких умов — це як пиляти гілку на якій сидиш — замовник в любий момент розриває контракт бо не задоволений якістю тестування.Від замовників необхідно вимагати специфікацію, мало того постійно треба обмінюватися інформацією про зміни в специфікації та знайдених багах. так як часто може виявитись що хтось забув оновити специфікацію і це не баг, а фіча:) — для того що б не було взаємних звинувачень — «в мене все працює, а ти дурак», потрібно робити скріншоти, логи і додавати їх до баг-рапортів, крім того вивіряти і чітко описувти процедуру як викликати помилки.Самий простий спосіб використовувати системи аля Test Track Pro — де всі баги записуються і також є така штука як assign тоді якщо девелопер закрив баг бо вважає що цей баг не цікавий — це вже його відповідальність і він дістане по шапці.- найважливішим фактором в такій співпраці — це якраз національні особливості та особисті відносини між людьми. Нерозуміння як працює друга сторона часто ставить хрест на успіху

Становится особенно интересно, когда есть две команды аутсорсеров — разработчики и тестировщики. У первых работа сделана, когда «всё работает», а у вторых — когда «найден баг». Вот тут и появляются конфликты по типу: Разработчик: "Тестировщикам надо показать, что они дело делают, вот они и сабмитят баги, которые на самом деле фичи. И вообще не так тестируют! «Тестировщик: «Разработчики офонарели! Куча багов, а они на них забивают! »

Подписаться на комментарии