Простой, но внезапный вопрос чуть не поставил в тупик: «Почему тестировать должны тестировщики, а не аналитики, разработчики или пользователи?» Попытаюсь быстренько обосновать, но, скорее всего, потребуется помощь со стороны, такие формулировки требуют многостороннего анализа и освещения, и, несмотря на многолетнее владение темой, может потребоваться время на обдумывание.
Начнем с общеобразовательного: тестировщик — роль в ИТ-команде. Не самая, скажем, высокая должность по рангу и зарплате, но требующая специальных знаний и умений.
1. Если руководитель не понимает пользы ролевого деления, значит он и его команда не созрели методологически. Методологии RUP, MSF разрешают совмещать роль тестировщика аналитикам, но не разработчикам. Экстремальные методики идут дальше — там можно совмещать практически все роли.
2. Если лидер пытается совместить роли, то это из-за экономии или из-за непонимание психологии. Экономия — чаще всего от бедности или от жадности.
Здесь важен психотип человека:
1. Разработчики — это созидатели.
2. Тестировщики — разрушители. Эффективность тестирования при прочих равных выше у того, кто намеренно ломает систему.
1. Профессионал всегда эффективнее, чем смежник или универсал. Аксиома.
2. Иногда хороший ИТ-професионал может показать результаты лучше какого-нибудь тестировщика. Но стоимость такого ресурса может оказаться намного выше стоимости привлечения тестировщика. Например, ещё Джоель Спольски написал в своем блоге, что за эти деньги можно привлечь трёх тестировщиков.
3. Исключение: для малых проектов, небольших команд или для agile-разработок — эффективно использовать универсалов, т.к. время проекта невелико, а коммуникационные затраты в виде экспоненциального роста от числа участников проекта — как описано у Ф.Брукса — никто не отменял.
1. «Грабли» (жарг.) = Человеческий фактор. Это лечится использованием автоматических средств.
2. «Замыленный глаз». Человеку надоедает многократно проверять. Тестировщики должны быть устойчивы к рутинным, повторяющимся операциям. Чтобы полностью не полагаться на человека, применяют формализацию — составление тест-планов, тестовых сценариев (test cases), тест-проверок — чтобы человек не забывал и не выдумывал, а выполнял строгие шаги проверок.
1. Ручное тестирование — есть много вариантов для совмещения.
2. Автоматизированное тестирование, особенно — нагрузочное. Необходимы знания инструментария, языков, протоколов, методик — а это требует специализации.
Смотрим результаты опроса — радуемся/плачем/совершенствуем процесс/нанимаем тестировщиков — выбрать по желанию :) victor435.habrahabr.ru/blog/45899
Моё мнение — нет панацеи, все аргументы становятся значимыми в определённых условиях, при достаточном уровне зрелости команды, формализации процессов, готовности к изменению процесса разработки, способности внедрять инструменты, и пр.
Дисклаймер. Статья отражает мое личное мнение. Ваше мнение очень важно для формулирования чётких формулировок и поиску истины в ролевом распределении при тестировании. С уважением, Виктор
Факты, доводы, мнения
Начнем с общеобразовательного: тестировщик — роль в ИТ-команде. Не самая, скажем, высокая должность по рангу и зарплате, но требующая специальных знаний и умений.
1. Если руководитель не понимает пользы ролевого деления, значит он и его команда не созрели методологически. Методологии RUP, MSF разрешают совмещать роль тестировщика аналитикам, но не разработчикам. Экстремальные методики идут дальше — там можно совмещать практически все роли.
2. Если лидер пытается совместить роли, то это из-за экономии или из-за непонимание психологии. Экономия — чаще всего от бедности или от жадности.
Психология
Здесь важен психотип человека:
1. Разработчики — это созидатели.
2. Тестировщики — разрушители. Эффективность тестирования при прочих равных выше у того, кто намеренно ломает систему.
Немного про эффективность:
1. Профессионал всегда эффективнее, чем смежник или универсал. Аксиома.
2. Иногда хороший ИТ-професионал может показать результаты лучше какого-нибудь тестировщика. Но стоимость такого ресурса может оказаться намного выше стоимости привлечения тестировщика. Например, ещё Джоель Спольски написал в своем блоге, что за эти деньги можно привлечь трёх тестировщиков.
3. Исключение: для малых проектов, небольших команд или для agile-разработок — эффективно использовать универсалов, т.к. время проекта невелико, а коммуникационные затраты в виде экспоненциального роста от числа участников проекта — как описано у Ф.Брукса — никто не отменял.
Примеры из жизни:
1. «Грабли» (жарг.) = Человеческий фактор. Это лечится использованием автоматических средств.
2. «Замыленный глаз». Человеку надоедает многократно проверять. Тестировщики должны быть устойчивы к рутинным, повторяющимся операциям. Чтобы полностью не полагаться на человека, применяют формализацию — составление тест-планов, тестовых сценариев (test cases), тест-проверок — чтобы человек не забывал и не выдумывал, а выполнял строгие шаги проверок.
Посмотрим со стороны ресурсов и инструментария:
1. Ручное тестирование — есть много вариантов для совмещения.
2. Автоматизированное тестирование, особенно — нагрузочное. Необходимы знания инструментария, языков, протоколов, методик — а это требует специализации.
Итоги опроса
Смотрим результаты опроса — радуемся/плачем/совершенствуем процесс/нанимаем тестировщиков — выбрать по желанию :) victor435.habrahabr.ru/blog/45899
Моё мнение — нет панацеи, все аргументы становятся значимыми в определённых условиях, при достаточном уровне зрелости команды, формализации процессов, готовности к изменению процесса разработки, способности внедрять инструменты, и пр.
Что можете добавить, хабралюди? Примеры? Возражения?
Дисклаймер. Статья отражает мое личное мнение. Ваше мнение очень важно для формулирования чётких формулировок и поиску истины в ролевом распределении при тестировании. С уважением, Виктор