Как определить что тестирование закончено

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

Согласно стандарту ANSI / IEEE 1059, тестирование можно определить как: процесс анализа элемента программного обеспечения для обнаружения различий между существующими и требуемыми условиями (дефектами / ошибками / ошибками) и для оценки характеристик элемента программного обеспечения.

Кто проводит тестирование?

Различные компании имеют разные обозначения для людей, которые тестируют программное обеспечение на основе их опыта и знаний, таких как Software Tester, Software Quality Assurance Engineer, QA Analyst и т. д.

Невозможно протестировать программное обеспечение в любое время в течение его цикла. Следующие два раздела указывают, когда тестирование должно быть начато и когда его завершить во время SDLC.

Когда начинать тестирование?

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

Это также зависит от используемой модели разработки. Например, в модели «Водопад» формальное тестирование проводится на этапе тестирования; но в инкрементной модели тестирование выполняется в конце каждого приращения / итерации, и все приложение тестируется в конце.

Тестирование выполняется в разных формах на каждой фазе SDLC:

Когда прекращать тестирование?

Трудно определить, когда прекратить тестирование, поскольку тестирование является бесконечным процессом, и никто не может утверждать, что программное обеспечение проверено на 100%. Для прекращения процесса тестирования необходимо учитывать следующие аспекты:

Проверка и проверка

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

Источник

Критерии выхода, завершения тестирования (Exit criteria). Когда остановиться тестировать?

Критерии завершения тестирования это один из часто задаваемых вопросов на собеседованиях на должность тестровщика ПО. Давайте разберем какие же основные факторы влияют на принятие решения о завершении тестирования тестировщиком.

Часто новички в тестировании отвечают на данный вопрос — буду тестировать пока не найду все баги 🙂
А возможно ли это? Нет конечно, никто не может гарантировать отсутствие багов, даже если это приложение было протестировано несколькими опытными тестировщиками. Исчерпывающие тестирование невозможно и об этом гласит один из принципов тестирования

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

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

3) Все тест кейсы пройдены, найденные баги исправлены и перепроверены — Для того чтобы протестировать приложение, тестировщик для начала должен ознакомиться с требованиями, функциональными спецификациями к приложению, если они конечно есть, или узнать со слов заказчика какое поведение должно быть при разных сценариях использования приложения или фитчи. Затем заняться составлением тестовой документации — написанием тест кейсов, написать тест план если нужно, покрывая весь функционал и требования к приложению. Также обсудить и решить в команде или самостоятельно не требуется ли проводить нефункциональное тестирование, такое как нагрузочное тестирование (Performance and Load Testing), тестирование удобства пользовавия (Usability Testing) и т.д. Так как у каждого приложения есть «узкие места», на которые следует обратить внимание при тестировании. Далее начать выполнять, проходить тест кейсы и в момент, когда все тест кейсы пройдены и найденные баги исправлены и перепроверены, можно завершать тестирование.

Источник

Как определить что тестирование закончено

1. Основы тестирования

1.1 Почему тестирование необходимо

1.1.1 Системный контекст программного обеспечения

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

1.1.2 Причины дефектов в программном обеспечении

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

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

1.1.3. Роль тестирования в разработке программного обеспечения, сопровождении и функционировании программного обеспечения

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

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

1.1.4 Тестирование и качество

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

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

Тестирование также является деятельностью по обеспечению качества (наравне с разработкой стандартов, обучением и анализом дефектов).

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

Для принятия решения о достаточном объеме тестирования, необходимо принимать во внимание уровень рисков, включая технические риски, риски безопасности и бизнес риски, а так же проектные ограничения, такие как время и бюджет. Риски обсуждаются далее в модуле 5.

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

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

Если система была протестирована и только несколько дефектов были найдены, какой мы можем сделать вывод о состоянии системы?

а. Система может быть без дефектов, но тестирование не может гарантировать, что это правда. b. Система без дефектов, и дальнейшие испытания, таким образом, будут пустой тратой ресурсов. c. Это зависит от того, для чего предназначена система. d. Следует рассмотреть вопрос о дальнейшем тестировании, но это должно быть сосредоточено на областях наибольшего риска, поскольку не будет возможности проверить все. e. Тестирование должно быть свернуто, потому что оно не дает никакой ценности.

1.2 Что такое тестирование

Бытует мнение, что тестирование состоит только из прогона тестов, то есть выполнения самой программы. Но это только часть тестирования, и далеко не все, что в него входит.

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

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

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

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

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

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

Какое из следующих утверждений НАИЛУЧШИМ ОБРАЗОМ подходит в качестве цели для команды тестирования?

Какое утверждение лучше всего описывает роль тестирования?

Какое из нижеследующих утверждений верно?

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

Какие из следующих утверждений, как правило, верны для тестирования?

a. Тестирование может показать наличие дефектов.
b. Тестирование увеличивает вероятность обнаружения дефектов.
c. Тестирование может показать, что ранее присутствовавший дефект был удален.
d. Тестирование может доказать, что программное обеспечение без дефектов.

1.3 Семь принципов тестирования

Эти принципы тестирования были предложены в последние 40 лет и являются общим руководством для тестирования в целом.

Принцип 1 – Тестирование демонстрирует наличие дефектов.

Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.

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

Принцип 2 – Исчерпывающее тестирование недостижимо

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

Принцип 3 – Раннее тестирование

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

Принцип 4 – Скопление дефектов

Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.

Принцип 5 – Парадокс пестицида

Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокс пестицида”, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.

Принцип 6 – Тестирование зависит от контекста

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

Принцип 7 – Заблуждение об отсутствии ошибок.

Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

Какое из следующих утверждений НАИЛУЧШИМ ОБРАЗОМ описывает один из семи ключевых принципов тестирования программного обеспечения?

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

1.4 Основной процесс тестирования

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

Основной процесс тестирования состоит из следующих направлений деятельности:

Несмотря на логическую последовательность, действия в процессе могут накладываться друг на друга или происходить одновременно. Для конкретных системы и проекта обычно требуется адаптация этих направлений деятельности.

1.4.1 Планирование и управление тестированием

Планирование тестирования –- это действия, направленные на определение целей тестирования и описание задач тестирования для достижения этих целей и миссии.

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

Планирование тестирования учитывает данные, полученные при проверке и управлении.

1.4.2 Анализ и проектирование тестов

Для анализа и проектирования тестов поставлены следующие основные задачи:

1.4.3 Реализация и выполнение тестов

Для реализации и выполнения тестов поставлены следующие основные задачи:

1.4.4 Оценка критериев выхода и отчетность

Для оценки критериев выхода поставлены следующие основные задачи:

1.4.5 Действия по завершению тестирования

Действия по завершению тестирования собирают данные о завершенных испытаниях для объединения опыта, тестового обеспечения, фактов и цифр.

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

Для действий по завершению тестирования поставлены следующие основные задачи:

Какая из этих задач должна быть выполнена на стадии Анализа и Проектирования основного процесса тестирования?

На каком из этапов фундаментального процесса тестирования настраивается тестовая среда?

Во время какой деятельности Фундаментального процесса тестирования вы определяете критерии выхода?

Поместите этапы фундаментального процесса тестирования в обычном порядке (по времени).

a. Действия по завершению тестирования.
b. Анализ и проектирование.
c. Планирование и контроль.
d. Реализация и исполнение.
e. Оценка критериев выхода и отчетность.

В приведенном ниже перечне (a-e) описывается одна основная задача для каждого из пяти основных видов деятельности в рамках Фундаментального процесса тестирования. В каком варианте задачи стоят в правильном порядке по времени?

а. Создать двунаправленную трассируемость между базисом тестирования и тестовыми случаями.
b. Проверка тестовых журналов на критерии выхода.
c. Определение цели тестирования.
d. Проверка, что запланированные результаты были достигнуты.
e. Сравнение фактических результатов с ожидаемыми результатами.

1.5 Психология тестирования

В этом уроке рассмотрены предположение об ошибках, независимость

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

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

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

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

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

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

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

Однако есть несколько способов улучшить коммуникации и отношения между тестировщиками и другими коллегами:

Какой из следующих подходов, определений или действий приведет к проблемам (или конфликту) в смешанных командах тестировщиков и разработчиков во время ревизий и тестирования?

Участие в тестировании программного обеспечения позволяет людям узнать конфиденциальную и секретную информацию. Одной из причин, зачем необходим кодекс этики, является необходимость гарантировать, что не будет утечки информации. Признавая кодекс этики для инженеров Ассоциации по вычислительной технике (ACM) и Института инженеров по электротехнике и радиоэлектронике (IEEE), ISTQB заявляет о следующем кодексе этики:

ОБЩЕСТВО – Сертифицированные тестировщики программного обеспечения должны действовать согласно интересам общества

КЛИЕНТ И РАБОТОДАТЕЛЬ – Сертифицированные тестировщики программного обеспечения должны действовать согласно интересам клиента и работодателя, если они не противоречат интересам общества.

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

ОЦЕНКИ – Сертифицированные тестировщики программного обеспечения должны поддерживать целостность и независимость своих профессиональных оценок.

УПРАВЛЕНИЕ – Сертифицированные руководители тестирования программного обеспечения и ведущие специалисты должны присоединяться и продвигать этические подходы к управлению тестированием программного обеспечения.

ПРОФЕССИЯ – Сертифицированные тестировщики программного обеспечения должны поднимать престиж и репутацию своей профессии в интересах общества.

КОЛЛЕГИ – Сертифицированные тестировщики программного обеспечения должны быть справедливыми, оказывать поддержку своим коллегам, и содействовать сотрудничеству с разработчиками программного обеспечения.

ЛИЧНАЯ ОТВЕТСТВЕННОСТЬ – Сертифицированные тестировщики программного обеспечения должны постоянно учиться навыкам своей профессии и способствовать продвижению этического подхода к своей деятельности.

Какие из следующих утверждений ВЕРНЫ?

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

Какое из следующих высказываний корректно описывает разницу между тестированием и отладкой?

Источник

Обзор частых вопросов по тестированию ПО на собеседованиях и ответы на них

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

Второстепенная цель – собрать воедино основные вопросы, которые, вероятней всего, будут заданы на собеседовании. Как у начинающего тестировщика, у меня уже скопился определенный опыт подготовки к собеседованиям на данную должность, и я могу заметить, что даже специализированные QA форумы не справляются с этой целью, а может и не ставят ее перед собой вообще.

Перечень вопросов разумеется не окончательный и не претендует на образцовость, а выступает лишь своеобразным ориентиром при подготовке специалистов с тестирования ПО.

Собственно вопросы:

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

Обеспечение качества определено в стандарте ISO 9000:2005 «Системы менеджмента качества. Основные положения и словарь» как «часть менеджмента качества, направленная на создание уверенности в том, что требования к качеству будут выполнены».

Менеджмент качества в этом же стандарте представлен как «скоординированная деятельность по руководству и управлению организацией применительно к качеству», а в примечании сказано, что он «обычно включает разработку политики и целей в области качества, планирование качества, управление качеством, обеспечение качества и улучшение качества».

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

Из этого определения становится понятно, что тестирование ПО включает в себя два различных процесса:
Валидация (validation): доказанное объективными результатами исследования подтверждение того, что требования для конкретного определенного использования приложения были выполнены. [ISO 9000]
Верификация (verification): доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены. [ISO 9000]

Цель тестирования (test objective, test target) — это причина или цель разработки и выполнения теста.

Следует также понимать что такое big-bang тестирование, тестирование «сверху вниз», восходящие и инкрементное тестирование;

Критерии входа (entry criteria) — это набор общих и специфичных условий для продолжения процесса с определенной задачей, например, фаза тестирования. Цель критериев входа — предотвращение начала задачи, которое может потребовать больше (бесполезных) усилий, чем на устранение не пройденных критериев входа.

Проще говоря для Вас, как будущего тестировщика, критерии входа следует понимать как основные условия, которые должны быть выполнены до того, как Вы и Ваша команда могут начать тестирование.

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

Проще говоря, как критерии входа определяют начало тестирования, так и критерии выхода определяют его окончание и ПО готово к следующему этапу жизненного цикла (внедрение и т.д.).

Реальный вопрос, на который мы ищем ответ: строим ли мы продукт правильно?

Процесс верификации (verification) выполняется, чтобы убедиться, что каждый этап жизненного цикла разработки ПО (разработка, тестирование и т.д.) строится на основе предопределенных требований (requirements) и спецификаций (specifications) и без каких-либо отклонений от них. (см. № 7)

Реальный вопрос, на который мы ищем ответ: строим ли мы правильный продукт?

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

Помните, валидация охватывает динамическую сторону тестирования, где определенное ПО тестируется и оценивается вопреки заданной SRS документации.

Отладка (debugging) — это процесс поиска, анализа, и устранения причин отказов и ошибок в ПО.

Эмуляция — это воспроизведение работы программы или системы (а не какой-то её мизерной части) с сохранением ключевых её свойств и принципов работы. Эмуляция выполняет программный код в привычной для этого кода среде, состоящей из тех же компонентов, что и эмулируемый объект.

Симуляция — это воспроизведение работы программы-оригинала сугубо виртуально, на движке специальной программы (средство разработки курсов, к примеру). Симуляция лишь имитирует выполнение кода, а не копирует его, всё виртуально на 100%, всё «понарошку».

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

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

Симулятор по полноте функций/учитываемых параметров уже, чем эмулятор. Эмулируется объект, а симулируются его свойства, функции или поведение.

Спецификация (specifications) — это текстовый файл с описанием того, что нужно протестировать в тестовых данных. В ней указывается какие результаты должна получить программа. Тестовый код находит реальные, вычисленные на живом коде результаты. А тестовый движок производит сверку спецификации и вычисленных результатов.

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

Кодирование (coding) — это процесс написания программного кода, скриптов, с целью реализации определённого алгоритма на определённом языке программирования.

Некоторые путают такие понятия, как программирование и непосредственно кодирование. Кодирование является лишь частью программирования, наряду с анализом, проектированием, компиляцией, тестированием и отладкой, сопровождением (В узких кругах кодирование также может называться «кодинг». Однако, если верить Вики, в литературе этот термин используется редко.).

Требование (requirement) — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.

Требования могут выражаться в виде текстовых утверждений и графических моделей.

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

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

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

Приоритет (priority) — это степень важности, присваиваемая багу. Другими словами определяется, насколько срочно это ошибка должна быть исправлена.

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

Драйвер (driver) — это компонент ПО или средство тестирования, которое заменяет компонент, обеспечивающий управление и/или вызов компонента или системы.

Обвязка (harness) — это тестовое окружение, включающее в себя заглушки и драйверы, необходимые для проведения теста.

Для измерения покрытия требований, необходимо проанализировать требования к продукту и разбить их на пункты. Опционально каждый пункт связывается с тест кейсами, проверяющими его. Совокупность этих связей — и является матрицей трассировки (traceability matrix). Проследив связи, можно понять какие именно требования проверяет тестовый случай.

Тесты не связанные с требованиями не имеют смысла. Требования, не связанные с тестами — это «белые пятна», т.е. выполнив все созданные тест кейсы, нельзя дать ответ реализовано данное требование в продукте или нет.

End-to-end тестирование — это тип тестирования где тестировщик использует ПО (сценарии, которые исследуют весь поток выполнения) в условиях которыми вероятней всего обладает пользователь.

Функциональное тестирование (functional testing) — это тестирование, основанное на анализе спецификации функциональности компонента или системы.

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) иприемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.

Белый ящик — это тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.

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

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

Спасибо за внимание и удачи в ваших начинаниях!

P.S. Пожалуйста, обратите внимание, что это всего лишь перечень вопросов составленный на основе моего опыта (он не будет уникальным для всех интервью), а запоминание ответов как истинных может помешать вам работать в индустрии. Целью является помочь вам понять основные вопросы, с которыми вы предположено столкнетесь во время собеседования.

Призываю к активному и обоснованному холивару!

Источник