- - - - - - - - -
Как стать тестировщиком... и дойти до 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»
Вопрос #11
Q: Что такое уровни детализации тест-плана?
A: В зависимости от особенностей проекта и методологии работы, бывает достаточным создание одного тест-плана или нескольких наследуемых тест-планов. В случае создания иерархии планов, обобщающий называется Мастер тест-планом, а вложенные — просто тест-планом или детальным тест-планом.
[ Master Test Plan ]
Мастер тест-план создается в двух случаях:
1. Если продукт имеет множество релизов или итераций, между которыми сохраняется общая информация, которую нет смысла повторять
2. Если различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа
В Мастер тест-плане содержится следующая информация:
1. Общая информация о продукте, ссылки на документацию, баг-трекер и прочие проектные ресурсы
2. Общие правила тестирования: требования к заводимым дефектам, условия принятия сборки на тестирование
3. Критерии готовности продукта к выпуску, метрики качества
4. Используемые инструменты и техники
[ Test Plan / Level Test PLan ]
Детальный тест-план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта. Его основная цель — кратко и доходчиво отразить задачи тестирования.
В детальном тест-плане содержится следующая информация:
1. Перечень областей тестирования с приоритетами
2. Стратегия тестирования
3. Проектные риски
4. Ресурсы, необходимые для выполнения задач
5. Проектный план (сроки готовности ключевых задач)
Q: Что такое уровни детализации тест-плана?
A: В зависимости от особенностей проекта и методологии работы, бывает достаточным создание одного тест-плана или нескольких наследуемых тест-планов. В случае создания иерархии планов, обобщающий называется Мастер тест-планом, а вложенные — просто тест-планом или детальным тест-планом.
[ Master Test Plan ]
Мастер тест-план создается в двух случаях:
1. Если продукт имеет множество релизов или итераций, между которыми сохраняется общая информация, которую нет смысла повторять
2. Если различные тестовые команды работают над одним продуктом, выполняя различные задачи, которые необходимо объединить в рамках одного документа
В Мастер тест-плане содержится следующая информация:
1. Общая информация о продукте, ссылки на документацию, баг-трекер и прочие проектные ресурсы
2. Общие правила тестирования: требования к заводимым дефектам, условия принятия сборки на тестирование
3. Критерии готовности продукта к выпуску, метрики качества
4. Используемые инструменты и техники
[ Test Plan / Level Test PLan ]
Детальный тест-план составляется на каждый релиз/итерацию или для каждой команды в рамках проекта. Его основная цель — кратко и доходчиво отразить задачи тестирования.
В детальном тест-плане содержится следующая информация:
1. Перечень областей тестирования с приоритетами
2. Стратегия тестирования
3. Проектные риски
4. Ресурсы, необходимые для выполнения задач
5. Проектный план (сроки готовности ключевых задач)
Вопрос #12
Q: Как правильно оценить риски по время составления плана тестирования?
A: Риск — это вероятность того, что дефекты в проекте повлекут за собой финансовые проблемы, нанесут урон репутации компании, снизят доверие клиентов, увеличат сроки исполнения проекта и затраты на его реализацию. Стратегия управления рисками — часть планирования тестирования.
Информация о рисках, влияющих на проект, используется при расстановке приоритетов при планировании тестирования. Например, если производительность системы — наиболее рискованная область, тестирование производительности может выполняться как можно раньше.
Определение рисков проекта:
1. Какие функции и атрибуты проекта являются критическим функционалом?
2. Насколько видимой будет проблема в функции/атрибуте для пользователей, заказчика и других заинтересованных лиц?
3. Насколько часто используется функция?
Риски также могут не относиться непосредственно к продукту, но влиять на приоритеты тестирования:
1. Проблемы с квалификацией персонала
2. Нехватка персонала
3. Проблемы с координацией и кооперацией
4. Нехватка инструментов
Q: Как правильно оценить риски по время составления плана тестирования?
A: Риск — это вероятность того, что дефекты в проекте повлекут за собой финансовые проблемы, нанесут урон репутации компании, снизят доверие клиентов, увеличат сроки исполнения проекта и затраты на его реализацию. Стратегия управления рисками — часть планирования тестирования.
Информация о рисках, влияющих на проект, используется при расстановке приоритетов при планировании тестирования. Например, если производительность системы — наиболее рискованная область, тестирование производительности может выполняться как можно раньше.
Определение рисков проекта:
1. Какие функции и атрибуты проекта являются критическим функционалом?
2. Насколько видимой будет проблема в функции/атрибуте для пользователей, заказчика и других заинтересованных лиц?
3. Насколько часто используется функция?
Риски также могут не относиться непосредственно к продукту, но влиять на приоритеты тестирования:
1. Проблемы с квалификацией персонала
2. Нехватка персонала
3. Проблемы с координацией и кооперацией
4. Нехватка инструментов
- - - - - - - - -
Собеседование на тестировщика (Junior QA) / Вопросы на собеседовании QA
- - - - - - - - -
В видео говорится о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное письмо? Именно правильно составленное резюме поможет вам без труда найти работу или как минимум попасть на интервью.
https://www.youtube.com/watch?v=UYZgZ2uYbfw
Собеседование на тестировщика (Junior QA) / Вопросы на собеседовании QA
- - - - - - - - -
В видео говорится о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное письмо? Именно правильно составленное резюме поможет вам без труда найти работу или как минимум попасть на интервью.
https://www.youtube.com/watch?v=UYZgZ2uYbfw
YouTube
Как создать резюме для тестировщика и других IT-специалистов
🚀 Забери интенсив по трудоустройству с личным разбором резюме https://stepik.org/a/248267
Сегодня поговорим о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное…
Сегодня поговорим о создании эффективного резюме для тестировщика, которое можно применить для любых IT-специалистов, а также о том: как написать грамотное мотивационное…