Что такое Баг?

Его структура и жизненный цикл.

Баг (дефект, ошибка) - отклонение фактического результата от ожидаемого результата

или иными словами отклонение от спецификации (документации).
Баг также может быть в самой спецификации (документации).

Структура Бага:
ID Bug
Заголовок

Предварительное условие

Шаги

Фактический результат

Ожидаемый результат

Приоритет

Серьёзность

Заголовок должен чётко описывать проблему.

Предварительное условие пишем, если оно нужно.
Шаги необходимы для того, чтобы воспроизвести баг (дефект, ошибку).
Фактический результат – это то, как на самом деле работает продукт (проект).
Ожидаемый результат – это то, как должен работать продукт (проект).
Источники ожидаемого результата:

 Документация (спецификация)
 Жизненный опыт
 Здравый смысл
 Общение (например, с коллегами),
 Статистические данные

Приоритет устанавливается со стороны Продукт Менеджера. Приоритет – это

последовательность устранения дефектов. Бывает 3 уровня:

 Низкий – дефект раздражает, но устранение можно выполнить после решения более

серьёзного дефекта;
 Средний – дефект может подождать;
 Высокий – дефект должен быть устранён как можно скорее.

Серьёзность устанавливается со стороны QA. Серьёзность – это степень влияния дефекта

(бага, ошибки) на работу функционала продукта (проекта). Бывает несколько уровней :
  Низкий – не приводит к серьёзным поломкам системы;
 Средний – вызывает нежелательное поведение, но система продолжает работать;
 Основной – это серьёзный дефект, приводящий к колапсу системы, но некоторые её
части продолжают функционировать.
 Критический – этот дефект указывает на полную остановку процесса, дальней шая
работа невозможна.

Статус высокого приоритета и низкой серьёзности указывает на то, что дефект должен быть
устранён немедленно, но при этом на функционал продукта (проекта), он не влияет
(например, логотип бренда).
Статус высокой серьёзности и низкого приоритета указывает на то, что дефект должен быть
устранён, но не немедленно.

Жизненный цикл Бага:

это набор специфических состояний бага (дефекта, ошибки),
через который он проходит во время своего существования.

Новый
(New)

Закрыто(Cl Направлен(
osed) Assigned)

Проверено( Открыт(Open)
Verified)
Повторно
открыт(ReOp
ened)

Повторное Зафиксирован
тестирование( (Fixed)
Retest)

Ожидание
повторного
тестирования(
Pending
retest)
При обнаружении Бага (дефекта, ошибки) после релиза, наши шаги:

 Выполнение Хотфикса;
 Выполнение Смок тестинга;
 Выполнение Регрешн тестинга.

Система контроля версий (VCS)

это место хранения кода со всеми его версиями.
Система управления версиями позволяет хранить несколько версий одного и того же
документа, при необходимости возвращаться к более ранним версиям, определять, кто и
когда сделал то или иное изменение, позволяет изменять одни и те же фай лы нескольким
разработчикам одновременно и без создания локальных копий на их компьютерах. При
этом все варианты изменений сохраняются отдельно, и можно сделать разные варианты
одного и того же фай ла с учетом разных правок от разных людей . Если же несколько
изменений затрагивают один и тот же фрагмент документа, то система предложит выбрать
нужный вариант.

Что нам дает использование VCS:

 Полную уверенность в том, что фай лы, которые мы получаем из системы, являются
актуальными всегда, в любой момент времени;
 Возможность получить требуемую версию с любого компьютера, который позволит
подключиться к серверу;
 Сохраняя фай л в VCS, не нужно думать о том, что кто-то, работающий с этим же
фай лом, пересохранит и затрет изменения.

Как VCS работает:

Подготовительная работа – это те
действия, которые нужно сделать один
раз.
Создать репозиторий – то есть место, где
будет храниться код;
Скачать проект из репозитория – то есть
клонировать (копировать) то, что лежит в
репозитории, к себе на компьютер
Ежедневная работа – это те действия,
которые будут выполняться часто.
Обновить проект, забрать последнюю
версию из репозитория – эта команда
может называться update (SVN) or pull
(Mercurial);
Внести изменения в репозиторий – это
делается одной или двумя командами в
зависимости от VSC;
 Commit (SVN)
 Commit + push (Mercurial, Git)
Разрешить конфликты (merge). Если
изменения не пересекаются, система
сохранит и то, и другое.
Создать бранч (ветку).
trunk - основная ветка
 Популярные VCS и отличия между ними:
 SVN — простая, но там очень сложно мерджиться, всегда нужна сеть
 Mercurial (он же HG), Git — распределенная система контроля версий . Внесение
изменений двухступенчатое — сначала коммит, потом push. Это удобно, если вы
работаете без интернета, или делаете мелкие коммиты, но не хотите ломать основной
код пока не доделаете большую задачу. Тут есть и автоматическое слияние разных
бранчей .
Git — распределённая система контроля версий , которая даёт возможность разработчикам
отслеживать изменения в фай лах и работать над одним проектом совместно с коллегами.
Она была разработана в 2005 году Линусом Торвальдсом, создателем Linux, чтобы другие
разработчики могли вносить свой вклад в ядро Linux. Git известен своей скоростью,
простым дизай ном, поддержкой нелиней ной разработки, полной децентрализацией и
возможностью эффективно работать с большими проектами.
GitHub — сервис онлай н-хостинга репозиториев, обладающий всеми функциями
распределённого контроля версий и функциональностью управления исходным кодом —
всё, что поддерживает Git и даже больше. Также GitHub может похвастаться контролем
доступа, багтрекингом, управлением задачами и вики для каждого проекта.
У любой системы контроля версий есть «консольный интерфей с». То есть общаться с ними
можно напрямую через консоль, вводя туда команды. Склонировать репозиторий , обновить
его, добавить новый фай л, удалить старый , смерджить изменения, создать бранч - всё это
делается с помощью команд.
Но есть и графический интерфей с. Устанавливаете отдельную программу и выполняете
дей ствия мышкой . Обычно это делается через «черепашку» — программа
называется Tortoise<VCS>. TortoiseSVN, TortoiseHG, TortoiseGit. Часть команд можно сделать
через среду разработки — IDEA, Eclipse, etc.

Клиент-серверная архитектура
Бывает трёхзвенная и двухзвенная.

Клиент Сервер
База Данных

Клиент – это графический интерфей с кода. Он бывает:

 Web — в браузере открыта, как google или facebook;

 Desktop — на компьютере, как калькулятор, то есть то, что даёт решение сразу
Сервер – это своего рода логика, он достаточно мощный , ненужно дублировать код и самое
главное так безопаснее.
Существует также кластер серверов –запасные сервера на случай того, если один упадет
или будет сильно нагружен. Перед ним, как правило, ставится балансировщик, который
отправляет запрос на менее нагруженный сервер, тем самый более равномерно
распределяет работу.
Горячий резерв — когда у нас есть несколько серверов, работающих в параллель, и
балансировщик распределяет нагрузку между ними.
Холодный резерв — когда у нас второй сервер является резервной копией «на всякий
случай ». Все запросы идут на первый сервер, второй отдыхает.
БД (база данных) — отдельный программный продукт, который позволяет:

 быстро делать выборки информации;

 сохранять информацию даже при рестарте системы.

Плюсы Архитектуры Минусы Архитектуры

Мощный сервер дешевле 100+ мощных
клиентских машин — если мы хотим,
чтобы приложение не тормозило, нужна
хорошая машина. Она у вас будет одна.
Или несколько, если нагрузка большая,
но явно меньше, чем количество
клиентов.
Нет дублирования кода — основной код
хранится на сервере, клиент отвечает
только за «нарисовать красивенько» и
простенькие проверки на полях «тут
число, тут строка не длиннее 100
символов».
Персональные данные в безопасности —
простой пользователь не видит лишнего.
Он не знает ваше ключевое слово,
паспортные данные и количество денег
на счете.
Упало одно звено — все отдыхают
Высокая стоимость оборудования так как к
железу для серверов совсем другие
требования по надежности + есть
поддержка специфичных функций
 — у HDD это специальная
микропрограмма контроллера,
которая оптимизирована для
работы диска в RAID, дома это не
нужно.
 — у SSD это наличие группы
конденсаторов, которые хранят
энергию на случай отключения
питания, чтобы хватило времени
скинуть из DDR кэша данные в
энергонезависимую память и
данные не побились.
 SSD — быстро работающий диск,
 HDD — обычный .
 RAID — когда мы N дисков вместе
соединили
 DDR кэш — это оперативная память

Техники тестирования (TEST DESIGN)

это этап обеспечения качества, в ходе которого мы создаём
сценарии тестирования и намечаем структуру тестовых
мероприятий для проекта.
Таким образом, мы

 Разрабатываем тесты, которые помогают обнаружить серьёзные проблемы;

 Вдумчиво подходим к тестированию и избегаем напрасной траты ресурсов;
 Минимизировать количество тестов, необходимых для утверждения проекта
 Сценарий пользователя
наглядное схематическое представление того, как
пользователь решает свою задачу с помощью сай та, что ему
помогает и что мешает в достижении цели.
Сценарии помогают лучше понимать предпочтения посетителей сай та и анализировать
пользовательский опыт. Это нужно, чтобы в дальней шем проектировать сай т или
интерфей с так, чтобы он вписывался в привычные для клиентов паттерны и приводил к
цели посещения за наименьшее количество шагов и с минимальными затратами сил,
времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении
юзабилити-тестов и других маркетинговых исследований .