Тестеры в разработке программного обеспечения
В моей компании мы разрабатываем программный продукт. До сих пор у нас не было тестеров, так что в основном разработчиками были тестеры, и, конечно, заказчики и пользователи (не очень хорошо).
В настоящее время наша команда состоит из 4 разработчиков, и мы работаем, в основном, с Cruisecontrol, Flex, ASP.NET, IIS, MSSQLServer и WebORB. Я призываю менеджеров нанять тестера, но мне интересно, нормальны ли тестеры в разработке программного обеспечения. Так:
- Нужны ли тестеры при разработке продукта (или крупномасштабного проекта)?
- Должны ли тестеры выполнять только тестовую работу? Или вы можете ожидать от разработчика или графического дизайнера тестирования недели?
- Где можно найти хороших тестеров (я полагаю, что нет степени в области тестирования разработки программного обеспечения)?
- Задача руководителя проекта технической команды - проверить все?
спасибо Ливен Кардоен
PS: Thx, Vinay, у нас есть модульные тесты, но действительно, модульные тесты не могут охватить то, что могут тестеры.
10 ответов
1) Нужны ли тестеры при разработке продукта (или крупномасштабного проекта)?
Да. Кто-то должен взять на себя ответственность за оценку того, когда что-то достаточно протестировано, и за то, какие ошибки нужно исправить или они могут быть отправлены, потому что есть обходные пути.
2) Должны ли тестеры выполнять только тестовую работу? Можно ли ожидать от разработчика или графического дизайнера тестирования пол недели?
Тестировщики часто выполняют работу по поддержке клиентов или работают с заказчиком для разработки требований. Тестировщики могут выступать в качестве внутренних голосов для клиентов... и, если они достаточно взаимодействуют с клиентом, они должны чувствовать ответственность за получение подходящего качественного продукта в процессе разработки, который, как они знают, потребует клиент.
3) Где можно найти хороших тестировщиков (я полагаю, что нет степени в тестировании разработки программного обеспечения)?
Могу поспорить, что где-то есть степень. У нас есть много тестировщиков, которые учатся в университете информатики и проводят год в промышленности, прежде чем вернуться в последний год обучения в университете.
4) Задача руководителя проекта технической команды привести все к проверке?
Не обязательно. Это зависит от того, насколько велика команда, если она маленькая, то да, кто-то может удвоиться и исполнить обе роли. Для больших проектов это разные люди.
Помните. Наличие тестера не является оправданием для разработчиков / программистов, чтобы они не тестировали код при его написании или создавали модульный тест. Разработчики по-прежнему несут ответственность за разработку хорошего продукта. Они никогда не должны пытаться оправдать созданную ими ошибку, обвиняя тестировщика в том, что он его не нашел.
Это вопрос № 10 по тесту Джоэла:
http://www.joelonsoftware.com/articles/fog0000000043.html
Должен рассказать вам все, что вам нужно знать.:)
Тестеры необходимы в обоих случаях. Даже если ваша разработка основана на тестировании, я думаю, что роль тестировщика часто фокусируется на внешних требованиях проекта - обеспечивает ли проект ожидаемый продукт, который будет соответствовать требованиям?
Я нахожу, что в больших корпоративных средах у вас часто есть золотая жила хороших тестеров в колл-центрах или тех, кто занимается обслуживанием клиентов. У них часто есть очень твердое понимание бизнес-процессов, проблем и требований.
В таком контексте мы часто позволяем тестировщикам работать над созданием реальных тестовых примеров и в серверных системах, иногда они даже используются в интеграционных тестах, которые пишут разработчики. Мы добились большого успеха, позволив разработчикам попросить тестировщиков предоставить данные / сценарии для тестирования автоматизированного тестирования на основе CI.
Вы можете ожидать, что другие роли примут участие в тестировании. Я действительно думаю, что все должны быть сосредоточены на качестве и тестировании, но, к сожалению, каждый не может нести ответственность.
В больших масштабах, да. Однако существует много разных методов и видов тестирования. К ним относятся пользовательское, регрессионное, модульное и интеграционное тестирование. Попробуйте и автоматизируйте столько, сколько сможете. Проверьте Selenium (IDE), Molydbenum, сценарии использования и гибкую разработку.
Разработчик или дизайнер должны решить, соответствуют ли они критериям приемлемости, но если они тестируют свою собственную работу, это все равно, что написать свой собственный экзамен, прежде чем сдавать его. Разработчики, тестирующие работу других разработчиков, на мой взгляд, не намного лучше.
Не знаю
Я думаю, что у менеджера проекта не будет времени на тщательное тестирование. Это действительно работа опытного тестировщика, который знает, как быть усердным и может взаимодействовать с менеджером проекта.
Никогда не стоит недооценивать ценность специалистов.
Большинству людей, которые не являются тестерами, особенно разработчикам, не нравится тестирование, и они не будут делать это хорошо. Если вы попросите, чтобы графический дизайнер или разработчик потратили половину своего времени на тестирование, в лучшем случае вы потеряете 50% результатов хорошего дизайнера / разработчика и получите 50% плохого, дорогого тестера. В худшем случае вы потеряете их полностью, потому что они найдут лучшее место для работы.
В случае разработчиков, они обычно слишком близки к коду, чтобы иметь возможность объективно его протестировать. Они сделают предположения, основанные на их знании внутренних органов. Разработчик, тестирующий собственный код, особенно плох.
Менеджер проекта должен нести ответственность за то, чтобы все было проверено, но они не должны делать это сами. У них не будет достаточно времени или необходимых знаний.
Ранее я работал в консалтинговой компании. У нас не было специалистов по тестированию, и вместо этого мы использовали бы тех консультантов, которые в настоящее время не имели проекта. Никто из них не имел опыта тестирования, и в результате большинство из них не были хорошими тестерами. Мы получали сообщения об ошибках типа "система больше не работает" или мой личный фаворит: снимок экрана приложения, показывающий, насколько медленно он работал (снимок экрана с запущенным приложением не выглядел бы по-другому). Они также будут злоупотреблять системой отслеживания ошибок (или полностью ее обходить в пользу своих собственных электронных таблиц Excel). Это был кошмар.
- Нужны ли тестеры при разработке продукта (или крупномасштабного проекта)?
- Должны ли тестеры выполнять только тестовую работу? Можно ли ожидать от разработчика или графического дизайнера тестирования пол недели?
- Где можно найти хороших тестеров (я полагаю, что нет степени в области тестирования разработки программного обеспечения)?
- Задача руководителя проекта технической команды - проверить все?
1 - на разработку продукта, когда у вас> 10 клиентов: черт возьми, да. ОСНОВНОЙ. То же самое в крупном проекте. Вы можете экономить, когда вы маленький, но как только вы наберете определенный размер, боль от обновления (например,) 100 клиентов по всему миру перевешивает зарплату даже ОДНОГО тестера.
2 - да, хотя есть некоторые совпадения с работой поддержки. Разработчик должен провести базовое тестирование - это работает? - но тестировщикам предстоит провести исчерпывающее, сквозное, странное тестирование варианта использования. Думаю, это пустая трата времени разработчиков. Графические дизайнеры не должны тестировать - ну, они тестируют пользователя, я надеюсь, но это еще до того, как это дойдет до разработчиков.
3 - некоторые разработчики делают хорошие тестеры. некоторые люди поддержки делают хороших тестеров. кроме этого - просто найдите их наугад. рекламировать. и т.д. нет никаких степеней, но кто-то, кто педантичен, может поддержать себя, и знает больше о том, как конечная среда держится вместе, чем то, как работает каждая строка кода, было бы хорошо.
4 - нет. премьер-министр объединяет проект и координирует работу тестировщиков, разработчиков и т. д. технический руководитель должен быть, знаете ли, руководить технической командой. не тестирую
Очевидно, что есть утечка между ролями. Иногда КАЖДЫЙ должен проводить какое-то тестирование, но это больше для того, чтобы получить максимальное покрытие непосредственно перед RTM, а не на ежедневной или еженедельной основе.
Модульные тесты - это хорошее начало, так как они улавливают логические ошибки, но от них нельзя ожидать сумасшедших взаимодействий с пользователем или проблем, которые проявляются только после того, как ваше приложение работает в течение 72 часов + - модульные тесты НИКОГДА не будут ловить эти, Ваш клиент будет, но тогда у вас не будет клиентов долго:)
Кстати, я "был там, сделал это". Я проводил тестирование на клиентах, и на разных этапах (стартапы, купленные крупной компанией) у меня были соответствующие тестеры одного и того же продукта. Продукт стал ОЧЕНЬ более надежным, когда у нас были тестеры, и клиенты тоже были счастливее (плюс, сложно развернуть небольшое критическое исправление на 400 сайтах по всему миру - поймайте его до того, как оно будет отправлено!)
Лучше иметь в команде тестеров. Мы, разработчики, не можем получить так много дефектов, когда мы тестируем, но если он тестируется тестером, то он улавливает так много дефектов, прежде чем выпустить дефекты.
Лучше также иметь модульные тесты. Когда мы разрабатываем новую функцию, нам просто нужно обновить тестовый пример и запустить его.
С какого-то размера, абсолютно (я бы сказал, около 10 разработчиков).
Тестировщики также могут выполнять сборку и интеграцию. В небольших группах разработчики должны тестировать, потому что больше некому это делать.
Хороший вопрос. Может быть, некоторые из ваших разработчиков любят тестирование.
Нет, особенно когда проект становится больше.
Я работал над большим проектом (сотни разработчиков), в нашей группе около пятидесяти. В нашей группе была группа по интеграции и тестированию, состоящая из двух-трех человек, занятых полный рабочий день, и группы студентов.
Я думаю, что тестеры (могут) принести на стол свежий взгляд на продукт. Я обнаружил, что при запуске программного обеспечения я, скорее всего, буду следовать по счастливому пути, будь то через взаимодействие с пользовательским интерфейсом или с помощью написанных мной классов. Когда вы знаете, как что-то должно работать, немного неестественно делать что-то неправильно, использовать продукт так, как он не предназначен, или пробовать что-то в таком порядке, что никто, кто знает, как это работает, не будет делать.
Мои ответы на ваши вопросы следующие:
Да. Тестирование является необходимостью, и поэтому необходим некоторый тестер. Как правило, модульные тесты выявляют множество проблем низкого уровня, но тестирование юзабилити и тестирование "требований" определяют, соответствует ли оно требованиям, указанным в глянцевой брошюре. Если вы утверждаете, что ваше программное обеспечение выполняет "X", то часть работы тестировщика - убедиться, что оно действительно "X". У нас был тестер, который обнаружил некоторые проблемы на платформах, которые я обычно не использую. Это хорошо, чтобы найти эти проблемы рано.
Может быть. Мы проводим перекрестное тестирование наших продуктов, но у нас также есть отдельная группа тестирования. Мы склонны (собственными силами) находить львиную долю проблем, но постоянные тестеры иногда находят вещи, которые мы, вероятно, никогда бы не нашли. Если вы разделите время между разработкой и тестированием, должно быть ясно, что тестирование не является запоздалой мыслью. Если я перегружен работой над своей разработкой и мне трудно тратить необходимое время на тестирование вашего продукта, то я не стану таким эффективным тестировщиком. Тайм-менеджмент очень важен, если вы хотите, чтобы разработчики удвоились как тестеры.
Точно сказать не могу. Некоторые группы (например, группы IV и V) в организации проводят только тестирование. Я подозреваю, что есть ряд людей, которые не имеют никакого программного обеспечения для бизнеса или желания писать, но могут проверить его на вкус. Некоторые из наших лучших тестировщиков на моей последней работе вообще не писали никакого кода.
Зависит от вашего проекта, но я бы сказал, нет. Ответственность - это то, что распространяется в моем магазине. Ведущий не несет ответственности за все испытания. Мы все несем ответственность.
Во всяком случае, это мои два цента.
Все скажут, что требуются тестеры, и это политически правильный ответ. Но тестеры являются лишь одним из многих инструментов, доступных в наборе инструментов обеспечения качества. Вы можете отправить отличное программное обеспечение без тестеров. Например, мне интересно, есть ли в Stackru тестовый отдел?
Тестер будет измерять качество кода, который создают ваши разработчики. Но наличие качественных измерений не улучшает качество.
Тестеры не приходят бесплатно. Вам придется изменить разработку, чтобы доставить ее в команду тестирования вместо клиента. Это может привести к разрыву между клиентами и разработчиками: тестировщики могут находить ошибки, о которых клиенты не могли бы заботиться, и игнорировать ошибки, которые очень важны для клиента. Кроме того, вам придется создать и поддерживать отдельную среду тестирования.
Хорошие тестеры помогут вам лучше развиваться, и, особенно, выпускать более плавно. Но ваш пробег будет меняться.
PS В большой компании тестеры необходимы: они позволяют переложить вину. Скажем, ошибка причиняет вред клиенту -> руководитель расстроен. На данный момент руководитель готов сделать неприятные вещи для вашей команды. С помощью команды тестирования вы можете перекладывать вину на группу тестирования, которая перекладывает вину обратно на вас. Раскрывается компромисс: вы внедряете новые процессы, команда тестов нанимает больше тестеров, а руководитель говорит, что он лично улучшил ситуацию.