Interview Questions Flashcards
Объясните термин «жизненный цикл программного обеспечения».
Жизненным циклом программного обеспечения (SLC) является период времени, начинающийся с момента появления концепции ПО и заканчивающийся тогда, когда использование ПО более невозможно. Жизненный цикл программного обеспечения обычно включает в себя следующие этапы: концепт, описание требований, дизайн, реализация, тестирование, инсталляция и наладка, эксплуатация и поддержка и, иногда, этап вывода из эксплуатации. Данные фазы могут накладываться друг на друга или проводиться итерационно.
Объясните термин «жизненный цикл разработки программного обеспечения».
Жизненным циклом разработки программного обеспечения (SDLC) является концепция, которая описывает комплекс мероприятий, выполняемых на каждом этапе (фазе) разработки программного обеспечения.
SDLC - это систематизированный процесс, этапы которого охватывают полный жизненный цикл программного обеспечения (Software Lifecycle) и который определяет различные этапы разработки программного обеспечения для создания высококачественного программного обеспечения, отвечающего ожиданиям клиентов и для улучшения эффективности разработки. Разработка системы должна быть завершена в заранее определенные сроки и стоимость. Каждая фаза жизненного цикла SDLC имеет свой собственный процесс и результаты, которые используются в следующей фазе.
Обычно он делится на шесть-восемь шагов, но менеджеры проектов могут объединять, декомпозировать или пропускать шаги, в зависимости от скоупа проекта.
В разных источниках фазы немного отличаются, но глобально суть везде одинакова.
Фазы SDLC:
1. Сбор и анализ требований (Requirement Gathering and Analysis): На этом этапе от клиента собирается вся необходимая информация для разработки продукта в соответствии с их ожиданиями. Любые неясности должны быть разрешены сразу на этом этапе. Бизнес-аналитик и менеджер проекта назначили встречу с заказчиком, чтобы собрать всю информацию, например, что заказчик хочет построить, кто будет конечным пользователем, какова цель продукта. Перед созданием продукта очень важно понимание или знание продукта. Например, клиент хочет иметь приложение, которое включает денежные транзакции. В этом случае требование должно быть четким, например, какие транзакции будут выполняться, как они будут проводиться, в какой валюте они будут проводиться и т. д. После того, как сбор требований завершен, проводится анализ для проверки возможности разработки продукта. После четкого понимания требования создается документ SRS (Спецификация требований к программному обеспечению). Этот документ должен быть полностью понят разработчикам, а также должен быть рассмотрен заказчиком для использования в будущем;
2. Дизайн (Design): На этом этапе требования, собранные в документе SRS, используются в качестве входных данных, и создается архитектура программного обеспечения, которая используется для реализации разработки системы. Создаются два вида дизайн-документов:
○ Высокоуровневый дизайн (HLD - High-Level Design):
■ Краткое описание и название каждого модуля;
■ Краткое описание функциональности каждого модуля;
■ Отношения интерфейсов и зависимости между модулями;
■ Таблицы базы данных, идентифицированные вместе с их ключевыми элементами;
■ Полные архитектурные схемы с подробными сведениями о технологиях.
○ Низкоуровневый дизайн (LLD - Low-Level Design):
■ Функциональная логика модулей;
■ Таблицы базы данных, которые включают тип и размер;
■ Полная детализация интерфейсов;
■ Решение всех типов проблем с зависимостями;
■ Список сообщений об ошибках;
■ Полные входные и выходные значения для каждого модуля.
3. Разработка (Implementation or Coding): Реализация / кодирование начинается, как только разработчик получает Design document. Дизайн программного обеспечения переведен в исходный код. На этом этапе реализуются все компоненты программного обеспечения;
4. Тестирование (Testing): Тестирование начинается после завершения кодирования и выпуска модулей для тестирования. На этом этапе разработанное программное обеспечение тщательно тестируется, и
все обнаруженные дефекты передаются разработчикам для их исправления. Повторное тестирование, регрессионное тестирование проводится до тех пор, пока программное обеспечение не будет соответствовать ожиданиям клиента. Тестировщики обращаются к документу SRS, чтобы убедиться, что программное обеспечение соответствует стандарту заказчика;
5. Развертывание (Deployment): После тестирования продукта он развертывается в производственной среде или выполняется первое UAT (пользовательское приемочное тестирование), в зависимости от ожиданий клиента. В случае UAT создается копия производственной среды, и заказчик вместе с разработчиками выполняет тестирование. Если клиент остается доволен, то предоставляет согласие на релиз;
6. Поддержка (Maintenance): Основное внимание на этом этапе SDLC уделяется обеспечению того, чтобы потребности продолжали удовлетворяться и чтобы система продолжала работать в соответствии со спецификацией, упомянутой в первом этапе. После того, как система развернута и клиенты начинают использовать разработанную систему следует 3 вида активностей:
○ Исправление ошибок;
○ Обновление;
○ Улучшение.
Объясните преимущество использования модели жизненного цикла разработки ПО (SDLC)
обеспечение основы проекта (методологии, активность…);
обеспечение визуализации хода реализации проекта;
помощь компании в эффективности и успешного завершения проекта (сокращение затрат, уменьшение сроков разработки и тестирования, повышение качества конечного продукта);
уменьшение рисков, связанных с процессом разработки ПО;
обеспечение специальным механизмом отслеживания прогресса проекта
Каковы основные фазы модели жизненного цикла разработки ПО?
Принятия решения (идея) о необходимости создания ПО;
Сбор и анализ требований;
Дизайн (Системы и ПО) на основе требований;
Кодирование на основе дизайна системы;
Тестирование;
Внедрение в пользовательскую среду;
Сопровождение (в том числе фиксация найденных в пользовательской среде ошибок);
Изъятие из эксплуатации (редко);
Объясните, что такое Обеспечение качества (Quality Assurance)?
Обеспечение качества (QA) — это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ПО и предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения требуемого уровня качества выпускаемого продукта.
Обеспечение качества определено в стандарте ISO 9000:2005 «Системы менеджмента качества. Основные положения и словарь» как «часть менеджмента качества, направленная на создание уверенности в том, что требования к качеству будут выполнены».
Менеджмент качества в этом же стандарте представлен как «скоординированная деятельность по руководству и управлению организацией применительно к качеству», а в примечании сказано, что он «обычно включает разработку политики и целей в области качества, планирование качества, управление качеством, обеспечение качества и улучшение качества».
или
Обеспечение качества (Quality Assurance) - Все мероприятия предпринимаемые на разных стадиях жизненного цикла ПО, для обеспеченияего качества. Задача - выстроить систему, которая будет превентивно работать на качество продукта. Организация процесса, чтобы багов возникало меньше.
Объясните, что такое Контроль качества (Quality Control)?
Контроль качества (QC) — это совокупность действий, проводимых над ПО в процессе разработки, для получения информации о его актуальном состоянии в аспектах готовности к выпуску, соответствия зафиксированным требованиям и соответствия заявленному уровню качества этого ПО.
или
Все действия осуществляемые над продуктом в процессе разработки с целью определения его готовности к выпуску, соответствия заданным требования и заявленному уровню качества. Это не только само тестирование, но и проверка его соответствия заранее согласованному уровню качества и готовность выпуска продукта. Основная задача QC предоставить картину того, что происходит с качеством продукта на разных этапах разработки
Объясните, что такое тестирование ПО?
Тестирование ПО — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, и показать, что они подходят для заявленных целей и для определения дефектов.
Какие основные цели тестирования ПО?
Цель тестирования (test objective, test target) — это причина или цель разработки и выполнения теста.
Основные цели:
обеспечить очищения ПО от ошибок (Вы не можете предоставить 100% покрытие, но Вы должны сделать все возможное, и гарантировать, что очевидные ошибки исправлены);
убедить, что ПО отвечает оригинальным требованиям и спецификации;
обеспечить уверенность в ПО (пользователям, заказчикам и т.д.).
Когда следует начинать тестировать ПО?
Простой ответ — как только это возможно! Более детально:
когда тестирование ПО проводится на ранней стадии, вы можете с легкостью повлиять на дизайн, так как его изменение на этой стадии не столь дорогостоящее чем на более поздних стадиях;
в свою очередь, чем раньше обнаруживается ошибка, тем дешевле она стоит компании;
также тестирование может начинаться до фактического получения ПО (статическое тестирование), что действительно немаловажно, так как снижает сложность провождения динамической стадии тестирования. Бытует мнение, что многие ошибки, которые найдены в стадии динамического тестирования, могли и должны были зафиксированные в стадии статического тестирования;
тестирование на ранних стадиях (изучение требований, спецификаций, бизнес случаев и т.д.) обеспечит тестировщику больше знаний о ПО, поможет обнаружить логические и технические ошибки, которые бы влияли на ПО, его конечный дизайн и стоимость.
Когда следует заканчивать тестирование ПО?
Простой ответ — управленческое решение, которое вероятней всего будет принято на основе:
тестового покрытия;
анализа рисков;
ухудшения тестирования.
Какие основные уровни тестирования ПО?
Компонентное (component)/ модульное тестирование (module, unit testing) — это тестирование отдельных компонентов ПО [IEEE 610];
Интеграционное тестирование (integration testing) — это тестирование, выполняемое для обнаружения дефектов в интерфейсах и во взаимодействии между интегрированными компонентами или системами.
Следует также понимать что такое big-bang тестирование, тестирование «сверху вниз», восходящие и инкрементное тестирование;
Системное тестирование (system testing) — это процесс тестирования системы в целом с целью проверки того, что она соответствует установленным требованиям;
Приёмочное тестирование (acceptance testing) — это формальное тестирование по отношению к потребностям, требованиям и бизнес процессам пользователя, проводимое с целью определения соответствия системы критериям приёмки (критерии выхода, которым должны соответствовать компонент или система, для того, чтобы быть принятыми пользователем, заказчиком или другим уполномоченным лицом) [IEEE 610], с чего следуют такие виды, о которых желательно не забывать:
пользовательское приёмочное тестирование (user acceptance testing);
производственное приемочное тестирование (factory acceptance testing) — это приемочное тестирование, проводимое на стороне разработчика программного продукта и проводящееся сотрудниками компании-поставщика с целью определить, соответствует или нет компонент или система как программным, так и аппаратным требованиям;
стороннее приемочное тестирование (site acceptance testing) — это приёмочное тестирование пользователями или заказчиком на своей стороне. Проводится с целью определить как соответствие бизнес-процессу, так и удостовериться, что данная система или компонент удовлетворяет потребностям пользователей или заказчика. Обычно включает в себя проверку как программного обеспечения, так и технической базы;
эксплуатационное приемочное тестирование (operational acceptance testing) — это эксплуатационное тестирование в фазе приемочного тестирования, обычно выполняемое пользователем и/или сотрудниками с администраторским доступом, в рабочей среде (возможно, симулированой), фокусируясь на функциональных аспектах (восстанавливаемость, поведение ресурсов, устанавливаемость и техническое соответствие).
Альфа-тестирование (alpha testing) — это моделируемое или действительное эксплуатационное тестирование потенциальными пользователями/заказчиками или независимой командой тестирования на стороне разработчиков, но вне разрабатывающей организации. Альфа-тестирование часто применяется к коробочному ПО в качестве внутреннего приёмочного тестирования;
Бета-тестирование (beta testing) — это эксплуатационное тестирование потенциальными и/или существующими клиентами/заказчиками на внешней стороне никак не связанными с разработчиками, с целью определения действительно ли компонент или система удовлетворяет требованиям клиента/заказчика и вписывается в бизнес-процессы. Бета-тестирование часто проводится как форма внешнего приёмочного тестирования готового программного обеспечения для того чтобы получить отзывы рынка;
Что такое критерии входа?
Критерии входа (entry criteria) — это набор общих и специфичных условий для продолжения процесса с определенной задачей, например, фаза тестирования. Цель критериев входа — предотвращение начала задачи, которое может потребовать больше (бесполезных) усилий, чем на устранение не пройденных критериев входа.
Проще говоря для Вас, как будущего тестировщика, критерии входа следует понимать как основные условия, которые должны быть выполнены до того, как Вы и Ваша команда могут начать тестирование.
Приведите несколько примеров, которые объясняют критерии входа для тестирования ПО.
все дефекты, которые относятся к ранним стадиям (проектирования) закрыты и проверены;
код проверенный с помощью осуществления «Unit» тестов;
основные функциональные возможности ПО готовы для тестирования;
имеется документация, которая определяет требования;
все тестировщики ознакомлены с архитектурой ПО;
все тестировщики ознакомлены с целями проекта;
готова среда тестирования;
доступные для использования билды;
утверждены план тестирования и/или тестовые случаи.
Что такое критерии выхода?
Критерии выхода (exit criteria) — это набор общих и специфичных условий, согласованных заранее с заинтересованными сторонами, для того, чтобы процесс мог официально считаться завершенным. Цель критериев выхода — предотвращение возможности, когда задание считается завершенным, однако еще существуют отдельные незавершенные части задания. Критерии выхода используются для отчетности, а также планирования того, когда остановить тестирование.
Проще говоря, как критерии входа определяют начало тестирования, так и критерии выхода определяют его окончание и ПО готово к следующему этапу жизненного цикла (внедрение и т.д.).
Приведите несколько примеров, которые объясняют критерии выхода для тестирования ПО.
все заранее предопределенные области ПО как «рисковые» протестированы и такой статус понижен/удален;
все ошибки тщательно задокументированы и доведены менеджменту/акционерам/заказчикам;
все тесты с высоким приоритетом пройдены и соответственно помечены как «Pass»;
все требования документации SRS (Спецификация требований ПО);
STR утверждено собственником проекта;
протестирована архитектура ПО;
ни одна серьезная или критическая ошибки не остаются открытыми;
90-95% всех тестов сделано.