Вопрос №29
Q: Какие SCRUM мероприятия вы знаете?
A: Четко установленные мероприятия используются в Скраме для того, чтобы придать процессу разработки регулярность и минимизировать потребность в совещаниях, не предписанных Скрамом. Скрам использует ограниченные по времени мероприятия, поэтому каждое мероприятие имеет свой верхний предел продолжительности. Это гарантирует, что планирование будет проводиться в предназначенное время, не позволяя потерь времени в процессе планирования.
Кроме главного мероприятия, собственно самого Спринта, который включает все остальные мероприятия, каждое мероприятие Скрама является возможностью что-то проверить и провести адаптацию чего-нибудь. Такие мероприятия являются специально разработанными для обеспечения необходимой прозрачности и контроля.
И все-таки что же такое Спринт?
Спринт является сердцем Скрама. Это промежуток времени длиной в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта.
Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.
Во время Спринта:
1. Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal).
2. Состав Команды Разработчиков и цели по качеству продукта остаются неизменными.
3. Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.
В течение Спринта регулярно проводятся следующие мероприятия(Meetings):
1. Планирования Спринта(Sprint Planning);
2. Ежедневные Скрамы(Standups);
3. Обзоры Спринта(Sprint Review);
4. Ретроспективы Спринта(Sprint Retrospective).
Q: Какие SCRUM мероприятия вы знаете?
A: Четко установленные мероприятия используются в Скраме для того, чтобы придать процессу разработки регулярность и минимизировать потребность в совещаниях, не предписанных Скрамом. Скрам использует ограниченные по времени мероприятия, поэтому каждое мероприятие имеет свой верхний предел продолжительности. Это гарантирует, что планирование будет проводиться в предназначенное время, не позволяя потерь времени в процессе планирования.
Кроме главного мероприятия, собственно самого Спринта, который включает все остальные мероприятия, каждое мероприятие Скрама является возможностью что-то проверить и провести адаптацию чего-нибудь. Такие мероприятия являются специально разработанными для обеспечения необходимой прозрачности и контроля.
И все-таки что же такое Спринт?
Спринт является сердцем Скрама. Это промежуток времени длиной в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта.
Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.
Во время Спринта:
1. Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal).
2. Состав Команды Разработчиков и цели по качеству продукта остаются неизменными.
3. Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.
В течение Спринта регулярно проводятся следующие мероприятия(Meetings):
1. Планирования Спринта(Sprint Planning);
2. Ежедневные Скрамы(Standups);
3. Обзоры Спринта(Sprint Review);
4. Ретроспективы Спринта(Sprint Retrospective).
👍3
Вопрос №30
Q: Что такое качество(Quality)?
A: Это когда клиент доволен. Да, такое определение верно, но это субъективная оценка. И зависит от того, кто является клиентом. Так как у каждого клиента своё понимание качества (а так же у тестера, у менеджера, у покупателя продукта). Для тестера, качество — это соответствие требованиям.
Q: Что такое качество(Quality)?
A: Это когда клиент доволен. Да, такое определение верно, но это субъективная оценка. И зависит от того, кто является клиентом. Так как у каждого клиента своё понимание качества (а так же у тестера, у менеджера, у покупателя продукта). Для тестера, качество — это соответствие требованиям.
👍3
- - - - - - - - -
Полезные статьи. Часть 7.
- - - - - - - - -
1. Ссылки для UX-специалистов: https://habr.com/ru/post/247493/
2. Как не надо проводить нагрузочное тестирование: https://xwizard-test.blogspot.com/2015/01/blog-post_30.html
3. Регрессионное тестирование: https://33testers.blogspot.com/2015/06/blog-post_17.html
Полезные статьи. Часть 7.
- - - - - - - - -
1. Ссылки для UX-специалистов: https://habr.com/ru/post/247493/
2. Как не надо проводить нагрузочное тестирование: https://xwizard-test.blogspot.com/2015/01/blog-post_30.html
3. Регрессионное тестирование: https://33testers.blogspot.com/2015/06/blog-post_17.html
Хабр
01 Ссылки для UX-специалистов
В этой подборке я хочу поделиться информационными ресурсами, где можно почерпать новые знания, отследить новые методы, техники и аналитку, а также улучшить свои...
👍2
- - - - - - - - -
Что делает тестировщик? Тестирование на примере
- - - - - - - - -
Видео для тех, кто не знает, что делает тестировщик. Автор видео показал: как выглядит тестирование на примере, поиск багов и составление баг репорта.
https://www.youtube.com/watch?v=bxcvLJf19bQ
https://www.youtube.com/watch?v=bxcvLJf19bQ
Что делает тестировщик? Тестирование на примере
- - - - - - - - -
Видео для тех, кто не знает, что делает тестировщик. Автор видео показал: как выглядит тестирование на примере, поиск багов и составление баг репорта.
https://www.youtube.com/watch?v=bxcvLJf19bQ
https://www.youtube.com/watch?v=bxcvLJf19bQ
👍2
Вопрос №31
Q: Что такое обеспечение качества продукта (Software Quality Assurance)?
A: Это процесс отслеживания и совершенствования всех видов деятельности, связанных с разработкой программного обеспечения. Этот процесс включает в себя всё: начиная со сбора требований, дизайна, код-ревью, тестирования, имплементирования и заканчивая обслуживанием (технической поддержкой на стороне клиента).
Q: Что такое обеспечение качества продукта (Software Quality Assurance)?
A: Это процесс отслеживания и совершенствования всех видов деятельности, связанных с разработкой программного обеспечения. Этот процесс включает в себя всё: начиная со сбора требований, дизайна, код-ревью, тестирования, имплементирования и заканчивая обслуживанием (технической поддержкой на стороне клиента).
👍2
Вопрос №32
Q: Возможно ли найти и исправить все баги в программном продукте? Зачем нужно тестирование?
A: Нет, невозможно. Но тестирование необходимо, чтобы уменьшить количество ошибок. Тестирование добивается этого путем установления и соблюдения бизнес-процессов в своей области (планирование тестирования, отслеживание ошибок, отчет об ошибках, автоматизация тестирования, сертификация релиза и другие).
Q: Возможно ли найти и исправить все баги в программном продукте? Зачем нужно тестирование?
A: Нет, невозможно. Но тестирование необходимо, чтобы уменьшить количество ошибок. Тестирование добивается этого путем установления и соблюдения бизнес-процессов в своей области (планирование тестирования, отслеживание ошибок, отчет об ошибках, автоматизация тестирования, сертификация релиза и другие).
👍2
Вопрос №33
Q: Что такое тестирование с помощью “черного\белого\серого” ящика?
A: 1. Тестирование “черного” ящика — методология, при которой тестер не имеет доступа к исходному коду (UI\UX тестирование, тестирование установки, тестирование локализации)
2. Тестирование “белого” ящика — методология, при которой тестер (чаще сам разработчик или тестер-автоматизатор) имеет доступ к исходному коду продукта(Unit тестирование). Как правило, в данном случае баг репорт отражает именно ошибки в коде, а не в функциональном поведении.
3. Тестирование “серого” ящика — это расширенная методология “черного ящика”, при которой тестер также не имеет доступ к исходному коду(или доступ сильно граничен), но представляет, как система устроена логически, может поделить её на модули и искать в них ошибки, используя специальные методики (например, взаимодействие веб-приложений по сети).
Q: Что такое тестирование с помощью “черного\белого\серого” ящика?
A: 1. Тестирование “черного” ящика — методология, при которой тестер не имеет доступа к исходному коду (UI\UX тестирование, тестирование установки, тестирование локализации)
2. Тестирование “белого” ящика — методология, при которой тестер (чаще сам разработчик или тестер-автоматизатор) имеет доступ к исходному коду продукта(Unit тестирование). Как правило, в данном случае баг репорт отражает именно ошибки в коде, а не в функциональном поведении.
3. Тестирование “серого” ящика — это расширенная методология “черного ящика”, при которой тестер также не имеет доступ к исходному коду(или доступ сильно граничен), но представляет, как система устроена логически, может поделить её на модули и искать в них ошибки, используя специальные методики (например, взаимодействие веб-приложений по сети).
👍3
- - - - - - - - -
Тестирование 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