- - - - - - - - -
Тестирование API простыми словами за 8 минут
- - - - - - - - -
Автор простыми словами объяснил, что такое API и почему надо его тестировать. Рассказал о видах API, способах его вызова и реализации.
https://www.youtube.com/watch?v=kUPWQMalWNk
https://www.youtube.com/watch?v=kUPWQMalWNk
Тестирование API простыми словами за 8 минут
- - - - - - - - -
Автор простыми словами объяснил, что такое API и почему надо его тестировать. Рассказал о видах API, способах его вызова и реализации.
https://www.youtube.com/watch?v=kUPWQMalWNk
https://www.youtube.com/watch?v=kUPWQMalWNk
YouTube
Тестирование API простыми словами за 8 минут / Тестировщик API
🔥 Забери актуальную программу курсов "Тестировщик с нуля" на Stepik https://stepik.org/a/250559
Сегодня постараюсь простыми словами объяснить что такое API и почему мы должны его тестировать. Расскажу о видах API, способах его вызова и реализации.
🎓 Хочешь…
Сегодня постараюсь простыми словами объяснить что такое API и почему мы должны его тестировать. Расскажу о видах API, способах его вызова и реализации.
🎓 Хочешь…
👍3
Вопрос №34
Q: Что такое “позитивное”(Positive) и “негативное”(Negative) тестирование?
A: 1. “Позитивное” тестирование направлено на выполнение тест-кейсов, при которых поведение пользователя не выходит за рамки “нормального” (нормальность как правило определяется юз-кейсами или здравым смыслом). Например — Открыли браузер, ввели логин\пароль, нажали кнопку, увидели окно Home.
2. “Негативное” тестирование направлено на то, чтобы проверить поведение продукта\системы(не зависает, а показывает информативную ошибку) при некорректных действиях пользователя. Например — Открыли браузер, ввели логин\пароль (но неверный логин\пароль, состоящий из запрещенный символов), нажали кнопку несколько раз, увидели окно Home.
ИТОГ: С помощью негативного тестирования находится наибольшее количество багов
Q: Что такое “позитивное”(Positive) и “негативное”(Negative) тестирование?
A: 1. “Позитивное” тестирование направлено на выполнение тест-кейсов, при которых поведение пользователя не выходит за рамки “нормального” (нормальность как правило определяется юз-кейсами или здравым смыслом). Например — Открыли браузер, ввели логин\пароль, нажали кнопку, увидели окно Home.
2. “Негативное” тестирование направлено на то, чтобы проверить поведение продукта\системы(не зависает, а показывает информативную ошибку) при некорректных действиях пользователя. Например — Открыли браузер, ввели логин\пароль (но неверный логин\пароль, состоящий из запрещенный символов), нажали кнопку несколько раз, увидели окно Home.
ИТОГ: С помощью негативного тестирования находится наибольшее количество багов
👍3
Вопрос №35
Q: Что включает в себя тест-кейс?
A: При планировании\разработке\дизайне тест-кейса:
1. Тест-кейс ID (уникальный номер\код)
2. Цели тест-кейса (название, описание и .д.)
3. Инструкции о том, как получить ожидаемый результат из текущего состояния системы\программного продукта
4. Ожидаемый результат
При выполнении тест-кейса добавляются еще две колонки:
5. Фактический результат
6. Отметка о том, пройден или провален тест-кейс
Q: Что включает в себя тест-кейс?
A: При планировании\разработке\дизайне тест-кейса:
1. Тест-кейс ID (уникальный номер\код)
2. Цели тест-кейса (название, описание и .д.)
3. Инструкции о том, как получить ожидаемый результат из текущего состояния системы\программного продукта
4. Ожидаемый результат
При выполнении тест-кейса добавляются еще две колонки:
5. Фактический результат
6. Отметка о том, пройден или провален тест-кейс
👍4
Вопрос №36
Q: Что включает в себя тест-план?
A: 1. Название
2. Идентификационные данные программного продукта, включая версию\номер релиза\сборки
3. Историю ревизии тест-плана, включая авторов, даты создания\изменения, ответственных за согласование тест-плана
4. Содержание
5. Цели документа, целевую аудиторию(для кого пишется тест-план)
6. Объект тестирования
7. Обзор(краткое описание) тестируемого продукта
8. Соответствующий список документов, например, требования, проектные документы, другие тест-планы и т. д.
9. Соответствующие стандарты или юридические требования
10. Соответствующие соглашения об именах и условные обозначения
11. Общая организация проекта и персонал/контакт-информация/ответственность
12. Анализ рисков проекта
13. Приоритеты тестирования
14. Покрытие(объем) и ограничения тестирования
15. Используемые тестовые инструменты, включая версии, патчи и т. д.
16. Распределение обязанностей(тест-кейсов) по персоналу(тестерам) и т.д.
Q: Что включает в себя тест-план?
A: 1. Название
2. Идентификационные данные программного продукта, включая версию\номер релиза\сборки
3. Историю ревизии тест-плана, включая авторов, даты создания\изменения, ответственных за согласование тест-плана
4. Содержание
5. Цели документа, целевую аудиторию(для кого пишется тест-план)
6. Объект тестирования
7. Обзор(краткое описание) тестируемого продукта
8. Соответствующий список документов, например, требования, проектные документы, другие тест-планы и т. д.
9. Соответствующие стандарты или юридические требования
10. Соответствующие соглашения об именах и условные обозначения
11. Общая организация проекта и персонал/контакт-информация/ответственность
12. Анализ рисков проекта
13. Приоритеты тестирования
14. Покрытие(объем) и ограничения тестирования
15. Используемые тестовые инструменты, включая версии, патчи и т. д.
16. Распределение обязанностей(тест-кейсов) по персоналу(тестерам) и т.д.
👍3
Вопрос №37
Q: Из каких компонентов состоит баг-репорт? Какие поля Вы заполняете в баг-репорте?
A: 1. Номер репорта - уникальный(в рамках проекта) идентификационный номер
2. Тестируемое приложение\модуль
3. Версия\номер релиза
4. Резюме проблемы\короткое описание
5. Шаги для воспроизведения
6. Серьезность\важность(Severity) — Блокирующая(S1, Blocker), Критическая(S2, Critical), Значительная(S3, Major), Незначительная(S4, Minor), Тривиальная(S5, Trivial)
7. Приоритет(Priority) — Высокий(High), Средний(Medium), Низкий(Low)
8. Аппаратная и программная среда, на которой проводилось тестирование
9. Кто написал отчет\репорт (Reporter)
10. На кого назначен отчет\репорт (Assignee)
11. Статус — Открыт, В процессе выполнения, Решен и т.д.(Open, Pending, Fixed, Closed, Сannot reproduce, etc.)
12. Решения, принятые по отчету
13. Ключевые слова
Q: Из каких компонентов состоит баг-репорт? Какие поля Вы заполняете в баг-репорте?
A: 1. Номер репорта - уникальный(в рамках проекта) идентификационный номер
2. Тестируемое приложение\модуль
3. Версия\номер релиза
4. Резюме проблемы\короткое описание
5. Шаги для воспроизведения
6. Серьезность\важность(Severity) — Блокирующая(S1, Blocker), Критическая(S2, Critical), Значительная(S3, Major), Незначительная(S4, Minor), Тривиальная(S5, Trivial)
7. Приоритет(Priority) — Высокий(High), Средний(Medium), Низкий(Low)
8. Аппаратная и программная среда, на которой проводилось тестирование
9. Кто написал отчет\репорт (Reporter)
10. На кого назначен отчет\репорт (Assignee)
11. Статус — Открыт, В процессе выполнения, Решен и т.д.(Open, Pending, Fixed, Closed, Сannot reproduce, etc.)
12. Решения, принятые по отчету
13. Ключевые слова
👍4
Вопрос №38
Q: Если Вы нашли баг, а разработчик говорит, что это “так задумано”, что Вы будете делать?
A: 1. Попытаюсь найти конкретное требование, в котором описан данный функционал, и подтвердить или опровергнуть слова разработчика.
2. Если в документации ничего об этом не сказано, но разработчик не хочет исправлять дефект, обращусь к руководителю/менеджеру группы тестирования.
Q: Если Вы нашли баг, а разработчик говорит, что это “так задумано”, что Вы будете делать?
A: 1. Попытаюсь найти конкретное требование, в котором описан данный функционал, и подтвердить или опровергнуть слова разработчика.
2. Если в документации ничего об этом не сказано, но разработчик не хочет исправлять дефект, обращусь к руководителю/менеджеру группы тестирования.
👍5
Вопрос №39
Q: Что такое регрессионное тестирование(Regression testing)?
A: Повторная проверка ПО после написания нового функционала или исправления бага (дефекта). Проводится, чтобы убедиться, что не появилось новых ошибок (ничего не было сломано), так как разработчик вносил изменения в код (либо разрабатывая новый функционал, либо исправляя существующие баги).
Q: Что такое регрессионное тестирование(Regression testing)?
A: Повторная проверка ПО после написания нового функционала или исправления бага (дефекта). Проводится, чтобы убедиться, что не появилось новых ошибок (ничего не было сломано), так как разработчик вносил изменения в код (либо разрабатывая новый функционал, либо исправляя существующие баги).
👍7
Вопрос №40
Q: Что такое каскадная модель разработки ПО (Waterfall model)?
A: В данной модели разработчики переходят от одного этапа к другому строго последовательно и только после окончания предыдущего. Фазы: определение требований, проектирование, кодинг, тестирование и отладка, поддержка.
Q: Что такое каскадная модель разработки ПО (Waterfall model)?
A: В данной модели разработчики переходят от одного этапа к другому строго последовательно и только после окончания предыдущего. Фазы: определение требований, проектирование, кодинг, тестирование и отладка, поддержка.
👍3
- - - - - - - - -
BDD тестирование. Язык Gherkin. Фреймворк Cucumber.
- - - - - - - - -
BDD (сокр. от англ. Behavior-driven development, дословно «разработка через поведение») — это методология разработки программного обеспечения, являющаяся ответвлением от методологии разработки через тестирование (TDD). Основной идеей данной методологии является совмещение в процессе разработки чисто технических интересов и интересов бизнеса, позволяя тем самым управляющему персоналу и программистам говорить на одном языке. Для общения между этими группами персонала используется предметно-ориентированный язык, основу которого представляют конструкции из естественного языка, понятные неспециалисту, обычно выражающие поведение программного продукта и ожидаемые результаты.
Статья: https://smartiqa.ru/blog/bdd_gherkin_cucumber
BDD тестирование. Язык Gherkin. Фреймворк Cucumber.
- - - - - - - - -
BDD (сокр. от англ. Behavior-driven development, дословно «разработка через поведение») — это методология разработки программного обеспечения, являющаяся ответвлением от методологии разработки через тестирование (TDD). Основной идеей данной методологии является совмещение в процессе разработки чисто технических интересов и интересов бизнеса, позволяя тем самым управляющему персоналу и программистам говорить на одном языке. Для общения между этими группами персонала используется предметно-ориентированный язык, основу которого представляют конструкции из естественного языка, понятные неспециалисту, обычно выражающие поведение программного продукта и ожидаемые результаты.
Статья: https://smartiqa.ru/blog/bdd_gherkin_cucumber
👍3
- - - - - - - - -
Docker. Основы работы с контейнерами.
- - - - - - - - -
Docker – технология создания контейнеров и управления ими.
Контейнер - изолированная среда выполнения с центральным процессором, памятью, блоками ввода и вывода и сетевыми ресурсами, использующая ядро гостевой операционной системы.
В этом случае нет необходимости запускать отдельную операционную систему в виртуальном окружении, так как изоляция осуществляется на уровне домашней "операционки".
Статья: https://smartiqa.ru/blog/docker-basics
Docker. Основы работы с контейнерами.
- - - - - - - - -
Docker – технология создания контейнеров и управления ими.
Контейнер - изолированная среда выполнения с центральным процессором, памятью, блоками ввода и вывода и сетевыми ресурсами, использующая ядро гостевой операционной системы.
В этом случае нет необходимости запускать отдельную операционную систему в виртуальном окружении, так как изоляция осуществляется на уровне домашней "операционки".
Статья: https://smartiqa.ru/blog/docker-basics
👍1
Вопрос №41
Q: Что такое гибкая методология разработки (Agile)?
А: Это итеративный подход к управлению проектами и разработке ПО. Разработка сводится к серии коротких циклов (итераций) по 2-3 недели. После каждой итерации продукт готов к выпуску. И также после каждого цикла пересматриваются требования на актуальность. Примеры: SCRUM, Kanban.
Q: Что такое гибкая методология разработки (Agile)?
А: Это итеративный подход к управлению проектами и разработке ПО. Разработка сводится к серии коротких циклов (итераций) по 2-3 недели. После каждой итерации продукт готов к выпуску. И также после каждого цикла пересматриваются требования на актуальность. Примеры: SCRUM, Kanban.
👍5