#теория
‼️Повторим понятия:

🔷Аутентификация – прохождение проверки подлинности.

🔷Авторизация – предоставление и проверка прав на совершение каких-либо действий в системе.

🔷Идентификация — это процедура распознавания субъекта по его идентификатору (проще говоря, это определение имени, логина или номера).

Давайте рассмотрим пример:
😉Пользователь хочет войти в систему:
*⃣Для начала система запрашивает логин, пользователь его указывает, система распознает его как существующий — это идентификация .
(Идентификатором может быть:
🔹номер телефона
🔹номер паспорта
🔹e-mail
🔹номер страницы социальной сети и )

*⃣Дальше система просит ввести пароль, пользователь его вводит, и система соглашается, что пользователь, похоже, действительно настоящий, раз пароль совпал, — это аутентификация.
❗️ Скорее всего, система дополнительно запросит еще и одноразовый код из SMS или приложения. Если пользователь и его правильно введет, то система окончательно согласится с тем, что он настоящий владелец аккаунта, — это двухфакторная аутентификация.
Проверка подлинности:
🔹Пароль – то, что мы знаем (слово, PIN-код, код для замка, графический ключ)
🔹Устройство – то, что мы имеем (пластиковая карта, ключ от замка, USB-ключ)
🔹Биометрика – то, что является частью нас (отпечаток пальца, портрет, сетчатка глаза)

*⃣После этого система предоставит пользователю право читать письма в его почтовом ящике — это авторизация .
Например
🔹Доступ к электронной почте после ввода пароля
🔹Разблокировка смартфона после сканирования отпечатка пальца
🔹Выдача средств в банке после проверки паспорта и данных о вашем счете

#Отличие итеративной (итерационной) модели от инкрементной модели.

Представьте, что есть два заказчика:

🔷Первый #заказчик не знает чего хочет и не может описать подробное техническое задание, и верит в работу проектной команды. Но знает, что хочет #мессенджер. Проектная команда разрабатывает мессенджер только чат и внедряет в эксплуатацию данный продукт. Мессенджер понравился пользователям, и проектная команда решает улучшать функциональность мессенджера, а именно через промежутки (итерации) добавлять новые возможности. Например, на рисунке указано, что во второй итерации добавили аудио-сообщения, а в третьей итерации уже видео-сообщения, а четвертой - загрузка файлов и т.д., то есть адаптируют мессенджер по требованиям рынка.
Это и есть #итеративная #модель!

🔷Второй заказчик хочет определенный мессенджер, и написал подробное техническое задание на чат, аудио-сообщение и видео-сообщение и отдал проектной команде на разработку.
Проектная команда решила сделать только чат и показать данный мессенджер пользователям, и посмотреть, понравится ли данный продукт пользователям.
Если и заказчику, и пользователям мессенджер нравится, работа над ним продолжается, но уже по частям - по инкрементам.
На рисунке указано, что во втором инкременте добавили #функциональность аудио-сообщение, в третьей части уже добавили видео-сообщение. Инкремент за инкрементом мессенджер обновляется согласно техническому заданию.
Это есть #инкрементная #модель!

Недостатки и преимущества моделей можно ознакомиться в открытых источниках, и это отдельный пост, но, если пост наберёт 150❤️😂, то я кратко опишу.

Это похожий пример из статьи gb.ru "Модели и методологии разработки ПО" и ещё отрывки:
" #Итеративнаямодель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.

#Инкрементнаямодель подходит для проектов, в которых точное техническое задание прописано уже на старте, а продукт должен быстро выйти на рынок."

А ещё есть общее определение Итерационной инкрементальной модели, которое описано в книге "Тестирование программного обеспечения" Святослава Куликова на странице 21😄

🔹🔹🔹🔹🔹🔹
Инкрементная разработка представляет собой процесс частичной реализации всей системы и медленного наращивания функциональных возможностей.

Определение требований не меняется:
Проектирование -> разработка -> тестирование -> выпуск 1
Проектирование -> разработка -> тестирование -> выпуск 2
Проектирование -> разработка -> тестирование -> выпуск 3

🔹🔹🔹🔹🔹🔹
Классическая итерационная модель абсолютизирует возможность возвратов на предыдущие этапы, а именно:
❗️Начнём сначала:
‼️Определение требований -> проектирование -> разработка -> тестирование и отладка -> выпуск (эксплуатация)

*⃣Возможные возвраты:
выпуск (эксплуатация) -> тестирование и отладка
выпуск (эксплуатация) -> разработка
выпуск (эксплуатация) -> проектирование
выпуск (эксплуатация) -> определение требований

Тестирование -> разработка
Тестирование -> проектирование
Тестирование -> определение требований

Разработка -> проектирование
Разработка -> определение требований

Проектирование -> определение требований

По существу, классическая схема остается верной, но только в рамках одной итерации и с одной важной поправкой: все полезное, что было сделано ранее, сохраняется.

#теория

#пособие
Модели жизненного цикла и технология проектирования программного обеспечения

1. Структурный анализ
1.1. Декомпозиция процессов
1.2. Модели и стадии жизненного цикла
2. Процессы жизненного цикла
2.1. Основные определения
2.2. Критерии для процессов
2.3. Описание процессов
2.4. Категории процессов жизненного цикла
3. Модели жизненного цикла
3.1. Каскадная модель ЖЦ
3.2. Спиральная модель ЖЦ
4. Технологии проектирования ПО
4.1. Rational Unified Process RUP (IBM)
4.2. Custom Development Method CDM (Oracle)
4.3. Microsoft Solution Framework MSF (MicroSoft)
4.4. Extreme Programming XP

Тестовый случай (Test Case) - это совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Под тест кейсом понимается структура вида: Action > Expected Result > Test Result

Отчет о дефекте (Bug Report) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Написание хороших баг репортов — это самый важный навык тестировщика! Баг — это отклонение фактического результата от ожидаемого результата.
фактический результат — это то, что мы “видим” или то, что произошло после проделанных действий
ожидаемый результат — это ожидания наблюдателя, которые он получил из требований, спецификаций, любой другой документации, личного опыта и здравого смысла

Тестовое Покрытие (Test Coverage) - это набор тестов для проверки тестируемой функции. Расчет тестового покрытия проводится по формуле: отношение количества строк кода, покрытых тестами, к общему количеству строк кода тестируемой функции, умноженное на 100%.
Существуют три подхода для оценки качества и выражения тестового покрытия в численном представлении в зависимости от области проверки: покрытие требований, покрытие кода и покрытие на базе анализа потока управления.

Детализация Тест Кейсов (Test Case Detalization) - это уровень детализации описания тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов.

Время Прохождения Тест Кейса (Test Case Pass Time) - это время от начала прохождения шагов тест кейса до получения результата теста.

#Полезныестатьи
Баг и баг репорт

Правильно пишем тест-кейсы. Памятка начинающему специалисту по тестированию

Тестовое Покрытие (Test Coverage). Критерии тестового покрытия в Тестировании ПО
#теория

Мифы О Тестировании
#тестирование #тестировщик

🚫Цель тестирования - демонстрация отсутствия ошибок в продукте

🚫Есть код, который нет нужды тестировать

🚫Тестирование – это просто. Все способны тестировать

🚫Тестирование – случайный, не систематизируемый процесс

🚫Тестированию не нужно учиться

🚫Тестирование = отсутствие карьерного роста

🚫Продукт может быть протестирован полностью

🚫Тестирование позволяет найти все дефекты продукта

🚫Все дефекты должны быть исправлены

🚫В пропущенных багах виноваты тестировщики

🚫Тестировщики ответственны за качество продукта

🚫Можно полностью протестировать программу

🚫Единственная задача тестировщика – поиск багов

🚫Кто угодно может тестировать программное обеспечение

🚫Тестирование — это монотонная и скучная работа.

🚫Автоматизированный тест эквивалентен аналогичному
выполненному человеком

🚫Тестирование слишком дорогое

🚫Тестирование занимает много времени

🚫Тестируются только готовые продукты

🚫Машины заменят тестировщиков, и они станут ненужными (Автоматизированное тестирование устраняет необходимость ручного тестирования ).

🚫Провести исчерпывающее тестирование возможно.

🚫Тестировщики не ладят с разработчиками.

🚫Работа тестировщика лишена творчества

🚫Тестирование осуществляется только после завершения стадии разработки.

🚫Тестирование увеличивает стоимость разработки.

ЕЩЕ БОЛЬШЕ МИФОВ о тестировании и тестировщиках
дополнительный материал:

⏳5 мифов о тестировании
⏳Мифы и факты о тестировании программного обеспечения
⏳Мифы о тестировании
⏳7 популярных мифов о тестировании
⏳МИФЫ О ТЕСТИРОВАНИИ / Могу ли я стать тестировщиком?
⏳Тестирование ПО - Мифы
⏳Мифы о тестировщиках 7 мифов о тестировании и тестерах
⏳Мифы о тестировании программного обеспечения
⏳7 мифов о профессии тестировщика

Для себя выделила следующие пункты:
1⃣. Принять ситуацию и не жалуйтесь, начинайте сразу действовать
2⃣. Познакомиться с командой, назначить встречу для передачи знаний
3️⃣. Больше общаться с разработчиком, он уж точно знает информацию, если давно на проекте.
Или
узнать, кто в вашей команде является основным носителем знаний о создаваемом приложении, подготовить список вопросов и обсудить его с этим человеком.
4⃣. Постарайтесь как можно больше узнать про архитектуру и конечный дизайн продукта
5⃣. Не бойтесь задавать вопросы
6⃣. Если в проекте есть руководитель тестирования, то запишите все вопросы, предварительно обсудите их с вашим руководителем и назначьте встречу с другими членами команды
7⃣. Стать реальным пользователем и опираться на свою логику, исследуйте (ad-hoc testing), самостоятельно изучите продукт
8⃣. Опираться на прошлый опыт - на прошлые проекты, если имелись (можно использовать чужой опыт)
9⃣. Обязательно фиксировать изученную информацию в общий доступ, например, в confluence.

#полезныестатьи

Новый функционал без ТЗ

Оценка тестового покрытия на проекте
Оцениваем покрытие требований тестами
🔅Проблема: требования не атомарны.
🔅Проблема: требований нет вообще.
🔅Проблема: требования не трассируемы.
🔅Проблема: требования всё время меняются.
🔅Проблема: не хватает времени документировать тесты.

Тестирование «без» требований: поиск и организация информации

5 Советов: Тест дизайн в условиях отсутствия требований

За долгое время не было тестов. Сегодня в течении дня #тестыдлязакреплениязнаний

Повторим😄