Роль тестировщиков в гибкой работе?

Ответ 1

Удержание тестеров, как правило, становится проще по мере созревания проекта (есть еще испытание!), но на ранних этапах также применяются следующие пункты:

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

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

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

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

Ответ 2

В идеале QA и тестеры должны быть задействованы, если не с первого дня, а с самого раннего этапа проекта разработки программного обеспечения, независимо от используемого процесса (водопада или гибкого). Команда тестирования должна будет:

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

• Подготовьте стратегию тестирования конкретного проекта и определите, какие шаги QA потребуются и на каких этапах проекта: интеграция, стресс, совместимость, проникновение, соответствие, удобство использования, производительность, бета-тестирование и т.д. Определите допустимые пороговые значения дефектов и разработать систему классификации по степени серьезности дефектов, указать рекомендации для отчетов о дефектах.

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

• Предоставьте всю необходимую информацию для формирования расписания проекта, структуры разбивки работ и плана ресурсов.

• Напишите тестовые скрипты.

• Приведите себя в порядок с проблемным доменом, системой AS-IS и предлагаемым решением.

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

Ответ 3

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

Общий миф о том, что тестеры не требуются, легко рассеивается.

1. Пока разработчик кодирует задачу, тестировщик не может ее протестировать (он еще не существует). Какова тогда роль тестера в этой точке

По моему опыту, тестер мог работать с клиентом, чтобы точно настроить рассказы в спринте.

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

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

Если гибкая команда достаточно продвинута, тестер обычно будет писать тесты ATDD (тестирование приемочного тестирования). Они могут быть в таких инструментах, как Fitnesse или Robot Framework, или они могут быть более продвинутыми рубиновыми тестами или даже некоторыми другими языками программирования. Или в некоторых случаях простая запись и воспроизведение часто могут быть полезны для небольшого количества тестов.

Они, очевидно, будут писать тесты и планировать некоторые сценарии или идеи для исследовательского тестирования.

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

2. Является ли тестером сейчас участие в модульном тестировании? Это делается параллельно с тестированием черного ящика?

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

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

3. Что делает тестер во время спринта, где были сделаны прежде всего инфраструктурные изменения, которые могут быть проверены только при тестировании устройства?

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

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

Я размещаю несколько подсказок: http://thesocialtester.posterous.com/

Надеюсь, это поможет вам Rob..

Ответ 4

Несколько мыслей, безусловно неполных:

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

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

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

Ответ 5

В последнее время я увидел хороший talk. В основном эта команда начала выполнять довольно стандартный процесс Scrum, затем перешла на Kanban и Lean. Одна из самых важных вещей, которые они делали, - постепенно подорвать различия между тестировщиками и разработчиками. Тестеры участвовали в написании модульных тестов и кода, разработчики приносили тесты более высокого уровня на ранней стадии разработки. Это была крутая кривая обучения для тестировщиков, но это стоило того, поскольку команда с самого начала строила качество. К настоящему времени тестеры называют себя разработчиками, потому что их работа настолько интегрирована в процесс написания кода.

Ответ 6

В моей компании мы используем и поддерживаем Agile. Наши члены команды QA участвуют в создании unit test, поддерживая инфраструктуру тестирования регрессии и, как и в водопаде, они также проверяют каждую функцию после завершения.

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

Итак, из моего ограниченного опыта, я постараюсь ответить на ваши вопросы:

• Если вам еще нечего тестировать, начните настройку инфраструктуры регрессии/тестирования и убедитесь, что все, что будет сделано, будет проверяться
• Да, он может сделать как
• Поддерживает инфраструктуру тестирования и охотится за тем, кто нарушает тесты.

Ответ 7

1) Пока разработчик кодирует задачу, тестировщик не может протестировать он (он еще не существует). Что тогда является роль тестера в этой точке

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

2) Является ли тестировщик сейчас включенным в модульное тестирование? Это делается параллельно с тестирование черного ящика?

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

3) Что делает тестер во время спринта, где прежде всего инфраструктурные были внесены изменения, которые могут можно тестировать при модульном тестировании?

Регрессионное тестирование! При создании инфраструктурных изменений, что-то сломалось? Насколько тщательный набор тестов может выполнять разработчик по сравнению с QA? У нас было это в спринте не так давно, когда большая часть работы по спринту была переделкой сантехники, поэтому было не так много, чтобы проверить, кроме как видеть, что все, что работало до того, как еще работать после этого.

В нашем случае мы тестируем как один уровень от нашей среды разработки, но все еще предпроизводственную среду. Идея состоит в том, чтобы разрешить QA спринт проверять выполненную работу и выявлять и фиксировать ошибки критической или высокой степени серьезности перед выпуском в стадию для окончательного тестирования приёма пользователей, поэтому, если разработчики работают над спринтом X, тогда QA проверяет спринт X-1 и производство могут иметь спринт X-2 или ранее выполняемый в зависимости от окончательного UAT и расписания развертывания, поскольку не каждый спринт превращает его в производство после того, как QA дает ОК для перехода в стадию. Существуют упражнения по спариванию, которые могут произойти после того, как разработчик выполнит начальное кодирование задачи, чтобы гарантировать, что и тестер, и конечный пользователь подпишут на том, что было построено. Это наша третья или четвертая версия, которая пытается интегрировать контроль качества в проект, так что это еще незавершенная работа, которая уже несколько раз развивается.

Ответ 8

Самый естественный подход к тестированию в гибкой среде - это, на мой взгляд, разведочное тестирование http://en.wikipedia.org/wiki/Exploratory_testing. Не звучит слова типа

Согласно Cem ​​Kaner и James Bach, разведочное тестирование - это больше [мышление] или "... способ мышления о тестировании", чем методология

или

тестирование пары

звук, знакомый с гибкими разработчиками. Тестеры могут участвовать гораздо раньше, чем в традиционном тестировании.

Ответ 9

Как и некоторые другие респонденты, Тестеры должны быть задействованы с первого дня. В ноте Sprint они должны быть вовлечены в обеспечение того, что Истории, которые производит Владелец Продукта, являются проверяемыми (например, проверяемыми после кодирования) и "приемлемыми" (т.е. когда вы идете по UAT). Когда изначально заполняется Backlog Product, тестеры могут работать в тестовых случаях для Stories, запланированных для текущего Sprint, и как только есть продукт для тестирования (в идеале, где-то в вашем первом Sprint), тогда они могут начать тестирование.

Если это звучит так, что никогда не будет ничего, чтобы протестировать несколько Спринтов, у вас есть свои истории неправильно. Цель Sprint, даже ранняя, состоит в том, чтобы иметь тонкий срез возможной системы. Сосредоточьтесь на "asprin" (т.е. При создании системы рецептур лекарств, как вы доставляете тестируемые функции через 2-4 недели? Создавайте те, которые назначают асприн) и "трассирующие пули" (те, которые, когда их сочетают в совокупности, касаются всех рискованные части архитектуры). Вы будете поражены тем, что вы можете сдавать, чтобы испытать на ранней стадии. Если тестеры в конечном итоге получают свободное время, попросите их подключить программу к разработчикам. Он будет строить отношения и взаимное уважение.

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

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