Поскольку тема про Agile Testing успешно превратилась в флейм и на этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, толковые книги или ссылки по тестированию в agile проектах, и в особенности в скраме.
Интересуют не столько инженерные практики для программистов (unit tests, TDD etc.), сколько область и способ применения QA инженеров (тестеров) в скрам-проектах, или в похожих методологиях: - Нужны ли тестеры вообще? Считается, что тестер всегда будет по другому смотреть на продукт, чем девелопер, и этим он особенно полезен. - Держать тестеров в скрам-командах или как внешний сервис? Как распределять тестовые работы в случае внешнего сервиса? Что считать Done? - Как распределять тестовые работы в команде в случае, если в ней есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? - Как лучше организовать regression testing? Что охватывать, как часто? - "Процесс тестирования"? Как формулировать в условиях скрама, и нужно ли? Как пересекать его со спринтами?
Естественно, у меня есть свои решения по каждому из вопросов для текущего проекта, но с точки зрения "самоучки" и опыта "классической" разработки, на уровне здравого смысла. Хотелось бы почитать советы людей с достаточным опытом и в скраме, и в тестировании.
Может быть, нам стоит заострить эту тему на следующем agile gathering?
Могу посоветовать пару книг по тестированию, но не все из них касаются именно Agile подходов:
Global Agile Software Development Quality Assurance (Mar 2007) - как раз описывает подходы в Agile проектах
Practical Software Testing - очень понравилась нашим QA, но у самого руки не дошли потому как книга довольно объемная
Software Testing and Analysis: Process, Principles and Techniques (Apr. 2007) - описание общих принципов и подходов
Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional (Feb. 2007) - не читал, но думаю посмотреть
Software Testing (Jul. 2007) - книга далека от Agile, но очень понравилась. много интересных идей, которые многие знают, но освежить и собрать воедино всегда полезно
On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote:
> Поскольку тема про Agile Testing успешно превратилась в флейм и на > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > толковые книги или ссылки по тестированию в agile проектах, и в > особенности в скраме.
> Интересуют не столько инженерные практики для программистов (unit > tests, TDD etc.), сколько область и способ применения QA инженеров > (тестеров) в скрам-проектах, или в похожих методологиях: > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > другому смотреть на продукт, чем девелопер, и этим он особенно > полезен. > - Держать тестеров в скрам-командах или как внешний сервис? Как > распределять тестовые работы в случае внешнего сервиса? Что считать > Done? > - Как распределять тестовые работы в команде в случае, если в ней > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > - Как лучше организовать regression testing? Что охватывать, как > часто? > - "Процесс тестирования"? Как формулировать в условиях скрама, и > нужно ли? Как пересекать его со спринтами?
> Естественно, у меня есть свои решения по каждому из вопросов для > текущего проекта, но с точки зрения "самоучки" и опыта "классической" > разработки, на уровне здравого смысла. Хотелось бы почитать советы > людей с достаточным опытом и в скраме, и в тестировании.
> Может быть, нам стоит заострить эту тему на следующем agile gathering?
Николай, жаль вы не пришли на встречу 9го... :) Спасибо за ссылки.
Вот что я думаю про тестирование в Скраме: ----------
В книгах по Scrum особо ничего про тестирование не говорится. Даже не упоминается слово "тестировщик", из чего складывается мнение, что Scrum и QA несовместимы. Это не так. В Scrum есть правила, из которых можно сделать необходимые выводы: 1. результат каждого спринта должен быть потенциально готов для поставки - базовое правило 2. (как следствие из 1) - команда, работающая над проектом, должна быть полно функциональна, то есть включать всех, чьих работы создают готовый продукт. а именно: архитекторов, дизайнеров, программистов, тестировщиков, тех писателей и т.д. словом всех.
Следуя этим правилам, можно выработать необходимые проектные правила, которые позволят достичь целей. А именно: - всё тестирование должно проводиться внутри итерации (спринта), так чтобы по окончании двухнедельного (или какого-то там) цикла все спланированные части продукта бы (фичи, багфиксы, документация, пакет установки) - следовать правилу 1 (см выше) нужно, даже если вы поставляете продукт фактически раз в квартал - следуя правилу 2, вы, как тестировщики должны быть с программистами, быть частью команды - активно присутствовать на всех утренних митингах, сборах по планированию, демонстрациях. - вы также должны уменьшать "единицу готовой работы", передаваемую от программиста к тестировщику, давая ответ программистам как можно быстрее (см на статью Майка Кона http://blog.mountaingoatsoftware.com/?p=11) - автоматическое тестирование вам очень поможет - советую добавлять задачи по тестированию в общий пул задач, давая им оценки, тогда тестирование станет общей заботой - поможет нахождение в физической близости к программистам (лучше в одном большом открытом пространстве) - развешивание графиков с актуальной информацией по статусу разработки-тестированию-приему тоже поможет очень помочь -----------------------
On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> Могу посоветовать пару книг по тестированию, но не все из них касаются > именно > Agile подходов:
> Global Agile Software Development Quality Assurance (Mar 2007) - как > раз описывает > подходы в Agile проектах
> Practical Software Testing - очень понравилась нашим QA, но у самого > руки не дошли > потому как книга довольно объемная
> Software Testing and Analysis: Process, Principles and Techniques > (Apr. 2007) - описание > общих принципов и подходов
> Pragmatic Software Testing: Becoming an Effective and Efficient Test > Professional (Feb. 2007) - не читал, > но думаю посмотреть
> Software Testing (Jul. 2007) - книга далека от Agile, но очень > понравилась. много интересных идей, > которые многие знают, но освежить и собрать воедино всегда полезно
> On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > Поскольку тема про Agile Testing успешно превратилась в флейм и на > > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > > толковые книги или ссылки по тестированию в agile проектах, и в > > особенности в скраме.
> > Интересуют не столько инженерные практики для программистов (unit > > tests, TDD etc.), сколько область и способ применения QA инженеров > > (тестеров) в скрам-проектах, или в похожих методологиях: > > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > > другому смотреть на продукт, чем девелопер, и этим он особенно > > полезен. > > - Держать тестеров в скрам-командах или как внешний сервис? Как > > распределять тестовые работы в случае внешнего сервиса? Что считать > > Done? > > - Как распределять тестовые работы в команде в случае, если в ней > > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > > - Как лучше организовать regression testing? Что охватывать, как > > часто? > > - "Процесс тестирования"? Как формулировать в условиях скрама, и > > нужно ли? Как пересекать его со спринтами?
> > Естественно, у меня есть свои решения по каждому из вопросов для > > текущего проекта, но с точки зрения "самоучки" и опыта "классической" > > разработки, на уровне здравого смысла. Хотелось бы почитать советы > > людей с достаточным опытом и в скраме, и в тестировании.
> > Может быть, нам стоит заострить эту тему на следующем agile gathering?
Еще добавлю следующее - в ответ на оригинальный вопрос Юрия:
1) Наличие QA в команде полезно. При этом роль QA в аджайл проекте сплетается с ролью бизнес аналитика. 2) Тестеры (QA) с моей точки зрения, должны быть частью команды. (Команда должна брать на себя ответстеность за весь продукт). Возможная дополнительная загрузка - подготовка историй (в том числе и приемочных тестов) на следующую итерацию. 3) Внешнее тестирование - у меня скорее негативный опыт (но это может быть специфической ситуацией проекта, на котором работаю) Проблемы - дополнительные затраты на коммуникация, время реакции (за сколько времени обнаруживаються баги), перебрасывание ответственность на разработчиков или тестеров. 4) Регрессионное тестирование - многоуровневое. Быстрый набор юнит тестов (каждый чекин) на всю новую функциональность, и изменяемую функциональность, которые дополняються интеграционными тестами, проходящими более долго (1-2 раза в день) + дополнительные категории тестов, в зависимости от продукта.
При наличии большого багажа легаси это нужно дополнять ручным тестированием, объем которого постепенно снижать за счет автоматизации, либо создания средств, его ускоряющего.
Я также слышал про варианты на месячный спринт 3 недели разработки + 1 тестирования Третий вариант, который слышал, если цикл тестирования является продолжительным - наличие назависимой команды тестировщиком, которые работают по классическому процессу и выполняют тестирование результатов итерации на следующей итерации(при этом результаты итерации должны быть протестированы командой разработчиков по максимуму). Это имеет смысл если необходимо например проводить нагрузочное тестирование, которое невозможно организовать вследствии длительности в рамках итерации
Также, оценка историй програмистами должна включать в себя все затраты на тестирование.
> Николай, жаль вы не пришли на встречу 9го... :) > Спасибо за ссылки.
> Вот что я думаю про тестирование в Скраме: > ----------
> В книгах по Scrum особо ничего про тестирование не говорится. Даже не > упоминается слово "тестировщик", из чего складывается мнение, что Scrum и QA > несовместимы. > Это не так. В Scrum есть правила, из которых можно сделать необходимые > выводы: > 1. результат каждого спринта должен быть потенциально готов для поставки - > базовое правило > 2. (как следствие из 1) - команда, работающая над проектом, должна быть > полно функциональна, то есть включать всех, чьих работы создают готовый > продукт. > а именно: архитекторов, дизайнеров, программистов, тестировщиков, тех > писателей и т.д. словом всех.
> Следуя этим правилам, можно выработать необходимые проектные правила, > которые позволят достичь целей. > А именно: > - всё тестирование должно проводиться внутри итерации (спринта), так чтобы > по окончании двухнедельного (или какого-то там) цикла все спланированные > части продукта бы (фичи, багфиксы, документация, пакет установки) > - следовать правилу 1 (см выше) нужно, даже если вы поставляете продукт > фактически раз в квартал > - следуя правилу 2, вы, как тестировщики должны быть с программистами, > быть частью команды - активно присутствовать на всех утренних митингах, > сборах по планированию, демонстрациях. > - вы также должны уменьшать "единицу готовой работы", передаваемую от > программиста к тестировщику, давая ответ программистам как можно быстрее (см > на статью Майка Кона http://blog.mountaingoatsoftware.com/?p=11) > - автоматическое тестирование вам очень поможет > - советую добавлять задачи по тестированию в общий пул задач, давая им > оценки, тогда тестирование станет общей заботой > - поможет нахождение в физической близости к программистам (лучше в одном > большом открытом пространстве) > - развешивание графиков с актуальной информацией по статусу > разработки-тестированию-приему тоже поможет очень помочь > -----------------------
> On 10/11/07, Alimenkou Nikolay < lumii.subscri...@gmail.com > wrote:
> > Могу посоветовать пару книг по тестированию, но не все из них касаются > > именно > > Agile подходов:
> > Global Agile Software Development Quality Assurance (Mar 2007) - как > > раз описывает > > подходы в Agile проектах
> > Practical Software Testing - очень понравилась нашим QA, но у самого > > руки не дошли > > потому как книга довольно объемная
> > Software Testing and Analysis: Process, Principles and Techniques > > (Apr. 2007) - описание > > общих принципов и подходов
> > Pragmatic Software Testing: Becoming an Effective and Efficient Test > > Professional (Feb. 2007) - не читал, > > но думаю посмотреть
> > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > понравилась. много интересных идей, > > которые многие знают, но освежить и собрать воедино всегда полезно
> > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > Поскольку тема про Agile Testing успешно превратилась в флейм и на > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > > > толковые книги или ссылки по тестированию в agile проектах, и в > > > особенности в скраме.
> > > Интересуют не столько инженерные практики для программистов (unit > > > tests, TDD etc.), сколько область и способ применения QA инженеров > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > > > другому смотреть на продукт, чем девелопер, и этим он особенно > > > полезен. > > > - Держать тестеров в скрам-командах или как внешний сервис? Как > > > распределять тестовые работы в случае внешнего сервиса? Что считать > > > Done? > > > - Как распределять тестовые работы в команде в случае, если в ней > > > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > > > - Как лучше организовать regression testing? Что охватывать, как > > > часто? > > > - "Процесс тестирования"? Как
> Николай, жаль вы не пришли на встречу 9го... :) > Спасибо за ссылки.
> Вот что я думаю про тестирование в Скраме: > ----------
> В книгах по Scrum особо ничего про тестирование не говорится. Даже не > упоминается слово "тестировщик", из чего складывается мнение, что Scrum и QA > несовместимы. > Это не так. В Scrum есть правила, из которых можно сделать необходимые > выводы: > 1. результат каждого спринта должен быть потенциально готов для поставки - > базовое правило > 2. (как следствие из 1) - команда, работающая над проектом, должна быть > полно функциональна, то есть включать всех, чьих работы создают готовый > продукт. > а именно: архитекторов, дизайнеров, программистов, тестировщиков, тех > писателей и т.д. словом всех.
> Следуя этим правилам, можно выработать необходимые проектные правила, > которые позволят достичь целей. > А именно: > - всё тестирование должно проводиться внутри итерации (спринта), так чтобы > по окончании двухнедельного (или какого-то там) цикла все спланированные > части продукта бы (фичи, багфиксы, документация, пакет установки) > - следовать правилу 1 (см выше) нужно, даже если вы поставляете продукт > фактически раз в квартал > - следуя правилу 2, вы, как тестировщики должны быть с программистами, быть > частью команды - активно присутствовать на всех утренних митингах, сборах по > планированию, демонстрациях. > - вы также должны уменьшать "единицу готовой работы", передаваемую от > программиста к тестировщику, давая ответ программистам как можно быстрее (см > на статью Майка Конаhttp://blog.mountaingoatsoftware.com/?p=11) > - автоматическое тестирование вам очень поможет > - советую добавлять задачи по тестированию в общий пул задач, давая им > оценки, тогда тестирование станет общей заботой > - поможет нахождение в физической близости к программистам (лучше в одном > большом открытом пространстве) > - развешивание графиков с актуальной информацией по статусу > разработки-тестированию-приему тоже поможет очень помочь > -----------------------
> On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> > Могу посоветовать пару книг по тестированию, но не все из них касаются > > именно > > Agile подходов:
> > Global Agile Software Development Quality Assurance (Mar 2007) - как > > раз описывает > > подходы в Agile проектах
> > Practical Software Testing - очень понравилась нашим QA, но у самого > > руки не дошли > > потому как книга довольно объемная
> > Software Testing and Analysis: Process, Principles and Techniques > > (Apr. 2007) - описание > > общих принципов и подходов
> > Pragmatic Software Testing: Becoming an Effective and Efficient Test > > Professional (Feb. 2007) - не читал, > > но думаю посмотреть
> > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > понравилась. много интересных идей, > > которые многие знают, но освежить и собрать воедино всегда полезно
> > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > Поскольку тема про Agile Testing успешно превратилась в флейм и на > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > > > толковые книги или ссылки по тестированию в agile проектах, и в > > > особенности в скраме.
> > > Интересуют не столько инженерные практики для программистов (unit > > > tests, TDD etc.), сколько область и способ применения QA инженеров > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > > > другому смотреть на продукт, чем девелопер, и этим он особенно > > > полезен. > > > - Держать тестеров в скрам-командах или как внешний сервис? Как > > > распределять тестовые работы в случае внешнего сервиса? Что считать > > > Done? > > > - Как распределять тестовые работы в команде в случае, если в ней > > > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > > > - Как лучше организовать regression testing? Что охватывать, как > > > часто? > > > - "Процесс тестирования"? Как формулировать в условиях скрама, и > > > нужно ли? Как пересекать его со спринтами?
> > > Естественно, у меня есть свои решения по каждому из вопросов для > > > текущего проекта, но с точки зрения "самоучки" и опыта "классической" > > > разработки, на уровне здравого смысла. Хотелось бы почитать советы > > > людей с достаточным опытом и в скраме, и в тестировании.
> > > Может быть, нам стоит заострить эту тему на следующем agile gathering?
> Ну вот, дожились! Я был и мы даже знакомились. Я был с Лешей > Солнцевым.
> On Oct 11, 12:01 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > wrote: > > Николай, жаль вы не пришли на встречу 9го... :) > > Спасибо за ссылки.
> > Вот что я думаю про тестирование в Скраме: > > ----------
> > В книгах по Scrum особо ничего про тестирование не говорится. Даже не > > упоминается слово "тестировщик", из чего складывается мнение, что Scrum > и QA > > несовместимы. > > Это не так. В Scrum есть правила, из которых можно сделать необходимые > > выводы: > > 1. результат каждого спринта должен быть потенциально готов для поставки > - > > базовое правило > > 2. (как следствие из 1) - команда, работающая над проектом, должна быть > > полно функциональна, то есть включать всех, чьих работы создают готовый > > продукт. > > а именно: архитекторов, дизайнеров, программистов, тестировщиков, тех > > писателей и т.д. словом всех.
> > Следуя этим правилам, можно выработать необходимые проектные правила, > > которые позволят достичь целей. > > А именно: > > - всё тестирование должно проводиться внутри итерации (спринта), так > чтобы > > по окончании двухнедельного (или какого-то там) цикла все спланированные > > части продукта бы (фичи, багфиксы, документация, пакет установки) > > - следовать правилу 1 (см выше) нужно, даже если вы поставляете продукт > > фактически раз в квартал > > - следуя правилу 2, вы, как тестировщики должны быть с программистами, > быть > > частью команды - активно присутствовать на всех утренних митингах, > сборах по > > планированию, демонстрациях. > > - вы также должны уменьшать "единицу готовой работы", передаваемую от > > программиста к тестировщику, давая ответ программистам как можно быстрее > (см > > на статью Майка Конаhttp://blog.mountaingoatsoftware.com/?p=11) > > - автоматическое тестирование вам очень поможет > > - советую добавлять задачи по тестированию в общий пул задач, давая им > > оценки, тогда тестирование станет общей заботой > > - поможет нахождение в физической близости к программистам (лучше в > одном > > большом открытом пространстве) > > - развешивание графиков с актуальной информацией по статусу > > разработки-тестированию-приему тоже поможет очень помочь > > -----------------------
> > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> > > Могу посоветовать пару книг по тестированию, но не все из них касаются > > > именно > > > Agile подходов:
> > > Global Agile Software Development Quality Assurance (Mar 2007) - как > > > раз описывает > > > подходы в Agile проектах
> > > Practical Software Testing - очень понравилась нашим QA, но у самого > > > руки не дошли > > > потому как книга довольно объемная
> > > Software Testing and Analysis: Process, Principles and Techniques > > > (Apr. 2007) - описание > > > общих принципов и подходов
> > > Pragmatic Software Testing: Becoming an Effective and Efficient Test > > > Professional (Feb. 2007) - не читал, > > > но думаю посмотреть
> > > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > > понравилась. много интересных идей, > > > которые многие знают, но освежить и собрать воедино всегда полезно
> > > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > > Поскольку тема про Agile Testing успешно превратилась в флейм и на > > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > > > > толковые книги или ссылки по тестированию в agile проектах, и в > > > > особенности в скраме.
> > > > Интересуют не столько инженерные практики для программистов (unit > > > > tests, TDD etc.), сколько область и способ применения QA инженеров > > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > > > > другому смотреть на продукт, чем девелопер, и этим он особенно > > > > полезен. > > > > - Держать тестеров в скрам-командах или как внешний сервис? Как > > > > распределять тестовые работы в случае внешнего сервиса? Что считать > > > > Done? > > > > - Как распределять тестовые работы в команде в случае, если в > ней > > > > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > > > > - Как лучше организовать regression testing? Что охватывать, как > > > > часто? > > > > - "Процесс тестирования"? Как формулировать в условиях скрама, и > > > > нужно ли? Как пересекать его со спринтами?
> > > > Естественно, у меня есть свои решения по каждому из вопросов для > > > > текущего проекта, но с точки зрения "самоучки" и опыта > "классической" > > > > разработки, на уровне здравого смысла. Хотелось бы почитать советы > > > > людей с достаточным опытом и в скраме, и в тестировании.
> > > > Может быть, нам стоит заострить эту тему на следующем agile > gathering?
> On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > Ну вот, дожились! Я был и мы даже знакомились. Я был с Лешей > > Солнцевым.
> > On Oct 11, 12:01 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > > wrote: > > > Николай, жаль вы не пришли на встречу 9го... :) > > > Спасибо за ссылки.
> > > Вот что я думаю про тестирование в Скраме: > > > ----------
> > > В книгах по Scrum особо ничего про тестирование не говорится. Даже не > > > упоминается слово "тестировщик", из чего складывается мнение, что Scrum > > и QA > > > несовместимы. > > > Это не так. В Scrum есть правила, из которых можно сделать необходимые > > > выводы: > > > 1. результат каждого спринта должен быть потенциально готов для поставки > > - > > > базовое правило > > > 2. (как следствие из 1) - команда, работающая над проектом, должна быть > > > полно функциональна, то есть включать всех, чьих работы создают готовый > > > продукт. > > > а именно: архитекторов, дизайнеров, программистов, тестировщиков, тех > > > писателей и т.д. словом всех.
> > > Следуя этим правилам, можно выработать необходимые проектные правила, > > > которые позволят достичь целей. > > > А именно: > > > - всё тестирование должно проводиться внутри итерации (спринта), так > > чтобы > > > по окончании двухнедельного (или какого-то там) цикла все спланированные > > > части продукта бы (фичи, багфиксы, документация, пакет установки) > > > - следовать правилу 1 (см выше) нужно, даже если вы поставляете продукт > > > фактически раз в квартал > > > - следуя правилу 2, вы, как тестировщики должны быть с программистами, > > быть > > > частью команды - активно присутствовать на всех утренних митингах, > > сборах по > > > планированию, демонстрациях. > > > - вы также должны уменьшать "единицу готовой работы", передаваемую от > > > программиста к тестировщику, давая ответ программистам как можно быстрее > > (см > > > на статью Майка Конаhttp://blog.mountaingoatsoftware.com/?p=11) > > > - автоматическое тестирование вам очень поможет > > > - советую добавлять задачи по тестированию в общий пул задач, давая им > > > оценки, тогда тестирование станет общей заботой > > > - поможет нахождение в физической близости к программистам (лучше в > > одном > > > большом открытом пространстве) > > > - развешивание графиков с актуальной информацией по статусу > > > разработки-тестированию-приему тоже поможет очень помочь > > > -----------------------
> > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> > > > Могу посоветовать пару книг по тестированию, но не все из них касаются > > > > именно > > > > Agile подходов:
> > > > Global Agile Software Development Quality Assurance (Mar 2007) - как > > > > раз описывает > > > > подходы в Agile проектах
> > > > Practical Software Testing - очень понравилась нашим QA, но у самого > > > > руки не дошли > > > > потому как книга довольно объемная
> > > > Software Testing and Analysis: Process, Principles and Techniques > > > > (Apr. 2007) - описание > > > > общих принципов и подходов
> > > > Pragmatic Software Testing: Becoming an Effective and Efficient Test > > > > Professional (Feb. 2007) - не читал, > > > > но думаю посмотреть
> > > > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > > > понравилась. много интересных идей, > > > > которые многие знают, но освежить и собрать воедино всегда полезно
> > > > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > > > Поскольку тема про Agile Testing успешно превратилась в флейм и на > > > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > > > > > толковые книги или ссылки по тестированию в agile проектах, и в > > > > > особенности в скраме.
> > > > > Интересуют не столько инженерные практики для программистов (unit > > > > > tests, TDD etc.), сколько область и способ применения QA инженеров > > > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > > > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > > > > > другому смотреть на продукт, чем девелопер, и этим он особенно > > > > > полезен. > > > > > - Держать тестеров в скрам-командах или как внешний сервис? Как > > > > > распределять тестовые работы в случае внешнего сервиса? Что считать > > > > > Done? > > > > > - Как распределять тестовые работы в команде в случае, если в > > ней > > > > > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > > > > > - Как лучше организовать regression testing? Что охватывать, как > > > > > часто? > > > > > - "Процесс тестирования"? Как формулировать в условиях скрама, и > > > > > нужно ли? Как пересекать его со спринтами?
> > > > > Естественно, у меня есть свои решения по каждому из вопросов для > > > > > текущего проекта, но с точки зрения "самоучки" и опыта > > "классической" > > > > > разработки, на уровне здравого смысла. Хотелось бы почитать советы > > > > > людей с достаточным опытом и в скраме, и в тестировании.
> > > > > Может быть, нам стоит заострить эту тему на следующем agile > > gathering?
Леше и Сергею - за, по сути, подтверждение взглядов и подходов к проблеме, до которых наша команда сама постепенно дошла и которыми мы успешно пользуемся. Всегда полезно знать, что ты не изобретаешь велосипед и что твой здравый смысл подтверждается "общемировым" опытом.
Николаю - за реальный список книг. Уже качаю электронные версии. Надеюсь, и мне и нашим тестерам найдется что-то интересное.
On 11 Жов, 18:54, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> On Oct 11, 5:07 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > wrote:
> > под псевдонимом? :)
> > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > > Ну вот, дожились! Я был и мы даже знакомились. Я был с Лешей > > > Солнцевым.
> > > On Oct 11, 12:01 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > > > wrote: > > > > Николай, жаль вы не пришли на встречу 9го... :) > > > > Спасибо за ссылки.
> > > > Вот что я думаю про тестирование в Скраме: > > > > ----------
> > > > В книгах по Scrum особо ничего про тестирование не говорится. Даже не > > > > упоминается слово "тестировщик", из чего складывается мнение, что Scrum > > > и QA > > > > несовместимы. > > > > Это не так. В Scrum есть правила, из которых можно сделать необходимые > > > > выводы: > > > > 1. результат каждого спринта должен быть потенциально готов для поставки > > > - > > > > базовое правило > > > > 2. (как следствие из 1) - команда, работающая над проектом, должна быть > > > > полно функциональна, то есть включать всех, чьих работы создают готовый > > > > продукт. > > > > а именно: архитекторов, дизайнеров, программистов, тестировщиков, тех > > > > писателей и т.д. словом всех.
> > > > Следуя этим правилам, можно выработать необходимые проектные правила, > > > > которые позволят достичь целей. > > > > А именно: > > > > - всё тестирование должно проводиться внутри итерации (спринта), так > > > чтобы > > > > по окончании двухнедельного (или какого-то там) цикла все спланированные > > > > части продукта бы (фичи, багфиксы, документация, пакет установки) > > > > - следовать правилу 1 (см выше) нужно, даже если вы поставляете продукт > > > > фактически раз в квартал > > > > - следуя правилу 2, вы, как тестировщики должны быть с программистами, > > > быть > > > > частью команды - активно присутствовать на всех утренних митингах, > > > сборах по > > > > планированию, демонстрациях. > > > > - вы также должны уменьшать "единицу готовой работы", передаваемую от > > > > программиста к тестировщику, давая ответ программистам как можно быстрее > > > (см > > > > на статью Майка Конаhttp://blog.mountaingoatsoftware.com/?p=11) > > > > - автоматическое тестирование вам очень поможет > > > > - советую добавлять задачи по тестированию в общий пул задач, давая им > > > > оценки, тогда тестирование станет общей заботой > > > > - поможет нахождение в физической близости к программистам (лучше в > > > одном > > > > большом открытом пространстве) > > > > - развешивание графиков с актуальной информацией по статусу > > > > разработки-тестированию-приему тоже поможет очень помочь > > > > -----------------------
> > > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> > > > > Могу посоветовать пару книг по тестированию, но не все из них касаются > > > > > именно > > > > > Agile подходов:
> > > > > Global Agile Software Development Quality Assurance (Mar 2007) - как > > > > > раз описывает > > > > > подходы в Agile проектах
> > > > > Practical Software Testing - очень понравилась нашим QA, но у самого > > > > > руки не дошли > > > > > потому как книга довольно объемная
> > > > > Software Testing and Analysis: Process, Principles and Techniques > > > > > (Apr. 2007) - описание > > > > > общих принципов и подходов
> > > > > Pragmatic Software Testing: Becoming an Effective and Efficient Test > > > > > Professional (Feb. 2007) - не читал, > > > > > но думаю посмотреть
> > > > > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > > > > понравилась. много интересных идей, > > > > > которые многие знают, но освежить и собрать воедино всегда полезно
> > > > > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > > > > Поскольку тема про Agile Testing успешно превратилась в флейм и на > > > > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > > > > > > толковые книги или ссылки по тестированию в agile проектах, и в > > > > > > особенности в скраме.
> > > > > > Интересуют не столько инженерные практики для программистов (unit > > > > > > tests, TDD etc.), сколько область и способ применения QA инженеров > > > > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > > > > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > > > > > > другому смотреть на продукт, чем девелопер, и этим он особенно > > > > > > полезен. > > > > > > - Держать тестеров в скрам-командах или как внешний сервис? Как > > > > > > распределять тестовые работы в случае внешнего сервиса? Что считать > > > > > > Done? > > > > > > - Как распределять тестовые работы в команде в случае, если в > > > ней > > > > > > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > > > > > > - Как лучше организовать regression testing? Что охватывать, как > > > > > > часто? > > > > > > - "Процесс тестирования"? Как формулировать в условиях скрама, и > > > > > > нужно ли? Как пересекать его со спринтами?
> > > > > > Естественно, у меня есть свои решения по каждому из вопросов для > > > > > > текущего проекта, но с точки зрения "самоучки" и опыта > > > "классической" > > > > > > разработки, на уровне здравого смысла. Хотелось бы почитать советы > > > > > > людей с достаточным опытом и в скраме, и в тестировании.
> > > > > > Может быть, нам стоит заострить эту тему на следующем agile > > > gathering?- Сховати цитований текст -
Да, и Леше отдельная благодарность за ссылку на блог Майка Кона. Там новой инфы немного, но по крайней мере я буду знать кого и где переспросить, если сформулирую свои вопросы конкретнее.
On 15 Жов, 22:16, Yuriy Mann <yurym...@gmail.com> wrote:
> Леше и Сергею - за, по сути, подтверждение взглядов и подходов к > проблеме, до которых наша команда сама постепенно дошла и которыми мы > успешно пользуемся. Всегда полезно знать, что ты не изобретаешь > велосипед и что твой здравый смысл подтверждается "общемировым" > опытом.
> Николаю - за реальный список книг. Уже качаю электронные версии. > Надеюсь, и мне и нашим тестерам найдется что-то интересное.
> On 11 Жов, 18:54, Alimenkou Nikolay <lumii.subscri...@gmail.com> > wrote:
> > Да нет, я и представился как Николай...
> > On Oct 11, 5:07 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > > wrote:
> > > под псевдонимом? :)
> > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > > > Ну вот, дожились! Я был и мы даже знакомились. Я был с Лешей > > > > Солнцевым.
> > > > On Oct 11, 12:01 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > > > > wrote: > > > > > Николай, жаль вы не пришли на встречу 9го... :) > > > > > Спасибо за ссылки.
> > > > > Вот что я думаю про тестирование в Скраме: > > > > > ----------
> > > > > В книгах по Scrum особо ничего про тестирование не говорится. Даже не > > > > > упоминается слово "тестировщик", из чего складывается мнение, что Scrum > > > > и QA > > > > > несовместимы. > > > > > Это не так. В Scrum есть правила, из которых можно сделать необходимые > > > > > выводы: > > > > > 1. результат каждого спринта должен быть потенциально готов для поставки > > > > - > > > > > базовое правило > > > > > 2. (как следствие из 1) - команда, работающая над проектом, должна быть > > > > > полно функциональна, то есть включать всех, чьих работы создают готовый > > > > > продукт. > > > > > а именно: архитекторов, дизайнеров, программистов, тестировщиков, тех > > > > > писателей и т.д. словом всех.
> > > > > Следуя этим правилам, можно выработать необходимые проектные правила, > > > > > которые позволят достичь целей. > > > > > А именно: > > > > > - всё тестирование должно проводиться внутри итерации (спринта), так > > > > чтобы > > > > > по окончании двухнедельного (или какого-то там) цикла все спланированные > > > > > части продукта бы (фичи, багфиксы, документация, пакет установки) > > > > > - следовать правилу 1 (см выше) нужно, даже если вы поставляете продукт > > > > > фактически раз в квартал > > > > > - следуя правилу 2, вы, как тестировщики должны быть с программистами, > > > > быть > > > > > частью команды - активно присутствовать на всех утренних митингах, > > > > сборах по > > > > > планированию, демонстрациях. > > > > > - вы также должны уменьшать "единицу готовой работы", передаваемую от > > > > > программиста к тестировщику, давая ответ программистам как можно быстрее > > > > (см > > > > > на статью Майка Конаhttp://blog.mountaingoatsoftware.com/?p=11) > > > > > - автоматическое тестирование вам очень поможет > > > > > - советую добавлять задачи по тестированию в общий пул задач, давая им > > > > > оценки, тогда тестирование станет общей заботой > > > > > - поможет нахождение в физической близости к программистам (лучше в > > > > одном > > > > > большом открытом пространстве) > > > > > - развешивание графиков с актуальной информацией по статусу > > > > > разработки-тестированию-приему тоже поможет очень помочь > > > > > -----------------------
> > > > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > wrote:
> > > > > > Могу посоветовать пару книг по тестированию, но не все из них касаются > > > > > > именно > > > > > > Agile подходов:
> > > > > > Global Agile Software Development Quality Assurance (Mar 2007) - как > > > > > > раз описывает > > > > > > подходы в Agile проектах
> > > > > > Practical Software Testing - очень понравилась нашим QA, но у самого > > > > > > руки не дошли > > > > > > потому как книга довольно объемная
> > > > > > Software Testing and Analysis: Process, Principles and Techniques > > > > > > (Apr. 2007) - описание > > > > > > общих принципов и подходов
> > > > > > Pragmatic Software Testing: Becoming an Effective and Efficient Test > > > > > > Professional (Feb. 2007) - не читал, > > > > > > но думаю посмотреть
> > > > > > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > > > > > понравилась. много интересных идей, > > > > > > которые многие знают, но освежить и собрать воедино всегда полезно
> > > > > > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > > > > > Поскольку тема про Agile Testing успешно превратилась в флейм и на > > > > > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, пожалуйста, > > > > > > > толковые книги или ссылки по тестированию в agile проектах, и в > > > > > > > особенности в скраме.
> > > > > > > Интересуют не столько инженерные практики для программистов (unit > > > > > > > tests, TDD etc.), сколько область и способ применения QA инженеров > > > > > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > > > > > - Нужны ли тестеры вообще? Считается, что тестер всегда будет по > > > > > > > другому смотреть на продукт, чем девелопер, и этим он особенно > > > > > > > полезен. > > > > > > > - Держать тестеров в скрам-командах или как внешний сервис? Как > > > > > > > распределять тестовые работы в случае внешнего сервиса? Что считать > > > > > > > Done? > > > > > > > - Как распределять тестовые работы в команде в случае, если в > > > > ней > > > > > > > есть тестеры? Как "ровно" загрузить тестера на протяжении спринта? > > > > > > > - Как лучше организовать regression testing? Что охватывать, как > > > > > > > часто? > > > > > > > - "Процесс тестирования"? Как формулировать в условиях скрама, и > > > > > > > нужно ли? Как пересекать его со спринтами?
> > > > > > > Естественно, у меня есть свои решения по каждому из вопросов для > > > > > > > текущего проекта, но с точки зрения "самоучки" и опыта > > > > "классической" > > > > > > > разработки, на уровне здравого смысла. Хотелось бы почитать советы > > > > > > > людей с достаточным опытом и в скраме, и в тестировании.
> > > > > > > Может быть, нам стоит заострить эту тему на следующем agile > > > > gathering?- Сховати цитований текст -
> > - Показати цитований текст -- Сховати цитований текст -
мы с Тимом читали семинар по Скраму недавно в Харькове для группы, где было порядком тестировщиков, и получили кое-какие озарения. попробуем оформить в виде статьи и поделиться.
леша.
On 10/15/07, Yuriy Mann <yurym...@gmail.com> wrote:
> Да, и Леше отдельная благодарность за ссылку на блог Майка Кона. Там > новой инфы немного, но по крайней мере я буду знать кого и где > переспросить, если сформулирую свои вопросы конкретнее.
> On 15 Жов, 22:16, Yuriy Mann <yurym...@gmail.com> wrote: > > Спасибо всем ответившим!
> > Леше и Сергею - за, по сути, подтверждение взглядов и подходов к > > проблеме, до которых наша команда сама постепенно дошла и которыми мы > > успешно пользуемся. Всегда полезно знать, что ты не изобретаешь > > велосипед и что твой здравый смысл подтверждается "общемировым" > > опытом.
> > Николаю - за реальный список книг. Уже качаю электронные версии. > > Надеюсь, и мне и нашим тестерам найдется что-то интересное.
> > On 11 Жов, 18:54, Alimenkou Nikolay <lumii.subscri...@gmail.com> > > wrote:
> > > Да нет, я и представился как Николай...
> > > On Oct 11, 5:07 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > > > wrote:
> > > > под псевдонимом? :)
> > > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > > > > Ну вот, дожились! Я был и мы даже знакомились. Я был с Лешей > > > > > Солнцевым.
> > > > > On Oct 11, 12:01 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com
> > > > > wrote: > > > > > > Николай, жаль вы не пришли на встречу 9го... :) > > > > > > Спасибо за ссылки.
> > > > > > Вот что я думаю про тестирование в Скраме: > > > > > > ----------
> > > > > > В книгах по Scrum особо ничего про тестирование не говорится. > Даже не > > > > > > упоминается слово "тестировщик", из чего складывается мнение, > что Scrum > > > > > и QA > > > > > > несовместимы. > > > > > > Это не так. В Scrum есть правила, из которых можно сделать > необходимые > > > > > > выводы: > > > > > > 1. результат каждого спринта должен быть потенциально готов для > поставки > > > > > - > > > > > > базовое правило > > > > > > 2. (как следствие из 1) - команда, работающая над проектом, > должна быть > > > > > > полно функциональна, то есть включать всех, чьих работы создают > готовый > > > > > > продукт. > > > > > > а именно: архитекторов, дизайнеров, программистов, > тестировщиков, тех > > > > > > писателей и т.д. словом всех.
> > > > > > Следуя этим правилам, можно выработать необходимые проектные > правила, > > > > > > которые позволят достичь целей. > > > > > > А именно: > > > > > > - всё тестирование должно проводиться внутри итерации (спринта), > так > > > > > чтобы > > > > > > по окончании двухнедельного (или какого-то там) цикла все > спланированные > > > > > > части продукта бы (фичи, багфиксы, документация, пакет > установки) > > > > > > - следовать правилу 1 (см выше) нужно, даже если вы поставляете > продукт > > > > > > фактически раз в квартал > > > > > > - следуя правилу 2, вы, как тестировщики должны быть с > программистами, > > > > > быть > > > > > > частью команды - активно присутствовать на всех утренних > митингах, > > > > > сборах по > > > > > > планированию, демонстрациях. > > > > > > - вы также должны уменьшать "единицу готовой работы", > передаваемую от > > > > > > программиста к тестировщику, давая ответ программистам как можно > быстрее > > > > > (см > > > > > > на статью Майка Конаhttp://blog.mountaingoatsoftware.com/?p=11) > > > > > > - автоматическое тестирование вам очень поможет > > > > > > - советую добавлять задачи по тестированию в общий пул задач, > давая им > > > > > > оценки, тогда тестирование станет общей заботой > > > > > > - поможет нахождение в физической близости к программистам > (лучше в > > > > > одном > > > > > > большом открытом пространстве) > > > > > > - развешивание графиков с актуальной информацией по статусу > > > > > > разработки-тестированию-приему тоже поможет очень помочь > > > > > > -----------------------
> > > > > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > > wrote:
> > > > > > > Могу посоветовать пару книг по тестированию, но не все из них > касаются > > > > > > > именно > > > > > > > Agile подходов:
> > > > > > > Global Agile Software Development Quality Assurance (Mar 2007) > - как > > > > > > > раз описывает > > > > > > > подходы в Agile проектах
> > > > > > > Practical Software Testing - очень понравилась нашим QA, но у > самого > > > > > > > руки не дошли > > > > > > > потому как книга довольно объемная
> > > > > > > Software Testing and Analysis: Process, Principles and > Techniques > > > > > > > (Apr. 2007) - описание > > > > > > > общих принципов и подходов
> > > > > > > Pragmatic Software Testing: Becoming an Effective and > Efficient Test > > > > > > > Professional (Feb. 2007) - не читал, > > > > > > > но думаю посмотреть
> > > > > > > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > > > > > > понравилась. много интересных идей, > > > > > > > которые многие знают, но освежить и собрать воедино всегда > полезно
> > > > > > > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > > > > > > Поскольку тема про Agile Testing успешно превратилась в > флейм и на > > > > > > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, > пожалуйста, > > > > > > > > толковые книги или ссылки по тестированию в agile проектах, > и в > > > > > > > > особенности в скраме.
> > > > > > > > Интересуют не столько инженерные практики для программистов > (unit > > > > > > > > tests, TDD etc.), сколько область и способ применения QA > инженеров > > > > > > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > > > > > > - Нужны ли тестеры вообще? Считается, что тестер всегда > будет по > > > > > > > > другому смотреть на продукт, чем девелопер, и этим он > особенно > > > > > > > > полезен. > > > > > > > > - Держать тестеров в скрам-командах или как внешний > сервис? Как > > > > > > > > распределять тестовые работы в случае внешнего сервиса? Что > считать > > > > > > > > Done? > > > > > > > > - Как распределять тестовые работы в команде в случае, > если в > > > > > ней > > > > > > > > есть тестеры? Как "ровно" загрузить тестера на протяжении > спринта? > > > > > > > > - Как лучше организовать regression testing? Что > охватывать, как > > > > > > > > часто? > > > > > > > > - "Процесс тестирования"? Как формулировать в условиях > скрама, и > > > > > > > > нужно ли? Как пересекать его со спринтами?
> > > > > > > > Естественно, у меня есть свои решения по каждому из
> мы с Тимом читали семинар по Скраму недавно в Харькове для группы, где было > порядком тестировщиков, и получили кое-какие озарения. попробуем оформить в > виде статьи и поделиться.
> леша.
> On 10/15/07, Yuriy Mann <yurym...@gmail.com> wrote:
> > Да, и Леше отдельная благодарность за ссылку на блог Майка Кона. Там > > новой инфы немного, но по крайней мере я буду знать кого и где > > переспросить, если сформулирую свои вопросы конкретнее.
> > On 15 Жов, 22:16, Yuriy Mann <yurym...@gmail.com> wrote: > > > Спасибо всем ответившим!
> > > Леше и Сергею - за, по сути, подтверждение взглядов и подходов к > > > проблеме, до которых наша команда сама постепенно дошла и которыми мы > > > успешно пользуемся. Всегда полезно знать, что ты не изобретаешь > > > велосипед и что твой здравый смысл подтверждается "общемировым" > > > опытом.
> > > Николаю - за реальный список книг. Уже качаю электронные версии. > > > Надеюсь, и мне и нашим тестерам найдется что-то интересное.
> > > On 11 Жов, 18:54, Alimenkou Nikolay <lumii.subscri...@gmail.com> > > > wrote:
> > > > Да нет, я и представился как Николай...
> > > > On Oct 11, 5:07 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > > > > wrote:
> > > > > под псевдонимом? :)
> > > > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com> wrote:
> > > > > > Ну вот, дожились! Я был и мы даже знакомились. Я был с Лешей > > > > > > Солнцевым.
> > > > > > On Oct 11, 12:01 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com
> > > > > > wrote: > > > > > > > Николай, жаль вы не пришли на встречу 9го... :) > > > > > > > Спасибо за ссылки.
> > > > > > > Вот что я думаю про тестирование в Скраме: > > > > > > > ----------
> > > > > > > В книгах по Scrum особо ничего про тестирование не говорится. > > Даже не > > > > > > > упоминается слово "тестировщик", из чего складывается мнение, > > что Scrum > > > > > > и QA > > > > > > > несовместимы. > > > > > > > Это не так. В Scrum есть правила, из которых можно сделать > > необходимые > > > > > > > выводы: > > > > > > > 1. результат каждого спринта должен быть потенциально готов для > > поставки > > > > > > - > > > > > > > базовое правило > > > > > > > 2. (как следствие из 1) - команда, работающая над проектом, > > должна быть > > > > > > > полно функциональна, то есть включать всех, чьих работы создают > > готовый > > > > > > > продукт. > > > > > > > а именно: архитекторов, дизайнеров, программистов, > > тестировщиков, тех > > > > > > > писателей и т.д. словом всех.
> > > > > > > Следуя этим правилам, можно выработать необходимые проектные > > правила, > > > > > > > которые позволят достичь целей. > > > > > > > А именно: > > > > > > > - всё тестирование должно проводиться внутри итерации (спринта), > > так > > > > > > чтобы > > > > > > > по окончании двухнедельного (или какого-то там) цикла все > > спланированные > > > > > > > части продукта бы (фичи, багфиксы, документация, пакет > > установки) > > > > > > > - следовать правилу 1 (см выше) нужно, даже если вы поставляете > > продукт > > > > > > > фактически раз в квартал > > > > > > > - следуя правилу 2, вы, как тестировщики должны быть с > > программистами, > > > > > > быть > > > > > > > частью команды - активно присутствовать на всех утренних > > митингах, > > > > > > сборах по > > > > > > > планированию, демонстрациях. > > > > > > > - вы также должны уменьшать "единицу готовой работы", > > передаваемую от > > > > > > > программиста к тестировщику, давая ответ программистам как можно > > быстрее > > > > > > (см > > > > > > > на статью Майка Конаhttp://blog.mountaingoatsoftware.com/?p=11) > > > > > > > - автоматическое тестирование вам очень поможет > > > > > > > - советую добавлять задачи по тестированию в общий пул задач, > > давая им > > > > > > > оценки, тогда тестирование станет общей заботой > > > > > > > - поможет нахождение в физической близости к программистам > > (лучше в > > > > > > одном > > > > > > > большом открытом пространстве) > > > > > > > - развешивание графиков с актуальной информацией по статусу > > > > > > > разработки-тестированию-приему тоже поможет очень помочь > > > > > > > -----------------------
> > > > > > > On 10/11/07, Alimenkou Nikolay <lumii.subscri...@gmail.com > > > wrote:
> > > > > > > > Могу посоветовать пару книг по тестированию, но не все из них > > касаются > > > > > > > > именно > > > > > > > > Agile подходов:
> > > > > > > > Global Agile Software Development Quality Assurance (Mar 2007) > > - как > > > > > > > > раз описывает > > > > > > > > подходы в Agile проектах
> > > > > > > > Practical Software Testing - очень понравилась нашим QA, но у > > самого > > > > > > > > руки не дошли > > > > > > > > потому как книга довольно объемная
> > > > > > > > Software Testing and Analysis: Process, Principles and > > Techniques > > > > > > > > (Apr. 2007) - описание > > > > > > > > общих принципов и подходов
> > > > > > > > Pragmatic Software Testing: Becoming an Effective and > > Efficient Test > > > > > > > > Professional (Feb. 2007) - не читал, > > > > > > > > но думаю посмотреть
> > > > > > > > Software Testing (Jul. 2007) - книга далека от Agile, но очень > > > > > > > > понравилась. много интересных идей, > > > > > > > > которые многие знают, но освежить и собрать воедино всегда > > полезно
> > > > > > > > On Oct 11, 5:21 am, Yuriy Mann <yurym...@gmail.com> wrote: > > > > > > > > > Поскольку тема про Agile Testing успешно превратилась в > > флейм и на > > > > > > > > > этом скончалась, я попытался сузить вопрос. Посоветуйте, > > пожалуйста, > > > > > > > > > толковые книги или ссылки по тестированию в agile проектах, > > и в > > > > > > > > > особенности в скраме.
> > > > > > > > > Интересуют не столько инженерные практики для программистов > > (unit > > > > > > > > > tests, TDD etc.), сколько область и способ применения QA > > инженеров > > > > > > > > > (тестеров) в скрам-проектах, или в похожих методологиях: > > > > > > > > > - Нужны ли тестеры вообще? Считается, что тестер всегда > > будет по > > > > > > > > > другому смотреть на продукт, чем девелопер, и этим он > > особенно > > > > > > > > > полезен. > > > > > > > > > - Держать тестеров в скрам-командах или как внешний > > сервис? Как > > > > > > > > > распределять тестовые работы в случае внешнего сервиса? Что > > считать > > > > > > > > > Done? > > > > > > > > > - Как распределять тестовые работы в команде в случае, > > если в > > > > > > ней > > > > > > > > > есть тестеры? Как "ровно" загрузить тестера на протяжении > > спринта? > > > > > > > > > - Как лучше организовать regression testing? Что > > охватывать, как > > > > > > > > > часто?
