Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
В преддверии тренинга Тест-дизайн и все все все, который пройдет этой осенью в четырех городах (24-25 сентября в Харькове; 15-16 октября в Нижнем Новгороде; 29-30 октября в Москве; 18-19 ноября в Самаре) Александр Федоров решил лучше познакомиться со своей аудиторией и провести бесплатный вебинар Тест-дизайн «в цикле».
Любые процессы цикличны по своей природе, и разработка тестов не исключение. Тест-кейсы придумываются, создаются и используются на продукте и иногда в его последующих версиях. На разных этапах разработки к тестированию и тест-дизайну выдвигаются разные требования, которые мы рассмотрим в рамках вебинара.
Особенности тест-дизайн при итерационной разработке
Польза и спорная эффективность автоматизации тестирования
Наследование тест-кейсов новыми и «родственными» версиями продукта
Поддержание тест-кейсов в актуальном состоянии на разных этапах жизненного цикла продукта
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
В преддверии тренинга Тест-дизайн и все все все, который пройдет этой осенью в четырех городах (24-25 сентября в Харькове; 15-16 октября в Нижнем Новгороде; 29-30 октября в Москве; 18-19 ноября в Самаре) Александр Федоров решил лучше познакомиться со своей аудиторией и провести бесплатный вебинар Тест-дизайн «в цикле».
Любые процессы цикличны по своей природе, и разработка тестов не исключение. Тест-кейсы придумываются, создаются и используются на продукте и иногда в его последующих версиях. На разных этапах разработки к тестированию и тест-дизайну выдвигаются разные требования, которые мы рассмотрим в рамках вебинара.
Особенности тест-дизайн при итерационной разработке
Польза и спорная эффективность автоматизации тестирования
Наследование тест-кейсов новыми и «родственными» версиями продукта
Поддержание тест-кейсов в актуальном состоянии на разных этапах жизненного цикла продукта
Управление компанией с использованием метода критического цепи (МКЦ)Евгений Пикулев
Частная презентация, рассказывающая о недостатках метода критического пути, и о достоинствах метода критической цепи. Полезна для собственников и руководителей компаний.
Glib Rybalko, GlobalLogic’s Test Lead, consultant and trainer was among 26 known Ukrainian and international experts who took a word on IT Weekend Ukraine 2013. Glib discussed features of automated software testing, benefits and feasibility of using this approach on various projects. During his speech, Glib pointed all necessary steps of automated testing implementation and gave homework for those who were interested in this field and wanted to implement it in their projects.
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хоро...Yandex
Конференция "План Б" в Санкт-Петербурге (17 декабря 2011)
Ирина Томилова "Чего хотят тестировщики? или как после планирования жить хорошо..." (DINO Systems)
Тезисы:
– тестировщики хотят того же, чего и все остальные – играть по правилам;
– правила игры не могут не меняться;
– готовность к изменениям закладывается при планировании;
– плановые риски требуют профилактики;
– планирование тестирования завершается не раньше, чем само тестирование.
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
2. Кто такой Денис Бесков
• 10 лет в разработке ПО
• 5 лет в разработке БД
• 5 лет в системном
анализе и архитектуре
• Соорганизатор
РИТ-2008/2009,
SQA-II, UML2.ru
• Докладчик на …
• Ведущий блога
http://system-analysis.ru
3. О чём речь
1. Как мы обычно работаем (if at all)
2. Какие проблемы возникают
3. Каковы причины этих проблем
4. Как мы могли бы работать
1. Планирование требований
2. Разработка требований
3. Согласование требований
4. Поддержка требований (not today)
5. Что теперь со всем этим делать?
6. Типичные проблемы
1. Качество требований
• Требования недостаточно полны (ширина)
• Часть требований недостаточно подробны (глубина)
• Часть требований избыточна
• В требованиях много ошибок
2. Нехватка времени
• Для исправления ошибок нужно значительное время
• Уже нет времени переделывать требования,
т.к. разработка уже идёт
3. Результат?
• Взаимное недовольство и конфликт
между аналитиком и тестировщиком
• Плохое качество тестов
7. Причины типичных проблем / 1
Менеджер проекта выбирает
сроки разработки требований
без учёта их качества
•У менеджера проекта
нет инструмента для оценки
и управления качеством требований
• Аналитик не договорился с потребителями
о качестве требований на базе
стоимости их разработки
8. Причины типичных проблем / 2
Ожидания поставщика и
потребителя требований
не согласованы
• Аналитик выбирает формат
и детализацию требований
без учёта потребителя
и согласования с ним
• Аналитик пишет требования «для себя», по книжке
• Тест-дизайнер недоступен для раннего вовлечения
9. Причины типичных проблем / 3
Глубина проработки требований
равномерно одинаковая
по всем фичам
• Необходимая глубина проработки
разных фич не определялась
• Фичи не взвешивались по сложности
тестирования
10. Однородность глубины /1
Выбирается один раз на проект
Фиксированная глубина:
1. Либо User Story / Feature (Cost = X)
2. Либо основные потоки способов
применения (Cost = 3X)
3. Либо полные сценарии способов
применения (Cost = 10X)
11. Однородность глубины /2
Формат Ф1 Ф2 Ф3 Ф4 … … … ФN
User Story X X X X X X X X
Основной поток
Use Case
X X X X X X X X
Все потоки
Use Case
14. Возможные принципы
• Клиентоориентированность аналитика
• Предварительные договорённости о
качестве требований с тест-дизайнером
• Рентабельность разработки требований
• Выбор глубины проработки требований на
основе сложности тестирования
• Выбор ширины проработки требований на
основе стоимости проработки
22. Разработка требований. Подход
1. Способы применения (use cases)
как основной формат требований,
удобный для тестировщика
2. Аналитик передаёт требования
на изучение порционно —
и по глубине и по ширине (3-5 UC)
23. Разработка требований. Цикл
1. Аналитик разрабатывает основной поток
способа применения и выявляет точки
расширения
2. Тест-дизайнер изучает основной поток,
даёт замечания, выявляет исключения
3. Аналитик описывает обработку исключений и
расширений
4. Тест-дизайнер вычитывает исключения и
расширения
5. Аналитик обрабатывает замечания тест-
дизайнера
28. Начинайте сотрудничество!
1. Договаривайтесь с
главным аналитиком о необходимости
совместного планирования
качества требований
2. Пробуйте планировать вместе
3. Продавайте менеджеру проекта
выгоды вашей совместной работы
4. Работайте вместе, а не по очереди