- - - - - - - - -
10 глупых вопросов тестировщику
- - - - - - - - -
Новый герой "10 глупых вопросов" – руководитель команды автоматизированного тестирования в компании OZON, а также преподаватель курса "Профессия Тестировщик" на Skillbox – Александр Воробей. Авторы задали Александру глупые вопросы о тестах в интернете, о багах и фичах и получили на них умные ответы.
https://youtu.be/NdFAn9YbyXI
10 глупых вопросов тестировщику
- - - - - - - - -
Новый герой "10 глупых вопросов" – руководитель команды автоматизированного тестирования в компании OZON, а также преподаватель курса "Профессия Тестировщик" на Skillbox – Александр Воробей. Авторы задали Александру глупые вопросы о тестах в интернете, о багах и фичах и получили на них умные ответы.
https://youtu.be/NdFAn9YbyXI
YouTube
10 глупых вопросов ТЕСТИРОВЩИКУ
Смотри новое видео по ссылке: https://linktr.ee/10sillyquestions
Новый герой "10 глупых вопросов" – руководитель команды автоматизированного тестирования в компании OZON, а также преподаватель курса "Профессия Тестировщик" на Skillbox – Александр Воробей.…
Новый герой "10 глупых вопросов" – руководитель команды автоматизированного тестирования в компании OZON, а также преподаватель курса "Профессия Тестировщик" на Skillbox – Александр Воробей.…
Продолжаем публиковать вопросы с ответами
Q: В чем разница между обычным билдом продукта и его релизной версией?
A: Билд (Build) - это номер сборки ПО, которая была предоставлена разработчиками команде тестирования. Релизный билд - это также номер сборки ПО, но с той разницей, что она предоставляется уже конечному пользователю командой тестировщиков / разработчиков.
Q: В чем разница между обычным билдом продукта и его релизной версией?
A: Билд (Build) - это номер сборки ПО, которая была предоставлена разработчиками команде тестирования. Релизный билд - это также номер сборки ПО, но с той разницей, что она предоставляется уже конечному пользователю командой тестировщиков / разработчиков.
Очередной вопрос с ответом
Q: Что такое DDT (Data Driven Testing)?
A: Это тестирование, управляемое данными. При таком подходе тестовые данные хранятся отдельно от тест-кейсов, допустим, в файле либо в базе данных. Такое разделение логически упрощает тесты.
Data-Driven Testing используется в тех проектах, где нужно выполнить тестирование отдельных приложений в нескольких средах с большими наборами данных и стабильными test cases.
Q: Что такое DDT (Data Driven Testing)?
A: Это тестирование, управляемое данными. При таком подходе тестовые данные хранятся отдельно от тест-кейсов, допустим, в файле либо в базе данных. Такое разделение логически упрощает тесты.
Data-Driven Testing используется в тех проектах, где нужно выполнить тестирование отдельных приложений в нескольких средах с большими наборами данных и стабильными test cases.
- - - - - - - - -
Как стать тестировщиком... и дойти до Senior'а за 1,5 года?
- - - - - - - - -
В этом видео автор рассказывает свою историю о том, как не имея технического образования, опыта и связей, он с нуля освоил профессию тестировщика программного обеспечения или, как часто пишут в названиях вакансий, Quality Assurance (QA) Engineer.
https://www.youtube.com/watch?v=VhyNqDzQ55Q&list=WL&index=4
Как стать тестировщиком... и дойти до Senior'а за 1,5 года?
- - - - - - - - -
В этом видео автор рассказывает свою историю о том, как не имея технического образования, опыта и связей, он с нуля освоил профессию тестировщика программного обеспечения или, как часто пишут в названиях вакансий, Quality Assurance (QA) Engineer.
https://www.youtube.com/watch?v=VhyNqDzQ55Q&list=WL&index=4
YouTube
Как стать тестировщиком... и дойти до Senior'а за 1,5 года?
В этом видео я рассказываю свою историю о том, как не имея технического образования, опыта и связей, я с нуля освоил профессию тестировщика программного обеспечения или, как часто пишут в названиях вакансий, Quality Assurance (QA) Engineer.
Когда я только…
Когда я только…
Вопрос #1
Q: Расскажите про жизненный цикл бага
A: Работа с багом включает следующие стадии:
1. Тестировщик находит баг. Баг отправляется к менеджеру команды разработки. Status: To Do
2. Если открытый баг действительно является валидным дефектом, то команда разработки добавляет его в планирование, чтобы пофиксить. Иначе задачу на исправление бага закрывают как не валидную. Status: Closed. Resolution: Won’t fix
3. Также необходимо убедиться, что задача на фикс данного бага не была создана ранее. Иначе тикет закрывают как дубликат. Status: Closed. Resolution: Duplicate
4. Далее необходимо проверить, относится ли данный баг к функционалу, который мы планируем пофиксить в рамках текущего релиза. Если нет - мы откладываем правку данного дефекта до соответствующего релиза.
5. Тикет на исправление бага назначается разработчику. Он начинает выполнение задачи. Status: In progress
6. Когда разработчик считает, что баг пофикшен - он переводит задачу на QA. Status: Ready for QA.
7. Тестировщик проверяет, что баг действительно был исправлен и закрывает задачу. Status: Closed. Resolution: Fixed
Q: Расскажите про жизненный цикл бага
A: Работа с багом включает следующие стадии:
1. Тестировщик находит баг. Баг отправляется к менеджеру команды разработки. Status: To Do
2. Если открытый баг действительно является валидным дефектом, то команда разработки добавляет его в планирование, чтобы пофиксить. Иначе задачу на исправление бага закрывают как не валидную. Status: Closed. Resolution: Won’t fix
3. Также необходимо убедиться, что задача на фикс данного бага не была создана ранее. Иначе тикет закрывают как дубликат. Status: Closed. Resolution: Duplicate
4. Далее необходимо проверить, относится ли данный баг к функционалу, который мы планируем пофиксить в рамках текущего релиза. Если нет - мы откладываем правку данного дефекта до соответствующего релиза.
5. Тикет на исправление бага назначается разработчику. Он начинает выполнение задачи. Status: In progress
6. Когда разработчик считает, что баг пофикшен - он переводит задачу на QA. Status: Ready for QA.
7. Тестировщик проверяет, что баг действительно был исправлен и закрывает задачу. Status: Closed. Resolution: Fixed
Вопрос #2
Q: Что такое Agile тестирование и в чем заключается его необходимость?
A: Agile — это методология итеративной разработки, в которой действия по разработке и тестированию выполняются одновременно. В Agile тестирование НЕ является отдельной фазой. Разработка и тестирование выполняются в интерактивном режиме и постепенно, что приводит к качественному конечному продукту, который соответствует требованиям заказчика. Кроме того, непрерывная интеграция приводит к раннему удалению дефектов и, следовательно, экономии времени, усилий и затрат.
Q: Что такое Agile тестирование и в чем заключается его необходимость?
A: Agile — это методология итеративной разработки, в которой действия по разработке и тестированию выполняются одновременно. В Agile тестирование НЕ является отдельной фазой. Разработка и тестирование выполняются в интерактивном режиме и постепенно, что приводит к качественному конечному продукту, который соответствует требованиям заказчика. Кроме того, непрерывная интеграция приводит к раннему удалению дефектов и, следовательно, экономии времени, усилий и затрат.
Вопрос #3
Q: Что такое тест кейс?
A: Тест-кейс — это профессиональная документация тестировщика, последовательность действий, направленная на проверку какого-либо функционала, описывающая как прийти к фактическому результату.
Любой тест-кейс обязательно включает в себя:
1. Уникальный идентификатор тест-кейса — необходим для удобной организации хранения и навигации по нашим тест-наборам.
2. Название — основная тема, или идея тест-кейса. Краткое описание его сути.
3. Предусловия — описание условий, которые не имеют прямого отношения к проверяемому функционалу, но должны быть выполнены.
4. Шаги — описание последовательности действий, которая должна привести нас к ожидаемому результату
5. Ожидаемый результат — результат: что мы ожидаем увидеть после выполнения шагов.
Q: Что такое тест кейс?
A: Тест-кейс — это профессиональная документация тестировщика, последовательность действий, направленная на проверку какого-либо функционала, описывающая как прийти к фактическому результату.
Любой тест-кейс обязательно включает в себя:
1. Уникальный идентификатор тест-кейса — необходим для удобной организации хранения и навигации по нашим тест-наборам.
2. Название — основная тема, или идея тест-кейса. Краткое описание его сути.
3. Предусловия — описание условий, которые не имеют прямого отношения к проверяемому функционалу, но должны быть выполнены.
4. Шаги — описание последовательности действий, которая должна привести нас к ожидаемому результату
5. Ожидаемый результат — результат: что мы ожидаем увидеть после выполнения шагов.
Вопрос #1
Q: Что такое Use Case?
A: Юзкейс — это описание набора последовательностей действий системы, в том числе вариантов таких последовательностей, в результате которых получается наблюдаемый результат, который обладает некой ценностью для кого-то из участников процесса.
Более краткое и емкое определение:
Юзкейс — это текст,
описывающий сценарий
взаимодействия с системой,
приводящий к значимому результату.
Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.
Зачем тестировщику юзкейсы? Для тестировщиков Use Cases являются отличной базой для формирования тестовых сценариев — Test Cases — так как они описывают, в каком контексте должно производиться каждое действие пользователя. Use Cases, по умолчанию, являются тестируемыми требованиями, так как в них всегда указана цель, которой нужно достигнуть, и какие шаги надо для этого воспроизвести.
Q: Что такое Use Case?
A: Юзкейс — это описание набора последовательностей действий системы, в том числе вариантов таких последовательностей, в результате которых получается наблюдаемый результат, который обладает некой ценностью для кого-то из участников процесса.
Более краткое и емкое определение:
Юзкейс — это текст,
описывающий сценарий
взаимодействия с системой,
приводящий к значимому результату.
Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.
Зачем тестировщику юзкейсы? Для тестировщиков Use Cases являются отличной базой для формирования тестовых сценариев — Test Cases — так как они описывают, в каком контексте должно производиться каждое действие пользователя. Use Cases, по умолчанию, являются тестируемыми требованиями, так как в них всегда указана цель, которой нужно достигнуть, и какие шаги надо для этого воспроизвести.
Вопрос #8
Q: Приведите пример Use Case
A: Use Case. Регистрация пассажира на рейс.
Краткое описание
---—
Система: Система регистрации пассажира на рейс
Основное действующее лицо: Пассажир
Цель: Зарегистрироваться на рейс
Триггер: Пассажир решает зарегистрироваться на рейс и заходит на страницу регистрации сайта
Результат: Информация о регистрации пассажира сохранена. У пассажира есть посадочный талон.
Основной поток событий
---—
Шаг 1. [ Система ] Запрашивает фамилию и код бронирования
Шаг 2. [ Пассажир ] Вводит фамилию и код бронирования
Комментарий: Код бронирования: 7 символов, заглавные латинские и цифры. Например: MTDTC1
Шаг 3. [ Система ] Проверяет, что приобретен билет на этот рейс на имя этого Пассажира
Шаг 4. [ Система ] Сохраняет информацию о регистрации Пассажира на рейс
Шаг 5. [ Система ] Подтверждает Пассажиру, что он зарегистрирован на рейс
Шаг 6. [ Система ] Выводит для печати посадочный талон
Шаг 7. [ Пассажир ] Отправляет посадочный талон на печать
С помощью этого Use Case мы можем выявить большой набор функциональных требований: практически каждая строчка Use Case является отдельным функциональным требованием.
Q: Приведите пример Use Case
A: Use Case. Регистрация пассажира на рейс.
Краткое описание
---—
Система: Система регистрации пассажира на рейс
Основное действующее лицо: Пассажир
Цель: Зарегистрироваться на рейс
Триггер: Пассажир решает зарегистрироваться на рейс и заходит на страницу регистрации сайта
Результат: Информация о регистрации пассажира сохранена. У пассажира есть посадочный талон.
Основной поток событий
---—
Шаг 1. [ Система ] Запрашивает фамилию и код бронирования
Шаг 2. [ Пассажир ] Вводит фамилию и код бронирования
Комментарий: Код бронирования: 7 символов, заглавные латинские и цифры. Например: MTDTC1
Шаг 3. [ Система ] Проверяет, что приобретен билет на этот рейс на имя этого Пассажира
Шаг 4. [ Система ] Сохраняет информацию о регистрации Пассажира на рейс
Шаг 5. [ Система ] Подтверждает Пассажиру, что он зарегистрирован на рейс
Шаг 6. [ Система ] Выводит для печати посадочный талон
Шаг 7. [ Пассажир ] Отправляет посадочный талон на печать
С помощью этого Use Case мы можем выявить большой набор функциональных требований: практически каждая строчка Use Case является отдельным функциональным требованием.
Вопрос #9
Q: Что такое CRUD тестирование?
A: CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (create), чтение (read), модификация (update), удаление (delete). Введён Джеймсом Мартином (англ. James Martin) в 1983 году как стандартная классификация функций по манипуляции данными.
CRUD тестирование представляет собой тестирование методом “Черного ящика”. Также в большинстве случаев понятие CRUD тестирование можно считать синонимом Тестирования БД. Очевидно, базы данных являются неотъемлемой часть любого современного приложения: неважно Web или Desktop - данные же должны где-то храниться. В настоящее время на рынке огромное количество вариантов систем управления БД, при этом каждая из них обладает своим набором характеристик.
Если говорить о CRUD операциях с точки зрения конечного пользователя, то можно представить их в таком виде:
1. Create: Сохранение пользователем новых данных
2. Read/Retrieve: Поиск или просмотр пользователем существующих данных
3. Update: Редактирование пользователем существующих данных
4. Delete: Удаление пользователем данных из системы
Q: Что такое CRUD тестирование?
A: CRUD — акроним, обозначающий четыре базовые функции, используемые при работе с базами данных: создание (create), чтение (read), модификация (update), удаление (delete). Введён Джеймсом Мартином (англ. James Martin) в 1983 году как стандартная классификация функций по манипуляции данными.
CRUD тестирование представляет собой тестирование методом “Черного ящика”. Также в большинстве случаев понятие CRUD тестирование можно считать синонимом Тестирования БД. Очевидно, базы данных являются неотъемлемой часть любого современного приложения: неважно Web или Desktop - данные же должны где-то храниться. В настоящее время на рынке огромное количество вариантов систем управления БД, при этом каждая из них обладает своим набором характеристик.
Если говорить о CRUD операциях с точки зрения конечного пользователя, то можно представить их в таком виде:
1. Create: Сохранение пользователем новых данных
2. Read/Retrieve: Поиск или просмотр пользователем существующих данных
3. Update: Редактирование пользователем существующих данных
4. Delete: Удаление пользователем данных из системы
Вопрос #10
Q: Что такое тест-план и из чего он состоит?
A: Тест-план является частью проектной документации и основным документом в тестировании, описывающим весь объем работ по тестированию.
При создании тест-плана можно использовать один из общепринятых шаблонов или создать свой собственный документ, подходящий под ваши нужды.
Варианты общепринятых шаблонов:
1. Темплейты стандарта ISO/IEC/IEEE 29119
2. Шаблон для подготовки плана по тестированию согласно методологии Rational Unified Process (RUP).
3. Тест-план в формате Mind map
В случае, если вами принято решение самостоятельно определить формат документа, то он должен как минимум отвечать на следующие вопросы:
1. [ Что надо ] тестировать (объект тестирования: система, приложение, оборудование)
2. [ Что будете ] тестировать (список функций и компонентов тестируемой системы)
3. [ Как ] будете тестировать (стратегия тестирования – виды тестирования и их применение по отношению к тестируемому объекту)
4. [ Тестовые окружения ], на которых необходимо проверять программный продукт
5. [ Когда ] будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, учёт зависимостей тестовых активностей от задач разработки и смежных групп)
6. [ Риски ] и стратегии по их разрешению
Q: Что такое тест-план и из чего он состоит?
A: Тест-план является частью проектной документации и основным документом в тестировании, описывающим весь объем работ по тестированию.
При создании тест-плана можно использовать один из общепринятых шаблонов или создать свой собственный документ, подходящий под ваши нужды.
Варианты общепринятых шаблонов:
1. Темплейты стандарта ISO/IEC/IEEE 29119
2. Шаблон для подготовки плана по тестированию согласно методологии Rational Unified Process (RUP).
3. Тест-план в формате Mind map
В случае, если вами принято решение самостоятельно определить формат документа, то он должен как минимум отвечать на следующие вопросы:
1. [ Что надо ] тестировать (объект тестирования: система, приложение, оборудование)
2. [ Что будете ] тестировать (список функций и компонентов тестируемой системы)
3. [ Как ] будете тестировать (стратегия тестирования – виды тестирования и их применение по отношению к тестируемому объекту)
4. [ Тестовые окружения ], на которых необходимо проверять программный продукт
5. [ Когда ] будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, учёт зависимостей тестовых активностей от задач разработки и смежных групп)
6. [ Риски ] и стратегии по их разрешению
Smartiqa - платформа о технологиях, программировании и тестировании ПО.
Сайт: https://smartiqa.ru
Канал YouTube: https://www.youtube.com/channel/UCk_7MNLSD0S2fxi0EQ-V6lQ
Vkontakte: https://vk.com/smartiqa
Vkontakte Python: https://vk.com/smartiqa_python
Сайт: https://smartiqa.ru
Канал YouTube: https://www.youtube.com/channel/UCk_7MNLSD0S2fxi0EQ-V6lQ
Vkontakte: https://vk.com/smartiqa
Vkontakte Python: https://vk.com/smartiqa_python
smartiqa.ru
IT Блог: Программирование и QA
Smartiqa - платформа о технологиях, программировании и тестировании ПО. Каждую неделю мы публикуем актуальные новости из мира разработчиков и QA, курсы, образовательные статьи и переводы — создаём поток информации для IT специалистов и всех, кто считает своим…
👍3
Programming & QA pinned «Smartiqa - платформа о технологиях, программировании и тестировании ПО. Сайт: https://smartiqa.ru Канал YouTube: https://www.youtube.com/channel/UCk_7MNLSD0S2fxi0EQ-V6lQ Vkontakte: https://vk.com/smartiqa Vkontakte Python: https://vk.com/smartiqa_python»