Роль тестеров в гибком? [закрытый]

1) While a developer is coding a task, it is impossible for a tester to test it (it doesn't exist yet). What then is the role of a tester at this point

The tester may still create test plans and have a list of what tests will be created. There may also be the need for the tester to get training if the development involves some off-the-shelf software,e.g. if you are doing a CMS project with Sitecore then the tester should know a few things about Sitecore. There can also be some collaboration of the tester, the developer and the end user or BA to know what are the requirements and expectations so that there isn't the finger pointing that can pop up in vague requirements.

2) Is the tester now involved in unit testing? Is this done parallel to black box testing?

Not in our case. The tester is doing more integration/user acceptance testing rather than the low-level unit testing. In our case, unit tests come before any QA tests as the developers creating the functionality will create a layer of tests.

3) What does the tester do during a sprint where primarily infrastructural changes have been made, that may only be testable in unit testing?

Regression testing! In making infrastructural changes, did anything break? How thorough a testing suite can developers run compared to QA? We had this in a sprint not that long ago where most of the sprint work was plumbing rework so there wasn't much to test other than seeing that things that worked before still work afterward.

In our case, we have testing as one level up from our development environment but still a pre-production environment. The idea is to allow QA a sprint to validate the work done and for any critical or high severity bugs to be found and fixed before a release into staging for final user acceptance testing, so if developers are working on sprint X then QA is validating sprint X-1 and production may have sprint X-2 or earlier running depending on the final UAT and deployment schedule as not every sprint will make it into production after QA gives the OK to move into staging. There are pairing exercises that can happen once a developer is done an initial coding of a task to ensure that both a tester and an end user sign off on what was built. This is our third or fourth version of trying to integrate quality control into the project so it is still a work in progress that has evolved a few times over already.

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

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

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

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

Несколько мыслей, определенно неполных:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Участвует ли тестировщик в модульном тестировании? Выполняется ли это параллельно с тестированием черного ящика?

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

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

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

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

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

Я размещаю несколько советов по Agile здесь: http: Роб ..

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

Согласно Джему Канеру и Джеймсу Баху, исследовательское тестирование - это скорее [образ мышления] или «... способ размышления о тестировании», чем методология

или

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

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

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

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

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

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