как понять что тестирование закончено
Как понять что тестирование закончено
Когда нужно остановить тестирование и нужно ли его останавливать? Полный ли объем информации проработан и все ли учтено? И вообще – есть ли предел совершенству? Эти вопросы актуальны для каждого тестировщика. Так давайте остановимся на минуту и подумаем: в какой момент нужно и можно прервать стремящийся к бесконечности процесс тестирования?
Причина для остановки: «Сроки поджимают! Время – деньги!»
Пример из практики. Вспоминается ситуация, когда из-за жестких сроков пострадало качество продукта. Тестировался интернет-магазин хозтоваров, и вместе с новой акционной скидкой только для зарегистрированных клиентов был внедрен баг: невозможность активировать несколько действующих на тот момент акций. Таким образом, релиз превратился в «релиз плюс еще пару напряженных дней баг-фикса». Наверное, гораздо лучше было подвинуть жесткие рамки на день-два и дать возможность дотестировать новый функционал… но в жизни встречаются разные ситуации.
Вывод. Главной задачей тестировщика в условиях ограниченного времени является охват максимально возможного количества критически важных тест-кейсов (тест-кейсы приоритета high и medium), запись всех найденных дефектов (во избежание их потери из-за времени и текучести задач) и формирование сообщения о реальном объеме проделанных работ. В итоге от тестировщика должна поступить полная картина проверенного и список того, что проверить еще не успели (чтобы в дальнейшем определить фронт работ).
Причина для остановки: «Это не конечная, а промежуточная»
Бывает, что в ходе тестирования нужно сделать вынужденную остановку, так как «что-то» критично блокирует оптимальную оценку тестируемого объекта, и из-за этого в дальнейшем может «протухнуть» вся система проверки. В таком случае лучше остановиться и дождаться решения проблемы.
Пример из практики. Тестировалось довольно крупное медицинское программное обеспечение. На тестовом стенде не было возможности проверить в полном объеме новый функционал (отправку писем клиентам при заполнении формы и данных личного кабинета клиента). Задача была довольно обширной и затрагивала многие аспекты: активацию отдельных разделов при полной загрузке документов, ограничения в доступе к разделам при определенной степени заполнения профиля и другие. На вопрос перед релизом «все ли проверено и можно ли заканчивать тестирование?» однозначный ответ дать было просто невозможно: проверка частично блокировалась из-за невозможности проверить факт получения части писем на тестовой среде. В итоге при релизе на стороне клиента вылезли критические ошибки. Клиенту не поступали нужные уведомительные письма, а потому он не мог получить и полный доступ к своему профилю. Во избежание появления подобных ситуаций было найдено следующее решение: после доработки стали доступны опции отправки и получения писем на тестовом стенде, что позволило в дальнейшем проверять эту часть достаточно важного функционала. Включение этих проверок во все последующие прохождения регресса дало возможность более оптимально оценивать готовность продукта перед выпуском на клиентскую часть.
Вывод. Анализ ошибок позволил сделать верные выводы и устранить все блокирующие моменты. И все-таки, в подобной ситуации работа над оптимизацией средств и инструментов тестирования по итогу уже выявленных ошибок вряд ли может считаться хорошим вариантом. Несомненно, гораздо более уместной и правильной была бы остановка процесса тестирования и доработка изначально неполного функционала тестовой среды для предотвращения появления критических моментов уже на клиентской части.
Причина для остановки: «Стоять нельзя двигаться дальше». Где поставить запятую, и почему возникает неразбериха?»
Пример из практики. Сразу приходит на память довольно распространенный и известный любому тестировщику случай, когда по ходу тестирования обнаруживаются критические баги, а половина тест-кейсов уже проверена, и результаты по ним проставлены. Иногда разработчики стараются настолько быстро исправить ошибку, что «забывают» известить об этом старательного тестировщика, который вовсю спешит пройти все запланированные тест-кейсы с регресса. В итоге тестирование продолжается после исправления (bug-fix) вместо того, чтобы остановить проверку и начать ее заново; часть ошибок уже не будет обнаружена.
Вывод. В таких ситуациях разработчику важно своевременно сообщить о своих исправлениях тестировщику для того, чтобы тот остановил тестирование и повторно прошел тест-кейсы – все или только самые критичные и высокого приоритета (если времени остается не так уж и много). Это поможет избежать в дальнейшем неразберихи в вопросе: а откуда взялись новые дефекты в продукте, и кто за них отвечает?
Причина для остановки: «Поступил приказ отступать!»
Пример из практики. Случалось, что практически полностью протестированный релиз откладывался. Казалось бы, все готово – тщательно протестированы все блоки, сделаны все задачи, – и можно отдавать готовый продукт на радость пользователю, но заказчик вдруг решает, что лучше все сделать совершенно по-другому, а практически уже готовый релиз временно нужно остановить. Минусом такой ситуации является потраченное время тестировщика, плюсом – написанные тест-кейсы, которые могут быть использованы для проверки функционала другого ПО.
Вывод. Для тестировщика в таком случае важно написать качественные тест-кейсы, с которыми можно будет работать в дальнейшем либо на аналогичных задачах, либо (в случае возобновления работы) по отмененному/отложенному релизу.
Причина для остановки: «Все, устал, хватит!»
Пример из практики. На одном из наших проектов «случился» довольно затяжной релиз; мы тестировали его напряженно и активно. Тестирование в моей голове не прекращалось даже во время сна. И в тот момент, когда ошибка оказалась буквально перед моими глазами, явно «сигнализируя» мне в логах, – я ее просто не увидела. В такие моменты нужно уметь сказать себе: «Стой, передохни, а иначе допустишь ошибку, пропустишь баг, внимательность будет на нуле!» А внимательность – это основное качество тестировщика. Конечно, сам процесс нельзя просто взять и остановить, но выделить личное время на отдых – необходимо!
Вывод. В подобных случаях остановка в тестировании – это обязательный и важный момент для тестировщика. Заканчивая работу, нужно обязательно отдохнуть и отвлечься (заняться другим делом, например), дабы избежать «замыливания глаз».
Причина для остановки: «Есть сомнения? Остановись!»
Пример из практики. В моем опыте были ситуация, когда ошибка обнаружилась уже на последних шагах (можно даже сказать, на последних минутах) регрессионного тестирования. Был ли это недочет тестировщика (то есть, мой)? Да, и это стало хорошим «пинком» для дальнейшей работы над своими ошибками. Но баг нужно было искоренять. Задачу «выкинули» из релиза для доработки, сам релиз состоялся довольно успешно. Не забывайте: заказчик скорее оценит качество проверки, чем соблюдения сроков без сохранения качества.
Вывод. Каждый этап процесса тестирования важен. Неверная проработка материала или неполное покрытие задачи тест-кейсами может стать причиной того, что тестировщик упустит важный и критический баг. На каком бы этапе тестирования это не обнаружилось – важно понимать, что в таких случаях необходимо остановиться, оценить ситуацию и принять решение о дальнейшем плане работ!
Причина для остановки: «По моему хотению – остановитесь!»
В тестировании важную роль играет понимание специалистом важности выпускаемого продукта. Плохо, если в человеке присутствует безразличие к итоговому продукту. В таком случае тестирование может остановиться просто потому, что сам процесс надоел тестировщику («и так сойдет!»).
По этому поводу вспоминается старый анекдот:
«Мужчина сшил в ателье костюм. Пришел домой, надел. Жена в ужасе:
– Ты что сшил? Посмотри: один рукав длиннее, другой – короче. Полы у пиджака разные, штанины. Неси все назад!
Муж пошел назад:
– Что вы мне сшили? Посмотрите! Брюки разной длины!
– А вы одну ногу согните в колене, ведь вы не ходите на прямых ногах. И все будет хорошо.
– Смотрите, рукава разной длины!
– Ну и что? Вы же не по швам руки держите. Согните их в локтях. Вот! Прекрасно!
– А полы? Что с ними делать?
– А вы немного набок наклонитесь. Все отлично!
Мужчина вышел в новом костюме. Люди на остановке:
– Смотри, какой урод! А как костюм хорошо сидит!»
Для тестировщика халатное отношение к процессу просто недопустимо. Все недочеты в итоге становятся явными, что в конечном итоге приводит к плачевным результатам.
Пример из практики. У меня и моих коллег, к счастью, таких ситуаций никогда не возникало: мы любим свою работу и с уважением относимся к конечным пользователям (ведь наши ошибки влияют на их опыт взаимодействия с продуктом). Надеюсь, подобного никогда и не случится. Главное – не забывать, что такое возможно, и избегать подобных случаев.
Вывод. Останавливать тестирование лишь по желанию тестировщика нельзя, каждая остановка должна быть обоснована. Решение об остановке процесса будет закономерным лишь в том случае, если оптимально и позитивно пройденным и тщательно проработанным оказывается целый набор параметров: написан полный объем тест-кейсов по задаче, правильно расставлены приоритеты для оценки времени в случае срочных или быстрых проверок, все задачи полностью проанализированы и сверены с техническими требованиями еще на начальных этапах ознакомления, все учтено на этапе планирования релиза.
И наконец… Барабанная дробь… Последняя, но самая желанная причина для остановки: «Готово, можно забирать!»
При начале планирования нового релиза закладывается определенный план тестирования, приоритеты и объемы. Правильное планирование ведет к положительным и качественным результатам. Когда все результаты тестирования полностью удовлетворяют критериям качества, можно смело сказать себе: «Стоп, здесь мы сделали все, что могли!» Но для этого нужно, чтобы все найденные ошибки были исправлены, все запланированные тест-кейсы пройдены (и не обнаружено ни одного бага выше минорного), все необходимые правки выполнены, а результат приемочного тестирования оказался полностью положительным. И так бывает на самом деле! Заказчик в таком случае доволен, а тестировщик может смело выписывать себе «медаль» за хорошую работу. А уж как это настраивает на дальнейшие «подвиги»!
Пример из практики. К примеру, некоторое время назад тестировали обновление сайта бытовой техники. Сайт пользовался и продолжает пользоваться довольно большой популярностью, ответственность за выпускаемый продукт была достаточно высокой. Итогом проведенного релиза стала положительная динамика и улучшение статистики по количеству пользователей, оформивших заказ через интернет. Это, конечно, огромный плюс для заказчика. Главный же показатель удачного релиза для тестировщиков – это продукт, максимально адаптированный под клиента и содержащий минимальное количество ошибок (а может, их там вообще не осталось. ). Остановка тестирования в таком случае вполне закономерна, так как заложена в четко установленных сроках с учетом всех необходимых критериев.
Финал
Подводя итоги, можно сказать, что последний сценарий – это идеальный вариант остановки тестирования: в нем сочетаются верное планирование, детальное тестирование и итоговая положительная приемочная часть. В остальных случаях остановки происходят из-за ошибок тестировщика, по желанию заказчика, недостаточно продуманного плана тестирования, неверного расчета времени или просто из-за лени (кстати, недопустимого в нашей профессии качества).
Поэтому и остановки в таких случаях не влекут за собой того конечного положительного результата, которого всегда хочется добиться. В данной ситуации важно сделать правильные выводы и вычленить причину основной ошибки. Как правило, это неверное планирование времени, боязнь спросить разработчика о готовности исправлений (то есть, плохо налаженное общение между разработчиком и тестировщиком) и халатное написание тест-кейсов из-за неполного ознакомления со спецификациями и требованиями. Выявив слабые места на проекте или в личных качествах, можно приступить к проработке плана дальнейшей более результативной работы.
Для этого всегда необходимо учитывать основные критерии: условия и пожелания заказчика, установленные временные рамки и степень покрытия тест-кейсами требований, указанных и описанных в задаче. Каждый пункт должен быть четко проработан и обговорен как с заказчиком, так и с разработчиком. Тестировщик должен представлять объем работ: какое тестирование можно успеть осуществить в обозначенные сроки, сколько тест-кейсов потребуется, до какого момента допускаются баг-фиксы, когда начинается код фриз и допускает ли найденное количество багов сам выпуск продукта.
Когда следует завершить тестирование?
Начало — половина дела. Это правило приложимо практически к любой сфере деятельности, и даже к тестированию ПО.
Зачастую в начале проекта тестировщики излучают энтузиазм, составляя документацию (стратегия тестирования, план тестирования или тест-кейсы).
Но в дальнейшем нередко возникают сложности. По завершении первого раунда тестирования, тестировщики обычно находят кучу багов, а затем подходят ко второму этапу несколько расслабленными. Имеет место т.н. человеческий фактор и общечеловеческая тенденция, когда становится скучно выполнять повторные операции.
В подобных ситуациях у многих возникает ощущение того, что они делают монотонную работу, и, как следствие, теряется интерес к продолжению тестирования уже знакомого ПО. И во время третьего, примерно, раунда над тестировщиком неумолимо нависает вопрос: «Когда же все-таки нужно прекращать тестирование?»
Каждый тестировщик хотя бы раз задавался таким вопросом, расширенная версия которого выглядела бы так:
«Когда, на каком этапе и как прекращать тестирование?»
Многие тестировщики полагают, что не существует каких-то особых условий, указывающих на то, что тестирование следует завершить. Но чтобы ответить на этот вопрос, придется проанализировать тестовую активность от начала до конца.
Допустим, стоит задача протестировать новый проект.
Тестирование, раунд #1)
Команда тестировщиков приступает к тестированию, как только ей передают только что созданный программный продукт.
На этапе тестирования тестировщики выполняют различные сценарии, пытаясь взломать ПО и обнаружить дефекты. (Поскольку приложение новое и проходит оценку впервые, показатель обнаруженных дефектов будет сравнительно высоким).
Разработчики устраняют дефекты и возвращают разработку тестировщикам для повторного теста.
Тестировщики проводят проводят проверку на предмет наличия дефектов, затем переходят к регрессионному тестированию.
Как только серьезные дефекты устранены и ПО демонстрирует стабильную работу, команда разработчиков выпускает следующую версию.
Тестирование, раунд #2)
Тестировщики начинает второй раунд тестирования и повторяют то, что выполнялось во время первого раунда.
Во время этого процесса, как правило, обнаруживаются еще некоторые дефекты.
Дефекты устраняются разработчиками и приложение вновь отправляется на проверку.
Тестировщики проводят повторные тесты и регрессионное тестирование тех частей разработки, которые не претерпели изменения.
Это можно продолжать до бесконечности. Раунд 3, 4, 5… до тех пор, пока программное обеспечение совершенно не очистится от багов.
Графически этот процесс можно изобразить следующим образом:
Но представляется ли теоретически возможным найти абсолютно все дефекты? Это вопрос на миллион долларов, но попробуем на него ответить.
Большинство приложений устроены сложно, оттого фронт их тестирования достаточно большой. Не то чтобы обнаружить абсолютно все дефекты совсем невозможно, но для этого понадобится вечность.
Даже после того, как большинство багов в ПО найдены, никто не сможет с уверенностью заявить, что приложение стало безупречным.
Более того, такая задача не стоит. Цель тестирование ПО — убедиться, что оно функционально и работает так, как запланировано. Достигается это за счет попыток взлома или поиска отклонений от ожидаемого поведения.
У приложений может быть бесконечное множество дефектов, и проводить тестирование ПО до полного их устранения непрактично. Никогда не знаешь, какой из багов окажется последним.
А если «прекращение тестирования, после полного устранения дефектов» теперь не является критерием, тогда из чего же следует исходить?
Попытаемся разобраться, какие факторы следует считать наиболее важными?
Решение о прекращении тестирования обычно зависит от времени (которое есть в распоряжении), бюджета и необходимой продолжительности тестирования.
Чаще всего решение завершить тестирование принимается, когда закончилось время/бюджет, или же когда все тестовые сценарии выполнены. Но это компромиссное решение, которое может быть в ущерб качеству.
Допустим, необходимо протестировать программный модуль, на эту работу выделен определенный бюджет. Время: 1 месяц. Общее количество тестовых сценариев: 200.
Первая неделя: Вы добились успеха — в первый же день нашли дефект Show Stopper. Но тестирование остановилось на 3 дня. Проверять другие сценарии вы не можете, пока не будет устранен обнаружившийся баг. Потеряв время, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев и найдено еще несколько опасных багов.
Неделя 2: Вы начинаете тестирование, тщательно выискиваете дефекты. За вторую неделю находите несколько багов 1-го, 2-го и 3-го уровня критичности. За это время удалось проверить 70 сценариев.
Неделя 3: К началу третьей недели все дефекты с высоким приоритетом устранены, но теперь к выполнению текущих сценариев добавляется еще и перепроверка ранее обнаруженных багов. За третью неделю вы охватили 120 сценариев, и нашли еще несколько багов. Теперь остается искать только дефекты третьего порядка.
Неделя 4: К началу четвертой недели необходимо перепроверить дефекты и 80 оставшихся сценариев. К концу недели вы проверили 180 сценариев; все дефекты с высоким приоритетом были устранены и протестированы повторно.
Данные о проведенном тестировании помещаются в таблицу:
Может этого уже достаточно?
Время, отведенное на тестирование, истекло. Вы нашли и устранили ряд дефектов первого уровня. Если на этом остановиться, можно ли будет считать разработанное ПО надежным? Не совсем, в силу некоторых причин:
Неделя 1: Вы находите дефект первого уровня в первый день тестирования. И тестирование откладывается на 3 дня. Потеряв три дня, вы вновь приступаете к работе.
К концу недели проверено 20 сценариев, найдено еще несколько опасных дефектов.
Результаты первой недели аналогичны примеру #1.
Неделя 2: За вторую неделю вы находите несколько багов 1-го, 2-го и 3-го уровня критичности. Но теперь задача — охватить как можно больше сценариев. Как итог, 120 сценариев к концу недели.
Неделя 3: К началу третьей недели все приоритетные дефекты устранены, и теперь, помимо текущих сценариев, необходимо перепроверить ранее обнаруженные дефекты. За третью неделю вы охватили 200 сценариев, и нашли еще ряд багов.
Теперь вы может сообщить только о дефектах второго и третьего уровня.
Данные о проведенном тестировании:
Этого достаточно?
Вы охватили полностью все сценарии тестирования, нашли еще несколько дефектов. Если на этом остановиться, можно ли будет считать ПО надежным?
Как можно видеть, оба сценария не гарантируют качества. Лучше всего в такой ситуации попытаться найти золотую середину, использовать такой подход, который бы учитывал все лучшие особенности из первого и второго сценариев. Для этого понадобится определить ряд критериев.
Критерии завершения или выхода
Критерий выхода позволяет установить, какой объем тестирования следует считать достаточным. Определяется он по завершении цикла тестирования и включается в план. Это набор условий или активностей, которые должны быть выполнены, чтобы тестирование можно было назвать законченным.
Что включает в себя критерий выхода?
В идеале это комбинация нескольких факторов, уникальных для всех проектов. Все зависит от требований конкретного проекта. Поэтому во время планирования целесообразнее подсчитать как можно больше параметров.
Ниже приведены некоторые нюансы, которые стоит учитывать во время функционального или системного тестирования. Вы можете составить определенную комбинацию или же использовать все эти факторы, чтобы определить, когда именно следует завершить тестирование.
Тестирование может быть завершено когда:
Охват теста:
(Общее число успешных текст-кейсов / общее число тест-кейсов ) * 100.
Сроки:
Срок, отведенный на тестирование, истек.
Документация по тестированию:
Вся документация по тестированию, подлежащая сдаче (например, отчет о тестировании), подготовлена, проверена и передана.
Бюджет:
И в заключение, пожалуйста, ответьте на несколько вопросов
Если большинство ответов окажутся утвердительными, это будет означать, что вы можете завершить тестирование. Если большинство ответов будут отрицательными, тогда придется искать, что было упущено.
Обзор частых вопросов по тестированию ПО на собеседованиях и ответы на них
Главная цель данной статьи – помочь преодолеть страх, который возникает у тестировщиков ПО (как начинающих, так и опытных) к предстоящему интервью в связи с незнанием грядущего.
Второстепенная цель – собрать воедино основные вопросы, которые, вероятней всего, будут заданы на собеседовании. Как у начинающего тестировщика, у меня уже скопился определенный опыт подготовки к собеседованиям на данную должность, и я могу заметить, что даже специализированные 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. Пожалуйста, обратите внимание, что это всего лишь перечень вопросов составленный на основе моего опыта (он не будет уникальным для всех интервью), а запоминание ответов как истинных может помешать вам работать в индустрии. Целью является помочь вам понять основные вопросы, с которыми вы предположено столкнетесь во время собеседования.
Призываю к активному и обоснованному холивару!