Мой первый блог. Или знакомство с тестированием

На приведенной ниже схеме наглядно представлено как качественно протестировать user story/ (Источник: http://www.xmind.net/m/V9WU. Автор Д. Манухина). Первый этап к составлению тест кейсов это определение и согласование стратегии тестирования: ·        Определение уровней тестирования ·        Учет рисков по проекту/продукту ·        Построение матрицы взаимодействия компонентов ·        Определяем какой функционал будем тестировать, а какой нет ·        Определяем глубину тестирования, % приемлемого тестового покрытия и критерии выхода ·        Определяем временные рамки с учетом того, что user story могут передать в тестирование в конце итерации ·        Выполняем тестирование user story Второй этап - определение необходимых видов тестирования user story . - Функциональное - Нефункциональное (ISTQB) ·        Reliability testing (надежности) ·        Usability testing (удобства использования) ·        Efficiency testing (эффективности) ·       

Рассмотрим еще одну интересную тему "Рецепт хорошего бага" (источник: http://www.xmind.net/m/kwhk). Ниже представлена схема построения бага. Разберем по частям. Для начала хочется обсудить, кто заинтересован в заведении бага? Вы думаете только тестировщик? Дефекты позволяют тимлиду команды оценить степень готовности проекта на данном этапе, возможно изменить ход работы команды с задачами. Некоторые дефекты появляются по причине недопонимания разработчика разрабатываемого функционала или потому, что описание функционала не однозначно и все члены команды понимают его по разному. Дефект для разработчика – это корректировка упущенной (или специально пропущенной?:) ) части функционала. Для аналитика дефект показывает: 1)     Возможно ошибку в описании функционала, что позволяет исправить ее на ранней стадии проекта 2)     Оценить корректность описанного функционала, ведь тестировщик (как говорилось выше) и аналитик могут воспринимать описанный функционал для разработк

На одном из занятий в МГТУ им. Баумана была рассмотрена интересная тема, касаемая профессии тестировщика. Ниже приведена схема "Топ 10 заблуждений о профессии тестировщика в России". (источник: http://www.xmind.net/m/mKd7)            Так как данная профессия установилась относительно недавно, многие заблуждения постепенно развеиваются. Но поговорить о них все таки стоит.            Я бы сравнила тестировщика с поваром. Он тестирует продукт по рецепту, который написан в книге, но добавляет свою изюминку, что позволяет найти больше несоответствий в программном продукте. Ведь не все люди могут готовить одинаково.           В профессии повара есть разделения: кто-то идеально готовит десерты, кто-то горячие блюда, а кто-то закуски. Так и в тестировании: кто-то функциональщик, кто-то автоматизатор, а кто-то нагрузочник. У тестирования, как и у кулинарии, есть свой шеф-повар, гуру, к уровню которого стоит стремиться.            "Тестировщик - это профессия для молодежи

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

Продолжаем разбираться в понятиях тестирования, и в данном блоге рассмотрим классификацию «по уровню детализации приложения»: модульное, интеграционное и системное ( рис.1). Рисунок 1. Схематичное представление классификации тестирования по уровню детализации приложения Уровни тестирования в основном предназначены для выявления недостающих областей и предотвращения дублирования и повторения между этапами жизненного цикла разработки. В моделях жизненного цикла разработки программного обеспечения существуют определенные этапы, такие как сбор и анализ требований, проектирование, кодирование или внедрение, тестирование и развертывание.  Каждая фаза проходит тестирование.   Модульным тестированием (unit testing, module testing, component testing) в основном занимаются (хорошие, но не все=) ) разработчики, чтобы убедиться что разрабатываемая часть кода работает верно в соответствии с документацией. Тестовый модуль является наименьшим проверяемым частью приложения , как фун