#тестовыйсценарий

Тестовый сценарий

Обязательные требования к тест-кейсам

Обязательные атрибуты:
Номер
Заголовок
Предусловие
Шаги
Ожидаемый результат

#Чеклист содержит:
✅Список проверок (с требуемой степенью детализации).
✅Окружение проверки:
🔅сборка, на которой проводилось тестирование;
🔅тестовое окружение (если применимо);
🔅информация о тестировщике.
✅Результат проверки.

Читать статью: Что такое чек-листы и как с ними работать

#дефект

Читать мой пост в инстаграме: Как правильно завести дефект

Дополнительная информация:
Статьи:
Принцип «Что? Где? Когда?» как ключ к успеху на проектах

Как правильно необходимо описывать шаги в баг-репорте

Как правильно описать дефект

А ну-ка выполним задание на внимательность и быстроту!!!😄
Раньше такие задания были на собеседованиях🙈

Посмотрите на картинку и найдите три отличия. Сколько по времени получилось найти отличия?
anonymous poll

1 - 3 минуты – 33
👍👍👍👍👍👍👍 42%

Меньше минуты – 21
👍👍👍👍 27%

Залип(ла)😄 – 17
👍👍👍👍 22%

Больше 4 минут – 7
👍 9%

👥 78 people voted so far.

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию https://victorz.ru/202001101079

В конце статьи есть шаблон

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

http://www.protesting.ru/testing/testcase.html

Сегодня меня спросили вопрос про графы в SQL, и это был вопрос на собеседование для Junior tester.
Я честно удивлена, что такие вопросы задают на позицию младшего тестировщика.
Поэтому рекомендую почитать Вам следующую статью:
Введение в графовые базы данных SQL Server 2017

Предупрежден значит вооружен😄

А в целом нужно ознакомиться с теорией графов.

🔷Граф — это множество вершин (узлов, node) и ребер (взаимосвязей, edge).
🔹Вершины представляют сущности, а
🔹ребра — связи, в атрибутах которых может содержаться информация.

Графовая база данных моделирует сущности в виде графа в том виде, как это определено в теории графов.
🔹Структуры данных — это вершины и ребра.
🔹Атрибуты — это свойства вершин и ребер.
🔹Связь — это соединение вершин.

Для моделирования связей SQL Server 2017 предлагает возможности графовых баз данных.
Вершины и ребра графа представляются в виде новых типов таблиц:
🔹NODE
🔹EDGE.

🔹Для запросов к графу используется новая функция T-SQL под названием MATCH().

❗️С помощью SQL Graph можно решить проблему с обработкой различных уровней иерархии.

Например,
В статье создают таблицу сотрудников EMP с идентификатором EMPNO и колонкой MGR, указывающей на идентификатор руководителя сотрудника.
🖍Сотрудники — это вершины графа из таблицы EMP. Сущность «сотрудник» связана сама с собою связью «подчиняется» (ReportsTo).
🖍В терминах графа, связь — это ребро (EDGE), которое связывает узлы (NODE) сотрудников.

‼️В данной статье указаны запросы создания таблиц узлов и ребер.

❗️Объекты, связанные с графами, располагаются в папке Graph Tables.
Иконка таблицы узлов помечена точкой, а таблицы ребер — двумя связанными кругами.
Выражение MATCH взято из CQL (Cypher Query Language). Это эффективный способ запроса к свойствам графа. CQL начинается с выражения MATCH.
Графовые базы данных — это выразительный язык для представления сложных систем. Эта технология используется в таких областях, как социальные сети, антифрод-системы, анализ ИТ-сетей, рекомендации по продуктам и контенту.

FYI: Графовые базы данных

Обработка графов в SQL Server и Базы данных SQL Azure


Графовые базы данных SQL Server

Готовьтесь к любым вопросам на собеседования.
Хотя по опыту на собеседованиях спрашивали простейшие запросы на SELECT , JOIN и UNION😄

#теория

#рубрикакроссвордов
#кроссворд по тестированию ПО

📌По горизонтали:
1️⃣ операционная система, ядро которой распространяется на бесплатной основе;
4️⃣ атрибут, характеризующий влияние дефекта на работоспособность приложения;
7️⃣ способ перемещения визуальной части окна вверх, вниз, вправо и влево для того чтобы увидеть дополнительную информацию в окне;
9️⃣ автоматизированное отдельно поставляемое программное средство, используемое для устранения проблем в программном обеспечении или изменения его функциональности;
🔟 тестирование всего приложения от начала и до конца;
1️⃣1️⃣ программа, способная перехватывать и анализировать сетевой трафик.


📌По вертикали:
2️⃣ контрольный список, содержащий ряд необходимых проверок для тестирования;
3️⃣ тестирование программного обеспечения на то, как оно не должно работать;
5️⃣ выпуск окончательной версии программы - готового для использования продукта;
6️⃣ комплект устройств интерактивного ввода-вывода (дисплей, клавиатура, мышь) для управления компьютером;
8️⃣ любое условие, которому должна соответствовать разрабатываемая система или программное средство;
1️⃣2️⃣ последовательный набор данных, хранящийся на каком-либо физическом носителе и имеющий собственные имя и расширение.

#Тестовыйсценарий имеет определенный шаблон, разработанный для того, чтобы стандартизировать и упростить создание и дальнейшее чтение тест-кейсов. Шаблон условно стандартизированный, потому что может меняться в зависимости от компаний и процессов.

1⚙️. ID - уникальный номер.
Обычно проставляется автоматически в системах хранения тест-кейсов.
2⚙️. Краткое описание тест-кейса (noscript).
Название тест-кейса должно быть коротким и понятным. Оба эти слова важны, например "Авторизация пользователя"

3⚙️. Ссылка на требования — ссылка на требование или ТЗ, на основе которого был составлен тест-кейс.
4⚙️. Автор тест-кейсы (аuthor) — тестировщик, который написал тест-кейс.
5⚙️. Приоритет (Priority) — насколько важен этот тест-кейс, в какую очередь его стоит выполнять.
6⚙️. Название/модуль/версия продукта (Component/Version) — описание ПО, на котором можно выполнить тест-кейс.
7⚙️. Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу.
8⚙️. Шаги (steps) — точная последовательно действий для выполнения проверки.
Шаги должны быть четкими и понятными. В идеале их нужно писать так, чтобы понял даже человек, который видит проект и тестирование в первый раз. Четкие шаги снизят риски того, что тест-кейс будет неправильно понят, а соответственно и неправильно протестирован другими тестировщиками, особенно новичками, которые только пришли на проект.
Например,
1.Открыть страницу сайта "..."
2. Ввести значения логина и пароля
3. Нажать кнопку "Войти"

9⚙️. Ожидаемый результат (expected result) — что мы получаем после выполнения шагов.
Например, Авторизация пользователя успешно завершена. Открыт личный кабинет пользователя

10⚙️. Приложения (attachments) — дополнительная информация, которая поможет выполнить тест-кейс, например, скриншоты, текстовые файлы и прочие файлы.

в помощь ознакомиться со статьей Основы тестирования. Тест-кейсы и чек-листы

#теория

🔷семь принципов тестирования

🔹 Тестирование демонстрирует (только) наличие дефектов (Testing shows presence of defects)
🔹 Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)
🔹 Раннее тестирование (экономит время и деньги) (Early testing saves time and money)
🔹 Принцип скопления дефектов (Defect clustering)
🔹 Парадокс пестицида (Pesticide paradox)
🔹 Тестирование зависит от контекста (Testing is context dependent)
🔹 Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)