Май - SQA Days 7
Июнь - Tech Talks in GlobalLogic
Июль - QAClub
Август - ?
вторник, 27 июля 2010 г.
вторник, 20 июля 2010 г.
Выступление на QA Club 23 июля
Выступаю 23 июля на QA Club с темой "Тестирование без требований".
Приходите, поддержите, послушайте.
http://www.qaclub.com.ua/node/80
Подробности взятые с форума QA Club:
"Коллеги, приглашаем Вас на июльскую тусовку QAClub!
Дата: 23 июля 2010 (пятн), Харьков, в 19.30 , место - то же, см. ниже
Тема: Тестирование без требований
О чем поговорим?
Вероятно, многие из нас сталкивались с проектом, где требования были размыты или вовсе отсутствовали. Задумывались ли вы о том, как можно протестировать такой проект? В своем докладе Артем Шаповал расскажет об основных предпосылках к появлению подобной ситуации, опишет ее влияние на процесс тестирования и расскажет, как можно смягчить негативные последствия.
О докладчике:
Артем Шаповал - выступал на конференции SQA Days 7 d Харькове, там мы и познакомились Smile. Опыт - 5 лет в разработке ПО, 2 года как разработчик + 3 года аналитик. Имеет опыт работы как с украинскими заказчиками, так и с иностранными клиентами. Сейчас работает на позиции QA/Risk Analyst в компании GlobalLogic. Имеет несколько сертификатов от ведущих вендоров: Oracle, PMI, IELTS.
Заявки принимаются на info@qaclub.com.ua с пометкой QAClub-July в теме письма. Подробности будут в рассылке и тут, на форуме.
Расписание:
19.30 - регистрация! 19.40 - начало! Актив старается подойти к 19.00, чтобы помочь подготовить зал, за это ему скидки до 100% и моя признательность))!!!
Агенда:
-новости клуба
-доклад
-кофебрейк
-продолжение доклада + вопросы/ответы
21.30 - 22.00- планируется окончание мероприятия
Формат: доклад, где-то посредине доклада сделаем перерыв с чаем-кофеем и плюшками, свободное общение, потом - окончание доклада и вопросы зала, опять чай-кофе для самых стойких.
Место:
ул. Сумская, 90, мед центр "Эввива" (бывший Небосвод), ст.м. Университет (выход "стекляшка"), и по Сумской вверх минут 5-7, не доходя до дворца бракосочетания, по правую руку увидите небольшое здание с колоннами и елками, на здании написано - Эввива. Внутри здания - будем в актовом зале на 2 этаже названном тематически "конференцзал" - там, где была встреча с Тимуром Хайруллиным и Сашей Орловым и т.п.
Стоимость: оргвзнос 50 грн, активу – скидки до 100%!!
Напоминаю!! - кто регистрируется, а потом не сможет быть - заранее сообщите плз, а то внесем Вас в черный список, сколько ж можно печенье за Вас доедать, актив теряет форму, не говоря уже об организаторах))."
Приходите, поддержите, послушайте.
http://www.qaclub.com.ua/node/80
Подробности взятые с форума QA Club:
"Коллеги, приглашаем Вас на июльскую тусовку QAClub!
Дата: 23 июля 2010 (пятн), Харьков, в 19.30 , место - то же, см. ниже
Тема: Тестирование без требований
О чем поговорим?
Вероятно, многие из нас сталкивались с проектом, где требования были размыты или вовсе отсутствовали. Задумывались ли вы о том, как можно протестировать такой проект? В своем докладе Артем Шаповал расскажет об основных предпосылках к появлению подобной ситуации, опишет ее влияние на процесс тестирования и расскажет, как можно смягчить негативные последствия.
О докладчике:
Артем Шаповал - выступал на конференции SQA Days 7 d Харькове, там мы и познакомились Smile. Опыт - 5 лет в разработке ПО, 2 года как разработчик + 3 года аналитик. Имеет опыт работы как с украинскими заказчиками, так и с иностранными клиентами. Сейчас работает на позиции QA/Risk Analyst в компании GlobalLogic. Имеет несколько сертификатов от ведущих вендоров: Oracle, PMI, IELTS.
Заявки принимаются на info@qaclub.com.ua с пометкой QAClub-July в теме письма. Подробности будут в рассылке и тут, на форуме.
Расписание:
19.30 - регистрация! 19.40 - начало! Актив старается подойти к 19.00, чтобы помочь подготовить зал, за это ему скидки до 100% и моя признательность))!!!
Агенда:
-новости клуба
-доклад
-кофебрейк
-продолжение доклада + вопросы/ответы
21.30 - 22.00- планируется окончание мероприятия
Формат: доклад, где-то посредине доклада сделаем перерыв с чаем-кофеем и плюшками, свободное общение, потом - окончание доклада и вопросы зала, опять чай-кофе для самых стойких.
Место:
ул. Сумская, 90, мед центр "Эввива" (бывший Небосвод), ст.м. Университет (выход "стекляшка"), и по Сумской вверх минут 5-7, не доходя до дворца бракосочетания, по правую руку увидите небольшое здание с колоннами и елками, на здании написано - Эввива. Внутри здания - будем в актовом зале на 2 этаже названном тематически "конференцзал" - там, где была встреча с Тимуром Хайруллиным и Сашей Орловым и т.п.
Стоимость: оргвзнос 50 грн, активу – скидки до 100%!!
Напоминаю!! - кто регистрируется, а потом не сможет быть - заранее сообщите плз, а то внесем Вас в черный список, сколько ж можно печенье за Вас доедать, актив теряет форму, не говоря уже об организаторах))."
среда, 7 июля 2010 г.
Исследовательское (exploratory) тестирование: преимущества и недостатки
Также в книге «A Practitioner's Guide to Software Test Design» by Lee Copeland (http://www.amazon.com/Practitioners-Guide-Software-Test-Design/dp/158053791X) есть сравнение преимуществ и недостатков исследовательского (exploratory) тестирования.
Приведу примеры из книги.
Преимущества исследовательского тестирования
1. Исследовательское тестированно ценно в ситуациях, когда выбор следующего тест кейса не может быть определен заранее, а базируется на предыдущих тестах и их результатах.
2. Исследовательское тестирование полезно, когда необходимо дать небольшой отзыв на качество продукта, в ограниченное время, когда требования неточны или отсутствуют вовсе, или на ранних стадиях разработки, когда система может быть нестабильной.
3. Исследовательское тестирование полезно, когда дефект найден и мы хотим исследовать размер, область и вариации дефекта для предоставления лучшего описания для команды разработчиков.
4. Исследовательское тестирование полезно как дополнение к формализованному тестированию, когда формализованные тесты становятся «утомительными» и не находят много ошибок.
Недостатки исследовательского тестирования
1. При исследовательском тестировании нет возможности предотвращать появление дефектов. Из-за того, что проектирование формализованных тест кейсов начинается на стадии сбора требований, дефекты могут быть найдены и исправлены ранее.
2. Если Вы полностью уверены, какие тесты необходимо запускать и в какой последовательности, нет необходимости проводить исследование. Пишите, а затем выполняйте формализованные тесты.
3. Если Вы обязаны по контракту или правилу использовать формализованное тестирование, то так и делайте. Попробуйте добавить исследовательское тестирование в качестве дополнительного метода.
Приведу примеры из книги.
Преимущества исследовательского тестирования
1. Исследовательское тестированно ценно в ситуациях, когда выбор следующего тест кейса не может быть определен заранее, а базируется на предыдущих тестах и их результатах.
2. Исследовательское тестирование полезно, когда необходимо дать небольшой отзыв на качество продукта, в ограниченное время, когда требования неточны или отсутствуют вовсе, или на ранних стадиях разработки, когда система может быть нестабильной.
3. Исследовательское тестирование полезно, когда дефект найден и мы хотим исследовать размер, область и вариации дефекта для предоставления лучшего описания для команды разработчиков.
4. Исследовательское тестирование полезно как дополнение к формализованному тестированию, когда формализованные тесты становятся «утомительными» и не находят много ошибок.
Недостатки исследовательского тестирования
1. При исследовательском тестировании нет возможности предотвращать появление дефектов. Из-за того, что проектирование формализованных тест кейсов начинается на стадии сбора требований, дефекты могут быть найдены и исправлены ранее.
2. Если Вы полностью уверены, какие тесты необходимо запускать и в какой последовательности, нет необходимости проводить исследование. Пишите, а затем выполняйте формализованные тесты.
3. Если Вы обязаны по контракту или правилу использовать формализованное тестирование, то так и делайте. Попробуйте добавить исследовательское тестирование в качестве дополнительного метода.
пятница, 2 июля 2010 г.
Формализованное (scripted) тестирование: преимущества и недостатки
Недавно прочитал книгу «A Practitioner's Guide to Software Test Design» by Lee Copeland (http://www.amazon.com/Practitioners-Guide-Software-Test-Design/dp/158053791X ) очень понравилось четкое определение преимуществ и недостатков формализованного (scripted) тестирования.
Приведу примеры из книги .
Преимущества:
1. Формализованное тестирование обеспечивает разделение работ – планирование, проектирование, разработка и выполнение тест кейсов может быть выполнено людьми со специфическими навыками и в различное время на протяжении процесса разработки.
2. Техники тестирования, такие как разбиение на классы эквивалентности, тестирование граничных условий, тестирование потока данных, парное тестирование и т.д. могут быть интегрированы непосредственно в процесс тестирования и использоваться для проверки соблюдения процессов.
3. Из-за того, что формализованные тесты созданы из требований, дизайна и кода, все важные атрибуты системы покрываются тестами и это покрытие можно продемонстрировать.
4. Из-за того, что тест кейсы можно однозначно отлинковать к требованиям, покрытие дизайна и кода может быть легко определено и измерено.
5. Из-за того что тесты детализированы, они легче поддаются автоматизации.
6. Из-за того, что тесты создаются на ранних этапах в процессе разработке, это позволяет высвободить дополнительно время в критический период выполнения тестирования.
7. В ситуациях, когда отсутствует хорошая спецификация требований, тест кейсы по окончанию проекта становятся де-факто спецификацией требований, включая также фактические результаты выполнения тестирования.
8. Формализованные тесты, которые написанные с достаточным уровнем детализации, могут быть выполнены людьми, которые не обладают достаточными знаниями в предметной области или в тестировании программного обеспечения.
9. Путем создания тестов на ранних этапах проекта мы можем обнаружить неисследованные ранее области.
Недостатки:
1. Формализованное тестирование напрямую зависит от качества требований. Были ли требования действительно завершенными, стабильными и однозначными, когда они брались за основу для формализованного тестирования? Вряд ли.
2. Формализованное тестирование, по своему определению, не гибкое. Оно всегда следует согласно запланированному перечню действий (скрипту). Если, во время тестирования, мы увидим что-то странное, мы сделаем заметку, но не будем продолжать «копать» в этом направление. Почему? Из-за того, что этого нет в скрипте. Множество интересных дефектов могут быть пропущены при использовании данного подхода.
3. Формализованное тестирование часто используется для снижения роли тестировщика. Данный подход можно описать как «Научи тестировщика выполнять один вид тестов и отправь его тестировать гору тестов. Из-за большого количества тестов, мы вероятно найдем большинство дефектов»
Приведу примеры из книги .
Преимущества:
1. Формализованное тестирование обеспечивает разделение работ – планирование, проектирование, разработка и выполнение тест кейсов может быть выполнено людьми со специфическими навыками и в различное время на протяжении процесса разработки.
2. Техники тестирования, такие как разбиение на классы эквивалентности, тестирование граничных условий, тестирование потока данных, парное тестирование и т.д. могут быть интегрированы непосредственно в процесс тестирования и использоваться для проверки соблюдения процессов.
3. Из-за того, что формализованные тесты созданы из требований, дизайна и кода, все важные атрибуты системы покрываются тестами и это покрытие можно продемонстрировать.
4. Из-за того, что тест кейсы можно однозначно отлинковать к требованиям, покрытие дизайна и кода может быть легко определено и измерено.
5. Из-за того что тесты детализированы, они легче поддаются автоматизации.
6. Из-за того, что тесты создаются на ранних этапах в процессе разработке, это позволяет высвободить дополнительно время в критический период выполнения тестирования.
7. В ситуациях, когда отсутствует хорошая спецификация требований, тест кейсы по окончанию проекта становятся де-факто спецификацией требований, включая также фактические результаты выполнения тестирования.
8. Формализованные тесты, которые написанные с достаточным уровнем детализации, могут быть выполнены людьми, которые не обладают достаточными знаниями в предметной области или в тестировании программного обеспечения.
9. Путем создания тестов на ранних этапах проекта мы можем обнаружить неисследованные ранее области.
Недостатки:
1. Формализованное тестирование напрямую зависит от качества требований. Были ли требования действительно завершенными, стабильными и однозначными, когда они брались за основу для формализованного тестирования? Вряд ли.
2. Формализованное тестирование, по своему определению, не гибкое. Оно всегда следует согласно запланированному перечню действий (скрипту). Если, во время тестирования, мы увидим что-то странное, мы сделаем заметку, но не будем продолжать «копать» в этом направление. Почему? Из-за того, что этого нет в скрипте. Множество интересных дефектов могут быть пропущены при использовании данного подхода.
3. Формализованное тестирование часто используется для снижения роли тестировщика. Данный подход можно описать как «Научи тестировщика выполнять один вид тестов и отправь его тестировать гору тестов. Из-за большого количества тестов, мы вероятно найдем большинство дефектов»
Подписаться на:
Сообщения (Atom)