Сообщений в теме: 87

[KaNoN]

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

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

[a66at]

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

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

Если же процесс только на бумаге, то стадию тест-дизайна ему не миновать.

А каким образом минует стадию тест-дизайна процесс, который не на бумаге? В обоих случаях делается тест-дизайн.

Да, вы ничего не поняли. Живой процесс регрессионки пригоден тем, что он уже есть и его со временем можно по мере возможностей автоматизировать, снимая нагрузку с людей, задействованных в тестировании (часть тестов делегируется на автоматическое тестирование и вручную не проходится).

Так он пригоден или необходим?

[KaNoN]

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

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

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

[KaNoN]

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

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

Если же процесс только на бумаге, то стадию тест-дизайна ему не миновать.

А каким образом минует стадию тест-дизайна процесс, который не на бумаге? В обоих случаях делается тест-дизайн.

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

Да, вы ничего не поняли. Живой процесс регрессионки пригоден тем, что он уже есть и его со временем можно по мере возможностей автоматизировать, снимая нагрузку с людей, задействованных в тестировании (часть тестов делегируется на автоматическое тестирование и вручную не проходится).

Так он пригоден или необходим?

Ваш вопрос звучал так

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

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

[a66at]

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

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

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

Т.е. я пришёл, выполнил анализ, проектирование и дизайн (например один вообще, сам, а кто мне может помешать?), это сформировало процесс, который необходим для старта автоматизации. Я удовлетворил необходимому условию наличия процесса для начала автоматизации из первой обсуждаемой статьи (в случае, если я изначально держал в голове именно такой план). Я всё правильно понял?
Просто возникает вопрос, а согласны ли Вы с первой обсуждаемой статьёй? Вот цитаты:
"Для внедрения автоматизации тестирования ПО необходим ... зафиксированный и работающий процесс тестирования"
"Процесс тестирования должен существовать, работать, поддаваться изменениям и анализу, а для этого процесс должен быть зафиксирован письменно и любые процессные изменения должны фиксировать тоже письменно. На процесс, который строится, ставить автоматизацию сверху нельзя – развалим."

Ваш вопрос звучал так

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

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

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

Сообщение отредактировал a66at: 01 февраля 2008 - 14:04

[a66at]

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

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

[Case]

Но для нагрузочного это, конечно, неверно.

А методы эксплуатационного анализа и полученные таким образом данные почему не являются входом для автоматизации нагрузочного тестирования?

[KaNoN]

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

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

Хм ... хорошая подсказка, особенно если учесть, что к исторической информации о выполнении тестирования также можно отнести и дефекты, выявленные в процессе. А ведь это один из артефактов, который получается на этапе выполнения. Соответственно, если мы еще не дошли никоим образом до данной стади, то у нас хотя бы должна быть инфраструктура, позволяющая нормально реализовать выполнение. Это и тестовая среда (без нее и разработка затруднительна), система трекинга дефектов + всякая специфика. В качестве системы для хранения дефектов подойдет поначалу и листик бумаги, на котором записываются выявленные проблемы, НО ... возвращаемся к разработке. Вот мы автоматизируем какой-то тест и возникла ошибка. Естественно мы ее фиксируем. Если ошибка некритичная, то разработку тестов мы можем продолжить. А если критичная? В этом случае фиксируем дефект и замораживаем разработку теста. К этому тесту нам придется вернуться только когда этот баг исправлен. Когда это произойдет? Когда описание этого бага попадет к разработчику и он эту ошибку будет устранять. А для того, чтобы это случилось, нужно, чтоб проводились соответствующие активности. То есть на данном этапе это должен быть не мертвый процесс, а очень даже функционирующий, который выдает уже результаты. Пока этого не случится, есть высокий риск того, что автоматизацию не удастся реализовать в полном запланированном объеме, если весь процесс тестирования пока только на бумаге, а не приведен в действие в полной мере.

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

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

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

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

Вот именно, что это только для старта. Стартовать автоматизацию можно, особенно, если подтянута инфраструктура (то есть уже можно выполнять тесты и фиксировать ошибки), иначе на это придется отвлечься.

Просто возникает вопрос, а согласны ли Вы с первой обсуждаемой статьёй? Вот цитаты:
"Для внедрения автоматизации тестирования ПО необходим ... зафиксированный и работающий процесс тестирования"
"Процесс тестирования должен существовать, работать, поддаваться изменениям и анализу, а для этого процесс должен быть зафиксирован письменно и любые процессные изменения должны фиксировать тоже письменно. На процесс, который строится, ставить автоматизацию сверху нельзя – развалим."

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

Ваш вопрос звучал так

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

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

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

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

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