Сочинение на тему TestLog – План тестирования и программное обеспечение для управления тестовыми наборами

<Р> «

Журнал испытаний состоит из:

Требования к клиенту – это список требований, разработанных совместно с клиентом и разработчиком. Этот список требований будет «мерной ручкой», с которой образцы должны пройти приемочные испытания. Эта часть журнала приемочных испытаний будет заполнена разработчиком до собеседования.

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

<Р> Принято? – Это просто столбец «да» или «нет», чтобы быстро увидеть, было ли конкретное рассматриваемое требование проверено клиентом как приемлемый стандарт. Эта часть журнала приемочных испытаний будет завершена разработчиком в течение

.

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

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

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

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

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

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

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

Типичный журнал испытаний будет содержать следующие заголовки:

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

Номер теста – Номер теста должен начинаться с 1 и увеличиваться для каждого НОВОГО теста. Однако, если конкретный тест не пройден, необходимо выполнить повторный тест, и номер теста должен показать это. Как правило, это делается путем добавления буквы или десятичного числа после номера теста, чтобы показать, что это повторное тестирование. Например, если тест № 7 не удался, то следующий тест, повторный тест № 7, должен быть помечен как 7.1, или 7.01, или 7a, что-то подходящее, чтобы показать читателю журнала испытаний, что это повторный тест, а не другой проверить полностью.

Цель теста. Цель теста должна быть кратко объяснена. Например, «Проверить гиперссылку index.html, чтобы связаться с нами». Этот столбец должен быть коротким и приятным, с достаточным количеством информации, чтобы сообщить читателю о том, что тестируется.