[Из песочницы] Тестирование. Ошибки при сертификации или ISTQB мне очень нужен
Статья полезна тем, кому небезразлична их квалификация и хочется стать лучше. Учиться никогда не поздно.
Любой тестировщик рано или поздно задумывается о качестве не только в рабочем процессе, но и в отношении себя, качестве своего образования и способностей. В данный момент далеко не все вузы способны подготовить такого специалиста. Остаются всяческие курсы, как правило, дистанционные, чтобы была возможность поучиться у людей из этой же области, добившихся успеха. Но есть и ещё один способ самоутвердиться. Это сертификаты. Их много, перечислять, смысла нет. Но практически во всех областях они есть и их получение, скорее плюс, чем минус.
Мне бы хотелось написать о ISTQB, т.н. International Software Testing Qualifications Board. Это признанная во всём мире сертификация для тестировщика. Если ты такое получил, то по идее владеешь базовыми знаниями и теорией, то есть и плюсик тебе на собеседованиях добыть можешь, и в общем самоутверждаешься.
В статье я бы поговорила об ошибках. О глупых и не очень. О тех, которые я лично совершила в таком тесте или могла. И не хотела бы, чтобы кто-то тоже так попался.
Исчерпывающее тестирование
Хотелось бы для начала, чтобы запомнили следующее, «исчерпывающее тестирование невозможно, независимо от того, сколько усилий затрачено на тестирование (т.н. Принцип # 2)». Этот принцип запомнить придется. Много ссылок на материалы для подготовки кидать не буду, одну приведу в конце статьи. Пункт, в котором засомневалась я, был «При достаточных усилиях и инструментальной поддержке исчерпывающее тестирование возможно для любого программного обеспечения». Первые мысли были о том, что терпение и труд всё перетрут. Это верно только для тривиальных ситуаций, в любой реальной системе предусмотреть все ситуации не сможем, остается только свести к минимуму количество проблем.
Стадии и задачи
Информация для запоминания. Основной процесс тестирования можно поделить на этапы, направления деятельности:
- Планирование (Этап 1)
- Анализ и проектирование (Этап 2)
- Внедрение и реализация (Этап 3)
- Оценка критериев выхода и создание отчетов (Этап 4)
- Действия по завершению тестов (Этап 5)
Эти все этапы стоит знать. Они выделены не случайно, все имеют особенности. Но это не значит, что они не могут накладываться друг на друга или происходить одновременно в конкретной ситуации.
Вопрос, с которым я столкнулась, по сути, был таким, какие задачи мы выполняем на этапе анализа и проектирования. Были разные варианты ответов.
- Определение целей тестирования
- Рецензирование базиса тестирования
- Создание тестовых наборов из тестовых процедур
- Анализ накопленного опыта для улучшения процесса
Ухватившись за слово проектирование, я предположила, что именно на этом этапе проектируются все тест планы, поэтому создание процедур и тестовых наборов казалось отличным ответом. Как я была не права.
Поэтому кратко рассмотрю все этапы, чтобы прочитав мою статью можно было не читать огромные мануалы. Специально пронумеровала этапы для ссылки на каждый.
Итак, этап номер 1, планирование. На этом этапе самое важное определить цель тестирования и описать для себя (или лицу вышестоящему) задачи, которые эту цель помогут достичь. Тут и объём, и риски, и подходы, и люди. Этот этап так же включает ещё и управление тестированием. Мы не только план составили, но и на протяжении всего процесса следим, что он выполняется, задача за задачей. Таким образом, не только ставили задачи, но и занимаемся их мониторингом.
На втором — мы анализируем и занимаемся проектом. Что в это входит? Как раз рецензирование базиса тестирования. В него входит требования на целостность проекта, отчет об анализе рисков, архитектура, дизайн, тех. требования к интерфейсу. На этом этапе, по сути, составляем отчеты о рисках, оцениваем характеристики, расставляем приоритеты, у проекта вырисовывается архитектура. Выбираем тестовое окружение и устанавливаем все инструменты.
Как раз на третьем этапе даётся воля для написания тестовых сценариев, тут же выполняется вся самая ответственная работа для выполнения их в ручном или автоматическом режиме. Этап внедрения и реализации я бы хотела отнести к самым главным в жизни тестировщика, в нем без сомнения проведётся больше всего времени, больше всего будет найдено проблем, которые, как не прискорбно признавать, нас воодушевляют для дальнейшей работы.
На четвертом этапе в основном занимаемся отчетом, оцениваем характеристики, какие можем, смотрим найденные баги, анализируем какие бы ещё тесты могли бы провести, всё это формируем в отчет для заинтересованных лиц.
И наконец, пятый этап, это скорее набор опыта. Смотрим, какие результаты мы получили, какие цели смогли достичь, анализируем данные для будущих релизов и используем дальше. На этом этапе тоже не обойтись без документации, которую надо сделать детально, чтобы отдать на этап сопровождения.
Тестирование в период сопровождения
В чём была моя ошибка, я предположила, что на этом этапе можно заниматься разбором жалоб по системе во время приёмочных процедур. И эта основная задача. На самом деле, к тестированию в период сопровождения относится работа системы после изменения окружения. То есть к этому пункту относится влияние этих изменений на действующую систему или какие-то дополнительные модификации.
Например, смена платформы. Что будет являться тестированием сопровождения? Все эксплуатационные тесты, тестирование изменений, стоит так же добавить в список планов регрессионное тестирование тех областей, которые при этом не были затронуты. При этом основная проблема — это границы области, которую стоит включить в тестирование. Если позволяет время и ресурсы, то стоит включить их все. Но на это времени хватает далеко не всегда. Поэтому для принятия решения придется оценить риск и соотношение размера системы к размеру внесенных изменений.
Системное и компонентное тестирование
Главное помнить, что компонентное тестирование обычно является ответственностью разработчиков, в то время как системное тестирование — типичная ответственность тестировщиков.
При компонентном тестировании занимаемся всё тем же поиском дефектов, только в разных кусочках системы, насколько возможно систему на эти части поделить. Важно, чтобы каждую из таких частей можно было тестировать изолированно. Есть множество способов и подходов, но это слишком широкая тема, которая уведет от самой сути, от разницы между видами тестирования. Ещё одной особенностью компонентного тестирования является то, что оно включает не только тестирование функциональное, но и проверяются нефункциональные характеристики. Например, к таким относится тестирование поведения ресурсов, отслеживаются утечки памяти. Как правило, при компонентном тестировании доступен код.
Противоположным тестированием является системное. Если в компонентном мы рассматривали каждую часть, как отдельную, то тут мы смотрим на систему, как на единый объект. При тестах применяем множество методов, и исследуем как функциональные, так и не функциональные требования. Тут уже подходят для исследования тестовые описания, варианты использования системы и прочие всевозможные способы поиска багов, но сама система рассматривается в виде «черного ящика» без доступа к коду.
Формальное рецензирование и его шаги
Когда для системы сформировано множество требований к коду, требований к входным данных, какие-то юридические моменты должны быть учтены, и прочее, и прочее, то как этап тестированию добавляется рецензирование. По сути есть список, что мы должны учесть для завершения каждого модуля в системе. Возможно, что в этом процессе придется прибегать к экспертам в нужной нам области.
Основные фазы формального рецензирования — это планирование, старт, индивидуальная подготовка, изучение/оценка/запись результатов, повторная обработка, отслеживание. Этапы на самом-то деле все последовательные и логичные. Спланировали, какие критерии нужны, и выбрали людей, при запуске поделились со всем своими планами, подготовились индивидуально, учитывая все особенности и требования именно этой системы. Далее получили результаты, которые показали нашим экспертам, и все проблемы, что всплывали, поправили. И дальше следим, чтобы нигде ничего не нарушалось.
Заключение
Данный материал не создан, чтобы решить все вопросы, связанные с предстоящей сертификацией. Надеюсь, хотя бы то немногое, что я успела осветить, уложится в голове наверняка. Если хоть в какой-то мере статья была полезна, то могу продолжить разбор самых, на мой взгляд, неочевидных ошибок, которых было просто избежать.
Всегда готова к конструктивной критике. Если возникнут вопросы или в моих утверждениях найдется предмет для дискуссии, будет повод лишний раз вернуться к теории.
Полезные ссылки
Материалы для подготовки
Хорошая статья о тестировании от Натальи Руколь
