Критерии завершения тестирования это один из часто задаваемых вопросов на собеседованиях на должность тестровщика ПО. Давайте разберем какие же основные факторы влияют на принятие решения о завершении тестирования тестировщиком.

Часто новички в тестировании отвечают на данный вопрос — буду тестировать пока не найду все баги :)
А возможно ли это? Нет конечно, никто не может гарантировать отсутствие багов, даже если это приложение было протестировано несколькими опытными тестировщиками. Исчерпывающие тестирование невозможно и об этом гласит один из принципов тестирования

Следует выделить 3 основных критерия для остановки, завершения тестирования:

• Время
• Бюджет
• Все тест кейсы пройдены, найденные баги исправлены и перепроверены

1) Время — В ходе тестирования могут находиться баги с разным приоритетом серьезности, попадаются баги блокеры, которые блокируют дальнейшее прохождение по тест кейсам, время на исправление и перепроверку багов может затянуться. Так как продукт или новую фитчу обещали к определенной дате то проджект менеджер вместе с тим лидом или тестировщиком принимает решение какие баги все таки стоить исправить, а какие можно отложить до следующего релиза в порядке приоритета и серьезности багов. Таким образом тестирование завершается по истечении времени.

Читать дальше →

Сейчас уже много тестировщиков и все они пишут тест кейсы. Но не все из них используют техники тест дизайна или используют но не догадываются об этом.
Краткий обзор самых распростроненных техник тест дизайна:

Разделение по классам еквивалентности

Для примера, имеется определенный диапазон предполагаемых значений от 1 до 10 ваша задача выбрать 1 без погрешности значение внутри этого интервала, допустим 3 и одно с погрешностью то есть не верное вне промежутка -0.

Анализ граничных Значений

В этом случае для положительного тестирования нужно выбрать, наименьшую и наибольшую границу: допустим от 2 и до 9 и значения больше и меньше границ допустим 1 и 10. Анализ имеет применение к любым сущностям с ограничениями в данной области.

Причина/ Следствие

В этом случае ввод определенных комбинаций будет представлен причиной. Когда ответ самой системы это будет следствие. Допустим, вы собираетесь узнать о возможности добавить пользуясь одной из мониторных форм. Для определения нужно разметить на несколько полей «Фамилия», «Год», «номер страховки» и и как только вы нажмете иконку «Добавить» — вы получаете причину. А следствие будет то когда система, добавит и выдаст его номер в базе.

Читать дальше →

Порой, тестируя большое количество новых фитч тестировщики забывают даже о самых важных принципах в тестировании и тем самым делая много стратегических и поведенческих ошибок в тестировании ПО.
В этой статье напомню общеизвестные и основные принципы о которых не следует забывать, когда тестируете какое либо приложение или новую фитчу

Основные принципы в тестировании ПО

Из множества принципов, которые наверно для себя выделил каждый тестировщик занимающийся тестированием ПО есть основные по мнению сообщества тестировщиков, которые и хотелось бы выделить:

1) Исчерпывающее тестирование невозможно ни одним из тестировщиков. Думаю что все понимают что протестировать все возможные случаи и комбинации просто невозможно, конечно если это не тривиальный случай.
Все случаи просто не могут быть включены в тест сьют, так как это заняло бы у нас очень много времени и в конце концов не стоило бы нам таких усилий. Если каждый тестировщик сядет и тщательно продумает все сценарии и если отдать эту фитчу для тестирования другому тестировщику, то он как правило находит еще кучу возможных сценариев и кейсов, которые можно включить. Поэтому в тестировании ПО принято проанализировать продукт или новую фитчу после чего сфокусировать усилия в тестировании на более рисковые и приоритетные случаи и участки нашего продукта.

2) Скопление багов. Если брать продукт и разбить его по модулям, то в процессе тестирования можно заметить что основная часть багов лежит в одном или нескольких модулях продукта, следовательно можно отметить эффект скопления багов. Как правило такое можно наблюдать в совершенно разных продуктах. Для того чтобы эффективно протестировать наш продукт, следует распределить свои усилия в тестировании по реальной плотности багов в модулях продукта, если же тестируем впервые, то пропорционально ожидаемой плотности. Со временем тенденция с накоплением багов может изменятся от модуля к модулю. Это следует отслеживать и перераспределять усилия в дальнейшем тестировании.

Читать дальше →

Пример конфигурирования Testng.xml:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >

<suite name="SeleniumTest" verbose="1">
    <test name="RozetkaTest">
       <parameter name="browser" value="chrome" />
        <classes>
            <class name="Tests.SmokeTest" />
            <class name="Tests.MenuTests" />
            <class name="Tests.AuthorizationTests" />
            <class name="Tests.OnlineOrderTests" />
        </classes>
    </test>
</suite>

В этом xml файле перечисляются классы, которые будут запускаться при нажатии на «test» в мавен панели.
Также могут быть перечислены отдельные методы и передаваться параметры, которые можно использовать в автотестах.

Всем доброго дня. У меня такая проблема — как такового опыта работы тестировщиком в компании у меня не было никогда, но меня взяли на работу в место, где никогда не было какого-либо специалиста по тпестированию. И вот сейчас я несколько в замешательстве, так как руководство компании ждет от меня упорядочения процессов тестирования и иных действий профессионального характера, а я имею опыт только в написании тестовой документации и проведения непосредственного тестирования продукта. И я хочу спросить вас, дорогие опытные специалисты и посетители этого сайта — с чего начать? Как наладить процессы?
пы.сы. почему меня взяли без опыта в компании где нужен человек с опытом ( по честному, да?)) — не спрашивайте)
Помогите советом, пожалуйста.

Когда изучаешь теорию тестирования и сталкиваешься с двумя терминами которые при прочтении описания кажутся во многом почти одним и тем же. И сложно найти подробное описание различий тем более что вопрос Что такое Верификация и Валидация и отличие между ними звучит на собеседованиях довольно часто.



Для удобства сведем различия и определения в таблицу из двух колонок

Верификация	Валидация
Отвечает на вопрос правильно ли мы делаем продукт и все ли в соответствии с поставленными требованиями	Отвечает на вопрос делаем ли мы продукт правильно с точки зрения ожидания потребности пользователей или заказчика от нашего продукта
В процессе верификации убеждаемся что функционал нашего продукта работает правильно	В процессе валидации убеждаемся что функционал нашего приложения соответствует поведению которое ожидает и подразумевает от такого функционала пользователь или заказчик
Верификация включает в себя такие вещи как проверка соответствия требованиям, технической документации и корректности выполнения кода на каждом этапе цикла разработки и тестирования ПО	Валидация в большей степени включает в себя оценку продукта «в общем» и может включать в себя субъективную оценку насколько хорошо работает программа или приложение

Читать дальше →

QA Engineer что это — это такая же профессия, работа по найму в IT как и многие другие о которых вы скорее всего слышали и знаете, к примеру, такие как программист или аналитик. QA Engineer выполняет весь обьем работ связанный с тестированием ПО на проекте.

Чем же занимается QA Engineer?

Его обязаности очень обширны начиная от анализа технической документации (требований, спецификаций) до написания тестовой документации и собственно тестирования и написания автоматических тестов. Но не все тестировщики (так их называют в народе) занимаются все этим на своей работе. Все зависит от компании в которой они работают и какой уровень квалификации имеют.

Уровни квалификации и опыта у Тестировщика (QA Engineer)

Обычно Тестировщиков делят на 4 основные категории:

Trainee QA Engineer

— это обычно человек, который не имеет опыта работы в этой профессии и только начинает свой путь в тестировании ПО

Junior QA Engineer

— человек, который уже имеет какие-то навыки и опыт в тестировании возможно комерческий или фриланс, часто таким знанием и квалификацией награждают после прохождения испытательного срока, который может длиться от 1 до 6 месяцев в зависимости от компании.

Middle QA Engineer

— это специалист среднего уровня знаний, умений и ответственности на проекте, может выполнять задачи самостоятельно и подсказывать по проекту и профессии младшим сотрудникам Trainee и Junior тестировщикам. Обычно имеет опыт от 1 до 3х лет в профессии.

Senior QA Engineer

— опытный сотрудник высокого уровня квалификации. Кроме самостоятельного выполнения задач, может легко обучать других сотрудников, брать на себя тестирование более сложных технических задач, выполняет наиболее широкий спектр задач используя различные виды тестирования как правило уже практикующий автоматизацию, но это не всегда, так как есть и такие инженеры, которые специализируются только лишь на ручном тестировании.

Читать дальше →

Подготовка пакета SpecFlow для написания тестов

Для начала работы нужно скачать и добавить референс на библиотеку SpecFlow. Это можно сделать через NuGet Package Manager.

Создание SpecFlow Feature File для описания сценариев

Далее при создании нового айтема будет доступен айтем SpecFlow Feature File с расширением .feature выбираем и создаем



После создания SpecFlow Feature файла мы можем видеть такую заготовку под описание сценариев
Писать сценарии в этих файлах могут как тестировщики так и аналитики и продакт овнеры. Главное чтобы учитывался подход в описании сценариев, используя такие ключевые слова как:

• Given
• When
• And/But
• Then

Читать дальше →

Обычно по статистике 20% кода вызывают 80% проблем, что образует эффект скопления багов в одном или нескольких связанных модулях приложения (defect clustering). Чтобы заранее обнаружить возможные баги, которые могут возникнуть при дальнейшем динамическом тестировании, мы можем статически тестировать код с помощью данной метрики.
Это очень полезная техника которая нам позволит определить число необходимых позитивных тестов, которые будут равны цикломатической сложности программы.

Вычисление цикломатической сложности (cyclomatic complexity metric) с помощью построения графа

Цикломатической сложность вычисляется легко, путем суммирования всех узлов таких как if, while, for и др. внутри и добавляя 1
Или по формуле
M = E − N + 2P,
где:
M = цикломатическая сложность,
E = количество рёбер,
N = количество узлов,
P = количество компонент связности.

К примеру проанализируем данный участок кода:

IF A = 100
THEN IF B > C
THEN A = B
ELSE A = C
ENDIF
ENDIF
Print A

В данном случае исходя из формулы цикломатическая сложность будет равна 8 — 7 + (2 * 1) = 3

Читать дальше →

Требования к приложению или новой фитче имеют очень высокую важность с точки зрения тестирования ПО. Но так как требования не всегда могут быть описаны документально то основным критериям качества требования является сам факт наличия этих требований к ПО. Сами же требования должны удовлетворять критериям качества, которые распишем ниже.

Всего критериев качества требований можно выделить девять:

Корректность

Бывает что в требованиях допускают ошибки при составлении таковых. Это можно обнаружить проанализировав требования целиком, найдя еще одно место где есть расхождения с предыдущим значением, к примеру некорректная необходимая процентная ставка по кредиту в банковском приложении, но если это место уникально то такую неточность тестировщику может оказаться распознать проблематично и только пользователь или тот кто детально введен в курс дела по точности данных, может распознать и исправить ее.

Недвусмысленность

Точность формулировки в требованиях может по-разному интерпретироваться тестировщиками, разработчиками и другими участниками проекта. Проблема возникает из-за того что требования пишутся на «естественном языке» и разные члены команды, относящиеся к разным группам настолько привыкли к своей интерпретации слов или фразы что им уже сложно предстать что это для кого-то другого имеет совершенно другой смысл.

Полнота

Часто в требованиях забывают описать валидации на поля или единицы измерения в каких будет показываться значения или даже целые секции, которые могут быть пропущены по невнимательности.

Непротиворечие

Конфликты в описании одного и того же функционала в разных частях требований зачастую находятся посредством механического анализа. Одна часть требований может гласить что на какое-то действие нужно выполнять то-то, в тоже время как в другой части требований можно найти что та же самая функциональность должна выполнять что-то другое.

Читать дальше →