24 октября, Москва, тренинг "Тестирование методом свободного поис

24 октября Алексей Баранцев проводит открытый однодневный тренинг "Тестирование методом свободного поиска (exploratory testing)".

В отличие от семинаров, тренинг – это активная форма обучения, нацеленная на формирование или закрепление у слушателей определённых практических навыков. Информация передаётся в ограниченном количестве, достаточном для усвоения навыков. Преподаватель рассказывает относительно мало, в основном используются активные методы, индивидуальная, групповая и коллективная работа.
Тестирование методом свободного поиска (exploratory testing)
Программа тренинга

1. Различные парадигмы тестирования -- почему они существуют и каковы практические последствия этого.
2. Метафора "The touring test". Построение карты приложения. Выбор "туров".
3. Концепция "сеанса тестирования". Первый практический сеанс и разбор полётов.
4. Парное тестирование. Второй практический сеанс.
5. Метод "шести шляп" де Боно. Третий практический сеанс.
6. Регрессионное тестирование методом свободного поиска. Четвёртый практический сеанс.
7. Автоматизация и тестирование методом свободного поиска -- друзья или враги? Пятый практический сеанс.
8. Особенности взаимоотношения с коллегами и начальством -- как им объяснить, "чем это вы тут занимаетесь"?

Условия участия

А где-нибудь можно посмотрить тезисы по этой теме?
Меня она очень заинтересовала :-)

7. Автоматизация и тестирование методом свободного поиска -- друзья или враги? Пятый практический сеанс.

Не получилось потому, что не умели? :-)

4. Парное тестирование. Второй практический сеанс.

"И тут мы подходим к такой проблеме: agile придумали программисты для программистов. И они придумали для себя много фановых штучек, практик. Они придумали парное программирование. Тестировщики потом как-то попытались делать парное тестирование — не получилось. А парное программирование работает хорошо."

http://testitquickly...santa-in-agile/

А где-нибудь можно посмотрить тезисы по этой теме?
Меня она очень заинтересовала :-)

7. Автоматизация и тестирование методом свободного поиска -- друзья или враги? Пятый практический сеанс.

Буквально только что Болтон написал отличную заметку "Testing vs Cheсking", которая проливает некоторый свет на эту тему.

Автоматизировать можно не только checking, но и testing.

Автоматизация -- это не только регрессионные тесты, не только стодвадцатьпятая проверка того, что уже стодвадцатьчетыре раза проверено.

Testing, то есть поиск новой информации, можно выполнять руками, а можно подключить к этому делу компьютер, и тогда это следует считать автоматизированным тестированием, ну или как минимум computer-aided.

Примеры:
-- тестирование на основе моделей;
-- Pex;
-- статический анализ кода;
-- нефункциональное тестирование, например, защищенности или производительности.

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

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

Не получилось потому, что не умели? :-)

4. Парное тестирование. Второй практический сеанс.

"И тут мы подходим к такой проблеме: agile придумали программисты для программистов. И они придумали для себя много фановых штучек, практик. Они придумали парное программирование. Тестировщики потом как-то попытались делать парное тестирование — не получилось. А парное программирование работает хорошо."

http://testitquickly...santa-in-agile/

Ну, в общем, да :)

Я же написал в предисловии, что "иногда мне очень хотелось возразить или объяснить, что я на самом деле думаю по тому или иному поводу".

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

Но прошёл год, появился новый опыт. Мы в нашей команде опробовали парную работу в режиме сеансового тестирования (session based testing) -- и это оказалось хорошо. Я даже удивляюсь, почему основоположники про это не пишут (ну или я не видел). Хотя сами таки тестируют в парах, как можно судить по их заметкам в блогах и по мастер-классам.

Не получилось потому, что не умели? :-)

Парное тестирование, не знаю как по сравнению с программированием, требует достаточно высокой и примерно равной квалификации. А так - работает, вроде бы.

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

см. книжку Lessons Learned in Software Testing.

Спасибо, заметка занимательная, но слабо помогает решению практической задачи - как повысить качество продукта при известных ограничениях по времени и ресурсам :-)

Под автоматизацией и я понимаю computer-aided.
Но вот опыт у меня от автоматизации без спецификаций скорее негативный.

Буквально только что Болтон написал отличную заметку "Testing vs Cheсking", которая проливает некоторый свет на эту тему.

Автоматизировать можно не только checking, но и testing.

Автоматизация -- это не только регрессионные тесты, не только стодвадцатьпятая проверка того, что уже стодвадцатьчетыре раза проверено.

Testing, то есть поиск новой информации, можно выполнять руками, а можно подключить к этому делу компьютер, и тогда это следует считать автоматизированным тестированием, ну или как минимум computer-aided.

Под автоматизацией и я понимаю computer-aided.
Но вот опыт у меня от автоматизации без спецификаций скорее негативный.

Совершенно необязательно автоматизировать спецификацию.

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

Парное тестирование, не знаю как по сравнению с программированием, требует достаточно высокой и примерно равной квалификации. А так - работает, вроде бы.

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

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

см. книжку Lessons Learned in Software Testing.

Таки пишут :)
А для тех оболтусов, кто подобно мне ещё не купил эту книжку, вот небольшая подборка заметок и презентаций на эту тему: http://www.kohl.ca/b...ves/000027.html

Спасибо, заметка занимательная, но слабо помогает решению практической задачи - как повысить качество продукта при известных ограничениях по времени и ресурсам :-)

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

Под автоматизацией и я понимаю computer-aided.
Но вот опыт у меня от автоматизации без спецификаций скорее негативный.

Кажется мы всё таки разные вещи подразумеваем под автоматизацией. То есть мне всё таки не удалось донести свою мысль.
А мысль очень простая: если мы заставили компьютер добыть для нас какую-то информацию вместо того, чтобы делать это руками -- это автоматизация.
При этом спецификации иногда нужны, а иногда в них нет совершенно никакой необходимости.
Зачем вам спецификация, чтобы искать в веб-приложении SQL-инъекции?
Зачем вам спецификация, чтобы провести статический анализ кода и обнаружить наличие deadlock при определённых условиях?
Зачем вам спецификация, чтобы провести тестирование целостности ссылок в веб-приложении?
Это всё можно сделать автоматически и без всяких спецификаций.
А для каких-то других видов автоматизации спецификации нужны, с этим думаю никто не станет спорить.

И почему вообще возникает эта тема -- со спецификациями и без спецификаций?
Тестирование методом свободного поиска -- это НЕ тестирование без спецификаций!
Это тестирование без заранее заготовленных тестов.
Неужели не видно разницы?

Я имел в виду именно тестовые спецификации.

Кстати, хороший пример "Зачем вам спецификация, чтобы провести тестирование целостности ссылок в веб-приложении?"
Кроме целостности на ссылки могут быть и другие требования. Например, разумная длина или изоляция в определенных разделах сайта.

При этом спецификации иногда нужны, а иногда в них нет совершенно никакой необходимости.
Зачем вам спецификация, чтобы искать в веб-приложении SQL-инъекции?
Зачем вам спецификация, чтобы провести статический анализ кода и обнаружить наличие deadlock при определённых условиях?
Зачем вам спецификация, чтобы провести тестирование целостности ссылок в веб-приложении?
Это всё можно сделать автоматически и без всяких спецификаций.
А для каких-то других видов автоматизации спецификации нужны, с этим думаю никто не станет спорить.

И почему вообще возникает эта тема -- со спецификациями и без спецификаций?
Тестирование методом свободного поиска -- это НЕ тестирование без спецификаций!
Это тестирование без заранее заготовленных тестов.
Неужели не видно разницы?