- - - - - - - - -
Инструментарий для нагрузочного тестирования и не только
- - - - - - - - -
Компания Altenar разрабатывает программное обеспечение для беттинга. Как и для многих разработчиков для них очень важна производительность, в связи с этим особое внимание они уделяют нагрузочному тестированию. Под катом подробный рассказ про их опыт выстраивания структуры данного вида тестирования.
https://m.habr.com/ru/post/554266/
Инструментарий для нагрузочного тестирования и не только
- - - - - - - - -
Компания Altenar разрабатывает программное обеспечение для беттинга. Как и для многих разработчиков для них очень важна производительность, в связи с этим особое внимание они уделяют нагрузочному тестированию. Под катом подробный рассказ про их опыт выстраивания структуры данного вида тестирования.
https://m.habr.com/ru/post/554266/
Хабр
Инструментарий для нагрузочного тестирования и не только
Мы в Altenar разрабатываем программное обеспечение для беттинга. Как и для многих разработчиков для нас очень важна производительность, в связи с этим особое внимание мы уделяем нагрузочному...
Ну а мы с вами прощаемся... Прощаемся с первым месяцем лета — июнем. Но перед тем, как окончательно закрыть эту полную на события страницу, напоминаем вам о нашем дайджесте публикаций.
1. [ Статья ] Инструментарий для нагрузочного тестирования и не только: https://m.habr.com/ru/post/554266/
2. [ Видео ] Когда стоит выбрать Appium в роли фреймворка для мобильных автотестов?: https://www.youtube.com/watch?v=ROFg5A6QESU
3. [ Видео ] Инструменты автоматизации на JS: преимущества и возможности: https://youtu.be/fyl3oflPS3U
4. [ Курс "Работа с Git" ] Урок 5. Слияние изменений и
продвинутая работа с ветками. Команды: merge, cherry-pick, rebase.: https://smartiqa.ru/courses/git/lesson-5
1. [ Статья ] Инструментарий для нагрузочного тестирования и не только: https://m.habr.com/ru/post/554266/
2. [ Видео ] Когда стоит выбрать Appium в роли фреймворка для мобильных автотестов?: https://www.youtube.com/watch?v=ROFg5A6QESU
3. [ Видео ] Инструменты автоматизации на JS: преимущества и возможности: https://youtu.be/fyl3oflPS3U
4. [ Курс "Работа с Git" ] Урок 5. Слияние изменений и
продвинутая работа с ветками. Команды: merge, cherry-pick, rebase.: https://smartiqa.ru/courses/git/lesson-5
Возможно вы заядлый тестировщик или же новичок в этом деле, все равно вам будут полезны вопросы, которые мы подготовили. Полезными они будут, потому что к вопросам мы также написали и ответы. Один пост – один вопрос-ответ. Следите за обновлениями.
Q: В чем разница между QA и тестированием?
A: Основная задача QA (Quality Assurance) - следить за качеством самого процесса производства ПО. В то время как протестировать ПО - значит просто убедиться в том, что финальная версия продукта соответствует предъявляемым требованиям.
Q: В чем разница между QA и тестированием?
A: Основная задача QA (Quality Assurance) - следить за качеством самого процесса производства ПО. В то время как протестировать ПО - значит просто убедиться в том, что финальная версия продукта соответствует предъявляемым требованиям.
- - - - - - - - -
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 является отдельным функциональным требованием.