Тестеры в [закрытой] разработке программного обеспечения

Это - вопрос № 10 на тесте Joel:

http://www.joelonsoftware.com/articles/fog0000000043.html

Должен сказать Вам все, что необходимо знать.:)

Тестеры необходимы в обоих случаях. Даже если на Вашей разработке делают пробную поездку, я думаю, что роль тестера часто фокусируется на внешних требованиях проекта - проект поставляет ожидаемый продукт, который выполнит требования?

Я нахожу, что в больших корпоративных средах у Вас часто есть золотой рудник хороших тестеров в центрах обработки вызовов или тех, кто делает обслуживание клиентов. У них часто есть очень основательное понимание бизнес-процессов, проблем и требований.

В таком контексте мы часто позволяли тестерам работать с построением реальных тестовых сценариев в системах бэкенда также, иногда они даже используются интеграционными тестами, которые пишут разработчики. Мы имели большой успех с разрешением разработчикам попросить, чтобы тестеры данные/сценарии протестировали на основанное на CI автоматизированное тестирование.

Можно ожидать, что другие роли примут участие в тестировании. Я действительно думаю, что все должны быть сфокусированы на качестве и тестировании, но к сожалению все не могут быть ответственными.

1. От некоторого размера на, абсолютно (я сказал бы что приблизительно 10 разработчиков).

2. Тестеры могли также сделать работа интеграции и сборка. В меньших группах разработчики должны протестировать, потому что нет никого больше, чтобы сделать это.

3. Хороший вопрос. Возможно, некоторые Ваши разработчики как тестирование.

4. Нет, особенно когда проект становится больше.

Я работал над крупным проектом (сотни разработчиков) в нашей группе приблизительно пятьдесят. У нашей группы были интеграция и группа тестирования из двух или трех полностью занятых людей и набор студентов.

Лучше иметь тестеры в команде. Мы, разработчики не могут получить большую часть дефектов, когда мы тестируем, но если она тестируется тестером затем, он ловит столько дефектов прежде, чем выпустить дефекты.

Лучше иметь случаи модульного теста также. Когда мы разрабатываем новую возможность, просто мы должны обновить тестовый сценарий и выполнить его.

1. НА крупном масштабе, да. Однако существует много различных методов и типов тестирования. Они включают пользователя, регрессию, единицу и интеграционное тестирование. Попытайтесь автоматизировать столько, сколько Вы можете. Селен выезда (IDE), Molydbenum, Сценарии Использования и Гибкая разработка.

2. Разработчик или разработчик должны решить, встретили ли они критерии допустимости, но если они тестируют свою собственную работу затем, она отчасти похожа на запись Вашего собственного экзамена перед нахождением для нее. Разработчики, тестирующие работу другого разработчика, не намного лучше, по-моему.

3. Не знать

4. Я думаю, что у менеджера проектов не будет времени для строгого тестирования. Это - действительно задание преданного тестера, который знает, чтобы быть прилежным и может взаимодействовать с менеджером проектов.

Никогда не недооценивайте значение специалистов.

Большинство людей, которые не являются тестерами, особенно разработчиками, не любит тестировать и не сделает этого хорошо. Если Вы попросите, чтобы графический дизайнер или разработчик провели половину их времени, тестируя, то в лучшем случае Вы потеряете 50% вывода хорошего разработчика/разработчика и получите 50% бедного, дорогого тестера. В худшем случае Вы потеряете их полностью, потому что они найдут где-нибудь лучше для работы.

В случае разработчиков они обычно слишком близки к коду, чтобы смочь протестировать его объективно. Они сделают предположения на основе своего знания внутренностей. Разработчик, тестирующий их собственный код, особенно плох.

Менеджер проектов должен быть ответственен за обеспечение, что все тестируется, но они не должны делать его сами. У них не будет достаточного количества времени или необходимых экспертных знаний.

Я ранее работал на компанию консультирования. Мы не имели никаких тестеров специалиста и будем вместо этого использовать, какой бы ни консультанты в настоящее время были без проекта. Ни один из них не имел экспертного знания тестирования, и в результате большинство из них не было очень хорошими тестерами. Мы добрались бы, отчеты об ошибках как "система больше не работает" или мой любимый: снимок экрана приложения, показывающего, насколько медленный это было (снимок экрана приложения, работающего быстро, не будет выглядеть несколько отличающимся). Они злоупотребили бы системой отслеживания ошибок также (или обошли бы ее полностью в пользу их собственного домашнего пива Excel spreadshhets). Это был кошмар.

1. Действительно ли тестеры необходимы в продукте (или крупномасштабный проект) разработка?
2. Тестеры должны только сделать тестовую работу? Из Вас может ожидать от разработчика или графического разработчика тестировать половину недели?
3. Где можно найти хорошие тестеры (я предполагаю, что нет градуса в тестировании разработки программного обеспечения)?
4. Действительно ли это - задача менеджера проектов технического teamlead для тестирования всего?

1 - на разработке продукта, когда Вы имеете> 10 клиентов: ад да. ВАЖНЫЙ. То же в крупном масштабе проект. Можно сэкономить, когда Вы являетесь маленькими, но после того как Вы преобладаете над определенным размером, боль обновления (например), 100 клиентов во всем мире перевешивает зарплату даже ОДНОГО тестера.

2 - да, tho существует некоторое перекрытие в работу поддержки также. Разработчик должен сделать основное тестирование - оно работает? - но это до тестеров, чтобы сделать исчерпывающее, сквозное сертификационное испытание странного примера использования. Это - пустая трата времени разработчиков, чтобы сделать это, я думаю. Графические дизайнеры не должны тестировать - хорошо, они пользовательский тест, я надеюсь, но это даже, прежде чем это доберется до разработчиков.

3 - некоторые разработчики делают хорошие тестеры. некоторые люди поддержки делают хорошие тестеры. кроме этого - просто находят их наугад. рекламировать. и т.д. нет никаких градусов, но кого-то, кто педантичен, может выставить для себя и знает больше о том, как среда конца скрепляет, чем, как каждая строка работ кода была бы хороша.

4 - нет. премьер-министр скрепляет проект и координирует тестеры, devs и т.д., технический вывод должен быть, Вы знаете, ведя техническую команду. не тестирование.

Очевидно, между ролями существует утечка. Иногда, ВСЕ должны делать некоторое тестирование, но это больше для получения максимального покрытия незадолго до RTM, не на повседневном или неделя к недельному основанию.

Модульные тесты являются большим запуском, поскольку они фиксируют логические ошибки, но они, как могут ожидать, не поймают сумасшедшее взаимодействие с пользователем или проблемы, которые только обнаруживаются после того, как Ваше приложение работало в течение 72 часов + - модульные тесты никогда не будут ловить их. Ваш клиент будет, но затем у Вас долгое время не будет клиентов :)

BTW, я "был там, сделал это". Я протестировал на клиентах и имел надлежащие тестеры на различных этапах (запустите vrs, купленный крупной компанией) того же продукта. Продукт был НАМНОГО более твердым, после того как у нас были тестеры, и клиенты были более счастливыми также (плюс, трудно развернуть маленький критический патч к 400 сайтам во всем мире - ловят его, прежде чем это будет поставляться!)

Я думаю, что тестеры (могут) принести к таблице, новая пара глаз на продукте. Я нашел, что, вероятно, буду следовать за счастливым путем, когда под управлением программное обеспечение, записал ли это быть через взаимодействие UI или классы использования я. Когда Вы знаете, как что-то, как предполагается, работает, это немного неестественно, чтобы сделать вещи неправильный путь, осуществить продукт способом, что это не было предназначено или попробовать вещи в порядке, который никто, кто знает, как это работает, не сделал бы.

Мои ответы на Ваши вопросы следующие:

1. Да. Тестирование является необходимостью, и таким образом своего рода тестер необходим. Как правило, модульные тесты поймают много проблем низкого уровня, но тестирование удобства пользования и тестирование 'требований' определяют, удовлетворяет ли оно требованиям на глянцевой брошюре. Если Вы утверждаете, что Ваше программное обеспечение делает 'X', то часть задания тестера должна удостовериться, что это действительно делает 'X'. Мы сделали, чтобы тестер раскрыл некоторые проблемы на платформах, которые я обычно не использую. Хорошо найти те проблемы рано.

2. Возможно. Мы перекрестный тестируем наши внутренние продукты, но имеем отдельную группу тестирования также. Мы ухаживаем к (внутренней) находке за львиной долей проблем, но полностью занятые тестеры иногда находят вещи, что мы, вероятно, никогда не находили бы. При разделении времени между разработкой и тестированием должно быть ясно, что тестирование не является запоздалой мыслью. Если я перегружен, работая над моей разработкой и нелегко проводить необходимое время, тестируя Ваш продукт, то я не собираюсь быть этим эффективным как тестер. Тайм-менеджмент важен, если Вы собираетесь иметь разработчиков, удваивающихся как тестеры.

3. Не уверен. Некоторые группы (IV и V групп, например) в организации делают только тестирование. Я подозреваю, что существует много людей там, которые не имеют никакого бизнеса или требуют писать программное обеспечение, но могут протестировать heck из продукта. Некоторые наши лучшие тестеры в моем последнем задании не написали кода вообще.

4. Зависьте от своего проекта, но я сказал бы "нет", обычно. Ответственность - что-то, что распространено в моем магазине. Вывод не ответственен за все тестирование. Мы все ответственны.

Во всяком случае это составляет мои два цента.

Все скажут, что тестеры требуются, и это - политкорректный ответ. Но тестеры являются только одним из многих инструментов, доступных на панели инструментов гарантии качества. Можно поставить превосходное программное обеспечение без тестеров. Например, интересно, имеет ли Stackoverflow испытательный цех?

Тестер измерит качество кода, который производят Ваши разработчики. Но доступность качественных измерений не делает ничего для улучшения качества.

Тестеры не приезжают бесплатно. Необходимо будет изменить разработку для поставки тестовой команде вместо клиента. Это может привести к разъединению между клиентами и разработчиками: тестеры могли бы найти ошибки, о которых клиенты не могли заботиться об и проигнорировать ошибки, которые очень важны для клиента. Кроме того, необходимо будет создать и поддержать отдельную тестовую среду.

Хорошие тестеры помогут Вам разработать лучше и особенно выпустить более гладко. Но Ваш пробег будет варьироваться.

P.S. В крупной компании тестеры важны: они включают перекладывание вины. Скажите, что ошибка наносит клиентский ущерб->, руководитель расстроен. В этой точке руководитель готов сделать противный материал Вашей команде. С тестовой командой можно свалить вину на тестовые команды, которые сваливают вину назад на Вас. Компромисс развертывает: Вы представляете новые процессы, тестовая команда нанимает больше тестеров, и руководитель заявляет, что лично улучшил материал.