Руководства по тестированию программного обеспечения

Software-Testing

Junior QA requirements

Основы, определения, виды тестирования

Качество ПО — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.
Обеспечение качества (QA) — комплекс мероприятий направленный на обеспечение качества разрабатываемого продукта, на всех стадиях разработки.
Тестирование ПО (Software Testing) – процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта.
Quality Control направлено на поиск дефектов в готовом продукте для того, чтобы убедиться, что продукт соответствует требованиям и готов к передаче пользователю (заказчику).
Quality Assurance направлено больше на процессы, их усовершенствование (оптимизацию) для минимизации количества багов (дефектов) в самом начале разработки продукта. Это довольно эффективно, так как анализируются все аспекты в самом начале, а не когда продукт готов и выясняется, что работать с ним не совсем удобно или можно реализовать функциональность по-другому.

Объекты тестирования

• Программы при их непосредственном запуске и исполнении (software).
• Код программ без запуска и исполнения (code).
• Прототип программного продукта (product prototype).
• Проектная документация (project documentation):
  • Требования к продукту (product requirements).
  • Функциональные спецификации к продукту (functional specifications).
  • Документы по архитектуре (product architecture) и дизайну (product design).
  • План проекта (project plan).
  • Тестовые сценарии (test cases).
• Сопроводительная документация:
  • Интерактивная помощь (on-line help).
  • Руководства по установке (Installation guide) и использованию (user manual).

Этапы тестирования (жизненный цикл тестирования)

• Анализ требований. Изучаем спецификации требований, функциональные требования к системе. Отвечаем на вопросы: что нам предстоит тестировать, как много будет работы, какие есть сложности, всё ли необходимое у нас есть. Получаем данные, по которым составляем план тестирования.
• Планирование испытаний. Определяем объемы испытаний и ресурсы, пишем расписание того, когда будем выполнять намеченные действия.
• Проектирование тестов. Определяем: цель тестирования, специфику входных данных (классы эквивалентности…), модули и подмодули приложения, архитектуру проверок (группы чек-листов), архитектуру тестов (детализация от крупного к деталям). Пишем тесты.
• Запуск тестов. Проверяем тесты в действии, анализируем тестовые результаты.
• Редактирование тестов. Пересматриваем и корректируем тесты, держим тесты в актуальном состоянии, дополняем новыми тестами.
• Системное тестирование. Проверяем всю систему (все модули нашего продукта как единую систему), получаем сведения о качестве ПО.
• Приемочные испытания (альфа и бета тестирование).
• Эксплуатация и сопровождение. Тестирование багов, найденных в релизном продукте, регрессионное тестирование билда после внесенных исправлений (regression testing).

Виды тестирования

По методу тестирования

Мы работаем с кодом системы?

• НЕТ = метод «черного» ящика (black-box)
• Частично = метод «серого» ящика (grey-box)
• ДА = метод «белого» ящика (white-box)

По уровню (вширь)

• Компонентное/модульное (component/unit testing). Каждая сложная программная система состоит из отдельных частей – модулей, выполняющих ту или иную функцию в составе системы. Для того, чтобы удостовериться в корректной работе системы в целом, необходимо вначале протестировать каждый модуль системы по отдельности.
• Интеграционное (integration testing). Результатом тестирования и верификации отдельных модулей, составляющих программную систему, является заключение о том, что эти модули являются внутренне непротиворечивыми и соответствуют требованиям. Однако отдельные модули редко функционируют сами по себе, поэтому следующая задача после тестирования отдельных модулей – тестирование корректности взаимодействия нескольких модулей, объединенных в единое целое. Такое тестирование называют интеграционным. Его цель – удостовериться в корректности совместной работы компонент системы.
• Системное (system testing). На этом этапе проводится не только функциональное тестирование, но и оценка характеристик качества системы – ее устойчивости, надежности, безопасности и производительности. На этом этапе выявляются многие проблемы внешних интерфейсов системы, связанные с неверным взаимодействием с другими системами, аппаратным обеспечением, неверным распределением памяти, отсутствием корректного освобождения ресурсов и т.п.

По уровню (вглубь)

• Приемочное (smoke test, acceptance testing) — проверка самой важной функциональности программного продукта.
• Тест критического пути (critical path test) – проверка функциональности, используемой типичными пользователями в повседневной деятельности.
• Расширенный тест (extended test) – проверка всей заявленной функциональности.

По цели

• Функциональное

  • Функциональное тестирование (functional testing)
  • Тестирование новой функциональности (new feature testing)
  • Тестирование безопасности (security testing)

• Нефункциональное

  • Производительности (performance testing) — определить, как быстро работает система или её часть под определённой нагрузкой:
    • нагрузочное (performance & load testing) — автоматизированное тестирование, которое имитирует одновременную работу множества пользователей над приложением;
    • стрессовое ( stress testing) позволяет проверить насколько приложение (система в целом) работоспособны в условиях стресса, и также оценить способность системы к регенерации (возвращение к нормальному состоянию после прекращения стресса);
    • тестирование стабильности / надежности (stability / reliability testing) проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки;
    • тестирование объемами (volume testing) оценить производительность при увеличении объемов данных в базах данных приложения.
  • Установочное (installation testing) направлено на проверку успешной инсталляции и настройки, а также обновления и удаления ПО.
  • Удобства пользования (usability testing) — тестирование, показывающее степень удобства использования, обучаемости, понятности и привлекательности для пользователя разрабатываемого ПО в контексте определенных условий.
  • Тестирование на отказ и восстановление (failover & recovery testing) проверяет продукт с точки зрения способности противостоять и успешно восстанавливаться после сбоев, возникших в связи с ошибками ПО, отказами оборудования или проблемами связи (например, отказ сети).
  • Конфигурационное (configuration testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров …).
  • Интернационализации (internationalization testing) проверяет готовность приложения к работе с разными языковвыми интерфейсами.
  • Локализационное (localization testing) проверяет, насколько корректно продукт адаптирован к работе на другом языке.
  • Тестирование документации (document testing) – тестирование, с которого начинается почти любой проект. Призвано обнаружить ошибки в документации на ранних стадиях.
  • Тестирование совместимости (compatibility testing) — тестирование, для проверки корректной работы продукта в определенном окружении.

• Связанное с изменениями

  • Дымовое тестирование (smoke testing) — короткий цикл тестов, чтобы убедиться, что после сборки кода (нового или исправленного) приложение стартует и выполняет основные функции.
  • Регрессионное тестирование (regression testing) — вид тестирования для подтверждения факта, что существующая ранее функциональность работает как и прежде после сделанных в приложении или окружающей среде исправлений или дополнений (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения).
  • Тестирование сборки (build verification testing) — тестирование выпущенной версии (сборки) по критериям качества для начала тестирования.
  • Проверка согласованности/исправности (sanity testing) — это узконаправленное тестирование, чтобы доказать, что конкретная функция работает согласно заявленным требованиям.

Верификация и валидация

Верификация (Verification) — это статическая практика проверки документов, дизайна, архитектуры, кода, т.д. Отвечает на вопрос “Делаем ли мы продукт правильно?”.
Валидация (validation) – это процесс оценки конечного продукта, необходимо проверить, соответствует ли программное обеспечение ожиданиям и требованиям клиента. Это динамический механизм проверки и тестирования фактического продукта. Отвечает на вопрос “Делаем ли мы правильный продукт?”.

Принципы тестирования

1. Тестирование показывает наличие дефектов. Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Тем не менее, важно составлять тест-кейсы, которые будут находить как можно больше багов. Таким образом, при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в программном обеспечении. В то же время, даже если дефекты не были найдены в процессе тестирования, нельзя утверждать, что их нет.
2. Исчерпывающее тестирование невозможно. Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключениям совсем уж примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО.
3. Раннее тестирование. Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения, и его усилия должны быть сконцентрированы на определенных целях.
4. Скопление дефектов. Разные модули системы могут содержать разное количество дефектов – то есть, плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.
5. Парадокс пестицида. Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают. Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов.
6. Тестирование зависит от контекста. Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы самой программы. Например, программное обеспечение для медицинских нужд требует гораздо более строгой и тщательной проверки, чем, скажем, компьютерная игра. Из тех же соображений, сайт с большой посещаемостью должен пройти через серьезное тестирование производительности, чтобы показать возможность работы в условиях высокой нагрузки.
7. Заблуждение об отсутствии ошибок. Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к релизу. Нахождение и исправление дефектов будут не важны, если система окажется неудобной в использовании, и не будет удовлетворять ожиданиям и потребностям пользователя.

Жизненный цикл разработки ПО и методологии разработки

Цикл (процесс) разработки ПО (software development life cycle) – это путь от идеи до поддержки готового продукта. Чем более отлажены каждая из стадий цикла и координация между ними, тем эффективнее работает компания, тем выше качество и тем счастливее пользователи/клиенты.

Жизненный цикл ПО:

• Формирование и анализ требований
• Проектирование
• Реализация
• Тестирование продукта
• Внедрение
• Эксплуатация и сопровождение

Когда начинать тестирование: на этапе формирования требований.

Когда заканчивать тестирование:

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

Модель разработки ПО — структура, систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов и множества других факторов.

Waterfall
Каскадная модель (англ. водопад) – модель процесса разработки ПО, в которой весь процесс выглядит как поток, последовательно проходящий фазы анализа требований, проектирования,
реализации, тестирования, интеграции и поддержки. Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей. Тестирования
подключается с середины.

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

• Снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение.
• Организация эффективной обратной связи команды с потребителем/заказчиками и создание продукта, реально отвечающего их потребностям.
• Акцент усилий на наиболее важных и критичных направлениях проекта.
• Непрерывное итеративное тестирование.
• Раннее обнаружение конфликтов и потенциальных багов.
• Более равномерная загрузка участников проекта.
• Эффективное использование накопленного опыта.
• Реальная оценка текущего состояния проекта.
• Затраты распределяются по всему проекту, а не группируются в конце.

Scrum
Scrum (от англ. scrum «схватка») — методология управления проектами, активно применяющаяся для гибкой разработки ПО. Scrum чётко делает акцент на качественном контроле процесса
разработки.
Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Новые функции ПО, которые должны быть реализованы в очередном спринте определяются в начале спринта на этапе планирования и не должны изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
Спринт (Sprint) — итерация в скраме, в ходе которой создаётся функциональный прирост ПО. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель.
Резерв Проекта (Product backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» (user story) или элементами резерва (backlog items).
Резерв спринта (Sprint backlog) — содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается
скрам-командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения спринта.
Scrum. Встречи:

• Планирование спринта (Sprint Planning Meeting) — в начале каждого спринта из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда. На основе выбранных задач создается резерв спринта. Каждая задача оценивается в идеальных человеко-часах. Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи. Обсуждается и определяется, каким образом будет реализован этот объём работ.
• Ежедневное совещание (Daily Scrum meeting): в течение совещания каждый член команды отвечает на 3 вопроса: Что сделано с момента предыдущего ежедневного совещания? Что будет сделано с момента текущего совещания до следующего? Какие проблемы мешают достижению целей спринта?
• Обзор итогов спринта (Sprint review meeting) проводится после завершения спринта. Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам (demo).
• Ретроспективное совещание (Retrospective meeting) проводится после завершения спринта. Члены команды высказывают своё мнение о прошедшем спринте и отвечают на два основных вопроса: Что было сделано хорошо в прошедшем спринте? Что надо улучшить в следующем спринте?

Канбан
В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»). Жизненный цикл задачи отображается на канбан-доске, физической или электронной. Такая визуализация делает рабочий процесс открытым и понятным для всех участников, что особенно важно в Agile, когда у команды нет одного формального руководителя. Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно. Иначе – необходимо решать проблему: искать, где и почему возникли задержки и чью работу надо оптимизировать.

###Техники тест-дизайна###

1. Эквивалентное разбиение. Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным. Например, мы тестируем функциональность приложения, позволяющего покупать авиа- и железнодорожные билеты онлайн. Стоимость билета будет зависеть от возраста пассажира, так как дети, студенты и пенсионеры относятся ко льготным категориям. У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно. QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.
2. Граничные значения. Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.
3. Таблица принятия решений. Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом. Какие возможны сценарии:

• Правильный логин и правильный пароль.
• Правильный логин, неправильный пароль.
• Неправильный логин, правильный пароль.
• Неправильный логин, неправильный пароль.
  Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого у нас получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей. Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.

1. Попарное тестирование. Суть этого метода, также известного как pairwise testing, в том, что каждое значение каждого проверяемого параметра должно быть протестировано на взаимодействие с каждым значением всех остальных параметров. После составления такой матрицы мы убираем тесты, которые дублируют друг друга, оставляя максимальное покрытие при минимальном необходимом наборе сценариев. Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.
2. Причина и следствие. Простая проверка базовых действий и их результата. Например, если нажать крестик в правом верхнем углу окна (причина), оно закроется (следствие), и т.д. Этот метод позволяет проверить все возможности системы, а также обнаружить баги и улучшить техническую документацию продукта.
3. Предугадывание ошибок. Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.

Тестирование требований

Требования (requirements) — описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.
Требования должны быть независимы от внутренней архитектуры приложения, т.е. должны описывать то, что необходимо заказчику без деталей реализации (принцип «what, not how»).
Почему же так важны требования? На каждом следующем шаге процесса разработки продукта стоимость обнаружения и устранения дефекта повышается в разы. Т.е. обнаружение максимального числа ошибок в требованиях поможет избежать лишней траты времени и средств в дальнейшем.
Уровни требований:

• Бизнес-требования. Выражают цель, ради которой разрабатывается продукт (зачем вообще он нужен, какая от него ожидается польза).
• Требования пользователей. Описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя).
• Функциональные требования. Описывают поведение системы, её действия (вычисления, преобразования, проверки, обработку).

Типы требований:

• функциональные. Определяют «что система должна делать»;
• нефункциональные. Определяют «как система это должна делать?». Нефункциональные требования включают:
• бизнес-правила (business rules) — описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и правил;
• атрибуты качества – это описания ключевых для проекта показателей качества (важных свойств продукта — производительность, масштабируемость, восстанавливаемость);
• требования к интерфейсу описывают особенности взаимодействия системы с другими системами, операционной средой и пользователем;
• ограничения представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта.
• другие требования:
• потребности (needs) — отражают проблемы бизнеса, которые должны быть соотнесены с использованием или приобретением системы
• системные требования (system requirements) — описывают высокоуровневые требования к ПО, содержащему несколько взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей (подключаемые модули).
• требования с количественной оценкой (quantifiable requirements) — требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность «столько-то запросов в секунду».

Источники требований:

• Соображения, высказанные представителем заказчика
• Артефакты, описывающие предметную область
• «Лучшие практики» («best practices»)
• Конкурирующие программные продукты

Важность тестирования требований состоит в том, что хорошие требования позволяют:

• достичь общего понимания между заказчиком и разработчиком;
• определить границы (рамки) проекта;
• более точно определить финансовые и временные характеристики проекта;
• обезопасить заказчика от риска получить продукт, в котором он не сможет работать;
• обезопасить разработчика от риска попасть в ситуацию «неконтролируемого размытия границ», которое может привести к непредвиденным затратам ресурсов сверх начальных ожиданий.

Хорошее требование должно быть:

• Завершённым (complete). Все важные аспекты должны быть включены. Ничто не должно быть оставлено «для будущего определения» (TBD — to be defined).
• Непротиворечивым (consistent). Требование не должно содержать противоречий как внутри себя, так и с другими требованиями.
• Корректным (correct) Требование должно чётко указывать на то, что должно выполнять приложение. Недопустимо при написании требования предполагать, что что-то окажется очевидным. Каждый человек понимает это «очевидное» по-своему.
• Недвусмысленным (unambiguous). Требование не должно допускать разночтений.
• Проверяемым (verifiable). Требование должно быть сформулировано так, чтобы существовали способы однозначной проверки — выполнено требование или нет.
• Модифицируемыми (modifiable) Структура и стиль набора требований должны быть такими, чтобы набор требований можно было легко модифицировать. Должна отсутствовать избыточность. Должно быть построено корректное содержание всего документа.
• Прослеживаемыми (traceable) У каждого требования должен быть уникальный идентификатор, по которому на это требование можно сослаться.
• Проранжированными по важности, стабильности и срочности (ranked for importance, stability and priority) Для каждого требования должен быть указан уровень его важности (насколько оно важно для заказчика), стабильности (насколько высока вероятность, что это требование ещё будет изменено в процессе обсуждения деталей проекта) и срочности (как быстро требование должно быть реализовано).

Техники тестирования требований:

1. Взаимный просмотр:

• беглый просмотр — автор показывает свою работу коллегам, они в свою очередь дают свои рекомендации, высказывают свои вопросы и замечания;
• технический просмотр — выполняется группой специалистов;
• формальная инспекция — привлекается большое количество специалистов, представляет собой структурированный, систематизированный и документированный подход. Минус такого варианта — тратится много времени.

1. Вопросы — если возникают вопросы, то можно спрашивать у представителей заказчика, более опытных коллег.
2. Тест-кейсы и чек-листы — хорошее требование должно быть проверяемым, чтобы это определить можно использовать чек-листы или полноценные тест-кейсы. Если можно быстро придумать несколько пунктов чек-листа — это уже хороший знак.
3. Исследование поведения системы — необходимо мысленно смоделировать процесс работы пользователя с системой, созданной по тестируемым требованиям, после этого определить неоднозначные варианты определения системы.
4. Рисунки — графическое представление дает наглядное представление приложения, на рисунке проще увидеть, что какие-то элементы не стыкуются, где-то чего-то не хватает и т.д.
5. Прототипирование — сделав наброски пользовательского интерфейса, легко оценить применить применение тех или иных пользовательских решений.

Тест план

Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Тест план – документ проектной документации, который описывает:

• процесс тестирования продукта в конкретном проекте;
• что, когда, кем и как будет тестироваться;
• компоненты тестирования;
• команду тестировщиков;
• стратегию и методы тестирования;
• критерии качества и риски тестирования;
• график работ.

Секции тестового плана:

1. Перечень работ. Включается перечень функциональных областей приложений, которые будут подвергаться тестированию. Здесь же может быть перечень компонентов или функциональности, которые не будут тестироваться по тем или иным причинам.
2. Критерии качества и оценка качества процесса. Здесь отражается перечень критериев качества, по которым оценивают уровень качества продукта и возможность передать его
   заказчику. Критерии качества относятся к качеству продукта. В тестовых планах могут быть зафиксированы и критерии качества самого процесса (тестирования и разработки). Чтобы в случае чего была возможность оценить, насколько грамотно был построен процесс тестирования, были ли проблемы, и, если были, разобраться, почему.
3. Риски. Кроме описания самого риска, нужно указать вероятность его возникновения и степень влияния на проект. Производная этих двух величин даёт показатель, который может рассматриваться как степень серьёзности риска.
4. Документация и Deliverables. В этой секции перечисляется перечень артефактов с шаблонами и результатами: тест план, тестовые сценарии, тестовые автоматические скрипты, дефект-репорты, отчеты о результатах тестирования, также указывается, кто будет их высылать, как часто, каким способом, кому и т.д.
5. Тестовая стратегия. Самый большой и один из самых важных разделов плана. Здесь расписывается стратегия тестирования, методы и типы тестов, каким образом будет выполняться тестирование, почему именно так и т. д.
6. Ресурсы. Человеческие ресурсы: перечень ключевых людей на проекте (менеджер проекта, представители заказчика, лидер команды разработчиков и т.д.), список тестировщиков с их ролями на проекте, а также с зонами ответственности. Аппаратные ресурсы (hardware): перечень тестовых серверов и рабочих станций, инструментов, используемых для тестирования или для вспомогательных работ, описание тестового окружения. Программные ресурсы (software): операционные системы, СУБД, серверы приложений, веб-серверы.
7. Метрики. Метрика – это числовая характеристика, позволяющая оценить аспект программного продукта или процесса.
8. Расписание. В этой секции описывается график тестирования в согласовании с графиком выпуска билдов и планом проекта, который разрабатывает менеджер проекта. Сюда же включаются основные даты (milestones): например, даты окончания промежуточных фаз работы. График тестирования нужен для того, чтобы чётко понимать, когда и что следует делать, ничего не пропустить, ничего не забыть и т.д. Он же упрощает контроль за ходом работ по тестированию, а также позволяет оценить текущую ситуацию, определить, всё ли выполнено из того, что было запланировано.
9. Ключевые точки и люди.

Критерии хорошего тест плана:

• определены цели тестирования, тестовый подход, стратегия, методы, виды тестирования. Запланированный подход должен быть реально выполним;
• установлены реалистичные критерии качества;
• определены критерии прохождения приёмочного теста и условия прекращения тестирования;
• определены все артефакты, подлежащие сдаче, поставке или распространению (заказчику, проекту и т.д.);
• перечислены тестовые ресурсы (люди, оборудование) с указанием ролей, назначений, ответственности;
• определено и описано тестовое оборудование, окружение, программное обеспечение;
• определён график тестирования, он должен быть реалистичен и выполним;
• соответствовать принятому в компании шаблону, если на проекте не решено иначе: например, использовать шаблон заказчика.

Разработка тестов (чек-листы, тест-кейсы)

Чек-лист (checklist) — cписок проверок без описания шагов. Упрощенная форма тест-кейса.
Тест кейс – совокупность шагов, условий и параметров созданных для проверки работоспособности функции или ее части.

Структура тест-кейса:

• Номер (number) или идентификатор (id)
• Связанное с тестом требование (related requirement)
• Модуль (feature)
• Имя (name)
• Предусловия (preconditions)
• Шаги (steps)
• Ожидаемый результат (expected result)
• Статус (passed, failed, blocked)
• Приоритет (priority: smoke, critical…)
• Cвязанный с тестом баг (если есть) (related bug)
• Постусловия (postconditions)

Результатом документирования тестов является тест-кейс. Набор тест-кейсов – Test Suite. Test Suite объединяет тесты по какому-то принципу: модулю, функционалу, виду тестирования.

Тест-кейсы могут быть:

1. Специфичными или общими (степень детальности). Когда все детали прописаны до мелочей, тест легко воспроизводить, снижается вероятность обнаружить ошибку. Общий тест-кейс сложно выполнять (особенно новичку).
2. Простыми или сложными. Простые тест-кейсы легко выполнять, они понятны новичкам, упрощают диагностику ошибки, делают наличие ошибки очевидным. Сложные тест-кейсы: больше шансов что-то сломать, пользователи, как правило, используют сложные сценарии, программисты сами редко проверяют такие варианты.
3. Независимыми или связанными друг с другом. Независимый самостоятельный тест-кейс легко и просто выполнить, такие тесты можно выполнять даже после краха других тестов, такие тесты можно группировать любым образом и выполнять в любом порядке. Связанные тесты имитируют работу реальных пользователей, удобны для разбиения на части тестов с большим количеством шагов, следующий в наборе тест использует данные и состояние приложения, подготовленные предыдущим.
4. Позитивными или негативными. Позитивные тесты проверяют, что приложение делает ТО, на ЧТО оно РАСЧИТАНО (т.е. такие тесты используют корректные данные и условия выполнения).
   Негативные тесты проверяют работу приложения в нестандартных условиях (с некорректными данными или командами или при работе в некорректных условиях).

Зачем нужны тест-кейсы:

• Тест-кейсы – хороший способ хранения проектной информации.
• Написание тест-кейсов – один из способов протестировать проектную документацию ещё до выхода первого билда.
• Наличие тест-кейсов ускоряет регрессионное тестирование.
• Тест-кейсы – прекрасный способ быстро ввести в курс дела новичка или сотрудника, только что подключившегося к проекту.
• Имея тест-кейсы, мы можем в любой момент «вспомнить», что мы делали месяц, полгода, год назад.
• Тест-кейсы позволяют легко отслеживать прогресс (X% тестов выполнено, Y% тестов прошло (завалилось), Z% требований покрыто тестами).

SQL

SQL — structured query language — «язык структурированных запросов», стандартный язык доступа и управления базами данных (БД).
Структурированный язык запросов — это стандартный язык доступа к БД, таким как SQL Server, Oracle, MySQL, Sybase и Access.
Программная инструкция для получения данных из БД, называется запросом к базе данных.

Основные MySQL запросы:
SELECT — извлекает данные из таблицы БД;
UPDATE — обновляет данные в таблице БД;
DELETE — уничтожает данные в таблице БД;
INSERT INTO- вставляет новые данные в таблицу БД.

Первичный ключ или PRIMARY KEY предназначен для однозначной идентификации каждой записи в таблице и является строго уникальным (UNIQUE): две записи таблицы не могут иметь одинаковые значения первичного ключа. Нулевые значения (NULL) в PRIMARY KEY не допускаются. Если в качестве PRIMARY KEY используется несколько полей, их называют составным ключом.

Пример:

CREATE TABLE USERS (
id INT NOT NULL,
name VARCHAR (20) NOT NULL,
PRIMARY KEY (id)
);

Здесь в качестве первичного ключа используется поле id.

Внешний ключ или FOREIGN KEY также является атрибутом ограничения и обеспечивает связь двух таблиц. По сути, это поле или несколько полей, которые ссылаются на PRIMARY KEY в родительской таблице.

Пример:

CREATE TABLE order (
order_id INT NOT NULL,
user_id INT,
PRIMARY KEY (order_id),
FOREIGN KEY (user_id) REFERENCES users(id)
);

В данном случае внешний ключ, привязанный к полю user_id в таблице order, ссылается на первичный ключ id в таблице users, и именно по этим полям происходит связывание двух таблиц.

SQL-ограничения (constraints) указываются при создании или изменении таблицы. Это правила для ограничения типа данных, которые могут храниться в таблице. Действие с данными не будет выполнено, если нарушаются установленные ограничения.

UNIQUE — гарантирует уникальность значений в столбце;
NOT NULL — значение не может быть NULL;
INDEX — создаёт индексы в таблице для быстрого поиска/запросов;
CHECK — значения столбца должны соответствовать заданным условиям;
DEFAULT — предоставляет столбцу значения по умолчанию.

Ключевое слово ORDER BY используется для сортировки данных в порядке возрастания (ASC) или убывания (DESC).

Пример:

SELECT * FROM user ORDER BY name DESC;

Чтобы объединить две таблицы в одну, следует использовать оператор JOIN. Соединение таблиц может быть внутренним (INNER) или внешним (OUTER), причём внешнее соединение может быть левым (LEFT), правым (RIGHT) или полным (FULL).

INNER JOIN — получение записей с одинаковыми значениями в обеих таблицах, т.е. получение пересечения таблиц.
FULL OUTER JOIN — объединяет записи из обеих таблиц (если условие объединения равно true) и дополняет их всеми записями из обеих таблиц, которые не имеют совпадений. Для записей, которые не имеют совпадений из другой таблицы, недостающее поле будет иметь значение NULL.
LEFT JOIN — возвращает все записи, удовлетворяющие условию объединения, плюс все оставшиеся записи из внешней (левой) таблицы, которые не удовлетворяют условию объединения.
RIGHT JOIN — работает точно так же, как и левое объединение, только в качестве внешней таблицы будет использоваться правая.

Оператор UNION используется для объединения полученных данных из двух или более запросов, которые должны иметь одинаковое количество столбцов с одинаковыми типами данных и расположенных в том же порядке.

Пример:

SELECT column(s) FROM first_table
UNION
SELECT column(s) FROM second_table;

Подстановочные знаки — это специальные символы, которые нужны для замены каких-либо знаков в запросе. Они используются вместе с оператором LIKE, с помощью которого можно отфильтровать запрашиваемые данные.
% — заменить ноль или более символов;
_ — заменить один символ.

Примеры:

SELECT * FROM user WHERE name LIKE '%test%';

Данный запрос позволяет найти данные всех пользователей, имена которых содержат в себе «test».

SQL-псевдонимы (aliases) нужны для того, чтобы дать временное имя таблице или столбцу. Это нужно, когда в запросе есть таблицы или столбцы с неоднозначными именами. В этом случае для удобства в составлении запроса используются псевдонимы. SQL-псевдоним существует только на время запроса.

Пример:

SELECT very_long_column_name AS alias_name
FROM table;

Тестирование веб-приложений

Web-приложение — это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером — web-сервер, что уже является по сути двумя программами, которые необходимо тестировать как отдельно, так и в связке. Кроме веб-сервера, приложение может использовать базы данных, другие приложения и удаленные веб-сервисы.

Любое веб-приложение представляет собой набор статических и динамических веб-страниц. Статическая веб-страница — это страница, которая всегда отображается перед пользователем в неизменном виде. Веб-сервер отправляет страницу по запросу веб-браузера без каких-либо изменений. В противоположность этому, сервер вносит изменения в динамическую веб-страницу перед отправкой ее браузеру.

Веб-сервер — это ПО, которое предоставляет веб-страницы в ответ на запросы веб-браузеров. Обычно запрос страницы создается при щелчке ссылки на веб-странице, выборе закладки в браузере либо вводе URL-адреса в адресной строке браузера.

«Клиент — сервер» (англ. client–server) — архитектура, в которой сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами.
Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на одной машине.

HTTP (англ. HyperText Transfer Protocol – «протокол передачи гипертекста») – протокол прикладного уровня передачи данных. Изначально – в виде гипертекстовых документов в формате HTML, сегодня используется для передачи произвольных данных. Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

Структура HTTP-запроса:

1. строка запроса (Request Line);
2. заголовки (Message Headers);
   Пустая строка (разделитель)
3. тело сообщения (Entity Body) – необязательный параметр.
   Строка запроса — указывает метод передачи, URL-адрес, к которому нужно обратиться и версию протокола HTTP.
   Заголовки — описывают тело сообщений, передают различные параметры и др. сведения и информацию. Тело сообщения — это сами данные, которые передаются в запросе. Тело сообщения – это необязательный параметр и может отсутствовать.

Ответ сервера:
HTTP/1.1 <код ответа> <сообщение><\n>
<заголовок>: <значение><\n>
<заголовок>: <значение><\n>
…
<заголовок>: <значение><\n>
<\n>
<тело документа>

Коды ответов сервера:
1хх Информационные сведения
2хх Подтверждение и принятие действия или команды
3хх Redirect или перенаправления
4хх Ошибка со стороны клиента
5хх Неполадки и сообщения со стороны сервера

Основные запросы:

1. GET — запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные. Не имеет тела.
2. POST — используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере. Имеет тело.
3. PUT — заменяет все текущие представления ресурса данными запроса.
4. DELETE — удаляет указанный ресурс.

JSON и XML — форматы файлов, которые используются для получения и отправки данных с веб-сервера.

JSON (англ. JavaScript Object Notation) — простой формат обмена данными, основанный на языке программирования JavaScript. Использует человекочитаемый текст для передачи объектов данных.

Синтаксические правила JSON:

• Данные указываются в парах имя / значение, разделяемые двоеточием «firstName»:«Lev»
• Данные разделяются запятыми «firstName»:«Anna», «lastName»:«Karenina»
• Фигурные скобки удерживают объекты {«firstName»:«Lev»,«lastName»:«Tolstoy»},
• Квадратные скобки содержат массивы

XML — язык разметки, который определяет набор правил для кодирования документов в формате, который читается человеком и читается машиной. Но чем больше информации (вложений, комментариев, вариантов тегов и т.д.) в xml, тем сложнее ее читать человеку.
XML хранит данные в текстовом формате. Это обеспечивает независимый от программного и аппаратного обеспечения способ хранения, транспортировки и обмена данными. XML также облегчает расширение или обновление до новых операционных систем, новых приложений или новых браузеров без потери данных.

Синтаксис XML:

• Весь XML документ должен иметь корневой элемент.
• Все теги должны быть закрыты (либо самозакрывающийся тег).
• Все теги должны быть правильно вложены.
• Имена тегов чувствительны к регистру.
• Имена тегов не могут содержать пробелы.
• Значения атрибута должны появляться в кавычках («»).
• Атрибуты не могут иметь вложения (в отличие от тегов).
• Пробел сохраняется.

Поиск и документирование дефектов

Программная ошибка – изъян в ПО, который вызывает несоответствие ожидаемых результатов выполнения и фактически полученных результатов.
Баг (bug) – это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
Дефект – поведение программы, затрудняющее (делающее невозможным) пользователю достигнуть цели или удовлетворить интересы. Подразумевает возможность исправления. При
невозможности переходит в разряд ограничения технологии.

Статусы бага:

1. Новый (New) или Открыт (Open). Тестировщик находит дефект и заносит его в систему управления дефектами. С этого момента баг начинает свою официальную жизнь и о его существовании знают необходимые люди.
2. Назначен (assigned). Далее разработчик рассматривает дефект и назначает его исправление кому-то из команды разработчиков.
3. Исправлен (fixed). Разработчик, которому было назначено исправление дефекта, исправляет его и сообщает о том, что задание выполнено.
4. Проверен (verified). Тестировщик, который обнаружил ошибку проверяет на новом билде (в котором исправление данной ошибки заявлено), исправлен ли дефект на самом деле. И только в том случае, если ошибка не проявится на новом билде, тестировщик меняет статус бага на Verified.
5. Открыт заново (reopened). Если баг проявляется на новом билде, тестировщик снова открывает этот дефект. Баг приобретает статус Reopened.
6. Не могу воспроизвести (can not reproduce). Если в описании бага нет всей необходимой информации, программист не сможет его воспроизвести, чтобы починить.
7. Не баг (not a bug). Баг может быть отклонён. Во-первых, потому, что для заказчика какие-то ошибки — не ошибки. Во-вторых, это может случиться по вине тестировщика из-за плохого знания продукта, требований (дефекта на самом деле нет).
8. Не чинить (will not fix). Формально это баг, но чинить его не будут, не могут или не хотят.
9. Дублирован (duplicate). Если уже существует открытый баг, который направлен на выявление той же самой ошибки.

Баг/Дефект Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и
ожидаемого результата.

Атрибуты баг репорта:

1. Идентификатор (id);
2. Краткое описание (summary). Хорошее краткое описание должно давать ответы на три вопроса: Что? Где? При каких условиях?
3. Подробное описание (description);
4. Шаги воспроизведения (steps to reproduce, STR) — точный путь, чтобы воспроизвести дефект;
5. Актуальный результат (Actual Result);
6. Ожидаемый результат (Expected Result);
7. Важность (severity) — показывает насколько ошибка затрагивает значимый функционал приложения;
8. Срочность (priority) — показывает, как быстро необходимо исправить ошибку.

Дополнительные атрибуты: возможность «обойти баг» (workaround), дополнительная информация (additional information), воспроизводимость (reproducible), приложения (attachments).

Test result report

Отчёт о результатах тестирования (test result report, TRR) – часть тестовой документации, включающая в себя описание процесса тестирования, суммарную информацию о протестированных за подотчётный период билдах, информацию о деятельности тестировщиков, а также другие статистические данные.

Цель TRR – предоставить лицам, заинтересованным в проекте, полную и объективную информацию о текущем состоянии качества проекта. Эта информация выражается в конкретных фактах и цифрах.

Структура отчёта:
• Команда тестировщиков: перечисляются все задействованные в процессе тестирования сотрудники с указанием занимаемой должности и роли на проекте в подотчётный период.
• Описание процесса тестирования (testing process descripion). Даётся краткое описание того, как происходило тестирование: какие использовались методы, техники, инструментальные средства и т.п.
• Краткое описание (summary). Краткое описание того, какие билды были протестированы, есть ли в качестве приложения прогресс или регресс, есть ли какие-либо проблемы, требующие внимания руководства.
• Расписание (tesing timetable). Детализированное описание того, какая работа и на протяжении какого времени выполнялась каждым тестировщиком.
• Рекомендации (recomendaions) — подчеркнуть те важные моменты, на которые следует обратить внимание руководству или лидерам проектных команд. Здесь также, возможно, будет дана рекомендация на передачу проекта заказчику («передачу в продакшн»).
• Статистика по ошибкам (bugs statistics). Приводится сводная таблица, содержащая информацию об ошибках, с которыми команде тестировщиков приходилось иметь дело в подотчётный период.
• Список новых ошибок (new bugs found). Приводится список ошибок, обнаруженных командой тестировщиков за отчётный период.
• Статистика по всем ошибкам (all bugs statistics). Сводная таблица с информацией об ошибках за всё время работы над проектом.

Отчёт о результатах тестирования в основном нужен:
• Менеджеру проекта
• Лидеру команды разработчиков
• Лидеру команды тестировщиков
• Заказчику

Тестирование веб-сервисов и API

Веб-сервис — это идентифицируемая веб-адресом программная система со стандартизированными интерфейсами.
Веб-сервисы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах (SOAP, XML-RPC, REST и т. д.).
Веб-приложение — это то, что пользователь может увидеть глазами и с чем может взаимодействовать используя графический интерфейс.
Веб-сервис — это программа, работающая без участия пользователя, как правило без графического интерфейса (gui может быть разработан для упрощения тестирования) и пользователь не может взаимодействовать с ней привычным способом, нажимая на кнопки и ссылки. Разрабатываются для автоматической обработки и распределения информации.
Структура веб-приложения:

• Уровень графического интерфейса (GUI). Пользовательский интерфейс нужен для предоставления входных данных для приложения и получения ответа.
• Сервисный уровень (функциональные возможности). Реализует функциональность, которая соответствует бизнес-требованиям приложения.
• Уровень хранения (данных). Сохраняет и обрабатывает данные, полученные на сервисном уровне.

Основные виды веб-сервисов:
SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур (RPC — Remote Procedure Call). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур.
REST (сокр. от англ. Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределенного приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределенной гипермедиа-системы. В определенных случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. Компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC.

Различия SOAP и REST сервисов:

• SOAP – это целое семейство протоколов и стандартов, откуда напрямую вытекает, что это более тяжеловесный и сложный вариант с точки зрения машинной обработки. Поэтому REST
  работает быстрее.
• REST поддерживает различные форматы: text, JSON, XML; SOAP — только XML.
• REST работает только по HTTP(S) используя всего 4 HTTP метода (Get, Post, Put, Delete), а SOAP может работать с различными протоколами.
• REST может работать с ресурсами. Каждый URL это представление какого-либо ресурса. SOAP работает с операциями, которые реализуют какую-либо бизнес логику с помощью нескольких
  интерфейсов.

Тестирование web-сервисов:

• Postman. Расширение для Google Chrome, которое в бесплатной версии позволяет посылать запросы, записывать их, показывать историю. Удобно и понятно.
• jMeter. Инструмент, получивший известность, прежде всего, благодаря нагрузочному тестированию, которое можно проводить с его помощью. Но это лишь одно из множества его
  применений.
• Fiddler. Позволяет просматривать посылаемые HTTP запросы. И много чего еще.
• SoapUI. Мощный продукт для разработки и тестирования веб приложений.
• Runscope. Cервис для автоматизированного тестирования API. С его помощью можно посылать запросы к серверу и проверять полученные ответы по заранее установленным критериям.
• Advanced REST Client. Еще одно расширение для Chrome для работы с API (конструкция запросов, их показ в удобном виде и другое).

Тестирование мобильных приложений

Тестирование мобильных приложений в целом соответствует общим принципам тестирования, поскольку основано на той же Клиент-Серверной архитектуре. Однако в силу некоторых обстоятельств имеет ряд особенностей:

• Специфичность операционных систем для мобильных платформ.
• Различные компании изготовители устройств и конфигурации комплектующих.
• Функциональность устройств как коммуникаторов.

Виды мобильных приложений:

• Нативные: нативный = родной. Разрабатываются специально под конкретную платформу (отдельно под iOS , Android, Windows Phone). Используются только «родные» языки программирования для написания таких приложений (Swift, Objective-C — iOS, Java — Android, C# for WP). Платформозависимый UX и UI. Бережное расходование ресурсов телефона (батарея, сеть..). Можно полностью зашифровать и скрыть реализацию исходного кода (proguard).
• Веб (web site и progressive): по сути, сайт, оптимизированный под смартфон. GUI создается при помощи стандартных веб-технологий. Кроссплатформенные— могут работать на всех устройствах, без дополнительной адаптации. Для установки не нужен магазин. Очень ограниченно могут использовать ПО смартфона (камера, гироскоп…).
• Гибридные. Почти полная функциональность нативного приложения на НЕзависимой платформе. Кроссплатформенность. Почти полное использование ПО смартфона (есть ограничения). Разработка дешевле и быстрее, чем у нативных. Не бережное использование ресурсов телефона. Нативное поведение и UI нужно прописывать самому отдельно и самостоятельно. Нельзя полностью скрыть исходный код.

Особенности тестирования:

1. Внешние прерывания:

• входящие и исходящие SMS и MMS
• входящие и исходящие звонки
• изъятие аккумулятора
• отключение и подключение usb-провода
• отключение и подключение сети
• переход из режима WiFi на 3G и обратно
• отключение и подключение SD-карты
• включение и выключение проигрывателя
• зарядка устройства
• push-уведомления сторонних приложений и их открытие
• засыпание устройства

1. Ресурсы телефона:

• как ведет себя приложение при малом количестве места на устройстве (недостаток места для установки или работы приложения)
• при низком заряде аккумулятора
• установка на карту SD
• очистка данных приложения при удалении его с устройства
• с включенным/выключенным GPS
• поддержка необходимых медиа-файлов данной моделью и ОС

1. Обратная связь с пользователем:

• сообщения при загрузке контента / прогресс-бар
• сообщения при ошибке доступа к сети
• наличие сообщений при попытке удалить важную информацию
• наличие экрана / сообщения при окончании процесса / игры
• наличие и синхронность звуковых и вибрационных уведомлений с уведомлениями на экране
• версии ОС: приложение не должно устанавливаться на неподдерживаемые устройства; обязательная проверка на всех возможных из поддерживаемых девайсов.

1. Остальное:

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

Middle QA