From 682918b2eedd044aba5aff460377f3a780ccc14e Mon Sep 17 00:00:00 2001 From: Vladislav610 <53944553+Vladislav610@users.noreply.github.com> Date: Sun, 21 Feb 2021 21:16:38 +0300 Subject: [PATCH] Update v. 2.0 --- Manual part 2.md | 7062 ++++++++++++++++++++++++++-------------------- 1 file changed, 3987 insertions(+), 3075 deletions(-) diff --git a/Manual part 2.md b/Manual part 2.md index 1f7499f..c041459 100644 --- a/Manual part 2.md +++ b/Manual part 2.md @@ -1,3906 +1,5003 @@ - - -

Тестовые артефакты и документация (Test Deliverables/TestWare/test artifacts)

-

Виды тестовой документации? - -

+

----- Тестовые артефакты и документация (Test Deliverables/TestWare/test artifacts) ----- 

+

Виды тестовой документации?

Внешняя документация: - Замечание – короткая записка, комментарий о небольшой неточности в реализации продукта. - Дефект-репорт – описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым – ошибки или ее проявления. Он обязательно должен содержать следующие элементы: - Запрос на изменение (улучшение) – описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя. И пути/рекомендации по модификации продукта для соответствия им. - Сводный отчет об испытаниях (Test summary report) представляет собой документ высокого уровня, в котором обобщаются проведенные испытания и результаты испытаний. - -Политика тестирования (Test policy) – Общая цель организации при выполнении тестовых заданий описана в документе «Политика тестирования». Он создается Lead’ами и Senior’ами в группе управления тестированием совместно с руководителями групп заинтересованных сторон. Иногда тестовая политика является частью более широкой политики качества, принятой организацией. В таких случаях политика качества разъяснит общую цель менеджмента в отношении качества. Политика тестирования — это краткий документ, обобщенный на высоком уровне, который содержит следующее: - +Политика тестирования (Test policy) – Общая цель организации при выполнении тестовых заданий описана в документе «Политика тестирования». Он создается Lead’ами и Senior’ами в группе управления тестированием совместно с руководителями групп заинтересованных сторон. Иногда тестовая политика является частью более широкой политики качества, принятой организацией. В таких случаях политика качества разъяснит общую цель менеджмента в отношении качества. Политика тестирования — это краткий документ, обобщенный на высоком уровне, который содержит следующее: -Стратегия тестирования (Test strategy) — это подход к проведению тестирования (STLC). Это относительно небольшой статический документ, который предшествует плану тестирования. Прежде чем писать объемный и подробный план, стоит формализовать некоторые базовые подходы к тестированию и убедиться, что все заинтересованные лица понимают одинаково, что и как будет тестироваться. Вероятность пропустить какую-либо тестовую активность очень мала, если существует правильная стратегия тестирования. Это самый важный документ для любой команды QA. Написание эффективного Стратегического документа - это навык, который тестер развивает с опытом. Стратегия включает: - +Стратегия тестирования (Test strategy) — это подход к проведению тестирования (STLC). Это относительно небольшой статический документ, который предшествует плану тестирования. Прежде чем писать объемный и подробный план, стоит формализовать некоторые базовые подходы к тестированию и убедиться, что все заинтересованные лица понимают одинаково, что и как будет тестироваться. Вероятность пропустить какую-либо тестовую активность очень мала, если существует правильная стратегия тестирования. Это самый важный документ для любой команды QA. Написание эффективного Стратегического документа - это навык, который тестировщик развивает с опытом. Стратегия включает: Внутренняя документация: - +Доп. материал:  +

Какие отличия у тест-кейса высокого и низкого уровня?

-Высокоуровневый тест-кейс (high level test case или logical test case) — тест-кейс без конкретных входных данных и ожидаемых результатов. -Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов. -Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — -намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса. - +Высокоуровневый тест-кейс (high level test case или logical test case) — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов. Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.

Отличия Test Suite от Test Scenario?

-Test Suite — это серия логически связанных Test case, которые позволяют проверить один из вариантов сценария. Test Scenario - представляет собой некий пользовательский сценарий по тестированию некой функциональности. Что-то, что пользователь может захотеть сделать с вашей системой, и вы хотите это проверить. Сценарий может иметь один или несколько Test Suite. - +Test Suite - это серия логически связанных Test case, которые позволяют проверить один из вариантов сценария. Test Scenario - представляет собой некий пользовательский сценарий по тестированию некой функциональности. Что-то, что пользователь может захотеть сделать с вашей системой, и вы хотите это проверить. Сценарий может иметь один или несколько Test Suite.

Какие отличия у плана тестирования и стратегии тестирования?

+

В чем разница между тест-кейсом и чек-листом?

+Сила тест-кейса в том, что в нем все расписано очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но все это сложно обновлять или изменять. +Сила чек-листа в том, что он простой. Там нет глубокой детализации, это просто памятка. Но тестировать приложение по чек-листу сразу, без подготовки, не понимая, что подразумевается под «Зачарджить ордер на бэкофисе» (это где? это как? это что? это откуда и куда?) — практически невозможно. + +Доп. материал:  + +

Чем Test case отличается от сценария тестирования?

+Test case - это артефакт тестирования для проверки определенного flow с определенными входными значениями, предварительными условиями тестирования, ожидаемым выходным сигналом и постусловиями, подготовленными для охвата определенного поведения. Тестовый сценарий может иметь одну или несколько ассоциаций с тестовым набором, что означает, что он может включать несколько тестовых наборов.

Виды тест планов?

Чаще всего на практике приходится сталкиваться со следующими видами тест планов: - -Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является «живым» документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте. - -В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения. - +Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте. +В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения. Для увеличения ценности вашего тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы: - Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным. -

Что является основой для подготовки плана приемки? (PAP — Product Acceptance Plan)

-Прежде всего, вам нужны данные из следующих областей, чтобы подготовиться к приемке. Они могут варьироваться от компании к компании и от проекта к проекту. + +Доп. материал: +Тест-план не для галочки, или 8 вопросов к заказчику на старте проекта +

Что является основой для подготовки плана приемки? (PAP - Product Acceptance Plan)

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

Что такое тест-анализ/основа/база тестирования и условия тестирования ? (Test Analysis/Test Basis/Test conditions)

+База тестирования определяется как источник информации или документ, необходимый для написания кейсов, а также для анализа тестов. База тестирования должна быть четко определена и должным образом структурирована, чтобы можно было легко определить условия тестирования, из которых можно получить тестовые примеры. Типичная основа тестирования: + -

В чем разница между тест-кейсом и чек-листом?

-Сила тест-кейса в том, что в нем все расписано очень детально, и с помощью тест-кейсов тестировать сможет даже человек, который ни разу не видел тестируемое им приложение. Но все это сложно обновлять или изменять. - -Сила чек-листа в том, что он простой. Там нет глубокой детализации, это просто памятка. Но тестировать приложение по чек-листу сразу, без подготовки, не понимая, что подразумевается под «Зачарджить ордер на бэкофисе» (это где? это как? это что? это откуда и куда?) — практически невозможно. - -

В чем разница между тест-кейсами высокого уровня и низкого уровня?

-Тест-кейсы высокого уровня охватывают основную функциональность продукта, такую как стандартные бизнес-процессы. - -Низкоуровневые тест-кейсы относятся к пользовательскому интерфейсу в приложении. - -

Чем Test case отличается от сценария тестирования?

-Test case — это артефакт тестирования для проверки определенного flow с определенными входными значениями, предварительными условиями тестирования, ожидаемым выходным сигналом и постусловиями, подготовленными для охвата определенного поведения. Тестовый сценарий может иметь одну или несколько ассоциаций с тестовым набором, что означает, что он может включать несколько тестовых наборов. -

Что такое тест-анализ/основа теста? (Test Analysis/Test Basis)

-Процесс поиска артефактов теста для определения условий / Test case. Следовательно, это также называется тестовой базой. Чаще всего информация получается из опыта или следующих источников: +Т. е. Test conditions - тестируемый аспект в test basis - элемент или событие компонента или системы, которые могут быть проверены одним или несколькими кейсами: функция, транзакция, фича, атрибут качества или структурный элемент и т.п. +Доп. материал:

Что такое документ бизнес-требований (BRD)?

-BRD предоставляет полное бизнес-решение для проекта, включая документацию о потребностях и ожиданиях клиентов. BRD выполняет следующие задачи. - +BRD предоставляет полное бизнес-решение для проекта, включая документацию о потребностях и ожиданиях клиентов. BRD выполняет следующие задачи. 

Что вы знаете о требованиях (уровни/виды и т. д.)?

Виды требований по уровню: - -Виды требований по характеру: - -1. Функциональные требования — что система должна делать. К функциональным требованиям относят (из первого вытекает следующее): +Виды требований по характеру: +1. Функциональные требования - что система должна делать. К функциональным требованиям относят (из первого вытекает следующее): -В группу функциональных требований относят и системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта — объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС - Windows не ниже XP, браузеры IE не ниже 7.0 и так далее. - -Почему важно указывать системные требования и утверждать их у заказчика? Если не указать, например, что важно обеспечить просмотр сайта в IE 6, то разработчики вполне могут выбрать такое архитектурное решение, которое не позволит корректно отображать сайт. Системные требования напрямую зависят от целевой аудитории проекта. - -2. Нефункциональные требования. Иначе говоря, как будет работать система и почему именно так. +В группу функциональных требований относят и системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объем оперативной памяти, объем жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта - объем памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера.  Для сайта: ОС - Windows не ниже XP, браузеры IE не ниже 7.0 и так далее. +Почему важно указывать системные требования и утверждать их у заказчика? Если не указать, например, что важно обеспечить просмотр сайта в IE 6, то разработчики вполне могут выбрать такое архитектурное решение, которое не позволит корректно отображать сайт. Системные требования напрямую зависят от целевой аудитории проекта.  +2. Нефункциональные требования. Иначе говоря, как будет работать система и почему именно так.  -Еще одна классификация: +Еще одна классификация: -Источники требований: +Источники требований: -Методы выявления требований: +Методы выявления требований: Требования начала для производства ПО: - Есть и другие условия, но они менее значимы и сильно зависят от конкретного процесса в компании. -

Расскажите, какие есть требования к самим требованиям?

- - -

Дефекты и ошибки

-

Что такое дефект?

+Доп. материал: + +

----- Дефекты и ошибки -----

+

Что такое дефект? 

Разница между ожидаемым и фактическим результатом. +Доп. материал: +Баг или фича? Вот в чем вопрос!

Классы дефектов?

-

Какие есть категории дефектов?

-Существует три основных категории дефектов: - +

Какие есть категории дефектов? 

+Существует три основных категории дефектов: 

Error/Mistake/Defect/Bug/Failure/Fault?

В русском языке переводятся практически одинаково, но это разные термины. В некоторых источниках данные термины следуют за категориями, описанными выше. - -

Каково содержание эффективного сообщения об ошибке?

- - - -

Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке?

- -

Серьезность и Приоритет Дефекта (Severity & Priority)

-Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. Все знают такой баг-трекер, как Atlassian JIRA. В нем, начиная с какой-то версии вместо одновременного использования полей Severity и Priority, оставили только Priority, которое собрало в себе свойства обоих полей. Но, всё же, разделение этих понятий может быть очень важно, а точнее использование обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный: - -Серьезность — представляет серьезность / глубину ошибки в контексте работоспособности самого ПО. Приоритет - указывает на очередность выполнения задачи или устранения дефекта. - -Серьезность — Описывает точку зрения приложения. Приоритет - точку зрения бизнеса. - -пример: -я в ходе тестирования нашёл дефект, довольно критичный для приложения на мой взгляд т.к. этот дефект закрывает доступ к 20% функционала. ставлю такому багу сиверити «критикал». ПМ видит багрепорт, анализирует ситуацию (поджимающие сроки, этот функционал будет рефакториться или вообще выкидываться в следующей итерации и т.п.) и ставит приорити — «медиум» или ниже. -а девелопер при работе с баг- тасктреккером руководствуется исключительно приорити, т.к. приорити и существует для регулирования очерёдности выполнения тасков. - -Градация Серьезности дефекта (Severity): - +

Каково содержание эффективного сообщения об ошибке? 

- - -Серьезность ошибки может быть низкой, средней или высокой, в зависимости от контекста. +Доп. материал: +О записи багов, или Найди кота +

Несколько ключевых моментов, которые следует учитывать при написании отчета об ошибке? 

-Градация Приоритета дефекта (Priority): - +
  • Воспроизведите ошибку 2-3 раза.  +
    • +
  • Используйте некоторые ключевые слова, связанные с вашей ошибкой, и выполните поиск в инструменте отслеживания дефектов.  +
    • +
  • Проверьте в аналогичных модулях. +
    • +
  • Сообщите о проблеме немедленно.  +
    • +
  • Напишите подробные шаги для воспроизведения ошибки.  +
    • +
  • Напишите хорошее summary дефекта. Следите за словами в процессе написания сообщения об ошибке, они не должны оскорблять людей. Никогда не используйте капс, объясняя проблему.  +
    • +
  • Желательно проиллюстрировать проблему с помощью правильных скриншотов.  +
    • +
  • Перед публикацией перепроверьте два или три раза ваш отчет об ошибке. +
    • + +

    Серьезность и Приоритет Дефекта (Severity & Priority)

    +Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. Все знают такой баг-трекер, как Atlassian JIRA. В нем, начиная с какой-то версии вместо одновременного использования полей Severity и Priority, оставили только Priority, которое собрало в себе свойства обоих полей. Но, все же, разделение этих понятий может быть очень важно, а точнее использование обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный: +Серьезность - представляет серьезность / глубину ошибки в контексте работоспособности самого ПО. Приоритет - указывает на очередность выполнения задачи или устранения дефекта. Серьезность - Описывает точку зрения приложения. Приоритет - точку зрения бизнеса. Приоритет выставляет менеджер, разработчик берет таски исходя из приоритета. + +пример: +я в ходе тестирования нашел дефект, довольно критичный для приложения на мой взгляд т.к. этот дефект закрывает доступ к 20% функционала. ставлю такому багу Severity "критикал". ПМ видит багрепорт, анализирует ситуацию (поджимающие сроки, этот функционал будет рефакториться или вообще выкидываться в следующей итерации и т.п.) и ставит приорити - "медиум" или ниже. +а девелопер при работе с баг- тасктреккером руководствуется исключительно приорити, т.к. приорити и существует для регулирования очередности выполнения тасков. + +Градация Серьезности дефекта (Severity): + + +Серьезность ошибки может быть низкой, средней или высокой, в зависимости от контекста. + + +Градация Приоритета дефекта (Priority):

    Может ли быть высокий severity и низкий priority? А наоборот?

    -Да, такое может быть при некоторых стечениях обстоятельств. - +Да, такое может быть при некоторых стечениях обстоятельств.  -

    Жизненный цикл дефекта?

    - -Жизненный цикл дефекта — это представление различных состояний дефекта, в которых он пребывает от начального до конечно этапа своего существования. Он может варьироваться от компании к компании или даже настраиваться для некоторых проектов. - -Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус «Новый». Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов: - -«Отклонен», если данный баг невалидный или повторный, или же его просто не смогли воспроизвести - -«Отсрочен», если данный баг не нужно исправлять в данной итерации - -«Открыт», если исправление бага необходимо +

    Жизненный цикл дефекта?

    + +Жизненный цикл дефекта - это представление различных состояний дефекта, в которых он пребывает от начального до конечного этапа своего существования. Он может варьироваться от компании к компании или даже настраиваться для некоторых проектов. +Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус "Новый". Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов: +"Отклонен", если данный баг невалидный или повторный, или же его просто не смогли воспроизвести +"Отсрочен", если данный баг не нужно исправлять в данной итерации +"Открыт", если исправление бага необходимо Рассмотрим теперь по порядку каждый из вариантов. - -Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на «Переоткрыт» либо закрыть его — статус «Закрыт» - -Отсрочен. Баг репорт в статусе «Отсрочен» можно перевести в статус «Открыт», когда потребуется исправление либо в статус «Закрыт», если уже не потребуется. - -Открыт. Именно в таком состоянии разработчик получает баг репорт для исправления. Он может отклонить (дальнейшие действия смотрите в пункте 1) или исправить баг. Баг репорт в статусе «Исправлен» переводится на тестировщика для проверки. В случае если проблема все еще воспроизводится, выставляется статус «Переоткрыт» и баг репорт направляется назад на доработку к разработчику. Если же исправление было успешным, то баг репорт переводится в статус «Закрыт». - +Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на "Переоткрыт" либо закрыть его - статус "Закрыт" +Отсрочен. Баг репорт в статусе "Отсрочен" можно перевести в статус "Открыт", когда потребуется исправление либо в статус "Закрыт", если уже не потребуется. +Открыт. Именно в таком состоянии разработчик получает баг репорт для исправления. Он может отклонить (дальнейшие действия смотрите в пункте 1) или исправить баг. Баг репорт в статусе "Исправлен" переводится на тестировщика для проверки. В случае если проблема все еще воспроизводится, выставляется статус "Переоткрыт" и баг репорт направляется назад на доработку к разработчику. Если же исправление было успешным, то баг репорт переводится в статус "Закрыт". * * * +Хотим отметить, что данная схема сильно упрощена. Для большей наглядности и, возможно, удобства работы на проекте, вы можете добавить дополнительные статусы и переходы, тем более, что современные баг трекинговые системы позволяют это делать. Правда имейте в виду, что излишне запутанные схемы переходов и лишние статусы могут значительно усложнить жизнь. -Хотим отметить, что данная схема сильно упрощена. Для большей наглядности и, возможно, удобства работы на проекте, вы можете добавить дополнительные статусы и переходы, тем более, что современные баг трекинговые системы позволяют это делать. Правда имейте ввиду, что излишне запутанные схемы переходов и лишние статусы могут значительно усложнить жизнь. - -Примечание 1: в некоторых системах баг трекинга, созданный баг репорт сразу получает статус «Открыт» без дополнительной валидации - +Примечание 1: в некоторых системах баг трекинга, созданный баг репорт сразу получает статус "Открыт" без дополнительной валидации Примечание 2: многие баг трекинговые системы позволяют переоткрывать закрытые баги, однако лично я против такой практики, поэтому и не описывал подобный переход в выше представленном жизненном цикле - -Примечание 3: Рассмотренный выше жизненный цикл основан на том, что в команде есть кто-то, ответственный за назначение баг репортов. В случае, если такой роли на проекте нет, то баги назначаются разработчиками самостоятельно, и тогда во избежании путанницы, есть смысл ввести еще один промежуточный статус «В разработке» (In progress), показывающий, что данный баг репорт уже назначен и находится на стадии исправления. - -

    Пришёл баг из продакшена, что делаем?

    -Воспроизводим, запускаем по пути жизненного цикла дефекта и анализируем причины, как данный дефект прошёл в прод. После исправления дефекта разработчиком проводим повторное тестирование. Добавляем данный дефект в регрессию. В зависимости от охватываемого функционала и Root Cause этих багов принимается решение о проведении санитарного/регрессионного тестирования после подтверждающего. - -

    Что такое утечка дефектов и релиз бага? (Bug Leackage & Bug Release)

    -Релиз бага — это когда программное обеспечение или приложение передается группе тестирования, зная, что дефект присутствует в выпуске. При этом приоритет и серьезность ошибки низки, поскольку ошибка может быть удалена до окончательной передачи обслуживания. - -Утечка бага — когда баг обнаруживается конечными пользователями или заказчиком, а не обнаруживается группой тестирования во время тестирования программного обеспечения. - -

    Что означает плотность дефектов при тестировании ПО?

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

    Что означает процент обнаружения дефектов при тестировании ПО?

    -Процент обнаружения дефектов (DDP) — это тип метрики тестирования. Он показывает эффективность процесса тестирования путем измерения соотношения дефектов, обнаруженных до выпуска и сообщенных после выпуска клиентами. Например, скажем, QA зарегистрировало 70 дефектов во время цикла тестирования, а клиент сообщил еще 20 после выпуска. DDP составит 72,1% после расчета 70 / (70 + 20) = 72,1%. - +Примечание 3: Рассмотренный выше жизненный цикл основан на том, что в команде есть кто-то, ответственный за назначение баг репортов. В случае, если такой роли на проекте нет, то баги назначаются разработчиками самостоятельно, и тогда во избежании путанницы, есть смысл ввести еще один промежуточный статус "В разработке" (In progress), показывающий, что данный баг репорт уже назначен и находится на стадии исправления.  +

    Что такое утечка дефектов и релиз бага? (Bug Leakage & Bug Release)

    +Релиз бага - это когда программное обеспечение или приложение передается группе тестирования, зная, что дефект присутствует в выпуске. При этом приоритет и серьезность ошибки низки, поскольку ошибка может быть удалена до окончательной передачи обслуживания.  +Утечка бага - когда баг обнаруживается конечными пользователями или заказчиком, а не обнаруживается группой тестирования во время тестирования программного обеспечения. +

    Что означает плотность дефектов при тестировании ПО? 

    +Плотность дефектов - это количество дефектов, подтвержденных в программном обеспечении / модуле в течение определенного периода эксплуатации или разработки, деленное на размер ПО / модуля. Это позволяет решить, готова ли часть ПО к выпуску. Плотность дефектов рассчитывается на тысячу строк кода, и обозначается KLOC. +Однако не существует фиксированного стандарта для плотности ошибок, исследования показывают, что один дефект на тысячу строк кода обычно считается признаком хорошего качества проекта.  +

    Что означает процент обнаружения дефектов при тестировании ПО? 

    +Процент обнаружения дефектов (DDP) - это тип метрики тестирования. Он показывает эффективность процесса тестирования путем измерения соотношения дефектов, обнаруженных до выпуска и сообщенных после выпуска клиентами. Например, скажем, QA зарегистрировало 70 дефектов во время цикла тестирования, а клиент сообщил еще 20 после выпуска. DDP составит 72,1% после расчета 70 / (70 + 20) = 72,1%. 

    Что означает эффективность устранения дефектов при тестировании ПО? (DRP)

    -Эффективность устранения дефектов (DRP) — это тип метрики тестирования. Это показатель эффективности команды разработчиков для устранения проблем перед выпуском. Он измеряется как отношение зафиксированных дефектов к общему количеству обнаруженных проблем. Например, допустим, что во время цикла тестирования было обнаружено 75 дефектов, в то время как 62 из них были устранены командой разработчиков во время измерения. DRE достигнет 82,6% после расчета 62/75 = 82,6%. - +Эффективность устранения дефектов (DRP) - это тип метрики тестирования. Это показатель эффективности команды разработчиков для устранения проблем перед выпуском. Он измеряется как отношение зафиксированных дефектов к общему количеству обнаруженных проблем. Например, допустим, что во время цикла тестирования было обнаружено 75 дефектов, в то время как 62 из них были устранены командой разработчиков во время измерения. DRE достигнет 82,6% после расчета 62/75 = 82,6%.

    Что означает эффективность Test case в тестировании ПО? (TCE)

    -Эффективность тестирования (TCE) — это тип метрики тестирования. Это четкий показатель эффективности выполнения Test case на этапе выполнения теста в выпуске. Это помогает в обеспечении и измерении качества Test case. Эффективность тестового набора (TCE) => (Количество обнаруженных дефектов / Количество выполненных Test case) * 100 - -

    Возраст дефекта в тестировании ПО?

    -Возраст дефекта — это время, прошедшее между днем обнаружения тестером и днем, когда разработчик исправил его. - -

    Что такое принцип Парето в тестировании ПО?

    +Эффективность тестирования (TCE) - это тип метрики тестирования. Это четкий показатель эффективности выполнения Test case на этапе выполнения теста в выпуске. Это помогает в обеспечении и измерении качества Test case. Эффективность тестового набора (TCE) => (Количество обнаруженных дефектов / Количество выполненных Test case) * 100  +

    Возраст дефекта в тестировании ПО? 

    +Возраст дефекта - это время, прошедшее между днем ​​обнаружения тестировщиком и днем, когда разработчик исправил его.  +

    Что такое принцип Парето в тестировании ПО? 

    В тестировании ПО принцип Парето говорит о том, что 80% всех ошибок приходится на 20% кода. - -

    Каковы различные способы применения принципа Парето в тестировании ПО?

    -1. Расставьте дефекты по их причинам, а не по последствиям. Не клубите ошибки, которые дают тот же результат. Группируйте проблемы в зависимости от того, в каком модуле они возникают. - -2. Сотрудничайте с командой разработчиков, чтобы найти новые способы классификации проблем. Например, используйте ту же статическую библиотеку для компонентов, которые учитывают большинство ошибок. - -3. Больше энергии вкладывайте в поиск проблемных областей в исходном коде, а не в случайный поиск. - -4. Переупорядочьте Test case и выберите наиболее важные для начала. - -5. Обратите внимание на реакцию конечного пользователя и оцените зоны риска. - +

    Каковы различные способы применения принципа Парето в тестировании ПО? 

    +1. Расставьте дефекты по их причинам, а не по последствиям. Не клубите ошибки, которые дают тот же результат. Группируйте проблемы в зависимости от того, в каком модуле они возникают.  +2. Сотрудничайте с командой разработчиков, чтобы найти новые способы классификации проблем. Например, используйте ту же статическую библиотеку для компонентов, которые учитывают большинство ошибок.  +3. Больше энергии вкладывайте в поиск проблемных областей в исходном коде, а не в случайный поиск.  +4. Переупорядочьте Test case и выберите наиболее важные для начала.  +5. Обратите внимание на реакцию конечного пользователя и оцените зоны риска. 

    В чем основное отличие отладки от тестирования? (Debugging Vs. Testing)

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

    Почему в программном обеспечении есть ошибки?

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

    Почему в программном обеспечении есть ошибки? 

    -

    Что вы будете делать, если во время тестирования появится ошибка?

    -Когда обнаруживается ошибка, запустите больше тестов, чтобы убедиться, что проблема имеет четкое описание. Запустите еще несколько тестов, чтобы убедиться, что одна и та же проблема не существует с разными входами. Как только мы полностью уверены в ошибке, мы можем добавить подробности и сообщить о ней. - -

    Как вы справляетесь с невоспроизводимой ошибкой?

    -Следующие типы ошибок относятся к категории невоспроизводимых. - +

    Что вы будете делать, если во время тестирования появится ошибка? 

    +Когда обнаруживается ошибка, запустите больше тестов, чтобы убедиться, что проблема имеет четкое описание. Запустите еще несколько тестов, чтобы убедиться, что одна и та же проблема не существует с разными входами. Как только мы полностью уверены в ошибке, мы можем добавить подробности и сообщить о ней.  +

    Как вы справляетесь с невоспроизводимой ошибкой? 

    +Следующие типы ошибок относятся к категории невоспроизводимых.  -Тестировщик может предпринять следующие действия для устранения невоспроизводимых ошибок. - +Тестировщик может предпринять следующие действия для устранения невоспроизводимых ошибок.  -

    Если продукт находится в производстве и один из его модулей обновляется, то необходимо ли провести повторную проверку?

    -Повторная проверка относится только к исправленным дефектам. После обновления модуля желательно выполнить регрессионное тестирование и запустить интеграционные тесты и прочие тесты для всех других модулей. После, QA следует провести Системное тестирование. Всё зависит от компании и бюджета, стратегии/политики тестирования или политики качества. - -

    Что такое анализ рисков?

    -Анализ рисков — это метод выявления вещей, которые могут пойти не так в проекте разработки ПО. Они могут негативно повлиять на объем, качество, своевременность и стоимость проекта. Тем не менее, все участники проекта участвуют в минимизации риска. Но именно лидер гарантирует, что вся команда понимает индивидуальную роль в управлении риском. - -Как выполнять анализ рисков во время тестирования ПО? Анализ рисков — это процесс выявления скрытых проблем, которые могут помешать успешной доставке приложения. Он также устанавливает приоритетность последовательности устранения выявленных рисков для целей тестирования. Ниже приведены некоторые из рисков, которые представляют интерес для обеспечения качества. - +

    Если продукт находится в производстве и один из его модулей обновляется, то необходимо ли провести повторную проверку? 

    +Повторная проверка относится только к исправленным дефектам. После обновления модуля желательно выполнить регрессионное тестирование и запустить интеграционные тесты и прочие тесты для всех других модулей. После, QA следует провести Системное тестирование. Все зависит от компании и бюджета, стратегии/политики тестирования или политики качества. +

    Что такое анализ рисков? 

    +Анализ рисков - это метод выявления вещей, которые могут пойти не так в проекте разработки ПО. Они могут негативно повлиять на объем, качество, своевременность и стоимость проекта. Тем не менее, все участники проекта участвуют в минимизации риска. Но именно лидер гарантирует, что вся команда понимает индивидуальную роль в управлении риском. +Как выполнять анализ рисков во время тестирования ПО? Анализ рисков - это процесс выявления скрытых проблем, которые могут помешать успешной доставке приложения. Он также устанавливает приоритетность последовательности устранения выявленных рисков для целей тестирования. Ниже приведены некоторые из рисков, которые представляют интерес для обеспечения качества.  -Мы выделяем их в три категории, которые заключаются в следующем. - +Мы выделяем их в три категории, которые заключаются в следующем.  -

    В чем разница между coupling и cohesion?

    -Сцепление/связность (Cohesion) - это степень, которая измеряет зависимость компонента ПО, который объединяет связанные функциональные возможности в одном блоке, тогда как соединение/связь (coupling) представляет его в другой группе. - -Cohesion имеет дело с функциональностью, которая связана с различными процессами в пределах одного модуля, в то время как coupling имеет дело с тем, насколько один модуль зависит от других модулей в продукте. - -Это хорошо для увеличения Cohesion между программным обеспечением, тогда как coupling не рекомендуется. -

    Что такое скрытый дефект? (Latent defect)

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

    Что такое маскировка ошибок, объясните примером?

    -Когда наличие одного дефекта скрывает наличие другого дефекта в системе, это называется маскированием неисправностей. Пример: если «отрицательное значение» вызывает исключение необработанного системного исключения, разработчик предотвратит ввод отрицательных значений. Это решит проблему и скроет дефект обработки необработанных исключений. - -

    Категории отладки? (Debugging)

    +

    Что такое маскировка ошибок, объясните примером? 

    +Когда наличие одного дефекта скрывает наличие другого дефекта в системе, это называется маскированием неисправностей. Пример: если «отрицательное значение» вызывает исключение необработанного системного исключения, разработчик предотвратит ввод отрицательных значений. Это решит проблему и скроет дефект обработки необработанных исключений.  +

    Категории/подходы к отладке? (Debugging approaches)

    +Отладка - этап, следующий после разработки и тестирования. Тестирование предназначено для поиска ошибок, а отладка - для поиска причины конкретной ошибки. +В целом мы можем разделить методы отладки на две основные категории: + +Подробнее: -

    Что такое Эффективность удаления дефектов? (DRE — Defect Removal Efficiency)

    -Этот показатель используется для измерения эффективности теста. Из этого показателя мы узнаем, сколько ошибок мы обнаружили в наборе Test case. Формула для расчета DRE имеет вид +

    Что такое Эффективность удаления дефектов? (DRE - Defect Removal Efficiency)

    +Этот показатель используется для измерения эффективности теста. Из этого показателя мы узнаем, сколько ошибок мы обнаружили в наборе Test case. Формула для расчета DRE имеет вид  DRE = Количество ошибок во время тестирования / (количество ошибок во время тестирования + количество ошибок, обнаруженных пользователем) -

    Что такое сортировка дефектов? (Bug triage)

    -Это формальный процесс, позволяющий определить, какие ошибки являются важными, путем определения их приоритетов на основе их серьезности, частоты, риска и других важных параметров. Тестеры назначают приоритет (высокий, средний, низкий) каждой ошибке на bug triage meeting и в зависимости от приоритета эти ошибки будут исправлены в соответствующем порядке. Делая это, мы экономим ресурсы организации. -     - +Это формальный процесс, позволяющий определить, какие ошибки являются важными, путем определения их приоритетов на основе их серьезности, частоты, риска и других важных параметров. Тестировщики назначают приоритет (высокий, средний, низкий) каждой ошибке на bug triage meeting и в зависимости от приоритета эти ошибки будут исправлены в соответствующем порядке. Делая это, мы экономим ресурсы организации. +

    ----- SDLC и STLC -----

    +

    Что вы знаете о жизненном цикле разработки ПО? (SDLC - Software Development Lifecycle) 

    +SDLC определяет все стандартные фазы, которые участвуют в процессе разработки ПО. Жизненный цикл SDLC - это процесс поэтапной разработки ПО, которому следуют в программных проектах. Каждый этап SDLC производит результаты, необходимые для следующего этапа жизненного цикла. Требования транслируются в дизайн. Код пишется в соответствии с дизайном. Тестирование должно проводиться на разработанном продукте в соответствии с требованиями. Развертывание должно быть сделано после завершения тестирования. -

    SDLC и STLC

    -

    Что вы знаете о жизненном цикле разработки ПО? (SDLC — Software Development Lifecycle)

    -SDLC определяет все стандартные фазы, которые участвуют в процессе разработки ПО. Жизненный цикл SDLC — это процесс поэтапной разработки ПО, которому следуют в программных проектах. Каждый этап SDLC производит результаты, необходимые для следующего этапа жизненного цикла. Требования транслируются в дизайн. Код пишется в соответствии с дизайном. Тестирование должно проводиться на разработанном продукте в соответствии с требованиями. Развертывание должно быть сделано после завершения тестирования. + -

    Что такое цикл/колесо Деминга? (Deming circle/cycle/wheel)

    -Цикл PDCA (Plan – Do – Check – Act) — это непрерывный (до получения конечного результата) итеративный четырехступенчатый метод управления, используемый в бизнесе для постоянного улучшения процессов. Это одна из ключевых концепций качества, и она также называется кругом/ циклом/ колесом Деминга. - +Цикл PDCA (Plan – Do – Check – Act) - это непрерывный (до получения конечного результата) итеративный четырехступенчатый метод управления, используемый в бизнесе для постоянного улучшения процессов. Это одна из ключевых концепций качества, и она также называется кругом/ циклом/ колесом Деминга.

    Модели разработки ПО?

    -Waterfall (каскадная модель, или «водопад»). В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х. - - -Преимущества «водопада»: Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью. Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до». - -Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию. - -Недостатки каскадной модели: Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию. - -Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит. Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать. - -«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО. При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт. +Waterfall (каскадная модель, или «водопад»). В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если все делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х. + +Преимущества «водопада»: Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью. Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до». +Не нужно нанимать тестировщиков с серьезной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию. +Недостатки каскадной модели: Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить ее будет стоить дорого. Тестировщики обнаружат ее, когда разработчик уже написал код, а технические писатели — документацию. +Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит. Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать. +«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО. При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт. V-образная модель (разработка через тестирование) - -Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х. - - +Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать ее на каждом этапе. История этой модели начинается в 1980-х. + Преимущества V-образной модели: Количество ошибок в архитектуре ПО сводится к минимуму. - -Недостатки V-образной модели: Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде». - -V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках. +Недостатки V-образной модели: Если при разработке архитектуры была допущена ошибка, то вернуться и исправить ее будет стоить дорого, как и в «водопаде».  +V-модель подходит для проектов, в которых важна надежность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.  Incremental Model (инкрементная модель) - -Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети. - +Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим ее на примере создания социальной сети. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет». - Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям. - Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании. - - + Преимущества инкрементной модели - -Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку. Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен. Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели. - -Недостатки инкрементной модели: Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание. - -Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда. - -Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок. +Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку. Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен. Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить ее будет стоить не так дорого, как в «водопаде» или V-образной модели. +Недостатки инкрементной модели: Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание.  +Разработчики будут оттягивать доработку основной функциональности и «пилить мелочевку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда.  +Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок. Iterative Model (итеративная модель) - Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание. - - + Рассмотрим на примере создания мессенджера, как эта модель работает. - Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих. - Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать. - Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка. - -Преимущества итеративной модели: Быстрый выпуск минимального продукта даёт возможность оперативно получать обратную связь от заказчика и пользователей. А значит, фокусироваться на наиболее важных функциях ПО и улучшать их в соответствии с требованиями рынка и пожеланиями клиента. Постоянное тестирование пользователями позволяет быстро обнаруживать и устранять ошибки. - -Недостатки итеративной модели: Использование на начальном этапе баз данных или серверов — первые сложно масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся переписывать большую часть приложения. Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка. - -Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате. +Преимущества итеративной модели: Быстрый выпуск минимального продукта дает возможность оперативно получать обратную связь от заказчика и пользователей. А значит, фокусироваться на наиболее важных функциях ПО и улучшать их в соответствии с требованиями рынка и пожеланиями клиента. Постоянное тестирование пользователями позволяет быстро обнаруживать и устранять ошибки. +Недостатки итеративной модели: Использование на начальном этапе баз данных или серверов — первые сложно масштабировать, а вторые не выдерживают нагрузку. Возможно, придется переписывать большую часть приложения. Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит конечная цель и когда закончится разработка. +Итеративная модель подходит для работы над большими проектами с неопределенными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.  Spiral Model (спиральная модель) - -Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение на основе рисков, продолжать ли развивать проект. - - -Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом». - -Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт. - +Используя эту модель, заказчик и команда разработчиков серьезно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение на основе рисков, продолжать ли развивать проект. + +Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».  +Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут ее реализовывать, разработали, протестировали и «выкатили» конечный продукт. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого. - Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом». - -Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски. - +Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.  Преимущества спиральной модели: Большое внимание уделяется проработке рисков. - -Недостатки спиральной модели: Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим. Разработка длится долго и стоит дорого. +Недостатки спиральной модели: Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим. Разработка длится долго и стоит дорого. На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке. -

    Что такое Agile?

    -В классической модели waterfall каждая стадия начиналась после предыдущей без возврата назад и только в самом конце начиналось тестирование. Можно ли обеспечить качество, когда уже всё готово? В книге «Как тестируют в Goooge» говорится, что QA не отвечает единолично за качество продукта, за это отвечает вся команда и в первую очередь разработчики. - +

    Что такое Agile? 

    +В классической модели waterfall каждая стадия начиналась после предыдущей без возврата назад и только в самом конце начиналось тестирование. Можно ли обеспечить качество, когда уже все готово? В книге «Как тестируют в Google» говорится, что QA не отвечает единолично за качество продукта, за это отвечает вся команда и в первую очередь разработчики. В результате post-development тестирования создавалась иллюзия качественного продукта, но это не обеспечение качества, а скорее QC. Еще одним следствием следования каскадной модели являлось то, что команда старалась реализовать сразу все требования и к этапу тестирования выяснялось, что требуется много доделок/переделок и в результате релиз откладывался. Помимо прочего, пока разработчики писали код, тестировщики бездействовали. Безусловно, что-то писалось по требованиям и интуитивно, но смысл понятен. Нередко из-за срыва срока релизов сокращался срок, отводимый на тестирование, что также неблагоприятно сказывалось на итоговом качестве продукта. - -Далее вмеcте с прогрессом пошла эволюция процессов SDLC и пришло понимание необходимости встраивания процессов обеспечения качества в жизненный цикл разработки продукта. Таким образом появлялись новые модели разработки и однажды группой энтузиастов был придуман Agile-манифест — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения (4 ценности, 12 принципов): - +Далее вместе с прогрессом пошла эволюция процессов SDLC и пришло понимание необходимости встраивания процессов обеспечения качества в жизненный цикл разработки продукта. Таким образом появлялись новые модели разработки и однажды группой энтузиастов был придуман Agile-манифест — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения (4 ценности, 12 принципов): Ценности: -
      -
    1. Люди и взаимодействие важнее процессов и инструментов.
      2. -
    2. Работающий продукт важнее исчерпывающей документации.
      3. -
    3. Сотрудничество с клиентом важнее согласования условий контракта.
      4. -
    4. Готовность к изменениям важнее следования первоначальному плану.
      5. +
    5. Люди и взаимодействие важнее процессов и инструментов. +
      6. +
    6. Работающий продукт важнее исчерпывающей документации. +
      7. +
    7. Сотрудничество с клиентом важнее согласования условий контракта. +
      8. +
    8. Готовность к изменениям важнее следования первоначальному плану. +
    Основные принципы: -
      -
    1. Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценного программного обеспечения.
      2. -
    2. Изменение требований приветствуется, даже на поздних стадиях разработки.
      3. -
    3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
      4. -
    4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
      5. -
    5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
      6. -
    6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
      7. -
    7. Работающий продукт — основной показатель прогресса.
      8. -
    8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
      9. -
    9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
      10. -
    10. Простота — искусство минимизации лишней работы — крайне необходима.
      11. -
    11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
      12. -
    12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
      13. +
    13. Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценного программного обеспечения. +
      14. +
    14. Изменение требований приветствуется, даже на поздних стадиях разработки. +
      15. +
    15. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. +
      16. +
    16. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. +
      17. +
    17. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. +
      18. +
    18. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. +
      19. +
    19. Работающий продукт — основной показатель прогресса. +
      20. +
    20. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. +
      21. +
    21. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. +
      22. +
    22. Простота — искусство минимизации лишней работы — крайне необходима. +
      23. +
    23. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. +
      24. +
    24. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. +
    - + Agile включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно: - -Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban. Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания. - +Не все перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чем разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы четко прописаны. Помимо Scrum, часто используют Kanban. Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведет работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания. В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс. - - + (Красный – waterfall, синий – разработка по гибкой методологии) - Впоследствии был разработан отдельный Манифест тестирования в Agile: + +Доп. материал: -

    Что такое Scrum?

    +

    Что такое Scrum? 

    Scrum – наиболее популярный Agile-подход, для многих людей согласно статистике эти термины являются синонимами. В целом о Scrum: - -Роли: +Роли: - - - - + - - - - + - - - - + - - - - + - - - - + - - - - +
    Product OwnerScrum MasterКоманда
    Product Owner +Scrum Master +Команда +
    определяет особенности продукта.управляет командой и заботится о продуктивности командыкоманда обычно состоит из 5-9 человек.
    определяет особенности продукта. +управляет командой и заботится о продуктивности команды +команда обычно состоит из 5-9 человек. +
    определяет дату релиза и соответствующие функцииподдерживает block список и устраняет барьеры в разработкев нее входят разработчики, дизайнер, а иногда и тестеры и т. д.
    определяет дату релиза и соответствующие функции +поддерживает block список и устраняет барьеры в разработке +в нее входят разработчики, дизайнер, а иногда и тестировщики и т. д.  +
    устанавливает приоритеты функций в соответствии с рыночной стоимостью и прибыльностью продукта.координирует все роли и функциикоманда организует и планирует свою работу самостоятельно
    устанавливает приоритеты функций в соответствии с рыночной стоимостью и прибыльностью продукта. +координирует все роли и функции +команда организует и планирует свою работу самостоятельно +
    несет ответственность за прибыльность продуктазащищает команду от внешних помехимеет право делать все в рамках проекта для достижения цели спринта
    несет ответственность за прибыльность продукта +защищает команду от внешних помех +имеет право делать все в рамках проекта для достижения цели спринта +
    может принять или отклонить результат заданияприглашает на ежедневные разборы, обзор спринта и встречи по планированиюактивно участвуют в ежедневных церемониях
    может принять или отклонить результат задания +приглашает на ежедневные разборы, обзор спринта и встречи по планированию +активно участвуют в ежедневных церемониях +
    -На практике в скрам-тестировании успешность спринта — это когда все задачи, которые были добавлены в Scrum, оказались в статусе Done. Хотя много зависит от определения, что такое Done в вашем проекте. Скрам по своей сути это просто таймбокс для работ и если не уложились в сроки – то это проблема планирования и на ретроспективе нужно разобраться почему это произошло и зафиксировать на будущее. +На практике в скрам-тестировании успешность спринта - это когда все задачи, которые были добавлены в Scrum, оказались в статусе Done. Хотя много зависит от определения, что такое Done в вашем проекте. Скрам по своей сути это просто таймбокс для работ и если не уложились в сроки – то это проблема планирования и на ретроспективе нужно разобраться почему это произошло и зафиксировать на будущее. + +Доп. материал: +

    Какие вообще особенности у тестирования в Scrum?

    -Классика типа Савина или Канера повествует скорее о традиционных моделях (именно поэтому там уделено столько внимания дизайну, документированию, видам тестирования и т.п., т.к. на всё это там есть время) но в гибких всё значительно отличается. -В гибкой методологии времени на разработку тест-кейсов низкого уровня и прочей документации обычно не бывает, поэтому подготавливаются чек-листы. Наборы проверок могут определяться как по не формализованным требованиям, так и на основе рисков (risk based). Ну и тестирование на основе экспертизы – самый простой подход к тестированию, но в то же время и самый рискованный, потому что все тестирование завязывается на экспертизу специалиста, выполняющего тестирование. В некоторых случаях мы всё же можем формализовать Стратегию тестирования (порядок тестирования и подход к выполнению работ по тестированию ПО) и Тест-план (в кратком содержании для спринта не менее 2-х недель, при меньших сроках спринта ведение не актуально). Требования к документации в аджайл: она должна служить потребностям команды, живая документация ценнее архивной. -
    - -
    -3+1 принципа тестирования в аджайл: предотвращение, автоматизация (авто QA - функциональное, приемочное. Devs - юнит, интеграция), гибкость, здравый смысл.
    -В agile user stories пишет Product Owner или Business Analyst. Кодеры по ним кодят, а тестеры по ним тестят. ПО или БА к каждой ЮС будут писать критерии приемки, а тестеры на основании их будут писать кейсы. При планировании спринта тестировщик должен выбрать пользовательскую историю из журнала невыполненных работ, которую следует протестировать. -Как тестировщик, он / она должен решить, сколько часов (оценка усилий) потребуется, чтобы завершить тестирование для каждой из выбранных пользовательских историй. -Как тестер, он / она должен знать, каковы цели спринта. -В качестве тестера, внести свой вклад в процесс расстановки приоритетов. Тестер отвечает за разработку сценариев автоматизации. Он планирует автоматизированное тестирование с помощью системы непрерывной интеграции (CI). Автоматизация получает важность из-за коротких сроков доставки.Выполнение нефункционального тестирования для утвержденных пользовательских историй. Тестер взаимодействует с клиентом и владельцем продукта, чтобы определить критерии приемки для приемочных испытаний. В конце спринта тестер также проводит приемочное тестирование (UAT) в некоторых случаях и подтверждает полноту тестирования для текущего спринта. -Узнать больше можно по ссылкам в теме "Ты – единственный тестировщик на проекте. Что делать?". +Классика типа Савина или Канера повествует скорее о традиционных моделях (именно поэтому там уделено столько внимания дизайну, документированию, видам тестирования и т.п., т.к. на все это там есть время) но в гибких все значительно отличается. В гибкой методологии времени на разработку тест-кейсов низкого уровня и прочей документации обычно не бывает, поэтому подготавливаются чек-листы. Наборы проверок могут определяться как по не формализованным требованиям, так и на основе рисков (risk based). Ну и тестирование на основе экспертизы – самый простой подход к тестированию, но в то же время и самый рискованный, потому что все тестирование завязывается на экспертизу специалиста, выполняющего тестирование. В некоторых случаях мы все же можем формализовать Стратегию тестирования (порядок тестирования и подход к выполнению работ по тестированию ПО) и Тест-план (в кратком содержании для спринта не менее 2-х недель, при меньших сроках спринта ведение не актуально). Требования к документации в аджайл: она должна служить потребностям команды, живая документация ценнее архивной. + -

    В чем отличие Kanban от Scrum?

    -В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»). Жизненный цикл задачи отображается на канбан-доске, физической или электронной. Такая визуализация делает рабочий процесс открытым и понятным для всех участников, что особенно важно в Agile, когда у команды нет одного формального руководителя. +3+1 принципа тестирования в аджайл: предотвращение, автоматизация (авто QA - функциональное, приемочное. Devs - юнит, интеграция), гибкость, здравый смысл. +В agile user stories пишет Product Owner или Business Analyst. Кодеры по ним кодят, а тестировщики по ним тестят. ПО или БА к каждой ЮС будут писать критерии приемки, а тестировщики на основании их будут писать кейсы. При планировании спринта тестировщик должен выбрать пользовательскую историю из журнала невыполненных работ, которую следует протестировать. Как тестировщик, он / она должен решить, сколько часов (оценка усилий) потребуется, чтобы завершить тестирование для каждой из выбранных пользовательских историй. Как тестировщик , он / она должен знать, каковы цели спринта. В качестве тестировщика, внести свой вклад в процесс расстановки приоритетов. Тестировщик отвечает за разработку сценариев автоматизации. Он планирует автоматизированное тестирование с помощью системы непрерывной интеграции (CI). Автоматизация получает важность из-за коротких сроков доставки.Выполнение нефункционального тестирования для утвержденных пользовательских историй. Тестировщик взаимодействует с клиентом и владельцем продукта, чтобы определить критерии приемки для приемочных испытаний. В конце спринта тестировщик также проводит приемочное тестирование (UAT) в некоторых случаях и подтверждает полноту тестирования для текущего спринта. Узнать больше можно по ссылкам в теме "Ты – единственный тестировщик на проекте. Что делать?". +Доп. материал:  + +

    В чем отличие Kanban от Scrum?

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

    Что знаете о User stories в гибких подходах к разработке?

    -Пользовательские истории (англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или несколько предложений на повседневном или деловом языке пользователя. Пользовательские истории – это один из самых быстрых способов документирования требований клиента (цель документирования состоит в том, чтобы оперативно и без затрат реагировать на возникающие изменения). - +Пользовательские истории (англ. User Story) - способ описания требований к разрабатываемой системе, сформулированных как одно или несколько предложений на повседневном или деловом языке пользователя. Пользовательские истории – это один из самых быстрых способов документирования требований клиента (цель документирования состоит в том, чтобы оперативно и без затрат реагировать на возникающие изменения). Главное действующее лицо User story – это некий персонаж, который будет совершать какие-либо действия с нашим тестируемым продуктом с учетом его потребностей. Персонаж сопровождается описанием проблем, которые он может (и хочет) решить с помощью нашего продукта. Потребность представляет собой тезис в 1-2 предложения. Для одного пользователя может быть разработано несколько (например, 4-6) User Story. - -Для того, чтобы персонажи стали эффективными инструментами проектирования сайта, потребуется не только провести исследование, но и выявить закономерности в поведении пользователей. Как правило, принято создавать и детально прорабатывать одного основного (как показано на mind-map ниже) и несколько второстепенных персонажей. - - +Для того, чтобы персонажи стали эффективными инструментами проектирования сайта, потребуется не только провести исследование, но и выявить закономерности в поведении пользователей. Как правило, принято создавать и детально прорабатывать одного основного (как показано на mind-map ниже) и несколько второстепенных персонажей. +

    Что значит жизненный цикл тестирования ПО? (STLC – Software Testing Lifecycle)

    STLC это модель тестирования, которая предлагает выполнять тестирование систематическим и запланированным способом. Модель STLC устанавливает следующие этапы: - +
      -
    1. Инициация – событие, которое извещает команду тестирования о необходимости сессии тестирования +
    2. Инициация – событие, которое извещает команду тестирования о необходимости сессии тестирования
      3. -
    3. Выявление требований (RA) – пожалуй, один из главных шагов в процессе тестирования. Необходимо собрать всю доступную информацию о предмете тестирования, вариантах использования и т. п. Первый источник – техническая документация и юзер-стори – это прямые требования. Если некоторые спецификации не являются точными или имеют разногласия, то заинтересованные стороны, такие как бизнес-аналитик (BA), архитекторы, клиенты, дают ясность. Качество же косвенных требований во многом зависят от добросовестности, ответственности, квалификации тестировщика и всей команды проекта.
      4. -
    4. Планирование тестирования (TP) — Как правило, на этом этапе старший QA определяет усилия и смету расходов по проекту, а также готовит и завершает план тестирования. На этом этапе также определяется стратегия тестирования. Команда тестирования выполняет следующие задачи на этапе TP:
      5. - +
    5. Выявление требований (RA) – пожалуй, один из главных шагов в процессе тестирования. Необходимо собрать всю доступную информацию о предмете тестирования, вариантах использования и т. п. Первый источник – техническая документация и юзер-стори – это прямые требования. Если некоторые спецификации не являются точными или имеют разногласия, то заинтересованные стороны, такие как бизнес-аналитик (BA), архитекторы, клиенты, дают ясность. Качество же косвенных требований во многом зависят от добросовестности, ответственности, квалификации тестировщика и всей команды проекта. +
      6. +
    6. Планирование тестирования (TP) - Как правило, на этом этапе старший QA определяет усилия и смету расходов по проекту, а также готовит и завершает план тестирования. На этом этапе также определяется стратегия тестирования. Команда тестирования выполняет следующие задачи на этапе TP: +
        7. -
      1. Подготовка плана тестирования / стратегии для различных типов тестирования
        2. -
      2. Выбор тестовых инструментов
        3. -
      3. Оценка усилий
        4. -
      4. Планирование ресурсов и определение ролей и обязанностей.
        5. -
      5. Требования к обучению
        6. -
      6. Расписание, критерии начала и окончания
        7. -
      7. Оценка рисков
        8. +
      8. Подготовка плана тестирования / стратегии для различных типов тестирования  +
        9. +
      9. Выбор тестовых инструментов +
        10. +
      10. Оценка усилий  +
        11. +
      11. Планирование ресурсов и определение ролей и обязанностей.  +
        12. +
      12. Требования к обучению +
        13. +
      13. Расписание, критерии начала и окончания +
        14. +
      14. Оценка рисков +
    - -
      -
    1. Генерация Test case – выявление всех возможных случаев использования продукта, его характеристик и особенностей в процессе эксплуатации. Это значит: всех случаев, которые тестировщик может «придумать» на основе прямых и косвенных требований, известных ему. Этот этап требует высокой квалификации специалиста по тестированию. При выполнении этой задачи также необходимо подготовить входные данные, необходимые для тестирования. Как только план тестирования будет готов, он должен быть рассмотрен Senior или Lead. Один из документов, который должна подготовить группа, — это матрица отслеживания требований (RTM). Это общеотраслевой стандарт, обеспечивающий правильное сопоставление тест-кейсов с требованиями.
      2. -
    2. Отбор Test case – отбор наиболее показательных, значимых и воспроизводимых Test case. От этого этапа зависит, насколько тестирование будет полезным, эффективным и анализируемым. Количество косвенных требований стремится к бесконечности, и проверять их все подряд – полный абсурд, но подобные кейсы должны быть сгенерированы хотя бы в голове проверяющего.
      3. -
    3. Настройка тестовой среды в STLC — Среда тестирования определяет условия программного и аппаратного обеспечения, при которых тестируется рабочий продукт. Настройка тестовой среды является одним из важнейших аспектов процесса тестирования и может выполняться параллельно с этапом разработки тестового набора. Команда тестирования может быть не вовлечена в это действие, если клиент / команда разработчиков предоставляет среду тестирования, и в этом случае команда тестирования должна выполнить проверку готовности (тестирование дыма) данной среды. Какие задачи выполняются на этапе настройки среды тестирования STLC?
      4. - +
    4. Генерация Test case – выявление всех возможных случаев использования продукта, его характеристик и особенностей в процессе эксплуатации. Это значит: всех случаев, которые тестировщик может «придумать» на основе прямых и косвенных требований, известных ему. Этот этап требует высокой квалификации специалиста по тестированию. При выполнении этой задачи также необходимо подготовить входные данные, необходимые для тестирования. Как только план тестирования будет готов, он должен быть рассмотрен Senior или Lead. Один из документов, который должна подготовить группа, - это матрица отслеживания требований (RTM). Это общеотраслевой стандарт, обеспечивающий правильное сопоставление тест-кейсов с требованиями.  +
      5. +
    5. Отбор Test case – отбор наиболее показательных, значимых и воспроизводимых Test case. От этого этапа зависит, насколько тестирование будет полезным, эффективным и анализируемым. Количество косвенных требований стремится к бесконечности, и проверять их все подряд – полный абсурд, но подобные кейсы должны быть сгенерированы хотя бы в голове проверяющего.  +
      6. +
    6. Настройка тестовой среды в STLC - Среда тестирования определяет условия программного и аппаратного обеспечения, при которых тестируется рабочий продукт. Настройка тестовой среды является одним из важнейших аспектов процесса тестирования и может выполняться параллельно с этапом разработки тестового набора. Команда тестирования может быть не вовлечена в это действие, если клиент / команда разработчиков предоставляет среду тестирования, и в этом случае команда тестирования должна выполнить проверку готовности (тестирование дыма) данной среды. Какие задачи выполняются на этапе настройки среды тестирования STLC?  +
        7. -
      1. Ознакомление с необходимой архитектурой, настройка среды и подготовка требований к оборудованию и ПО для среды тестирования.
        2. -
      2. Настройка тестовой среды и тестовых данных
        3. -
      3. Выполнение Smoke тестирования
        4. +
      4. Ознакомление с необходимой архитектурой, настройка среды и подготовка требований к оборудованию и ПО для среды тестирования.  +
        5. +
      5. Настройка тестовой среды и тестовых данных  +
        6. +
      6. Выполнение Smoke тестирования +
      -
    7. Проведение проверок – тут все понятно. На этом этапе команда запускает тестовые наборы в соответствии с планом тестирования, определенным в предыдущих шагах, либо adhoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок.
      8. -
    8. Фиксация результатов – создание внутренней и внешней тестовой документации в формализованном виде или в виде записей и т. п. На данном этапе отчет о тестировании даже если и создается, то не считается законченным.
      9. -
    9. Анализ результатов – вынесение решения о соответствии проверенного продукта требованиям. Формализация данного решения и его обоснование в виде отчета о тестировании. Сюда также входят процедуры по оценке покрытия требований проверками, тайм-шитинг и пр. Таким образом, проводится анализ не только результатов, но и самой сессии тестирования.
      10. -
    10. Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п.
      11. +
    11. Проведение проверок – тут все понятно. На этом этапе команда запускает тестовые наборы в соответствии с планом тестирования, определенным в предыдущих шагах, либо adhoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок.  +
      12. +
    12. Фиксация результатов – создание внутренней и внешней тестовой документации в формализованном виде или в виде записей и т. п. На данном этапе отчет о тестировании даже если и создается, то не считается законченным. +
      13. +
    13. Анализ результатов – вынесение решения о соответствии проверенного продукта требованиям. Формализация данного решения и его обоснование в виде отчета о тестировании. Сюда также входят процедуры по оценке покрытия требований проверками, тайм-шитинг и пр. Таким образом, проводится анализ не только результатов, но и самой сессии тестирования. +
      14. +
    14. Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п.  +
    -

    Что вы знаете о техниках оценки теста? (Test Estimation)

    -Оценка теста — это управленческая деятельность, которая приблизительно показывает, сколько времени потребуется для выполнения Задачи. Оценка усилий для теста является одной из основных и важных задач в управлении тестированием (Test Management). Что оценивается? +

    Что вы знаете о техниках оценки теста? (Test Estimation)

    +Оценка теста - это управленческая деятельность, которая приблизительно показывает, сколько времени потребуется для выполнения Задачи. Оценка усилий для теста является одной из основных и важных задач в управлении тестированием (Test Management). Что оценивается?

    В чем разница между SDLC и STLC?

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

    Что такое быстрая разработка приложений? (RAD — Rapid Application Development)

    + +SDLC определяет все стандартные фазы, которые участвуют в процессе разработки ПО, тогда как процесс STLC определяет различные действия для улучшения качества продукта. SDLC - это жизненный цикл разработки, тогда как STLC - это жизненный цикл тестирования. В SDLC команда разработчиков создает планы проектирования высокого и низкого уровня, в то время как в STLC аналитик тестов создает Систему, План тестирования интеграции. В SDLC разрабатывается реальный код, и фактическая работа выполняется в соответствии с проектной документацией, тогда как в STLC команда тестирования готовит среду тестирования и выполняет тестовые примеры. Жизненный цикл SDLC помогает команде завершить успешную разработку ПО, в то время как фазы STLC охватывают только тестирование ПО.  +

    Что такое быстрая разработка приложений? (RAD - Rapid Application Development) 

    Быстрой разработкой приложений формально является параллельное развитие функций и последующей интеграции. Компоненты/функции развиваются параллельно, как если бы они были мини-проекты, события, time-boxed, доставлены и собраны в работающий прототип. Это может очень быстро дать клиенту что-то увидеть и использовать, и обеспечить обратную связь по поводу доставки и их требований. Быстрое изменение и развитие продукта возможно с помощью этой методики, однако спецификация продукта должна быть разработана для продукта в какой-то момент, и проект должен быть размещен под более формальный контроль перед запуском в производство. - -

    Что такое разработка через тестирование (TDD — Test Driven Development)?

    +

    Что такое разработка через тестирование (TDD - Test Driven Development)?

    В традиционном подходе сначала пишут код, который затем покрывают тестами; в этом подходе сначала разрабатываются тесты, которые в будущем должны быть пройдены кодом. Разработчик будет писать код, пока тесты не начнут проходить. Разработка через тестирование начинается с проектирования и разработки тестов для каждой небольшой функциональности приложения. Также очевидно, в TDD вы получаете 100% покрытия кода тестами. - Есть два уровня TDD: - - -

    TDD в Agile Model Driven Development (AMDD)

    + + +

    Что такое Value Driven Testing (тестирование на основе ценности)?

    +Чтобы понять, как обстоят дела с тестированием на проекте, нужно проанализировать его эффективность с точки зрения качества создаваемого продукта и процессов. Тут можно рассчитывать плотность дефектов, разрывы, утечки, эффективность тест-кейсов, RC, FDP, DDP, PTC, MTTD, TDE и десятки других метрик тестирования. Но, чтобы определить рентабельность такого тестирования, необходимо считать деньги. Деньги и их возрастающий поток — основная цель заказчика в большинстве случаев разработки ПО. +Чтобы правильно принимать управленческие решения, тест-менеджеру необходимо в полной мере ориентироваться в себестоимости активностей по тестированию, видеть зоны развития и пути оптимизации процессов. Заказчику также важно понимать, за что он платит и почему, где он теряет, а где зарабатывает. Один в поле не воин, и задача так называемого архитектора постараться заставить пчел реально осознать, сколько денег они приносят заказчику, сколько помогли сэкономить. Сэкономленные деньги не обязательно, но могут формировать фонд для потенциального увеличения оплаты труда тех же пчел. +Цена и ценность +Любое качество имеет свою цену: Cost of Quality = Cost of Poor Quality + Cost of Good Quality: + +Общая стоимость тестирования достаточно велика, но стоит лишь оценить стоимость плохого тестирования, как она уже кажется вполне приемлемой. Уоррен Баффет как-то сказал, что цена — это то, что вы платите, а ценность — то, что получаете. И не всегда они совпадают. Качество еще не означает ценность. Попробуйте сегодня продать очень качественную печатную машинку либо убедить заказчика, что для него ценнее будет зарелизить фичу не послезавтра, а через год, ведь за это время вы еще лучше все протестите и качество будет выше. Не получится. Дорога ложка к обеду, и time to market никто не отменял. +Задача в том, чтобы достичь оптимального соотношение цена/качество для заказчика. Почему оптимального? Потому что по мере увеличения затрат на поиск дефектов и их устранения стоимость поломки будет снижаться до тех пор, пока не будет достигнута оптимальная точка, после которой дальнейшее увеличение активностей по тестированию станет экономически нецелесообразным. + +Источник: Что нужно знать о Value Driven Testing. Анализируем ценность и экономическую целесообразность тестирования +

    TDD в Agile Model Driven Development (AMDD)

    TDD очень хорош в детальной спецификации и валидации. Он не может продумать более важные вопросы, такие как общий дизайн, использование системы или пользовательский интерфейс. AMDD решает проблемы гибкого масштабирования, которых нет в TDD. Таким образом, AMDD используется для больших проблем. - Жизненный цикл AMDD: - -TDD сокращает цикл обратной связи программирования, AMDD сокращает цикл обратной связи моделирования. TDD — детальная спецификация, AMDD работает для больших проблем. TDD способствует разработке качественного кода, AMDD способствует качественному общению с заинтересованными сторонами и разработчиками. TDD общается с программистами, AMDD общается с бизнес-аналитиками, заинтересованными сторонами и специалистами по данным. TDD не визуально ориентированный, AMDD визуально ориентированный. TDD имеет ограниченную область применения, AMDD имеет широкий охват. Это предполагает работу по достижению общего понимания. Оба поддерживают эволюционное развитие. - -

    Тестирование на основе моделей (MDD — Model-driven Development)

    -Это метод тестирования черного ящика, при котором поведение тестируемого программного обеспечения во время выполнения проверяется на основе прогнозов, сделанных моделями. Модель — это описание поведения системы. Поведение может быть описано в виде наглядной схемы, Data Flow, Control Flow, Dependency Graphs, Decision Tables, State transition machines или mind map. Простой аналогией модели в тестировании является электрическая схема при разработке электроприбора. Этот подход к тестированию требуется, когда высока цена ошибки в большом продукте и нужно как можно раньше попытаться ее предотвратить. - -

    Тестирование на основе данных (DDT — Data Driven testing)

    -DATA DRIVEN testing — это инфраструктура автоматизации тестирования, которая хранит тестовые данные в виде таблицы. Это позволяет инженерам по автоматизации иметь единый сценарий тестирования, который может выполнять тесты для всех тестовых данных в таблице. В этой структуре входные значения считываются из файлов данных и сохраняются в переменную в тестовых сценариях. Ddt (тестирование на основе данных) позволяет объединять как положительные, так и отрицательные Test case в один тест. В среде автоматизации тестирования на основе данных входные данные могут храниться в одном или нескольких источниках данных, таких как xls, XML, csv и базы данных. - -Часто у нас есть несколько наборов данных, на которых мы должны запускать одни и те же тесты. Создание отдельного теста для каждого набора данных — длительный и трудоемкий процесс. Data Driven testing Framework решает эту проблему, отделяя данные от функциональных тестов. Один и тот же сценарий тестирования может выполняться для различных комбинаций входных данных теста и генерировать результаты теста. Например, мы хотим протестировать вход в систему с несколькими полями ввода с 1000 различными наборами данных. Чтобы проверить это, вы можете использовать следующие разные подходы: Подход 1) Создайте 1000 сценариев по одному для каждого набора данных и запускайте каждый тест отдельно по одному. Подход 2) Вручную измените значение в тестовом скрипте и запустите его несколько раз. Подход 3) Импортируйте данные из листа Excel. Извлеките данные теста из строк Excel по очереди и выполните скрипт. В приведенных трех сценариях первые два являются слишком трудоемкими. Таким образом, идеально следовать третьему подходу и это не что иное, как Data-Driven Framework. - -

    Тестирование на основе риска (RBT — Risk Based Testing)

    -ТЕСТИРОВАНИЕ НА ОСНОВЕ РИСКА (RBT) — это тип тестирования, основанный на вероятности риска. Он включает в себя оценку риска на основе сложности, критичности бизнеса, частоты использования, видимых областей, областей, подверженных дефектам, и т. д. Он включает определение приоритетов тестирования модулей и функций тестируемого приложения на основе влияния и вероятности отказов. - -Риск — это возникновение неопределенного события, которое положительно или отрицательно влияет на измеримые критерии успеха проекта. Это могут быть события, которые произошли в прошлом или текущие события, или что-то, что может произойти в будущем. Эти неопределенные события могут повлиять на стоимость, бизнес, технические и качественные цели проекта. Позитивные риски упоминаются как возможности и помощь в устойчивости бизнеса. Например, инвестирование в новый проект, изменение бизнес-процессов, разработка новых продуктов. Отрицательные риски называются угрозами, и для успеха проекта должны быть реализованы рекомендации по их минимизации или устранению. - +TDD сокращает цикл обратной связи программирования, AMDD сокращает цикл обратной связи моделирования. TDD - детальная спецификация, AMDD работает для больших проблем. TDD способствует разработке качественного кода, AMDD способствует качественному общению с заинтересованными сторонами и разработчиками. TDD общается с программистами, AMDD общается с бизнес-аналитиками, заинтересованными сторонами и специалистами по данным. TDD не визуально ориентированный, AMDD визуально ориентированный. TDD имеет ограниченную область применения, AMDD имеет широкий охват. Это предполагает работу по достижению общего понимания. Оба поддерживают эволюционное развитие. +

    Тестирование на основе моделей (MDD - Model-driven Development)

    +Это метод тестирования черного ящика, при котором поведение тестируемого программного обеспечения во время выполнения проверяется на основе прогнозов, сделанных моделями. Модель - это описание поведения системы. Поведение может быть описано в виде наглядной схемы, Data Flow, Control Flow, Dependency Graphs, Decision Tables, State transition machines или mind map. Простой аналогией модели в тестировании является электрическая схема при разработке электроприбора. Этот подход к тестированию требуется, когда высока цена ошибки в большом продукте и нужно как можно раньше попытаться ее предотвратить. + +Доп. материал: +Тестирование на основе моделей +

    Тестирование на основе данных (DDT - Data Driven testing)

    +DATA DRIVEN testing - это инфраструктура автоматизации тестирования, которая хранит тестовые данные в виде таблицы. Это позволяет инженерам по автоматизации иметь единый сценарий тестирования, который может выполнять тесты для всех тестовых данных в таблице. В этой структуре входные значения считываются из файлов данных и сохраняются в переменную в тестовых сценариях. Ddt (тестирование на основе данных) позволяет объединять как положительные, так и отрицательные Test case в один тест. В среде автоматизации тестирования на основе данных входные данные могут храниться в одном или нескольких источниках данных, таких как xls, XML, csv и базы данных. +Часто у нас есть несколько наборов данных, на которых мы должны запускать одни и те же тесты. Создание отдельного теста для каждого набора данных - длительный и трудоемкий процесс. Data Driven testing Framework решает эту проблему, отделяя данные от функциональных тестов. Один и тот же сценарий тестирования может выполняться для различных комбинаций входных данных теста и генерировать результаты теста. Например, мы хотим протестировать вход в систему с несколькими полями ввода с 1000 различными наборами данных. Чтобы проверить это, вы можете использовать следующие разные подходы: Подход 1) Создайте 1000 сценариев по одному для каждого набора данных и запускайте каждый тест отдельно по одному. Подход 2) Вручную измените значение в тестовом скрипте и запустите его несколько раз. Подход 3) Импортируйте данные из листа Excel. Извлеките данные теста из строк Excel по очереди и выполните скрипт. В приведенных трех сценариях первые два являются слишком трудоемкими. Таким образом, идеально следовать третьему подходу и это не что иное, как Data-Driven Framework. +

    Тестирование на основе риска (RBT - Risk Based Testing)

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

    Что вы знаете о потоковом тестировании? (BFT — BusinessFlowTesting)

    +
  • Важные функциональные возможности в проекте.  +
    • +
  • Видимая пользователю функциональность в проекте  +
    • +
  • Функциональность, оказывающая наибольшее влияние на безопасность  +
    • +
  • Функциональные возможности, которые оказывают наибольшее финансовое влияние на пользователей  +
    • +
  • Сложные области исходного кода и кодов, подверженных ошибкам  +
    • +
  • Функции, которые могут быть проверены в начале цикла разработки.  +
    • +
  • Особенности или функциональные возможности, которые были добавлены в дизайн продукта в последнюю минуту.  +
    • +
  • Критические факторы подобных / связанных предыдущих проектов, которые вызвали проблемы.  +
    • +
  • Основные факторы или проблемы аналогичных / связанных проектов, которые оказали огромное влияние на эксплуатационные расходы.  +
    • +
  • Плохие требования, которые приводят к плохим проектам и тестам, которые могут повлиять на цели и результаты проекта.  +
    • +
  • В худшем случае продукт может быть настолько дефектным, что его невозможно переработать, и его необходимо полностью утилизировать, что может нанести серьезный ущерб репутации компании. Определите, какие проблемы имеют решающее значение для целей продукта.  +
    • +
  • Ситуации или проблемы, которые могут привести к постоянным жалобам на обслуживание клиентов. Сквозные тесты могут легко сфокусироваться на нескольких функциональных возможностях системы. Оптимальный набор тестов, которые могут максимизировать покрытие риска  +
    • +
  • Какие тесты будут иметь лучшее соотношение риска и требуемого времени? +
    • + + +

    Что вы знаете о потоковом тестировании? (BFT — Business Flow Testing)

    BFT – это подход к тестированию, где вы смотрите на продукт не с точки зрения конкретных кейсов, а с точки зрения поведения системы в каждой ее точке. Подход является объединением таких концепций, как Data Driven testing и Behaviour Driven testing, примененным к бизнес-моделям, хорошо описываемым графами движения данных. Вы не тестируете отдельные тест-кейсы, а проверяете работоспособность системы, тест-кейсы получаются сами по себе. Образно говоря, у вас есть: - У вас нет тест-кейсов. Тест-кейсы генерируются на основании входных данных сами. Больше не надо спорить, как назвать тест-кейсы правильно. Название тест-кейса – это набор определяющих его входных данных и путь, по которым они пройдут. Название получается длинное, но полностью описывающее данный тест. И к тому же вы не тратите на него ни секунды — оно создается само. -     - +

    В чем разница между coupling и cohesion? 

    +Это термины из принципов разработки ПО: + + +Доп. материал: + -

    Тестирование в разных сферах/областях (testing different domains)

    -

    Что такое веб-тестирование и как его производить?

    -ВЕБ-ТЕСТИРОВАНИЕ, или тестирование веб-сайта, проверяет ваше веб-приложение или веб-сайт на наличие потенциальных ошибок, прежде чем оно будет опубликовано и доступно для широкой публики. +

    ----- Тестирование в разных сферах/областях (testing different domains) -----

    +

    Что такое веб-тестирование и как его производить? 

    +ВЕБ-ТЕСТИРОВАНИЕ, или тестирование веб-сайта, проверяет ваше веб-приложение или веб-сайт на наличие потенциальных ошибок, прежде чем оно будет опубликовано и доступно для широкой публики.  -1. Функциональное тестирование: используется для проверки того, соответствует ли ваш продукт спецификациям, а также функциональным требованиям, которые вы наметили для него в документации по разработке. Включает в себя: +1. Функциональное тестирование: используется для проверки того, соответствует ли ваш продукт спецификациям, а также функциональным требованиям, которые вы наметили для него в документации по разработке. Включает в себя:  - - -2. Юзабилити-тестирование стало важной частью любого веб-проекта. Его могут провести тестировщики или небольшая фокус-группа, похожая на целевую аудиторию веб-приложения. +2. Юзабилити-тестирование стало важной частью любого веб-проекта. Его могут провести тестировщики или небольшая фокус-группа, похожая на целевую аудиторию веб-приложения.  - - -3. Тестирование интерфейсов: Здесь тестируются три области: приложение, веб-сервер и сервер базы данных. +3. Тестирование интерфейсов: Здесь тестируются три области: приложение, веб-сервер и сервер базы данных.  - - -4. Тестирование базы данных: База данных является одним из важнейших компонентов вашего веб-приложения, и необходимо тщательно провести тестирование. Тестирование будет включать в себя: +4. Тестирование базы данных: База данных является одним из важнейших компонентов вашего веб-приложения, и необходимо тщательно провести тестирование. Тестирование будет включать в себя:  - + - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - +
    СценарийКейсы
    Сценарий +Кейсы +
    Деятельность кассира -
      -
    • Проверьте правильность ввода товаров, приобретенных клиентом
      • -
    • Тестовые скидки применяются правильно
      • -
    • Убедитесь, что платежные карты магазина (value cards) могут быть использованы
      • -
    • Управление мелочью работает как положено
      • -
    • Проверьте соответствие итогов и закрытия
      • -
    • Убедитесь, что денежный ящик кассы работает правильно
      • -
    • Проверьте, что система POS совместима с периферийными устройствами, такими как считыватель RFID, сканер штрих-кода и т. д.
      • -
    -
    Деятельность кассира +
      +
    • Проверьте правильность ввода товаров, приобретенных клиентом  +
      • +
    • Тестовые скидки применяются правильно  +
      • +
    • Убедитесь, что платежные карты магазина (value cards) могут быть использованы  +
      • +
    • Управление мелочью работает как положено  +
      • +
    • Проверьте соответствие итогов и закрытия  +
      • +
    • Убедитесь, что денежный ящик кассы работает правильно +
      • +
    • Проверьте, что система POS совместима с периферийными устройствами, такими как считыватель RFID, сканер штрих-кода и т. д.  +
      • +
    +
    Обработка платежного шлюза -
      -
    • Проверка правильности CVV кредитных карт
      • -
    • Тест на использование карт с обеих сторон
      • -
    • Убедитесь, что данные карты правильно зашифрованы и расшифрованы
      • +
    		Обработка платежного шлюза +
      +
    • Проверка правильности CVV кредитных карт +
      • +
    • Тест на использование карт с обеих сторон +
      • +
    • Убедитесь, что данные карты правильно зашифрованы и расшифрованы +
    -
    Продажи -
      -
    • Проверьте для обычного процесса продажи
      • -
    • Продажи могут быть обработаны дебетовой / кредитной картой
      • -
    • Проверить покупку по карте лояльности
      • -
    • Проверка правильности отображаемой цены для покупаемых товаров
      • -
    • Тест для «0» или нулевой транзакции
      • -
    • Привязка UPC или штрих-кодов с поставщиками
      • -
    • Проверка платежных данных или данных о доставке в диспетчере платежей
      • -
    • Тест для reference транзакции
      • -
    • Проверьте формат печати сгенерированной квитанции
      • -
    • Убедитесь, что для утвержденных, удержанных или отклоненных транзакций создан правильный код
      • -
    -
    Продажи +
      +
    • Проверьте для обычного процесса продажи  +
      • +
    • Продажи могут быть обработаны дебетовой / кредитной картой  +
      • +
    • Проверить покупку по карте лояльности +
      • +
    • Проверка правильности отображаемой цены для покупаемых товаров  +
      • +
    • Тест для "0" или нулевой транзакции  +
      • +
    • Привязка UPC или штрих-кодов с поставщиками  +
      • +
    • Проверка платежных данных или данных о доставке в диспетчере платежей  +
      • +
    • Тест для reference транзакции  +
      • +
    • Проверьте формат печати сгенерированной квитанции  +
      • +
    • Убедитесь, что для утвержденных, удержанных или отклоненных транзакций создан правильный код +
      • +
    +
    Сценарии возврата и обмена -
      -
    • Убедитесь, что внутренняя опись хорошо интегрирована с другими торговыми точками или цепочкой поставок
      • -
    • Чек на обмен или возврат товара наличными
      • -
    • Проверьте, работает ли система при обмене или возврате товара с помощью кредитной карты
      • -
    • Проверка системы обработки продажи с чеком или без чека
      • -
    • Убедитесь, что система должна позволять вводить штрих-код вручную, если сканер не работает
      • -
    • Убедитесь, что система отображает как текущую сумму, так и сумму скидки при обмене товара, если применимо
      • -
    -
    Сценарии возврата и обмена +
      +
    • Убедитесь, что внутренняя опись хорошо интегрирована с другими торговыми точками или цепочкой поставок  +
      • +
    • Чек на обмен или возврат товара наличными  +
      • +
    • Проверьте, работает ли система при обмене или возврате товара с помощью кредитной карты  +
      • +
    • Проверка системы обработки продажи с чеком или без чека  +
      • +
    • Убедитесь, что система должна позволять вводить штрих-код вручную, если сканер не работает  +
      • +
    • Убедитесь, что система отображает как текущую сумму, так и сумму скидки при обмене товара, если применимо +
      • +
    +
    Производительность -
      -
    • Проверьте скорость или время, необходимое для получения ответа или отправки запроса
      • -
    • Проверьте, применяются ли правила транзакций (скидки / налоги и т. д.)
      • -
    • Убедитесь, что для утвержденных, удержанных или отклоненных транзакций создан правильный код
      • +
    		Производительность +
      +
    • Проверьте скорость или время, необходимое для получения ответа или отправки запроса  +
      • +
    • Проверьте, применяются ли правила транзакций (скидки / налоги и т. д.)  +
      • +
    • Убедитесь, что для утвержденных, удержанных или отклоненных транзакций создан правильный код +
    -
    Негативные сценарии -
      -
    • Тестовая система с просроченными данными карты
      • -
    • Тест с неверным PIN-кодом для кредитной карты
      • -
    • Проверьте инвентарь, введя неправильный код товара
      • -
    • Проверьте, как система реагирует при вводе неверного номера счета
      • -
    • Тест на отрицательную транзакцию
      • -
    • Проверьте ответ системы при вводе недопустимой даты для рекламных предложений онлайн-товаров
      • -
    -
    Негативные сценарии +
      +
    • Тестовая система с просроченными данными карты  +
      • +
    • Тест с неверным PIN-кодом для кредитной карты  +
      • +
    • Проверьте инвентарь, введя неправильный код товара  +
      • +
    • Проверьте, как система реагирует при вводе неверного номера счета  +
      • +
    • Тест на отрицательную транзакцию  +
      • +
    • Проверьте ответ системы при вводе недопустимой даты для рекламных предложений онлайн-товаров +
      • +
    +
    Управление акциями и скидками -
      -
    • Проверка: система для различных скидок, таких как ветеранская скидка, сезонная скидка, скидка на покупку или перелет и т. д.
      • -
    • Проверка: система для различных рекламных предложений по отдельным позициям
      • -
    • Проверка: система оповещений, которая уведомляет об окончании или начале сезонных предложений
      • -
    • Проверьте, распечатывает ли квитанция точную скидку или предложения, которые используются
      • -
    • Проверка: система для определения неправильных предложений или скидок на товары онлайн
      • -
    • Протестируйте процесс управления заказами
      • -
    • Убедитесь, что данные продукта, полученные после сканирования штрих-кода, являются точными
      • -
    -
    Управление акциями и скидками +
      +
    • Проверка: система для различных скидок, таких как ветеранская скидка, сезонная скидка, скидка на покупку или перелет и т. д.  +
      • +
    • Проверка: система для различных рекламных предложений по отдельным позициям  +
      • +
    • Проверка: система оповещений, которая уведомляет об окончании или начале сезонных предложений  +
      • +
    • Проверьте, распечатывает ли квитанция точную скидку или предложения, которые используются  +
      • +
    • Проверка: система для определения неправильных предложений или скидок на товары онлайн  +
      • +
    • Протестируйте процесс управления заказами  +
      • +
    • Убедитесь, что данные продукта, полученные после сканирования штрих-кода, являются точными +
      • +
    +
    Отслеживание данных клиента -
      -
    • Проверка ответа системы с неверным вводом данных клиента
      • -
    • Проверка: система для разрешения авторизованного доступа к конфиденциальным данным клиента
      • -
    • Протестируйте базу данных для записи истории покупок клиента (что он покупает, как часто он покупает и т. д. )
      • +
    		Отслеживание данных клиента +
      +
    • Проверка ответа системы с неверным вводом данных клиента  +
      • +
    • Проверка: система для разрешения авторизованного доступа к конфиденциальным данным клиента  +
      • +
    • Протестируйте базу данных для записи истории покупок клиента (что он покупает, как часто он покупает и т. д. ) +
    -
    Безопасность и соответствие нормативным требованиям -
      -
    • Проверка системы POS на соответствие нормативным требованиям
      • -
    • Проверка: система оповещения -> security defenders
      • -
    • Убедитесь, что вы можете аннулировать платеж перед отправкой
      • -
    • Тестируйте профили пользователей и уровни доступа в POS Software
      • -
    • Проверка согласованности базы данных
      • -
    • Проверьте конкретную информацию о каждой наличности, идентификатор купона, номер чека и т. д.
      • -
    -
    Безопасность и соответствие нормативным требованиям +
      +
    • Проверка системы POS на соответствие нормативным требованиям  +
      • +
    • Проверка: система оповещения -> security defenders +
      • +
    • Убедитесь, что вы можете аннулировать платеж перед отправкой  +
      • +
    • Тестируйте профили пользователей и уровни доступа в POS Software  +
      • +
    • Проверка согласованности базы данных  +
      • +
    • Проверьте конкретную информацию о каждой наличности, идентификатор купона, номер чека и т. д.  +
      • +
    +
    Тестирование отчетности -
      -
    • Тестирование отчета по анализу трендов
      • -
    • Тестовая информация, связанная с транзакцией по кредитной карте, должна быть отражена в отчетах
      • -
    • Тест для отдельных, а также сводные отчеты истории покупок клиентов
      • -
    • Тест для генерации онлайн отчетов
      • +
    		Тестирование отчетности +
      +
    • Тестирование отчета по анализу трендов  +
      • +
    • Тестовая информация, связанная с транзакцией по кредитной карте, должна быть отражена в отчетах  +
      • +
    • Тест для отдельных, а также сводные отчеты истории покупок клиентов +
      • +
    • Тест для генерации онлайн отчетов +
    -
    - - -

    Тестирование в сфере страхования (Insurance)

    -Страховые компании в значительной степени полагаются на ПО для ведения своего бизнеса. Программные системы помогают им заниматься различными видами страховой деятельности, такими как разработка стандартных форм полисов, обработка процесса выставления счетов, управление данными клиента, оказание качественных услуг клиенту, координация между филиалами и так далее. Хотя это ПО разработано с учетом ожиданий заказчика, его надежность и согласованность должны быть проверены перед его фактическим внедрением. Тестирование ПО гарантирует качество страхового ПО, выявляя ошибки перед запуском. - -Страхование определяется как справедливая передача риска убытков от одного субъекта другому в обмен на платеж. Страховая компания, которая продает полис, называется СТРАХОВОЙ, а лицо или компания, которая использует полис, называется ЗАСТРАХОВАННЫЙ. Страховые полисы обычно делятся на две категории, и страховщик покупает эти полисы в соответствии с их требованиями и бюджетом. Тем не менее, есть другие виды страхования, которые подпадают под эти категории: +

    Тестирование в сфере страхования (Insurance)

    +Страховые компании в значительной степени полагаются на ПО для ведения своего бизнеса. Программные системы помогают им заниматься различными видами страховой деятельности, такими как разработка стандартных форм полисов, обработка процесса выставления счетов, управление данными клиента, оказание качественных услуг клиенту, координация между филиалами и так далее. Хотя это ПО разработано с учетом ожиданий заказчика, его надежность и согласованность должны быть проверены перед его фактическим внедрением. Тестирование ПО гарантирует качество страхового ПО, выявляя ошибки перед запуском.  +Страхование определяется как справедливая передача риска убытков от одного субъекта другому в обмен на платеж. Страховая компания, которая продает полис, называется СТРАХОВОЙ, а лицо или компания, которая использует полис, называется ЗАСТРАХОВАННЫЙ. Страховые полисы обычно делятся на две категории, и страховщик покупает эти полисы в соответствии с их требованиями и бюджетом. Тем не менее, есть другие виды страхования, которые подпадают под эти категории:  -Есть много ветвей в страховой компании, которые требуют тестирования: - +Есть много ветвей в страховой компании, которые требуют тестирования:  -Сектор страхования представляет собой сеть небольших подразделений, которая прямо или косвенно занимается обработкой требований. Для бесперебойного функционирования страховой компании необходимо, чтобы каждое из этих подразделений было тщательно проверено для достижения желаемого результата. Тестирование включает в себя: - +Сектор страхования представляет собой сеть небольших подразделений, которая прямо или косвенно занимается обработкой требований. Для бесперебойного функционирования страховой компании необходимо, чтобы каждое из этих подразделений было тщательно проверено для достижения желаемого результата. Тестирование включает в себя:  Образцы тестов для страховой заявки: - -

    Тестирование в сфере телекоммуникаций (Telecom)

    +Test for 100% coverage and accuracy in calculations determining premium rates) + +
  • Убедитесь, что формула для расчета дивидендов и выплаченных значений дает правильное значение (Make sure formula for calculating dividend and paid up values gives correct value) +
    • +
  • Убедитесь, что значения выдачи рассчитываются в соответствии с требованиями политики (Verify surrender values are calculated as per the policy requirement) +
    • +
  • Проверьте фидуциарные детали и требования бухгалтерского учета (Verify fiduciary details and bookkeeping requirements) +
    • +
  • Тестирование сложных сценариев для отклонения политики провала и восстановления (Test complex scenarios for policy lapse and revivals) +
    • +
  • Испытайте различные условия для стоимости без конфискации (Test various conditions for non-forfeiture value) +
    • +
  • Тестовые сценарии для прекращения действия политики (Test scenarios for policy termination) +
    • +
  • Убедитесь, что учетная запись главной книги ведет себя так же, как и для сверки с дополнительной книгой (Verify general ledger account behave same as to reconcile with subsidiary ledger) +
    • +
  • Тестовый расчет чистого обязательства для оценки (Test calculation of net liability for valuation) +
    • +
  • Условия тестирования для длительного страхования (Test conditions for extended term insurance) +
    • +
  • Проверка политики для варианта без конфискации (Verify policy for a non-forfeiture option) +
    • +
  • Проверьте, что другой страховой продукт ведет себя как ожидалось (Check different insurance product term behaves as expected) +
    • +
  • Проверьте сумму выплаты согласно плану продукта (Verify premium value as per product plan) +
    • +
  • Тестирование автоматической системы обмена сообщениями для информирования клиентов о новых продуктах (Test automatic messaging system to inform customer about new products) +
    • +
  • Проверяйте все данные, введенные пользователями, по мере их прохождения через рабочий процесс, чтобы инициировать предупреждения, соответствие, уведомления и другие события рабочего процесса (Validate all the data entered by users as it progresses through the workflow to trigger warnings, compliance, notification and other workflow events) +
    • +
  • Убедитесь, что шаблон страхового документа поддерживает такой формат документа, как MS-Word (Verify insurance document template supports the document format like MS-Word) +
    • +
  • Тестовая система для автоматического выставления счета и отправки его клиенту по электронной почте (Test system for generating invoice automatically and send it to customer through e-mail) +
    • + +

    Тестирование в сфере телекоммуникаций (Telecom)

    После перехода сектора телекоммуникаций на цифровые и компьютерные сети, телекоммуникационная отрасль повсеместно использует ПО. Сектор телекоммуникаций зависит от различных видов компонентов ПО, чтобы доставить множество услуг, таких как маршрутизация и коммутация, VoIP и широкополосный доступ, и т. д. Таким образом, тестирование ПО Telecom является неизбежным. - -Для предоставления телекоммуникационных услуг требуется наличие IVR, колл-центров, выставление счетов и т. д. и системы, которые включают в себя маршрутизаторы, коммутаторы, сотовые вышки и т. д. +Для предоставления телекоммуникационных услуг требуется наличие IVR, колл-центров, выставление счетов и т. д.  и системы, которые включают в себя маршрутизаторы, коммутаторы, сотовые вышки и т. д.  Примеры тест-кейсов: -

    Тестирование протокола: L2 и L3 OSI

    Когда компьютеры общаются друг с другом, существует общий набор правил и условий, которым должен следовать каждый компьютер. Другими словами, протоколы определяют, как данные передаются между вычислительными устройствами и по сетям. - -PROTOCOL testing проверяет протоколы связи в областях коммутации, беспроводной связи, VoIP, маршрутизации и т. д. Цель состоит в том, чтобы проверить структуру пакетов, которые отправляются по сети, с помощью инструментов тестирования протоколов. - -Протоколы делятся на две категории: Routed и routing. Routed могут использоваться для отправки пользовательских данных из одной сети в другую. Он переносит пользовательский трафик, такой как электронная почта, веб-трафик, передача файлов и т. д. Routed являются IP, IPX и AppleTalk. - -Routing это сетевые протоколы, которые определяют маршруты для маршрутизаторов. Они используется только между маршрутизаторами. Например, RIP, IGRP, EIGRP и т. д. - -Модель OSI имеет в общей сложности 7 уровней сетевого взаимодействия, в которых уровень 2 и уровень 3 очень важны. - +PROTOCOL testing проверяет протоколы связи в областях коммутации, беспроводной связи, VoIP, маршрутизации и т. д.  Цель состоит в том, чтобы проверить структуру пакетов, которые отправляются по сети, с помощью инструментов тестирования протоколов. +Протоколы делятся на две категории: Routed и routing. Routed могут использоваться для отправки пользовательских данных из одной сети в другую. Он переносит пользовательский трафик, такой как электронная почта, веб-трафик, передача файлов и т. д.  Routed являются IP, IPX и AppleTalk.  +Routing это сетевые протоколы, которые определяют маршруты для маршрутизаторов. Они используется только между маршрутизаторами. Например, RIP, IGRP, EIGRP и т. д.  +Модель OSI имеет в общей сложности 7 уровней сетевого взаимодействия, в которых уровень 2 и уровень 3 очень важны.  Для тестирования протокола вам понадобится анализатор протокола и симулятор. - -Анализатор протокола обеспечивает правильное декодирование наряду с анализом вызовов и сеансов. В то время как симулятор имитирует различные сущности сетевого элемента. - -Обычно тестирование протокола выполняется DUT (тестируемым устройством) для других устройств, таких как коммутаторы и маршрутизаторы, и для настройки протокола в нем. После этого проверяется структура пакетов, отправленных устройствами. Он проверяет масштабируемость, производительность, алгоритм протокола и т. д. устройства с помощью таких инструментов, как lxNetworks, Scapy и Wireshark. - -Тестирование протокола включает тестирование функциональности, производительности, стека протоколов, функциональной совместимости и т. д. Во время тестирования протокола, в основном, выполняется три проверки: - +Анализатор протокола обеспечивает правильное декодирование наряду с анализом вызовов и сеансов. В то время как симулятор имитирует различные сущности сетевого элемента.  +Обычно тестирование протокола выполняется DUT (тестируемым устройством) для других устройств, таких как коммутаторы и маршрутизаторы, и для настройки протокола в нем. После этого проверяется структура пакетов, отправленных устройствами. Он проверяет масштабируемость, производительность, алгоритм протокола и т. д.  устройства с помощью таких инструментов, как lxNetworks, Scapy и Wireshark.  +Тестирование протокола включает тестирование функциональности, производительности, стека протоколов, функциональной совместимости и т. д.  Во время тестирования протокола, в основном, выполняется три проверки:  -Тестирование протокола может быть разделено на две категории. Стресс и тесты надежности и функциональные тесты. Стресс-тесты и тесты надежности охватывают нагрузочное тестирование, стресс-тестирование, тестирование производительности и т. д. В то время как функциональное тестирование включает в себя негативное тестирование, тестирование на соответствие, тестирование на совместимость и т. д. - -Тестирование соответствия: протоколы, реализованные в продуктах, тестируются на соответствие, например, IEEE, RFC и т. д. Тестирование совместимости: проверяется совместимость для разных поставщиков. Это тестирование проводится после тестирования соответствия на соответствующей платформе. Проверка функциональности сети: функциональность сетевых продуктов проверена на функциональность со ссылкой на проектную документацию. Например, функциями могут быть защита портов на коммутаторе, ACL на маршрутизаторе и т. д. - -Вот примеры Test case для роутеров: - +Тестирование протокола может быть разделено на две категории. Стресс и тесты надежности и функциональные тесты. Стресс-тесты и тесты надежности охватывают нагрузочное тестирование, стресс-тестирование, тестирование производительности и т. д.  В то время как функциональное тестирование включает в себя негативное тестирование, тестирование на соответствие, тестирование на совместимость и т. д.   +Тестирование соответствия: протоколы, реализованные в продуктах, тестируются на соответствие, например, IEEE, RFC и т. д.  Тестирование совместимости: проверяется совместимость для разных поставщиков. Это тестирование проводится после тестирования соответствия на соответствующей платформе. Проверка функциональности сети: функциональность сетевых продуктов проверена на функциональность со ссылкой на проектную документацию. Например, функциями могут быть защита портов на коммутаторе, ACL на маршрутизаторе и т. д.  +Вот примеры Test case для роутеров:  -

    Тестирование интернета вещей (IoT — Internet of Things)

    -Интернет вещей — это сеть, состоящая из устройств в транспортных средствах, зданиях или любых других подключенных электронных устройств. Эта взаимосвязь облегчает сбор и обмен данными. 4 общих компонента системы IoT: - +

    Тестирование интернета вещей (IoT - Internet of Things)

    +Интернет вещей - это сеть, состоящая из устройств в транспортных средствах, зданиях или любых других подключенных электронных устройств. Эта взаимосвязь облегчает сбор и обмен данными. 4 общих компонента системы IoT:  -IOT — это соединение идентифицируемых встроенных устройств с существующей интернет-инфраструктурой. Проще говоря, мы можем сказать, что IOT - это эра «умных», связанных продуктов, которые обмениваются данными и передают большой объем данных и загружают их в облако. +IOT - это соединение идентифицируемых встроенных устройств с существующей интернет-инфраструктурой. Проще говоря, мы можем сказать, что IOT - это эра «умных», связанных продуктов, которые обмениваются данными и передают большой объем данных и загружают их в облако. - - - - - +Testing Types + - - - - - - + - - - - - - + - - - - - - + - - - - - - + - - - - - - + - - - - - - + - - - - - - +
    IOT elements -Testing TypesSensorApplicationNetworkBackend (Data Center)
    Sensor +Application +Network +Backend (Data Center) +
    Functional testingTrueTrueFalseFalse
    Functional testing +True +True +False +False +
    Usability testingTrueTrueFalseFalse
    Usability testing +True +True +False +False +
    Security testingTrueTrueTrueTrue
    Security testing +True +True +True +True +
    Performance testingFalseTrueTrueTrue
    Performance testing +False +True +True +True +
    Compatibility testingTrueTrueFalseFalse
    Compatibility testing +True +True +False +False +
    Services testingFalseTrueTrueTrue
    Services testing +False +True +True +True +
    Operational testingTrueTrueFalseFalse
    Operational testing +True +True +False +False +
    -Категории тестов с примерами Test Conditions: +Категории тестов с примерами Test Conditions:

    Что такое облачное тестирование? (Cloud testing)

    -CLOUD testing — это тип тестирования программного обеспечения, который проверяет услуги облачных вычислений. Облачные вычисления - это интернет-платформа, предоставляющая различные компьютерные сервисы, такие как оборудование, программное обеспечение и другие компьютерные сервисы, удаленно. Существует три модели облачных вычислений: - +CLOUD testing - это тип тестирования программного обеспечения, который проверяет услуги облачных вычислений. Облачные вычисления - это интернет-платформа, предоставляющая различные компьютерные сервисы, такие как оборудование, программное обеспечение и другие компьютерные сервисы, удаленно. Существует три модели облачных вычислений: -Все облачное тестирование разделено на четыре основные категории: - +Все облачное тестирование разделено на четыре основные категории:  -Облачное тестирование фокусируется на основных компонентах, таких как: - +Облачное тестирование фокусируется на основных компонентах, таких как:  Другие типы тестирования в облаке включают: - Как выполнять облачное тестирование: - Примеры Test Scenario и несколько Test case для каждого из них: - -

    Что такое тестирование сервис-ориентированной архитектуры? (SOA — Service Oriented Architecture)

    -Это тестирование архитектурного стиля SOA, в котором компоненты приложения предназначены для сообщения по протоколам связи, обычно через сеть. SOA — это метод интеграции бизнес-приложений и процессов для удовлетворения потребностей бизнеса. В разработке программного обеспечения SOA обеспечивает гибкость бизнес-процессов. Изменения в процессе или приложении могут быть направлены на конкретный компонент, не затрагивая всю систему. Разработчики программного обеспечения в SOA либо разрабатывают, либо покупают куски программ под названием SERVICES. Что такое Service? - +

    Что такое тестирование сервис-ориентированной архитектуры? (SOA - Service Oriented Architecture) 

    +Это тестирование архитектурного стиля SOA, в котором компоненты приложения предназначены для сообщения по протоколам связи, обычно через сеть. SOA - это метод интеграции бизнес-приложений и процессов для удовлетворения потребностей бизнеса. В разработке программного обеспечения SOA обеспечивает гибкость бизнес-процессов. Изменения в процессе или приложении могут быть направлены на конкретный компонент, не затрагивая всю систему. Разработчики программного обеспечения в SOA либо разрабатывают, либо покупают куски программ под названием SERVICES. Что такое Service?  Пример: на домашней странице веб-сайта и в поисковой системе отображается ежедневный прогноз погоды. Вместо того, чтобы писать код для виджета прогноза погоды, у продавца можно купить Службу прогноза погоды и встроить ее в страницу. - Тестирование SOA должно быть сосредоточено на 3 уровнях: - - + -Методы тестирования SOA: +Методы тестирования SOA: +
  • Performance testing: +
    • -
  • End to End testing:
    • - +
  • Тестирование уровня интеграции (Integration level testing): +
    • +
  • End to End testing: +
    • + -

    Что такое тестирование планирования ресурсов предприятия? (ERP — Enterprise Resource Planning)

    + +

    Что такое тестирование планирования ресурсов предприятия? (ERP - Enterprise Resource Planning)

    Планирование ресурсов предприятия, также известное как ERP, представляет собой комплексное программное обеспечение, которое объединяет различные функции организации в единую систему. Программное обеспечение имеет общую базу данных, содержащую всю информацию, относящуюся к различным функциям или подразделениям организации. Система ERP помогает оптимизировать процессы и доступ к информации по всей организации 24 × 7. - Приложения ERP стали критически важными для бесперебойной работы предприятий. Поскольку они включают в себя множество модулей, функций и процессов, необходимость их проверки становится критической. Предприятия осознают необходимость использования модели SMAC (Social, Mobile, Analytics и Cloud) для ускорения роста. Однако капитальный ремонт основных процессов, администрируемых устаревшими приложениями ERP, также важен. Приложения ERP помогают предприятиям управлять различными функциями, отделами и процессами, включая генерируемые в них данные. Эти приложения помогают предприятиям работать как единое целое и в процессе генерировать такие результаты, как повышение производительности, повышение эффективности, сокращение отходов, повышение качества обслуживания клиентов и повышение рентабельности инвестиций. Ввиду важности приложений ERP для организаций, они должны быть протестированы и утверждены. Тестирование приложений ERP может обеспечить бесперебойную работу множества задач в организациях. Они могут включать в себя отслеживание инвентаризации и операций с клиентами, управление финансами и человеческими ресурсами, среди многих других. - Каждое программное обеспечение ERP поставляется с несколькими версиями и требует настройки в соответствии с конкретными бизнес-требованиями. Более того, поскольку каждый элемент приложения связан с каким-либо другим модулем, их обновление может быть сложной задачей. Например, для создания заказа на продажу потребуется доступ к модулю управления запасами. Если какой-либо из модулей не функционирует оптимально, это может повлиять на все приложение ERP. Это может оказать каскадное влияние на производительность компании, а также создать плохой опыт клиентов. Следовательно, тестирование приложений ERP должно обеспечить правильную реализацию программного обеспечения и предотвратить сбои. Тестирование программного обеспечения ERP, помимо проверки функциональности программного обеспечения, должно обеспечивать точное формирование отчетов и форм. Выявляя и устраняя ошибки на этапе тестирования, тестировщики могут избежать столкновения с проблемами после внедрения. Более того, это может привести к скорейшему внедрению программного обеспечения и обеспечить его бесперебойную работу. Службы тестирования приложений ERP проверяют бизнес-процессы, функции и регулирующие их правила. Они помогают снизить операционные риски в условиях ограниченности имеющихся ресурсов и времени. - Поскольку система ERP содержит огромные объемы данных, тестирование ручных процедур может потребовать много времени и средств. Автоматизированное тестирование может помочь проверить все функции и возможности при минимальных затратах времени и средств. Кроме того, поскольку несколько бизнес-подразделений организации могут иметь разные процессы или процедуры, автоматическое тестирование может проверять точность их результатов по конкретным параметрам. Кроме того, ERP-систему необходимо периодически обновлять с появлением новых технологий, таких как Cloud, Big Data и Mobility. Такие обновления помогают организации проверять транзакции в режиме реального времени, что невозможно вручную. - -Системы ERP доступны в нескольких версиях, предназначенных для нескольких доменов, подразделений и клиентов, лучшие доступные инструменты: - +Системы ERP доступны в нескольких версиях, предназначенных для нескольких доменов, подразделений и клиентов, лучшие доступные инструменты:  -

    Тестирование качества видеосвязи WebRTC-based сервиса видеоконференций

    -WebRTC (англ. real-time communications — коммуникации в реальном времени) — проект с открытым исходным кодом, предназначенный для организации передачи потоковых данных между браузерами или другими поддерживающими его приложениями по технологии точка-точка. Стандарт поддерживается в браузерах, поэтому низкий порог вхождения – не нужно писать клиент. Помимо браузеров известны такие гиганты в сфере видеоконференций, как: Skype, Google Meets/hangouts, Discord. +Доп. материал: +Тестування CRM-систем на прикладі Salesforce +

    Тестирование качества видеосвязи WebRTC-based сервиса видеоконференций

    +WebRTC (англ. real-time communications — коммуникации в реальном времени) — проект с открытым исходным кодом, предназначенный для организации передачи потоковых данных между браузерами или другими поддерживающими его приложениями по технологии точка-точка. Стандарт поддерживается в браузерах, поэтому низкий порог вхождения – не нужно писать клиент. Помимо браузеров известны такие гиганты в сфере видеоконференций, как: Skype, Google Meets/hangouts, Discord. В чем выражается качество видеосвязи? В подавляющем большинстве случаев речь о: - -Как обычно пытаются тестировать? С помощью плохой сети. Например, отойти с планшетом подальше от wi-fi точки. Вообще плохая сеть подразумевает большой пинг, низкую пропускную способность канала, потерю пакетов. +Как обычно пытаются тестировать? С помощью плохой сети. Например, отойти с планшетом подальше от wi-fi точки. Вообще плохая сеть подразумевает большой пинг, низкую пропускную способность канала, потерю пакетов.  К сожалению, ручное тестирование видеосвязи (впрочем, как и аудио-) не даст достоверных и точных результатов. На следующем этапе команда приходит к идее писать автотесты (по большей части unit) и лишь некоторые доходят до написания бенчмарков. Возможно, в комментариях опытные коллеги поделятся своим опытом. -

    Что такое тестирование ETL?

    -ETL расшифровывается как Extract, Transform, Load. ETL — это процесс, объединяющий три этапа: извлечение, преобразование и загрузка данных из одного источника в другой. Проще говоря, операции ETL выполняются с данными, чтобы вытащить их из одной базы данных в другую. Процесс ETL часто используется в хранилищах данных. - +ETL расшифровывается как Extract, Transform, Load. ETL - это процесс, объединяющий три этапа: извлечение, преобразование и загрузка данных из одного источника в другой. Проще говоря, операции ETL выполняются с данными, чтобы вытащить их из одной базы данных в другую. Процесс ETL часто используется в хранилищах данных. -ETL-тестирование — это тип тестирования, выполняемый для гарантии того, что данные, перенесенные из исходной в целевую базу данных, являются точными и соответствуют действующим правилам преобразования. - -Пример: - -Давайте рассмотрим пример слияния двух компаний — компании A и компании B. После слияния их операции будут объединены, а их клиенты, сотрудники и другие данные будут храниться в единой централизованной базе данных. Предположим, что компания A использует базу данных Oracle для хранения всей информации, а компания B использует MySQL. Теперь для объединения своей информации обе компании могут использовать процесс ETL для переноса данных из своих отдельных баз данных в одну согласованную базу данных. В процессе ETL, поскольку две базы данных различны, данные обеих компаний будут в другом формате, будут использоваться разные соглашения об именах, будут использоваться разные структуры таблиц и так далее. Из-за этих различий компаниям необходимо удостовериться, что перед загрузкой данных в целевую базу данных она была должным образом очищена и может сформировать нужный формат. При тестировании ETL тестеры должны убедиться, что данные обеих баз данных были преобразованы в формат целевой базы данных; необходимые функции преобразования были выполнены; в процессе не было потеряно никаких данных, и данные являются точными. +ETL-тестирование - это тип тестирования, выполняемый для гарантии того, что данные, перенесенные из исходной в целевую базу данных, являются точными и соответствуют действующим правилам преобразования. -Типы тестирования ETL: +Пример:  +Давайте рассмотрим пример слияния двух компаний - компании A и компании B. После слияния их операции будут объединены, а их клиенты, сотрудники и другие данные будут храниться в единой централизованной базе данных. Предположим, что компания A использует базу данных Oracle для хранения всей информации, а компания B использует MySQL. Теперь для объединения своей информации обе компании могут использовать процесс ETL для переноса данных из своих отдельных баз данных в одну согласованную базу данных. В процессе ETL, поскольку две базы данных различны, данные обеих компаний будут в другом формате, будут использоваться разные соглашения об именах, будут использоваться разные структуры таблиц и так далее. Из-за этих различий компаниям необходимо удостовериться, что перед загрузкой данных в целевую базу данных она была должным образом очищена и может сформировать нужный формат. При тестировании ETL тестировщики должны убедиться, что данные обеих баз данных были преобразованы в формат целевой базы данных; необходимые функции преобразования были выполнены; в процессе не было потеряно никаких данных, и данные являются точными. +Типы тестирования ETL:  -     - - -

    Мобильное тестирование

    +Доп. материал: +«Как QA в управлении хранилища данных эволюционировал» +

    ----- Мобильное тестирование -----

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

    В чем отличия тестирования мобильного приложения от десктопного?

    В чем отличия тестирования мобильного приложения от web?

    -Из этих основных различий следуют и различия в тестировании – уровни, виды, типы и т. д. - -

    Почему так много внимания уделяется прерываниям? Что такое Activity Lifecycle?

    -У приложения есть жизненный цикл со строго определенными в системе активностями. Данные активити должны корректно обрабатываться. - -
    -На просторах много материала по данной теме, возможно позже оформлю здесь подробнее. - +Из этих основных различий следуют и различия в тестировании – уровни, виды, типы и т. д.  + +Мнение: +"Ваши усилия должны скорее быть направлены на выявление узких мест такие как ограничения на доступ к ресурсам выходящие с каждой новой версией мобильных операционных систем - шифрование хранилищ. Глубокая модернизация ядра (Что касается Android) устройств. Нюансы работы оффлайн воркеров для PWA. C  другой стороны в "Старших" операционных системах вы столкнетесь с взаимодействием с другими программными продуктами в рамках одной операционной системы - поскольку в них приложения не запускаются в своем собственном Sandbox но очень не слабо влияют друг на друга.  Самая яркая иллюстрация этого существование InstallShield в рамках WIndows  в течении уже многих лет." (с) @Havy_Man +

    Как работает Android, какая у него архитектура?

    + + + + +Applications. Android поставляется с набором основных приложений, включающим календарь, карты, браузер, менеджер контактов и другие. Все перечисленные приложения написаны на Java. +Application Framework. Предоставляя открытую платформу разработки, Android дает разработчикам возможность создавать гибкие и инновационные приложения. Разработчики могут использовать аппаратные возможности устройства, получать информацию о местоположении, выполнять задачи в фоновом режиме, устанавливать оповещения и многое другое. Разработчики имеют полный доступ к тем же API, что используются в основных приложениях. +Архитектура приложений разработана с целью упрощения повторного использования компонентов; любое приложение может "публиковать" свои возможности и любое другое приложение может затем использовать эти возможности (с учетом ограничений безопасности). Этот же механизм позволяет заменять стандартные компоненты на пользовательские. +Libraries. Android включает в себя набор C/C++ библиотек, используемых различными компонентами системы. Эти возможности доступны разработчикам в контексте применения Android Application Framework. Некоторые основные библиотеки, перечислены ниже: +Mедиа библиотеки – эти библиотеки предоставляют поддержку воспроизведения и записи многих популярных аудио, видео форматов и форматов изображений, в том числе MPEG4, MP3, AAC, AMR, JPG, PNG и других; +Surface Manager – управляет доступом к подсистеме отображения 2D и 3D графических слоев; +LibWebCore – современный веб-движок, на котором построен браузер Android; +SGL – основной графический движок 2D; +3D библиотеки – реализованы на основе OpenGL; библиотеки используют либо аппаратное 3D-ускорение (при его наличии), либо включены программно; +FreeType – поддержка растровых и векторных шрифтов +SQLite – механизм базы данных, доступной для всех приложений. +Android Runtime. Android включает в себя набор основных библиотек, которые обеспечивают большинство функций, доступных в библиотеках Java. Каждое приложение Android работает в своем собственном процессе, со своим собственным экземпляром виртуальной машины Dalvik. Dalvik была написана так, что устройство может работать эффективно с несколькими виртуальными машинами одновременно. +Dalvik проектировалась специально под платформу Android. Виртуальная машина оптимизирована для низкого потребления памяти и работы на мобильном аппаратном обеспечении. Dalvik использует собственный байт-код. Android-приложения переводятся компилятором в специальный машинно-независимый низкоуровневый код. И именно Dalvik интерпретирует и выполняет такую программу при выполнении на платформе. Кроме того, с помощью специальной утилиты, входящей в состав Android SDK, Dalvik способна переводить байт-коды Java в коды собственного формата и также исполнять их в своей виртуальной среде. +Linux Kernel. Android основан на Linux версии 2.6 с основными системными службами – безопасность, управление памятью, управление процессами и модель драйверов. Разработчики Android модифицировали ядро Linux, добавив поддержку аппаратного обеспечения, используемого в мобильных устройствах и, чаще всего, недоступного на компьютерах. +Источник: https://intuit.ru/studies/courses/4462/988/lecture/14988 +Доп. материал: Android's HIDL: Treble in the HAL +

    Что такое тестирование прерываний (Interrupt Testing)? Причем тут Activity Lifecycle?

    +У приложения есть жизненный цикл со строго определенными в системе активностями. То есть при любом типе прерывания приложение должно вести себя корректно. Это важно проверять, так как это происходит буквально постоянно, а разработчики могут упустить такие кейсы в коде. Примеры можно посмотреть в разделе полезных ресурсов, там множество чек-листов и мнемоник. + +

    Как устроена iOS?

    +Все в курсе, что мобильные девайсы Apple работают под управлением iOS. Многие знают, что iOS представляет собой облегченную версию настольной Mac OS X. Некоторые догадываются, что в основе Mac OS X лежит POSIX-совместимая ОС Darwin, а те, кто всерьез интересуется IT, в курсе, что основа Darwin — это ядро XNU, появившееся на свет в результате слияния микроядра Mach и компонентов ядра FreeBSD. Однако все это голые факты, которые ничего не скажут нам о том, как же на самом деле работает iOS и в чем ее отличия от настольного собрата. +Условно начинку OS X / iOS можно разделить на три логических уровня: ядро XNU, слой совместимости со стандартом POSIX (плюс различные системные демоны/сервисы) и слой NeXTSTEP, реализующий графический стек, фреймворк и API приложений. Darwin включает в себя первые два слоя и распространяется свободно, но только в версии для OS X. iOS-вариант, портированный на архитектуру ARM и включающий в себя некоторые доработки, полностью закрыт и распространяется только в составе прошивок для айдевайсов (судя по всему, это защита от портирования iOS на другие устройства). +По своей сути Darwin — это «голая» UNIX-подобная ОС, которая включает в себя POSIX API, шелл, набор команд и сервисов, минимально необходимых для работы системы в консольном режиме и запуска UNIX-софта. В этом плане он похож на базовую систему FreeBSD или минимальную установку какого-нибудь Arch Linux, которые позволяют запустить консольный UNIX-софт, но не имеют ни графической оболочки, ни всего необходимого для запуска серьезных графических приложений из сред GNOME или KDE. +Ключевой компонент Darwin — гибридное ядро XNU, основанное, как уже было сказано выше, на ядре Mach и компонентах ядра FreeBSD, таких как планировщик процессов, сетевой стек и виртуальная файловая система (слой VFS). В отличие от Mach и FreeBSD, ядро OS X использует собственный API драйверов, названный I/O Kit и позволяющий писать драйверы на C++, используя объектно-ориентированный подход, сильно упрощающий разработку. +iOS использует несколько измененную версию XNU, однако в силу того, что ядро iOS закрыто, сказать, что именно изменила Apple, затруднительно. Известно только, что оно собрано с другими опциями компилятора и модифицированным менеджером памяти, который учитывает небольшие объемы оперативки в мобильных устройствах. Во всем остальном это все то же XNU, которое можно найти в виде зашифрованного кеша (ядро + все драйверы/модули) в каталоге /System/Library/Caches/com.apple.kernelcaches/kernelcache на самом устройстве. +Уровнем выше ядра в Darwin располагается слой UNIX/BSD, включающий в себя набор стандартных библиотек языка си (libc, libmatch, libpthread и так далее), а также инструменты командной строки, набор шеллов (bash, tcsh и ksh) и демонов, таких как launchd и стандартный SSH-сервер. Последний, кстати, можно активировать путем правки файла /System/Library/LaunchDaemons/ssh.plist. Если, конечно, джейлбрейкнуть девайс. +На этом открытая часть ОС под названием Darwin заканчивается, и начинается слой фреймворков, которые как раз и образуют то, что мы привыкли считать OS X / iOS. + +Darwin реализует лишь базовую часть Mac OS / iOS, которая отвечает только за низкоуровневые функции (драйверы, запуск/остановка системы, управление сетью, изоляция приложений и так далее). Та часть системы, которая видна пользователю и приложениям, в его состав не входит и реализована в так называемых фреймворках — наборах библиотек и сервисов, которые отвечают в том числе за формирование графического окружения и высокоуровневый API для сторонних и стоковых приложений +Как и во многих других ОС, API Mac OS и iOS разделен на публичный и приватный. Сторонним приложениям доступен исключительно публичный и сильно урезанный API, однако jailbreak-приложения могут использовать и приватный. +В стандартной поставке Mac OS и iOS можно найти десятки различных фреймворков, которые отвечают за доступ к самым разным функциям ОС — от реализации адресной книги (фреймворк AddressBook) до библиотеки OpenGL (GLKit). Набор базовых фреймворков для разработки графических приложений объединен в так называемый Cocoa API, своего рода метафреймворк, позволяющий получить доступ к основным возможностям ОС. В iOS он носит имя Cocoa Touch и отличается от настольной версии ориентацией на сенсорные дисплеи. +<...> +Источник: Как устроена iOS +

    Жизненный цикл iOS-приложения?

    +В любой момент времени ваши приложение находятся в каком либо из перечисленных ниже состояний. Система меняет состояния вашего приложения в ответ на происходящие события. Например, когда пользователь нажимает кнопку Home, или поступает входящий вызов, или что либо еще — приложения в ответ на все это меняют свое состояние. + + + + + + + + + + + +
    Not Running +Приложение не запущено, либо запущенно но прервано системой. +
    Inactive +Приложение работает, но в настоящий момент ничего не делает (это может быть связано с выполнением другого кода). Приложение, как правило, остается в этом состоянии очень мало времени и переходит в другое состояние +
    Active +Нормальный обычный режим работы приложения на переднем плане. +
    Background +Приложение находится в фоне, но работает. Большинство приложений входят в это состояние на короткое время и позже приостанавливаются. Но если необходимо дополнительное время для работы в бекграунде, приложение может оставаться в этом состоянии +
    Suspended +Приложение работает в фоне, но не выполняет никакой код. Система перемещает приложение в это состояние автоматически и не предупреждает об этом. При условии малого количества памяти, система может не предупреждая закрыть приложения в этом состоянии для освобождения памяти. +
    + +Приложение должно быть готово к завершению в любое время. Завершение — это нормальная часть жизненного цикла. Система обычно выключает приложения, для очищения памяти и подготовки к запуску других приложений, которые запущены пользователем, но система также может выключить приложения , которые некорректно или не отвечающим на события своевременно. +Suspended приложения не получают уведомления о завершении. Система убивает процесс и восстанавливает соответствующую память. Если приложение запущено в фоне и не отвечает, система вызовет applicationWillTerminate: чтобы приложение подготовилось к выключению. Система не вызывает метод когда устройство перезагружается. +Доп. материал: +

    Что вы знаете о симуляторах и эмуляторах?

    -Всегда идет спор о том, что тестирование мобильных приложений более экономично и быстрее на реальных устройствах. Но прежде чем разрушить этот миф, давайте взглянем на базовое определение эмуляторов, симуляторов и реальных устройств: - +Всегда идет спор о том, что тестирование мобильных приложений более экономично и быстрее на реальных устройствах. Но прежде чем разрушить этот миф, давайте взглянем на базовое определение эмуляторов, симуляторов и реальных устройств:  -Тестирование на симуляторах или эмуляторах имеет много преимуществ, так как они бесплатны, имеют высокую скорость выполнения, не имеют проблем при автоматическом тестировании, просты в отладке и просты в настройке. Но эмулятор / симулятор не всегда является лучшим решением для таких сценариев, как те, в которых команде тестирования необходимо проверять производительность приложения в течение более длительного периода времени. Реальные устройства стоят дороже по сравнению с эмулятором / симуляторами. Но, как следует из названия, результаты реальных устройств всегда более точны по сравнению с эмуляторами или симуляторами. Для тестирования мобильных приложений всегда требуется большое количество мобильных устройств, поскольку тестирование мобильных приложений — это все о комбинациях ПО и железа. Следовательно, в таких случаях эффективность может быть достигнута только с помощью реальных устройств. +Тестирование на симуляторах или эмуляторах имеет много преимуществ, так как они бесплатны, имеют высокую скорость выполнения, не имеют проблем при автоматическом тестировании, просты в отладке и просты в настройке. Но эмулятор / симулятор не всегда является лучшим решением для таких сценариев, как те, в которых команде тестирования необходимо проверять производительность приложения в течение более длительного периода времени. Реальные устройства стоят дороже по сравнению с эмулятором / симуляторами. Но, как следует из названия, результаты реальных устройств всегда более точны по сравнению с эмуляторами или симуляторами. Для тестирования мобильных приложений всегда требуется большое количество мобильных устройств, поскольку тестирование мобильных приложений - это все о комбинациях ПО и железа. Следовательно, в таких случаях эффективность может быть достигнута только с помощью реальных устройств. +Доп. материал: +Эмулятор и симулятор мобильного устройства против реального устройства

    Типы мобильных приложений?

    + + -

    Что основное проверить при тестировании мобильного приложения?

    +

    Что основное проверить при тестировании мобильного приложения? 

    Проверяем в начале тестирования: - Список кейсов под iPhone из утерянного источника, довольно неплохой: + +Мультиплеерные игры. + -- Перепроверка функциональности, где ранее были обнаружены наиболее критические дефекты (регрессионное тестирование) - -- Проверка функциональности на корректных данных (текущая дата, короткие имена и т.д.) - -- Проверка на некорректных значениях (например: пустые поля, длинные имена, установка на телефоне даты в прошлом и т.д.) - -- Проверка интерфейса приложения на соответствие требованиям Apple (Human interface guidelines for iPhone\iPad) - -- Производительность приложения и скорость ответа интерфейса (используется iPhone 2g) - -- Тесты на удобство пользования приложением (Usability tests) - -- Тест на совместимость с другими приложениями\функциональностью iPhone (будильник\таймер\напоминания\входящий звонок\смс) +Conformance testing: + -- Проверка настроек приложения и корректность их применения -- Поиск возможных мест «падения» приложения (crash) и причин их возникновения -- Корректность работы приложения при использовании wi-fi\gprs (включая обрывы связи\ее отсутствие) -- Проверка на корректность работы приложения с памятью iPhone (memory leaks) +И еще: Физическая/виртуальная клавиатура, проверка обновления и чистой установки. Платный контент: соответствие цен и содержимого, покупки 2 типов (восстанавливаемые и невосстанавливаемые (кредиты)) - проверка восстановления покупок привязанных к учетке (переустановка/обновление/другое устройство)+должен быть выбор из текущего прогресса и сохраненного в учетке. Реклама: не должна перекрывать элементы, должна иметь доступную кнопку закрытия (А если кнопка еще не появилась, то каунтдаун до этого). Глобализация - меняется все что нужно и это происходит корректно. Защита от получения преимуществ при манипуляциях с датой и временем. Копирование и вставка из/в приложение. +Больше чек-листов и идей можно найти в разделе полезных ресурсов. +

    Как быть с покрытием девайсов?

    +Большинство багов обнаруживается на покрытии около 30% девайсов - разрешение, мощность, версия ос+нижняя граница для данной аппы. Варианты: физическая ферма устройств, эмулятор и симулятор (BrowserStack (облачный), родной в Android Studio, BlueStack, Genymotion и т.п.). Вообще физический устройств желательно иметь хотя бы штук 6 - два отличающихся айфона, по планшету на iOS и Android, 2 разных андроида. Хуавей сейчас тестится отдельно из-за гугл сервисов. +Доп. материал: + +

    Последнее обновление Android/iOS, что нового?

    +Актуализируется перед собеседованием, т.к. написанное здесь будет слишком быстро устаревать. +

    Основные различия iOS и Android?

    + -- проверка того, что звук не пропадает при подключении наушников -- Поведение приложения при переходе iPhone в спящий режим -- Работа приложения с акселерометром (поворот экрана в соответствии с положением iPhone, использование функции акселерометра для получения данных приложением (шагомер)) +Доп. материал: + +

    Что такое Middleware?

    + +Связу́ющее програ́ммное обеспе́чение (англ. middleware; также переводится как промежу́точное программное обеспечение, программное обеспечение среднего слоя, подпрогра́ммное обеспечение, межплатфо́рменное программное обеспечение) — широко используемый термин, означающий слой или комплекс технологического программного обеспечения для обеспечения взаимодействия между различными приложениями, системами, компонентами. (с) Вики. В данном разделе нас интересует применение в мобильной разработке. +Особенностью заказной разработки мобильных приложений является то, что основной сервер с API обычно предоставляет заказчик. Ниже список, с чем в этом случае придется иметь дело мобильным разработчикам: + +И добавим сюда понимание, что со всем этим придется бороться сразу на двух платформах, которые хоть и являются мобильными, часто используют разные архитектурные подходы и, как следствие, разные сроки старта и готовности этапов. Все это приводит к увеличению сроков разработки и, соответственно, стоимости разработки.  +Для минимизации всех этих проблем предлагается использовать промежуточный сервер — шину данных. +Middleware - чаще всего простой быстро настраиваемый сервер, не хранящий каких-либо данных, кроме логов. Он позволяет использовать для общения мобильных приложений с собой простой REST API, строго подогнанный под логику экранов, а сам уже обращается к целевому API необходимым образом. +Бонусом мы имеем возможность разрабатывать приложения со своими наработками по авторизации, обработкам ошибок и прочим мелочам, протестированными и проверенными. +Плюсы такого подхода: + +Все это позволяет снизить сроки и стоимость, напрямую и косвенно, за счет снижения рисков простоя, сложности реализации серверной части и тестирования. Шикарный бонус разработчику — возможность предложить более низкую цену и выиграть конкурс, а заказчику - сэкономить и уменьшить сроки внедрения МП. +Источник: Middleware: необходимость в мире разработки мобильных приложений -- Тестирование локализации (при поддержке приложением) +

    Виды жестов и т.п.?

    +Основное, остальное см. в полезных материалах (сборники терминов). + -- Проверка корректности работы приложения с камерой iPhone (если такая функциональность поддерживается), а также корректность работы приложения с iPod. +Доп. материал: +UI-элементы и жесты в мобильных приложениях +

    Как проверить использование процессора на мобильных устройствах? 

    +В Google Play или App Store доступны различные инструменты,, из которых можно установить приложения, такие как CPU Monitor, Usemon, CPU Stats, CPU-Z и т. д.  Это расширенный инструмент, который записывает информацию о процессах, запущенных на вашем устройстве. Не все показатели могут быть доступны, это зависит от конкретного устройства. Также в инструментах разработчика доступны инструменты профилирования. Другой вариант - профилировщик в IDE (Android Studio). +

    Что вы знаете о PWA?

    +Перспектива разработки мобильного приложения, которое не потребуется скачивать и ждать review из App Store, очень заманчива, ведь аналогов привычного ПО существует несколько: Progressive Web Apps (PWA), Android Instant Apps (AIA) и Accelerated Mobile Pages (AMP).  +Доп. материал: + -- быстрые «клики» по элементам интерфейса (переход по категориям, переход по записям внутри категории) -- если есть длительный workflow – проводить его весь (вроде длинных программ в Yoga) в реальном времени -- если есть готовый список и поле для вбивания параметров, то проверить поведение, когда в поле появляется подсказка из словаря и одновременно кликаешь по записи в списке <> подсказке. возможны конфликты между подсказкой айфона и реальным выбором. -- проверка контента: адекватный размер изображений (до 1МБ) и достаточное качество. Дополнительно смотреть на iPhone4 (большее разрешение) + см. MobileHIG.pdf chapter 11 для требований к разрешению изображений. -- GUI: иконки соответствуют тому, к чему относятся (хелп – знак вопроса, настройки – шестеренка и т.д.), новые окна плавно открываются справа, присутствует значок загрузки если происходит длительный процесс) -- Наличие экрана Game Over и корректные ссылки на нем – для игровых проектов (+ корректная отработка попадания на этот экран) -Мультиплеерные игры. -- корректность подключения игроков (напр., списывание баланса только после подключения) -- временные лаги -- подключение через различные сети -- корректное поведение при отключении игроков +

    ----- Сети и около них -----

    -- подключение ботов (если используются) +Некоторая база в одной статье: Сети для начинающего IT-специалиста. Обязательная база +

    Что такое http?

    +HTTP — широко распространенный протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам), сейчас же для любых данных. +Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное ПО обрабатывает данный запрос, формирует ответ и передает его обратно клиенту.  +То есть этот протокол не только устанавливает правила обмена информацией, но и служит транспортом для передачи данных — с его помощью браузер загружает содержимое сайта на ваш компьютер или смартфон. -
    - Conformance testing: +У HTTP есть один недостаток: данные передаются в открытом виде и никак не защищены. На пути из точки А в точку Б информация в интернете проходит через десятки промежуточных узлов, и, если хоть один из них находится под контролем злоумышленника, данные могут перехватить. То же самое может произойти, когда вы пользуетесь незащищенной сетью Wi-Fi, например, в кафе. Для установки безопасного соединения используется протокол HTTPS с поддержкой шифрования. +Защиту данных в HTTPS обеспечивает криптографический протокол SSL/TLS, который шифрует передаваемую информацию. По сути этот протокол является оберткой для HTTP. Он обеспечивает шифрование данных и делает их недоступными для просмотра посторонними. Протокол SSL/TLS хорош тем, что позволяет двум незнакомым между собой участникам сети установить защищенное соединение через незащищенный канал. При установке безопасного соединения по HTTPS ваш компьютер и сервер сначала выбирают общий секретный ключ, а затем обмениваются информацией, шифруя ее с помощью этого ключа. Общий секретный ключ генерируется заново для каждого сеанса связи. Его нельзя перехватить и практически невозможно подобрать — обычно это число длиной более 100 знаков. Этот одноразовый секретный ключ и используется для шифрования всего общения браузера и сервера. Казалось бы, идеальная система, гарантирующая абсолютную безопасность соединения. Однако для полной надежности ей кое-чего не хватает: гарантии того, что ваш собеседник именно тот, за кого себя выдает. Для этой гарантии существует сертификат. +Вам как пользователю сертификат не нужен, но любой сервер (сайт), который хочет установить безопасное соединение с вами, должен его иметь. Сертификат подтверждает две вещи: 1) Лицо, которому он выдан, действительно существует и 2) Оно управляет сервером, который указан в сертификате. Выдачей сертификатов занимаются центры сертификации — что-то вроде паспортных столов. Как и в паспорте, в сертификате содержатся данные о его владельце, в том числе имя (или название организации), а также подпись, удостоверяющая подлинность сертификата. Проверка подлинности сертификата — первое, что делает браузер при установке безопасного HTTPS-соединения. Обмен данными начинается только в том случае, если проверка прошла успешно. +Доп. материал: + +

    Компоненты HTTP?

    +HTTP определяет следующую структуру запроса (request): -
    -И еще: -Физическая\виртуальная клавиатура, проверка обновления и чистой установки. -Платный контент: соответствие цен и содержимого, покупки 2 типов (восстанавливаемые и невосстанавливаемые (кредиты)) - проверка восстановления покупок привязанных к учетке (переустановка\обновление\другое устройство)+должен быть выбор из текущего прогресса и сохраненного в учетке. -Реклама: не должна перекрывать элементы, должна иметь доступную кнопку закрытия (А если кнопка еще не появилась, то каунтдаун до этого). -Глобализация - по геолокации или вручную меняется всё что нужно и это происходит корректно. -Защита от получения преимуществ при манипуляциях с датой и временем. -Копирование и вставка из\в приложение. - -

    Как быть с покрытием девайсов?

    -Большинство багов обнаруживается на покрытии около 30% девайсов - разрешение, мощность, версия ос+нижняя граница для данной аппы. Варианты: физическая ферма устройств, эмулятор и симулятор (BrowserStack (облачный), родной в Android Studio, BlueStack, Genymotion и т.п.). Вообще физический устройств желательно иметь хотябы штук 6 - два отличающихся айфона, по планшету на iOS и Android, 2 разных андроида. Хуавей сейчас тестится отдельно из-за гугл сервисов. -
    Есть хорошая статья по теме: https://habr.com/ru/post/464433/ - -

    Последнее обновление Android/iOS, что нового?

    -Актуализируется перед собеседованием. -На данный момент в iOS 14 основное это: +HTTP определяет следующую структуру ответного сообщения (response): -Android 11: -habr.com/ru/company/google/blog/506992/ -

    Основные различия iOS и Android?

    +Доп. материал: https://iit-web-lectures.readthedocs.io/ru/latest/www/http.html +

    Методы HTTP-запроса?

    +Метод, используемый в HTTP-запросе, указывает, какое действие вы хотите выполнить с этим запросом. Раньше хватало только GET, т.к. считалось, что вы можете хотеть от сервера только получить ответ. Но сейчас вам может понадобиться отредактировать профиль, удалить пост в соц. сети и т.п. Тогда для удобства были созданы различные методы. Вот основные: