Простой, но внезапный вопрос едва не завёл в тупик: «Почему тестировщики должны тестировать, а не аналитики, разработчики или пользователиЭ» Постараюсь быстро обосновать, но, скорее всего, потребуется помощь извне, подобные формулировки требуют многостороннего анализа и освещения, и, несмотря на многолетнее знание темы, на размышление может потребоваться время.
Факты, аргументы, мнения
Начнем с общего образования: тестировщик — это роль в ИТ-команде.Не, скажем, самая высокая должность по званию и окладу, но она требует особых знаний и навыков.
1. Если руководитель не понимает преимуществ разделения ролей, значит, он и его команда методологически не созрели.
Методологии RUP и MSF позволяют аналитикам, но не разработчикам, совмещать роль тестировщиков.
Крайние методы идут дальше — там можно совмещать практически все роли.
2. Если лидер пытается совмещать роли, то это из-за экономии или непонимания психологии.
Экономия – чаще всего от бедности или жадности.
Психология
Здесь важен психотип человека: 1. Разработчики — творцы.2. Испытатели — разрушители.
«Эффективность тестирования при прочих равных условиях выше у того, кто сознательно ломает систему.
Немного об эффективности:
1. Профессионал всегда эффективнее субподрядчика или универсала.Аксиома.
2. Иногда хороший ИТ-специалист может показать результаты лучше, чем какой-нибудь тестировщик.
Но стоимость такого ресурса может оказаться намного выше, чем стоимость найма тестировщика.
Например, также Джоэл Спольски написал в своем блоге, что за эти деньги можно привлечь троих тестировщиков.
3. Исключение: для небольших проектов, небольших команд или для гибкой разработки - эффективно использовать универсалов, поскольку время проекта короткое, а затраты на связь в виде экспоненциального роста от количества участников проекта - как описано в Ф.
Брукс - никто это не отменял.
Примеры из жизни:
1. «Грабли» ( сленг .) = Человеческий фактор.
Это лечится автоматическими средствами.
2. «Вьюжный глаз».
Человек устает постоянно проверять.
Тестировщики должны быть устойчивы к рутинным, повторяющимся задачам.
Чтобы не полагаться полностью на человека, используется формализация — составление планов тестирования, тестовых сценариев (тест-кейсов), тестовых проверок — чтобы человек не забывал и не выдумывал, а осуществлял строгие действия по проверке.
Давайте посмотрим на ресурсы и инструменты:
1. Ручное тестирование – вариантов комбинирования множество.2. Автоматизированное тестирование, особенно нагрузочное тестирование.
Требуется знание инструментов, языков, протоколов, методик — а это требует специализации.
Результаты опроса
Смотрим результаты опроса - радуемся/плачем/улучшаем процесс/нанимаем тестировщиков - выбирайте как хотите :) victor435.habrahabr.ru/блог/45899 Моё мнение, панацеи не существует, все аргументы становятся значимыми в определённых условиях, при достаточном уровне зрелости команды, формализации процессов, готовности менять процесс разработки, умении внедрять инструменты и т.д.Что можете добавить, хабралюди? Примеры? Возражения?
Отказ от ответственности.Статья отражает мое личное мнение.
Ваше мнение очень важно для формулирования четких утверждений и поиска истины в распределении ролей при тестировании.
С уважением, Виктор Теги: #тестирование #Роль #качество #тестирование ИТ-систем
-
Как Конвертировать Avchd В Mp4, Mpeg4, H.264
19 Oct, 24 -
Обзор Портативного Компьютера Asus M70Sa
19 Oct, 24 -
Тасманский Язык И Авторское Право
19 Oct, 24
