Название: Аутсорсинг тестирования — точим чужое оружие
Вид работы: доклад
Рубрика: Информатика и программирование
Размер файла: 13.78 Kb
Скачать файл: referat.me-137375.docx
Краткое описание работы: Выбрать модель тестирования для нового заказного проекта.
Аутсорсинг тестирования — точим чужое оружие
Есть задача: выбрать модель тестирования для нового заказного проекта.
Вводная: проект большой, силами разработчиков его тестить как-то не очень. Заказчик человек умный и готов платить за качество. Вопрос только в том открывать ли для этих целей свой отдел (работы ему точно хватит только по этому одному проекту) либо не заморачиваться и вынести тестирование на плечи аутсорсинговой компании. Логично оценить затраты. Прикинем.
Я себе вижу оценку затрат примерно следующим образом, почему и склоняюсь к своему отделу:
Есть N человеко-часов тестирования (планирование, управление ресурсами — включено).
Есть M часов, которое можно отвести на тестирование, согласно планам разработки (срок понят и принят и разработчиками и заказчиками).
M/N = T кол-во тестировщиков (включая руководителя или менеджеров).
Кол-во занятых тестировщиков в принципе своём неизменно не зависимо от варианта.
Есть два варианта: нанять Т сторонних тестеров (зааутсорсить) и нанять Т своих тестеров (свой отдел).
Накладные расходы в том и в другом случае:
Для сторонних тестеров.
Давайте смотреть реально: нужно кормить не только самих тестеров, но и штат компании которая берётся за тестирование. У них есть офис, амортизация оборудования и ваши расходы, за счёт которых руководящий состав хочет вернуть вложения — особо хочу отметить этот этап. Кроме того стоит денег, которые уйдут на сторону, организация рабочих мест (локальных или же удалённых — то есть затраты на инфраструктуру связи с разработчиками).
Для своего отдела: офис, амортизация оборудования, зарплата (всё как и в предыдущем случае), за исключением того, что нужно кормить всю машину сторонней компании, которая этим самым аутсорсингом живёт. По сути всё звено менеджеров, которое привело вас в эту компанию, идёт в перерасход по сравнению со своим отделом (я не утрирую — даже если вы их нашли сами через сайт к примеру, сайт тоже стоит денег и он также учтён в плане возврата инвестиций).
Как я вижу — свой отдел будет дешевле.
Аутсорсинг разработки понятен, если разработка ПО не есть профильном для компании, которая хочет получить систему. Но аутсорсинг тестирования?! Для компании, которая разрабатывает ПО? Есть своя инфраструктура IT направления. Есть специалисты по управлению, опыт поиска новых специалистов, есть программа и опыт разработки. Почему выносить тестирование, которое есть по сути своей частью разработки на сторону? Аутсорсить тестирование можно в одном и только одном случае — если это приёмочное тестирование, проводимое самим заказчиком.
Особо хочется отметить стратегические выгоды при своём отделе — опыт не уходит в трубу аутсорсинга — мы точим своё оружие. Бесценный опыт тестирования, которое в последнее время всё больше становится полноценной отраслью разработки специфичного класса программных систем, не должен уходить на сторону вместе с командой нанятых под проект тестеров. Они приходят, точат на нашем проекте своё умение — своё оружие! — и уходят, как гордые самураи-наёмники, унося знания о предметной области, а зачастую и коммерческие наработки.
Похожие работы
-
Оптимальная антивирусная защита информации
Построены модели функционирования антивирусной защиты информации и процесса проникновения и размножения вирусной инфекции в вычислительной системе.
-
Технологии тестирования программного обеспечения
Теоретическое обоснование технологий тестирования программного обеспечения. Разработка технологического процесса тестирования.
-
Автоматизированное тестирование при разработке ПО
Тестирование - один из важнейших этапов проверки качества разработанного ПО.
-
Когда прекращать тестирование программ?
Никто не сомневается в необходимости тестирования программ. Будь то небольшой учебный пример или целая информационная система. Вопрос только в том, сколько нужно тестировать и когда можно считать программу протестированной?
-
Технологии тестирования программного обеспечения
2.1. Введение. Понятия процесса программирования качественно изменились.Производство программ приобрело массовый характер, существенноувеличились их объем и сложность. Разработка программных комп-лексов потребовала значительных усилий больших коллективовспециалистов. Программы перестали быть только вычислительнымии начали выполнять важнейшие функции по управлению и обработкеинформации в различных отраслях.
-
Вопросы по информатике
В чем состоят особенности организации пакетного режима работы ЭВМ. Сформировать файл, содержащий результаты сессии студентов одной группы в виде матрицы.
-
Проблемы интеграции: Mercury Interactive QuickTest & TestDirector
Эта статья ориентирована на тестировщиков со средним и выше уровнем подготовки. Поэтому предполагается, что тестировщик знаком с такими инструментами компании Mercury Interactive как QuickTest (функциональное тестирование) и TestDirector.
-
Инструменты необходимые для тестирования Linux
Данная статья представляет из себя набор тех утилит, с которыми приходится сталкиваться QA инженеру при тестировании linux/unix подобных таргетов. Здесь описаны лишь некоторые, основные инструменты, с которыми Вам наверняка придется работать.
-
Особенности интерфейса программы RightMark Audio Analyzer 6.0.3
Характеристики пользовательского многооконного интерфейса программы RightMark Audio Analyzer 6.0.3. Общие настройки теста, алгоритмы тестирования акустики, настройка уровней записи и воспроизведения. Просмотр информации обо всех проводившихся тестах.
-
Почему IBM ClearCase и ClearQuest лучше других средств
Предлагаемые решения основаны на сочетании методологии и инструментальных средств IBM Rational.