QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Техники тест дизайна для черноящичного тестированияDmytro Protsenko
Разобрано на пальцах несколько техник из книги Lee Copeland "A Practitioner's Guide to Software Test Design". Все что касается BlackBox Testing - cгруппированo в три раздела. Oбъяснены секреты магии Pairwise, почему тестирование областей определения переворачивает самолеты и дана краткая инструкция, как вернуть деньги за билет, если в связи с предыдущим пунктом, вы передумали лететь.
The document discusses requirements testing. It provides definitions of requirements and specifications, explains why projects can be unsuccessful, and describes characteristics of good requirements and specifications. It also outlines the requirements testing process, discusses validating requirements, and lists common problems with requirements that can lead to project issues if not addressed.
Дополнительные материалы по предмету "Управление проектами"Jana Pavlenkova
Краткий обзор особенностей ИТ-проектов для группы ТО - все это вам пригодится на контрольной. Еще раз матрица логики проектов, фазы и особенности ИТ-проектов, а также общая формула оценки стоимости ПО-проекта. Удачи!
Согласно результатов исследования, проведенного в 2006 году компанией IDC (ведущий поставщик консультационных услуг на рынках информационных технологий), в 70-80% случаев некачественные требования стали причиной неуспешно реализованных ИТ-проектов. Что же делать, если проектные требования отсутствуют вовсе, а тестирование и сдачу продукта заказчику необходимо выполнить. В своем докладе я расскажу об основных предпосылках для возникновения подобной ситуации, опишу ее влияние на процесс разработки программного обеспечения и расскажу, как можно смягчить данные обстоятельства с точки зрения процесса тестирования. Также уделю внимание неформальным техникам тестирования, которые не требуют детального описания и документирования: исследовательское и Ad hoc тестирование. Применение представленных методов позволяет снизить риски при отсутствии проектных требований.
использование высокоуровневых чеклистов (High-Level Check List), как один из видов описания функциональности; использование информации, собранной из подобных продуктов (требования к функциональности, архитектура и используемые технологии, руководства пользователю, FAQ, пользовательский интерфейс, статистические данные использования, форумы пользователей и разработчиков); планирование с использованием опыта на прошлых проектах; при условии недостаточных требований, использование процентного соотношения от общего количества запланированных часов на проект; изучение конкурирующих продуктов на рынке (как они работают, что они делают, какие ожидания от этих продуктов).
использование кода, как основы идей для тестовых сценариев; Test Plans могут выступать в роли низкоуровневых требований.
умение задавать правильные вопросы: при функциональном тестировании определенных функций – разработчикам, при тестировании бизнес-логики и пользовательского интерфейса – бизнес-аналитикам и конечным пользователям; использование неформальных техник тестирования, не требующих документации: A d hoc тестирование и исследовательское ( exploratory ) тестирование
Добавить использование опыта с прошлых, схожих проектов Провести аналогию с джазовым исполнением Ad hoc тестирование – импровизированное тестирование без предварительной подготовки. Ad h oc тестирование – термин, часто используемый для тестов, выполняемых без предварительного планирования и документации. Чтение требований и документации (если они существуют) редко дает понимание, как программа действительно должна работать в реальности. Ad h oc тестирование является одним из лучших методом для обзора продукта. Данное тестирование часто критикуется ввиду своей неструктурированности, но имеет большое преимущество: важные дефекты находятся на ранних стадиях проекта. В соответствии с моделью зрелости процессов создания программного обеспечения (CMM) Ad h oc тестирование соответствует компании 1 уровня (Chaotic).
Исследовательское (exploratory) тестирование, также называемое интуитивным, подразумевает под собой одновременное проектирование, выполнение тестов и обучение продукту. Обладает рядом особенностей: - переплетение дизайна тестов и выполнения. Это является противоположным процессу, в котором тесты сначала создаются, а потом запускаются; - тестировщик узнает продукт в процессе его тестирования; - особое внимание уделяется творчеству и спонтанности. Основным отличием предложенных подходов тестирования от формального ( scripted ) является то, что при формальном тестировании выполнение тестов ограничено разработанными и спроектированными тестами.