Тестировщики и тех.поддержка: взаимовыгодное сотрудничество

Вопросам взаимодействия тестировщиков и технической поддержки уделяется гораздо меньше внимания , чем, например отношениям тестировщиков и разработчиков. Хотя, на мой взгляд, тут также довольно много разных тонкостей, психологических моментов, проблем , стереотипов  и всяческих там особенностей.
Сотрудники технической поддержки находятся на самом "острие" , ежедневно общаясь с заказчиком, мотаются по командировкам , где зачастую в стрессовых ситуациях вынуждены оперативно решать технические проблемы, прикрывая порой промахи остального коллектива, оставшегося в уютном оффисе. Саппортеры - первые, кто узнает о проблемах заказчиков, фильтрует всяческие ошибки настройки от реальных багов. Благодаря близости к "реальной эксплуатации" техподдержка обладает особо ценными знаниями о конфигурациях софта, о типичных действиях реальных пользователей, об реальных объемах баз данных и еще о многом таком, о чем тестировщики могут только догадываться. В общем, "сильные стороны" тех.поддержки очевидны. Переворачивая известный афоризм , можно  сказать , что "недостатки техподдержки являются продолжением их достоинств". Сотрудник тех.поддержки зачастую не знает досконально всех особенностей системы и не настолько глубоко в нее "погружен" как разработчик или тестировщик. Поэтому порой ему недостаточно знаний о системе, чтобы точно поставить "диагноз" той или иной проблеме и, тем более , выявить точную причину произошедшего сбоя.
Тестировщики же, наоборот  , зачастую "оторваны от реальности" , не обладая полным пониманием всех тонкостей и особенностей того, как именно используется софт " в бою".
Исходя из вышесказанного должно быть понятно, почему вопрос взаимодействия тестирования и тех.поддержки - довольно важен. Для менеджмента и руководителей этих подразделений важно не только решать всяческие шероховатости, конфликты , возможные взаимные производственные споры сторон, но и налаживать и отлаживать процесс обмена знаниями. Тестировщики должны быть более осведомлены о "реалиях" использования софта для того, чтобы само тестирование стало более адекватным и направленным на реальные, а не вымышленные или высосанные из пальца  сценарии и конфигурации. Сотрудники тех.поддержки должны быть более информированы об особенностях этого самого софта  , чтобы давать более точные  и оперативные рекомендации заказчикам.
Процесс обмена знаниями можно построить по-разному.
Я бы хотел поделиться собственным положительным опытом организации и участия в одном из вариантов подобного обмена.
А именно в некоей ротации.
Время от времени сотрудникам технической поддержки передаются задачи на регрессионное тестирование тех или иных частей системы. Почему именно регрессионное?  Потому что в этом случае саппортеру не надо выдумывать тесты, погружаться в теорию и практику тест-дизайна - он проверяет работоспособность по методикам тестирования , которые , к слову, после работы с ними техподдержки , становятся намного богаче и адекватнее.
В то же самое время тестировщикам время от времени поручается разбор кейсов от заказчика, в ходе которого ребята по-новому начинают смотреть на вроде бы уже досконально знакомую систему и наборы своих тестов. А также, что немаловажно - переоценивают свою меру ответственности за общий результат.
Вот такое вот взаимовыгодное сотрудничество.

Ротация

"На фронте я любил наблюдательного человека посылать. Старый ему видимую обстановку докладывал, а новый свежим взглядом проверял. И представляете, очень удачно это порой получалось. У старого наблюдателя от целого дня напряженного высматривания глаз, что называется, замылился. Он чего и не было замечал, а то что вновь появлялось не видел…». Володя Шарапов :)

Добрый день, коллеги.
Несколько слов о ротации тестировщиков...
При тестировании сложной программной системы , состоящей из множества подсистем , модулей, обеспечивающих функционирование различных бизнес-процессов , команда тестировщиков неизбежно делится на людей, специализирующихся на конкретных частях тестируемой системы. То есть со временем тестировщик начинает узнавать систему все лучше и лучше, но в какой-то отдельной ее части он разбирается лучше других.
Все новые доработки этой наиболее близкой и понятной ему части распределяются на него, он быстрее всех и качественнее всех диагностирует проблемы в этой подсистеме. В общем, его руководителю проще и дешевле дать эту подсистему на откуп. И так для каждой части сложного программного комплекса. В такой ситуации работы по тестированию проходят с максимальной скоростью. Люди досконально знают тестируемые ими части системы и не тратят время на лишние выяснения и ознакомления.
Все хорошо до тех пор, пока у человека не начинается "замыливаться взгляд". Он продолжает быстро справляться с задачами , связанными с его областью, но его тестирование становится все менее въедливым и растет риск пропуска (или намеренного игнорирования) сначала некритичных ошибок , а затем и серьезных проблем. Это ненадуманная проблема - с ней приходилось сталкиваться в реальной практике.
Способ решения довольно прост и напрашивается сам собой. Производить ротацию тестировщиков по подсистемам, время от времени давая им длительное время поработать с поначалу плохо знакомой им частью программного комплекса. При систематическом применении такого подхода средний уровень "знания" тестировщиками программного продукта повышается, люди по-прежнему ценны для компании , но в то же время взаимозаменяемы, им интереснее трудиться и еще много плюсов побольше и поменьше, самый главный из которых состоит в том, что как правило сразу после ротации в каждой подсистеме "новичками" обнаруживаются ошибки казалось бы там, где уже все "вылизано"...
Отмечу, что подобный процесс должен сопровождаться качественным документированием методик тестирования, особенностей реализации и функционирования тестируемых подсистем, для того, чтобы снизить временные затраты на ознакомление.

Так что товарищ Шарапов все сказал правильно =)