Подтвердить что ты не робот

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

В моей компании мы разрабатываем программный продукт. До сих пор у нас не было никаких тестеров, поэтому в основном разработчики были тестировщиками, и, конечно же, клиентом и пользователями (не хорошо).

Наша команда теперь состоит из 4 разработчиков, и мы работаем в основном с Cruisecontrol, Flex, ASP.NET, IIS, MSSQLServer и WebORB. Я настоятельно призываю менеджеров нанять тестер, но мне интересно, нормально ли тестировщики в разработке программного обеспечения. Итак:

  • Являются ли тестеры необходимыми для разработки продукта (или крупномасштабного проекта)?
  • Если тестировщики выполняют только пробную работу? Или вы можете ожидать от разработчика или графического дизайнера протестировать половину недели?
  • Где вы можете найти хороших тестеров (я полагаю, что не существует степени в тестировании разработки программного обеспечения)?
  • Задача менеджера проекта технической команды - проверить все?

спасибо, Lieven Cardoen

ps: спасибо, Vinay, у нас есть Unit Tests, но действительно, Unit Tests не может покрыть то, что могут тестировать.

4b9b3361

Ответ 1

1) Необходимы ли тестеры в разработке продукта (или крупномасштабного проекта)?

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

2) Если тестировщики выполняют только пробную работу? Можно ли ожидать от разработчика или графического дизайнера тестирования половины недели?

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

3) Где вы можете найти хороших тестеров (я полагаю, что не существует степени в тестировании разработки программного обеспечения)?

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

4) Задача менеджера проекта технической команды - проверить все?

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


Помните. Наличие тестера не является оправданием для разработчиков/программистов, чтобы не тестировать код, когда они его пишут или создают unit test. Разработчики по-прежнему несут ответственность за разработку хорошего продукта. Они никогда не должны пытаться оправдать ошибку, которую они создали, обвинив тестировщика в том, что он не нашел его.

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

  • В больших масштабах, да. Однако существует множество различных методов и типов тестирования. К ним относятся тестирование пользователей, регрессии, единицы измерения и интеграции. Попытайтесь автоматизировать как можно больше. Проверьте Selenium (IDE), Молиббенум, Сценарии использования и Agile развития.

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

  • Незнайка

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

Ответ 7

  • Являются ли тестеры необходимыми для разработки продукта (или крупномасштабного проекта)?
  • Если тестировщики выполняют только пробную работу? Вы можете ожидать от разработчика или графического дизайнера для испытайте половину недели?
  • Где вы можете найти хороших тестеров (я полагаю, что в тестирование разработки ПО)?
  • Задача менеджера проекта технической команды - проверить все?

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

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

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

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

Очевидно, что существует утечка между ролями. Иногда, КАЖДЫЙ должен делать некоторые тесты, но это больше, чтобы получить максимальный охват непосредственно перед RTM, а не на ежедневной основе или на неделю.

Модульные тесты - отличное начало, поскольку они ловят логические ошибки, но от них нельзя ожидать, что они поймут сумасшедшие пользовательские взаимодействия или проблемы, которые появляются только после того, как ваше приложение работает в течение 72 часов + - модульные тесты будут НИКОГДА ВСЕГДА их поймайте. Ваш клиент будет, но тогда у вас не будет клиентов надолго:)

Кстати, я "был там, сделал это". Я тестировал на клиентах и ​​имел подходящих тестеров на разных этапах (стартап, купленный крупной компанией) того же продукта. Продукт был намного более твердым, как только у нас были тестеры, и клиенты были счастливее (плюс, трудно развернуть небольшой критический патч на 400 сайтах по всему миру - поймайте его перед его отправкой!)

Ответ 8

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

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

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

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

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

Ответ 9

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

Мои ответы на ваши вопросы таковы:

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

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

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

  • В зависимости от вашего проекта, но я бы сказал, нет, вообще. Ответственность - это то, что распространяется в моем магазине. Ведущий не несет ответственности за все испытания. Мы все подотчетны.

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

Ответ 10

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

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

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

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

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