Pull to refresh

Тестирование ПО: как объяснить руководителю, что 2 х 2=4?

IT systems testing *
Простой, но внезапный вопрос чуть не поставил в тупик: «Почему тестировать должны тестировщики, а не аналитики, разработчики или пользователи?» Попытаюсь быстренько обосновать, но, скорее всего, потребуется помощь со стороны, такие формулировки требуют многостороннего анализа и освещения, и, несмотря на многолетнее владение темой, может потребоваться время на обдумывание.



Факты, доводы, мнения


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

1. Если руководитель не понимает пользы ролевого деления, значит он и его команда не созрели методологически. Методологии RUP, MSF разрешают совмещать роль тестировщика аналитикам, но не разработчикам. Экстремальные методики идут дальше — там можно совмещать практически все роли.
2. Если лидер пытается совместить роли, то это из-за экономии или из-за непонимание психологии. Экономия — чаще всего от бедности или от жадности.

Психология

Здесь важен психотип человека:

1. Разработчики — это созидатели.
2. Тестировщики — разрушители. Эффективность тестирования при прочих равных выше у того, кто намеренно ломает систему.

Немного про эффективность:

1. Профессионал всегда эффективнее, чем смежник или универсал. Аксиома.
2. Иногда хороший ИТ-професионал может показать результаты лучше какого-нибудь тестировщика. Но стоимость такого ресурса может оказаться намного выше стоимости привлечения тестировщика. Например, ещё Джоель Спольски написал в своем блоге, что за эти деньги можно привлечь трёх тестировщиков.
3. Исключение: для малых проектов, небольших команд или для agile-разработок — эффективно использовать универсалов, т.к. время проекта невелико, а коммуникационные затраты в виде экспоненциального роста от числа участников проекта — как описано у Ф.Брукса — никто не отменял.

Примеры из жизни:

1. «Грабли» (жарг.) = Человеческий фактор. Это лечится использованием автоматических средств.
2. «Замыленный глаз». Человеку надоедает многократно проверять. Тестировщики должны быть устойчивы к рутинным, повторяющимся операциям. Чтобы полностью не полагаться на человека, применяют формализацию — составление тест-планов, тестовых сценариев (test cases), тест-проверок — чтобы человек не забывал и не выдумывал, а выполнял строгие шаги проверок.

Посмотрим со стороны ресурсов и инструментария:

1. Ручное тестирование — есть много вариантов для совмещения.
2. Автоматизированное тестирование, особенно — нагрузочное. Необходимы знания инструментария, языков, протоколов, методик — а это требует специализации.

Итоги опроса

Смотрим результаты опроса — радуемся/плачем/совершенствуем процесс/нанимаем тестировщиков — выбрать по желанию :) victor435.habrahabr.ru/blog/45899

Моё мнение — нет панацеи, все аргументы становятся значимыми в определённых условиях, при достаточном уровне зрелости команды, формализации процессов, готовности к изменению процесса разработки, способности внедрять инструменты, и пр.

Что можете добавить, хабралюди? Примеры? Возражения?



Дисклаймер. Статья отражает мое личное мнение. Ваше мнение очень важно для формулирования чётких формулировок и поиску истины в ролевом распределении при тестировании. С уважением, Виктор
Tags:
Hubs:
Total votes 50: ↑48 and ↓2 +46
Views 11K
Comments Comments 59