Сама не поняла, но удалила как-то подпись к скринам выше 🥲
Если кратко:
Собираю 10 человек на курс
Первый поток - стоимость 50т.р., возможна рассрочка
Место забиваем по предоплате
Следующий поток будет дороже!
Стартуем в конце апреля, обучение длится 3 месяца (17-20 занятий)
Подробная инфа в скринах выше и моем инстаграме (закреп «курс»)
https://www.instagram.com/lattelegs/profilecard/?igsh=ZmZtNnlpMGFtOXVk
По всем вопросам пишите в комментарии, в личку, в инсту - на все отвечу💕
Если кратко:
Собираю 10 человек на курс
Первый поток - стоимость 50т.р., возможна рассрочка
Место забиваем по предоплате
Следующий поток будет дороже!
Стартуем в конце апреля, обучение длится 3 месяца (17-20 занятий)
Подробная инфа в скринах выше и моем инстаграме (закреп «курс»)
https://www.instagram.com/lattelegs/profilecard/?igsh=ZmZtNnlpMGFtOXVk
По всем вопросам пишите в комментарии, в личку, в инсту - на все отвечу
Please open Telegram to view this post
VIEW IN TELEGRAM
👏5❤4🔥2
Модель OSI и TCP:IP.pdf
211.8 KB
Шпаргалка:
Модель OSI и TCP/IP
Это мой самый нелюбимый вопрос на собесе😭
Модель OSI и TCP/IP
Это мой самый нелюбимый вопрос на собесе
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥3🙏3
Какими должны быть требования?
(Этот вопрос уже несколько раз попадался моим ученикам на собеседованиях)
Давайте разбираться вместе
👇 👇 👇
Ключевые концепции тестирования требований
Что такое требования к продукту?
Требование — это спецификация того, что должно быть реализовано.
В нем описывается поведение и атрибуты системы.
Процесс определения требований имеет огромное значение в процессе разработки требований.
Он представляет собой третий этап, следующий за сбором и анализом требований, которым управляют такие роли, как бизнес-аналитики, системные аналитики и дизайнеры продуктов, которые варьируются от проекта к проекту.
Цель состоит в том, чтобы создать документ c требованиями или спецификацию с соответствующей детализацией.
Этот документ будет содержать все требования к дизайну, проверке и техническому обслуживанию продукта.
Требования - первое, на что обращает внимание команда проекта, это основа для проектирования и разработки продукта.
Стив Макконнелл в своей книге "Сколько стоит программный проект" указывает, что около 30 % ошибок вносится в продукт при разработке требований.
Очевидно, что гораздо проще и дешевле исправить дефект в паре строк требований, чем потом переделывать несколько сотен (или даже тысяч) строк кода.
Почему тестирование требований важно?
Тестирование требований - необходимая и очень важная процедура, которая помогает оптимизировать работу команды и избежать недопонимания, а также позволяет понять, могут ли эти требования быть выполнены с точки зрения времени, ресурсов и бюджета.
В связи с вышесказанным, при разработке программного обеспечения тестирование должно проводиться уже на этапе разработки спецификации (требований).
Ключевыми характеристиками хороших требований являются:
*️⃣ Полнота.
Все ли описано? Ничего ли не забыли? Что, если у нас все еще есть неописанный функционал или пользовательский сценарий? Документация должна предоставлять максимально четкую информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом.
*️⃣ Корректность и согласованность.
Все утверждения должны быть правильными, правдивыми и иметь смысл.
*️⃣ Последовательность. Требования не должны противоречить сами себе. Обычно это происходит, когда требований много. Аналитик просто забывает, что уже писал о параметре, и снова придумывает его поведение. Иногда он придумывает что-то немного другое.
*️⃣ Ясность.
Требования должны быть прозрачными и понятными для всех, с возможностью только одной интерпретации.
*️⃣ Тестируемость.
Можно ли протестировать эту функциональность? Подумайте об этом заранее. А бывает, что разработчик уже все сделал, и только тогда тестировщик понимает, что задачу никак нельзя проверить. Или можно проверить вручную, но нельзя написать автотесты, фреймворк под новую функциональность не заточен. Это может быть проблемой, если в компании все проверки автоматизируются.
*️⃣ Прослеживаемость. Требование полностью или частично соответствует потребностям бизнеса, заявленным заинтересованными сторонами, и это задокументировано.
*️⃣ Атомарность. Требование не может быть разделено на несколько более детальных требований без потери полноты.
*️⃣ Выполнимость. Требование может быть реализовано в рамках данного проекта.
*️⃣ Актуальность.
Требование не устарело по прошествии времени.
*️⃣ Модифицируемость.
Упорядочены по важности, стабильности и срочности.
(Этот вопрос уже несколько раз попадался моим ученикам на собеседованиях)
Давайте разбираться вместе
Ключевые концепции тестирования требований
Что такое требования к продукту?
Требование — это спецификация того, что должно быть реализовано.
В нем описывается поведение и атрибуты системы.
Процесс определения требований имеет огромное значение в процессе разработки требований.
Он представляет собой третий этап, следующий за сбором и анализом требований, которым управляют такие роли, как бизнес-аналитики, системные аналитики и дизайнеры продуктов, которые варьируются от проекта к проекту.
Цель состоит в том, чтобы создать документ c требованиями или спецификацию с соответствующей детализацией.
Этот документ будет содержать все требования к дизайну, проверке и техническому обслуживанию продукта.
Требования - первое, на что обращает внимание команда проекта, это основа для проектирования и разработки продукта.
Стив Макконнелл в своей книге "Сколько стоит программный проект" указывает, что около 30 % ошибок вносится в продукт при разработке требований.
Очевидно, что гораздо проще и дешевле исправить дефект в паре строк требований, чем потом переделывать несколько сотен (или даже тысяч) строк кода.
Почему тестирование требований важно?
Тестирование требований - необходимая и очень важная процедура, которая помогает оптимизировать работу команды и избежать недопонимания, а также позволяет понять, могут ли эти требования быть выполнены с точки зрения времени, ресурсов и бюджета.
В связи с вышесказанным, при разработке программного обеспечения тестирование должно проводиться уже на этапе разработки спецификации (требований).
Ключевыми характеристиками хороших требований являются:
Все ли описано? Ничего ли не забыли? Что, если у нас все еще есть неописанный функционал или пользовательский сценарий? Документация должна предоставлять максимально четкую информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом.
Все утверждения должны быть правильными, правдивыми и иметь смысл.
Требования должны быть прозрачными и понятными для всех, с возможностью только одной интерпретации.
Можно ли протестировать эту функциональность? Подумайте об этом заранее. А бывает, что разработчик уже все сделал, и только тогда тестировщик понимает, что задачу никак нельзя проверить. Или можно проверить вручную, но нельзя написать автотесты, фреймворк под новую функциональность не заточен. Это может быть проблемой, если в компании все проверки автоматизируются.
Требование не устарело по прошествии времени.
Упорядочены по важности, стабильности и срочности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤2👍2🤩2
Продолжаем развернуто изучать тестирование требований:
Техники тестирования требований
🔘 Взаимный просмотр
-беглый просмотр
-технический просмотр
🔘 Формальная инспекция
🔘 Вопросы
🔘 Написание тест-кейсов и чек листов
🔘 Исследование поведения системы
🔘 Рисунки (графическое представление)
🔘 Прототипирование
Идеи тестирования требований
🔘 Полнота
Проверка полноты требований:
-Проверьте каждый объект на соответствие требованиям CRUDL (Create, Read, Update, Delete (или Deactivate), List).
-Подумайте, что может пойти не так, какими могут быть негативные сценарии и граничные условия (сценарии использования).
-Проверьте, что в сложных условиях "если - то" описаны все варианты (таблица решений).
🔘 Корректность
Если требование корректно, значит, оно не содержит неверной и неточной информации. Этот критерий обычно сложно проверить. Помогает, если требования проверяет человек, хорошо разбирающийся в предметной области.
🔘 Согласованность
Проверяя согласованность, обратите внимание на:
Одно и то же требование написано несколько раз в разных местах - если вы его измените, то, скорее всего, где-то забудете.
Союз "и" в требованиях — это несколько разных требований, и они могут противоречить друг другу. Например, "быстро, хорошо и дешево".
🔘 Ясность
Все члены команды должны понимать требования однозначно:
Терминология - все должны понимать, что стоит за каждым понятием. Одни и те же вещи должны называться одним и тем же понятием.
Качественные определения - "красиво", "удобно", "быстро". Такие требования должны быть заменены конкретными параметрами, чтобы все понимали, как их проверять.
Требования должны быть написаны простым языком – тогда понятно, "кто что делает".
🔘 Тестируемость/верифицируемость
Один из самых важных критериев - проверяемость.
Как вы узнаете, что требование выполнено? Как вы узнаете, что проект в целом успешен? Если у требования нет тест-кейса или вы не можете сразу придумать тест, это плохое требование.
Например, вы можете проверить пользовательскую историю:
Критерии приемки присутствуют в пользовательской истории.
Критерии приемки точны и недвусмысленны.
QA-инженер может написать чек лист или тест-кейсы для этой истории пользователя.
🔘 Выполняемость
Когда вы проверяете выполнимость требований, посмотрите, можно ли это вообще сделать в рамках существующих ограничений.
Обычно QA-инженеры делают это вместе с разработчиками, поскольку вторые обладают более глубокой технической экспертизой.
Техники тестирования требований
-беглый просмотр
-технический просмотр
Идеи тестирования требований
Проверка полноты требований:
-Проверьте каждый объект на соответствие требованиям CRUDL (Create, Read, Update, Delete (или Deactivate), List).
-Подумайте, что может пойти не так, какими могут быть негативные сценарии и граничные условия (сценарии использования).
-Проверьте, что в сложных условиях "если - то" описаны все варианты (таблица решений).
Если требование корректно, значит, оно не содержит неверной и неточной информации. Этот критерий обычно сложно проверить. Помогает, если требования проверяет человек, хорошо разбирающийся в предметной области.
Проверяя согласованность, обратите внимание на:
Одно и то же требование написано несколько раз в разных местах - если вы его измените, то, скорее всего, где-то забудете.
Союз "и" в требованиях — это несколько разных требований, и они могут противоречить друг другу. Например, "быстро, хорошо и дешево".
Все члены команды должны понимать требования однозначно:
Терминология - все должны понимать, что стоит за каждым понятием. Одни и те же вещи должны называться одним и тем же понятием.
Качественные определения - "красиво", "удобно", "быстро". Такие требования должны быть заменены конкретными параметрами, чтобы все понимали, как их проверять.
Требования должны быть написаны простым языком – тогда понятно, "кто что делает".
Один из самых важных критериев - проверяемость.
Как вы узнаете, что требование выполнено? Как вы узнаете, что проект в целом успешен? Если у требования нет тест-кейса или вы не можете сразу придумать тест, это плохое требование.
Например, вы можете проверить пользовательскую историю:
Критерии приемки присутствуют в пользовательской истории.
Критерии приемки точны и недвусмысленны.
QA-инженер может написать чек лист или тест-кейсы для этой истории пользователя.
Когда вы проверяете выполнимость требований, посмотрите, можно ли это вообще сделать в рамках существующих ограничений.
Обычно QA-инженеры делают это вместе с разработчиками, поскольку вторые обладают более глубокой технической экспертизой.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍3❤🔥1
Я сама не заметила как нас стало больше трехста человек в группе 😍
Ниже поговорим про тест-кейсы☕️
Ниже поговорим про тест-кейсы
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤4🙏1
Что такое тест‑кейс???
Тест-кейс — это форма записи проверки, которую проводит тестировщик👨💻
По сути, это алгоритм действий, по которому предполагается тестировать уже написанную программу.
В нём подробно прописаны шаги, которые нужно сделать для подготовки к тесту, сама проверка и ожидаемый результат.
Один тест-кейс описывает небольшую последовательность действий с одним конкретным результатом.
Например, успешную авторизацию на сайте для конкретного пользователя или добавление одного конкретного товара в корзину.
Обычно тест-кейсы пишут к задачам, которые нужно периодически повторять.
Основные функции системы следует проверять в каждой новой версии — это называется регрессионное тестирование. Например, при каждом обновлении проверять функцию регистрации для системы, которая может работать только с зарегистрированными пользователями. Тест-кейс каждый раз служит инструкцией, являясь по сути многоразовым.
Тест-кейс может выглядеть по-разному. У него есть стандартные поля, но каждая компания оформляет его как ей удобно. Кто-то использует специальные программы TMS, например Allure TestOps, как на скриншоте. Кто-то — документы Word или Excel
Тест-кейс — это форма записи проверки, которую проводит тестировщик
По сути, это алгоритм действий, по которому предполагается тестировать уже написанную программу.
В нём подробно прописаны шаги, которые нужно сделать для подготовки к тесту, сама проверка и ожидаемый результат.
Один тест-кейс описывает небольшую последовательность действий с одним конкретным результатом.
Например, успешную авторизацию на сайте для конкретного пользователя или добавление одного конкретного товара в корзину.
Обычно тест-кейсы пишут к задачам, которые нужно периодически повторять.
Основные функции системы следует проверять в каждой новой версии — это называется регрессионное тестирование. Например, при каждом обновлении проверять функцию регистрации для системы, которая может работать только с зарегистрированными пользователями. Тест-кейс каждый раз служит инструкцией, являясь по сути многоразовым.
Тест-кейс может выглядеть по-разному. У него есть стандартные поля, но каждая компания оформляет его как ей удобно. Кто-то использует специальные программы TMS, например Allure TestOps, как на скриншоте. Кто-то — документы Word или Excel
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤3🔥2
Чек-лист в отличие от тест-кейса гораздо короче, он описывает, что именно нужно проверить, без конкретных данных и шагов.
Чек-листы подходят, если система не очень сложная, а тестированием занимаются специалисты, вовлечённые в продукт. Если система многокомпонентная, проверки требуют сложных условий, а тестировать продукт будут менее вовлечённые в него люди, лучше потратить время на тест-кейсы.
Чек-листы подходят, если система не очень сложная, а тестированием занимаются специалисты, вовлечённые в продукт. Если система многокомпонентная, проверки требуют сложных условий, а тестировать продукт будут менее вовлечённые в него люди, лучше потратить время на тест-кейсы.
👍6🔥2🙏1
● Позитивные, или положительные. Проверяют, что система адекватно реагирует на корректные данные. Например, если при регистрации ввести в поле логина существующий, корректно написанный email, ещё не зарегистрированный в системе, сайт поймёт это правильно и допустит регистрацию.
● Негативные, или отрицательные. Показывают, что система умеет работать с некорректными данными. Например, если не написать в email значок @ или пропустить точку, сайт сообщит об ошибке и не допустит регистрацию.
● Деструктивные. Служат для проверки прочности системы. Например, позволяют убедиться, что в поле для email нельзя ввести команду, которая удалит базу данных зарегистрированных пользователей.
👍4❤3🙏1
Атрибуты тест‑кейса
Тест-кейсы принято оформлять по определённому стандарту. Поэтому каждый тест-кейс состоит из нескольких чётких элементов — атрибутов:
● Уникальный номер. Это может быть любая нумерация, принятая в проекте. Он позволит ссылаться на определённые тесты по номеру.
● Заголовок. Кратко, но ёмко описывает конкретную цель тест-кейса ― что именно нужно проверить.
● Предусловия. Условия, которые нужно соблюсти перед началом тест-кейса. Как правило, нужно авторизоваться или находиться в определённом разделе программы.
● Окружение. Где именно работал тестировщик: на каком устройстве, в каком браузере. Иногда его заполняют до тестирования, чтобы указать, на каком именно оборудовании и ПО его проходить. Иногда — после, и тогда тестировщик сам указывает, в каком окружении работал.
● Постусловия. Действия, которые нужно проделать после проведения проверки. Этот пункт встречается редко, но иногда он необходим. Например, может понадобиться удалить внесённые данные, чтобы они не скапливались в базе.
● Шаги ― последовательность шагов, которую нужно проделать для проверки.
● Ожидаемый результат тест-кейса. То, что тестировщик должен получить от системы после или во время прохождения шагов.
● Статус. Passed/Failed, то есть Успех/Провал или другой. Его заполняет тестировщик из заранее определённых вариантов, принятых в команде.
● Фактический результат тест-кейса. То, что получилось после выполнения шагов тест-кейса. Часто этого поля нет, и фактический результат описывают в баг-репорте в случае статуса failed.
Тест-кейсы принято оформлять по определённому стандарту. Поэтому каждый тест-кейс состоит из нескольких чётких элементов — атрибутов:
● Уникальный номер. Это может быть любая нумерация, принятая в проекте. Он позволит ссылаться на определённые тесты по номеру.
● Заголовок. Кратко, но ёмко описывает конкретную цель тест-кейса ― что именно нужно проверить.
● Предусловия. Условия, которые нужно соблюсти перед началом тест-кейса. Как правило, нужно авторизоваться или находиться в определённом разделе программы.
● Окружение. Где именно работал тестировщик: на каком устройстве, в каком браузере. Иногда его заполняют до тестирования, чтобы указать, на каком именно оборудовании и ПО его проходить. Иногда — после, и тогда тестировщик сам указывает, в каком окружении работал.
● Постусловия. Действия, которые нужно проделать после проведения проверки. Этот пункт встречается редко, но иногда он необходим. Например, может понадобиться удалить внесённые данные, чтобы они не скапливались в базе.
● Шаги ― последовательность шагов, которую нужно проделать для проверки.
● Ожидаемый результат тест-кейса. То, что тестировщик должен получить от системы после или во время прохождения шагов.
● Статус. Passed/Failed, то есть Успех/Провал или другой. Его заполняет тестировщик из заранее определённых вариантов, принятых в команде.
● Фактический результат тест-кейса. То, что получилось после выполнения шагов тест-кейса. Часто этого поля нет, и фактический результат описывают в баг-репорте в случае статуса failed.
❤4👍1🔥1🙏1
Правила составления тест-кейсов
Тестировщики сами составляют тест-кейсы на основе требований к разрабатываемому продукту. Поэтому для них важен навык правильного написания тест-кейсов.
При создании тест-кейса важно учитывать следующие моменты:
1. Заголовок должен быть чётким, лаконичным и выражающим суть проверки. В него не нужно добавлять шаги тест-кейса.
2. В предусловии важно описать состояние системы, которое нужно для выполнения шагов тест-кейса. Например, там могут быть конкретные ссылки на среды, где проводятся тестирования. Или на документы, которые понадобятся для прохождения шагов.
3. Шаги тест-кейса не нужно описывать слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
4. Шаги не должны быть размытыми или абстрактными. Нельзя сказать «Зайдите в раздел «Магазин» — лучше указать путь к нему, если он не слишком очевиден.
5. Скриншоты лучше использовать только как дополнение к словесному описанию, но не в качестве его замены.
Тестировщики сами составляют тест-кейсы на основе требований к разрабатываемому продукту. Поэтому для них важен навык правильного написания тест-кейсов.
При создании тест-кейса важно учитывать следующие моменты:
1. Заголовок должен быть чётким, лаконичным и выражающим суть проверки. В него не нужно добавлять шаги тест-кейса.
2. В предусловии важно описать состояние системы, которое нужно для выполнения шагов тест-кейса. Например, там могут быть конкретные ссылки на среды, где проводятся тестирования. Или на документы, которые понадобятся для прохождения шагов.
3. Шаги тест-кейса не нужно описывать слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
4. Шаги не должны быть размытыми или абстрактными. Нельзя сказать «Зайдите в раздел «Магазин» — лучше указать путь к нему, если он не слишком очевиден.
5. Скриншоты лучше использовать только как дополнение к словесному описанию, но не в качестве его замены.
👍3❤2🙏2🔥1
На этих ночных постах я ухожу в отпуск☕️
А также напоминаю, что еще есть места на курс "Тестирование с нуля"
Начинаем 22 апреля
Стоимость обучения 50 т. р. за все (обучение + подготовка к собеседованию и сопровождение)✨
Есть рассрочка
Завтра до 15:00 еще есть места на бесплатную консультацию по курсу, пишите (это созвончик в зуме).
А потом я буду в отпуске и смогу консультировать только по аудио либо переписке в ТГ✨
Написать мне в личку: lattelegss
А также напоминаю, что еще есть места на курс "Тестирование с нуля"
Начинаем 22 апреля
Стоимость обучения 50 т. р. за все (обучение + подготовка к собеседованию и сопровождение)
Есть рассрочка
Завтра до 15:00 еще есть места на бесплатную консультацию по курсу, пишите (это созвончик в зуме).
А потом я буду в отпуске и смогу консультировать только по аудио либо переписке в ТГ
Написать мне в личку: lattelegss
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🤩3🔥1🦄1
Разница между REST и SOAP
Частый вопрос на собесе
https://qalearning.net/usefullresourses/raznica-mejdu-rest-i-soap
Частый вопрос на собесе
https://qalearning.net/usefullresourses/raznica-mejdu-rest-i-soap
qalearning.net
Разница между REST и SOAP
Понимание двух популярных веб-сервисов. Особенности тестирования REST и SOAP
🔥4👍3❤2
Daria QA
Спускаю 💞 В закрытом чате собрали для вас материалы по собеседованиям, примеры собеседований, разборы и многое другое. Доступ платный - 2000 на все время. Материалы постоянно пополняются. Кому будет полезно? 🔵 тем, кто готовится или уже проходит собеседования…
Спускаю для всех новеньких ❤️🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2🙏1
📚 5 обязательных книг для QA тестировщика
▪️«Тестирование программного обеспечения. Базовый курс.»
В основу книги положен десятилетний опыт проведения тренингов для тестировщиков, позволивший обобщить типичные для многих начинающих специалистов вопросы, проблемы и сложности. Будет полезна как начинающим, так и опытным специалистам. 📂 Скачать (версия от 05.2024)
▪️Эффективное тестирование
Это пособие объясняет, как проводить тестирование максимально продуктивно, уделяя внимание практическим аспектам тестирования. Книга подчеркивает важность автоматизации и современных подходов. 📂 Скачать
▪️Сэм Канер, Джек Фолк, Енг Кек Нгуен. «Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений»
Книга именитых специалистов в области разработки программного обеспечения. Подробно рассматривается широкий спектр вопросов: от организации процесса тестирования до собственно текстирования проекта, кода, документации и т.д. 📂 Скачать
▪️A Practitioner's Guide to Software Test Design — Ли Копланд (2019)
Книга рассматривает лучшие методы проектирования тестов и помогает усовершенствовать навыки создания качественных тест-кейсов. Рекомендуется как для начинающих, так и для опытных тестировщиков 📂 Скачать
▪️Борис Бейзер «Тестирование черного ящика»
Книга доктора Бейзера "Тестирование черного ящика" давно была признана классическим трудом в области поведенческого тестирования разнообразных систем. 📂 Скачать
▪️«Тестирование программного обеспечения. Базовый курс.»
В основу книги положен десятилетний опыт проведения тренингов для тестировщиков, позволивший обобщить типичные для многих начинающих специалистов вопросы, проблемы и сложности. Будет полезна как начинающим, так и опытным специалистам. 📂 Скачать (версия от 05.2024)
▪️Эффективное тестирование
Это пособие объясняет, как проводить тестирование максимально продуктивно, уделяя внимание практическим аспектам тестирования. Книга подчеркивает важность автоматизации и современных подходов. 📂 Скачать
▪️Сэм Канер, Джек Фолк, Енг Кек Нгуен. «Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений»
Книга именитых специалистов в области разработки программного обеспечения. Подробно рассматривается широкий спектр вопросов: от организации процесса тестирования до собственно текстирования проекта, кода, документации и т.д. 📂 Скачать
▪️A Practitioner's Guide to Software Test Design — Ли Копланд (2019)
Книга рассматривает лучшие методы проектирования тестов и помогает усовершенствовать навыки создания качественных тест-кейсов. Рекомендуется как для начинающих, так и для опытных тестировщиков 📂 Скачать
▪️Борис Бейзер «Тестирование черного ящика»
Книга доктора Бейзера "Тестирование черного ящика" давно была признана классическим трудом в области поведенческого тестирования разнообразных систем. 📂 Скачать
Telegram
📚 Библиотека PM / BA / QA
Тестирование программного обеспечения — базовый курс (2024)
🔥10❤4👍2🤩1
Что такое баг, типы багов
По версии международной комиссии по сертификации тестирования программного обеспечения (ISTQB),
баг (дефект) — изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Например, неверный оператор или определение данных может привести к отказам компонента или системы.
Критичность и приоритет бага:
Критичность бага — это атрибут, который характеризует влияние бага на общую функциональность разрабатываемого ПО. По критичности баги делят на:
S1. Блокирующий (Blocker). Все тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.
S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функциональность, не связанную с расшифровыванием каналов.
S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.
S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести в пример неточный перевод с русского на английский в меню приёмника.
S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.
Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:
P1. Высокий приоритет (High). Нужно исправить немедленно, потому что баг является крайне важным для всего релиза. Например, старое сообщение об отсутствии подписки на пакет, хотя обновление текстов являлось целью этого релиза.
P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.
P3. Низкий приоритет (Low). Нужно будет исправить, но баг не очень важный и не требует немедленного решения. Например, это могут быть баги в функциональности, которая уже не используется оператором, но ещё не была удалена из кода.
По версии международной комиссии по сертификации тестирования программного обеспечения (ISTQB),
баг (дефект) — изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
Например, неверный оператор или определение данных может привести к отказам компонента или системы.
Критичность и приоритет бага:
Критичность бага — это атрибут, который характеризует влияние бага на общую функциональность разрабатываемого ПО. По критичности баги делят на:
S1. Блокирующий (Blocker). Все тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.
S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функциональность, не связанную с расшифровыванием каналов.
S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.
S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести в пример неточный перевод с русского на английский в меню приёмника.
S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.
Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:
P1. Высокий приоритет (High). Нужно исправить немедленно, потому что баг является крайне важным для всего релиза. Например, старое сообщение об отсутствии подписки на пакет, хотя обновление текстов являлось целью этого релиза.
P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.
P3. Низкий приоритет (Low). Нужно будет исправить, но баг не очень важный и не требует немедленного решения. Например, это могут быть баги в функциональности, которая уже не используется оператором, но ещё не была удалена из кода.
🔥5❤4🦄1
У меня тут столько в жизни всего происходит, поэтому я немножко вас забросила, простите меня великодушно 😭😭😭
-была в отпуске в Бангкоке
-после отпуска сразу же прыгнула в машину и была двое суток в дороге до Крыма
-сейчас тут в Севастополе пытаюсь привести свое жилье в порядок (год никто не жил в доме, все заросло паутино🗿)
Из позитивного:
Сегодня стартует курс «Тестирование с 0». Первый поток.
Сегодня будет организационное занятие, в четверг уже сделаем первую практику в Postman.
Если хотите присоединиться - можно еще до след недели забежать в последний вагон так сказать, дальше группа закроется.
Про себя:
купила себе тоже обучение по тестированию, чтобы посмотреть какие пробелы могут быть у меня, и чтобы еще более качественные знания передавать ребятам.
Постоянно стараюсь сама обучаться, потому что работа в IT - это век живи век учись)
На месте стоять нельзя )
-была в отпуске в Бангкоке
-после отпуска сразу же прыгнула в машину и была двое суток в дороге до Крыма
-сейчас тут в Севастополе пытаюсь привести свое жилье в порядок (год никто не жил в доме, все заросло паутино🗿)
Из позитивного:
Сегодня стартует курс «Тестирование с 0». Первый поток.
Сегодня будет организационное занятие, в четверг уже сделаем первую практику в Postman.
Если хотите присоединиться - можно еще до след недели забежать в последний вагон так сказать, дальше группа закроется.
Про себя:
купила себе тоже обучение по тестированию, чтобы посмотреть какие пробелы могут быть у меня, и чтобы еще более качественные знания передавать ребятам.
Постоянно стараюсь сама обучаться, потому что работа в IT - это век живи век учись)
На месте стоять нельзя )
❤12🔥5❤🔥3
Внимание ❕ полезный тренажер!
Алексей Клименко (QA Engineer / Mentor QA) сделал еще один веб-тренажёр для практики анализа требований, построения диаграммы состояний и переходов (state transition) и функционального тестирования.
Тренажер имитирует блог с возможностью публикации статей и по работе с ними на основе ролевой модели.
🪲 🐞 Задание от Алексея:
выполнить функциональное тестирование, которое позволит обнаружить имеющиеся баги.🪲 🪳
Алексей Клименко (QA Engineer / Mentor QA) сделал еще один веб-тренажёр для практики анализа требований, построения диаграммы состояний и переходов (state transition) и функционального тестирования.
Тренажер имитирует блог с возможностью публикации статей и по работе с ними на основе ролевой модели.
выполнить функциональное тестирование, которое позволит обнаружить имеющиеся баги.
Please open Telegram to view this post
VIEW IN TELEGRAM
aklimenkoschool.ru
state-quest-tester-trainer
Lovable Generated Project
🔥7❤5🆒4
URI*️⃣ URN*️⃣ URL
Что это и в чем разница?👀
ГО разбираться🙃
Для начала давайте расшифруем аббревиатуры:
🟢 URI - Uniform Resource Identifier (унифицированный идентификатор ресурса)
🟢 URL - Uniform Resource Locator (унифицированный определитель местонахождения ресурса)
🟢 URN - Unifrorm Resource Name (унифицированное имя ресурса)
То есть по сути:
🟢 URI – имя и адрес ресурса в сети, включает в себя URL и URN
🟢 URL – адрес ресурса в сети, определяет местонахождение и способ обращения к нему
🟢 URN – имя ресурса в сети, определяет только название ресурса, но не говорит как к нему подключиться
Рассмотрим примеры:
🟢 URI –
https://wiki.merionet.ru/images/vse-chto-vam-nuzhno-znat-pro-devops/1.png
🟢 URL -
https://wiki.merionet.ru
🟢 URN - images/vse-chto-vam-nuzhno-znat-pro-devops/1.png
Как вы видите – первые две сточки в вашем браузере отобразились как ссылки и по ним можно перейти, однако по третьей сточке нельзя, потому что непонятно как и куда.
Что это и в чем разница?
ГО разбираться
Для начала давайте расшифруем аббревиатуры:
То есть по сути:
Рассмотрим примеры:
https://wiki.merionet.ru/images/vse-chto-vam-nuzhno-znat-pro-devops/1.png
https://wiki.merionet.ru
Как вы видите – первые две сточки в вашем браузере отобразились как ссылки и по ним можно перейти, однако по третьей сточке нельзя, потому что непонятно как и куда.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥5😱2👍1