Глава 6
А один из результатов планирования у нас выглядит примерно так:
Альбом: office
Я добрался до 6-го чаптера.
Ура-ура.
Слово Канеру
Глава 6 Документирование тестирования
Обзор
Мы написали эту главу, чтоб помочь вам изучить требования к тестовой документации. Мы не дадим примеров документации (См. главу 3, техники тестирования, примеры матриц и таблиц). Вместо этого зададим вопросы, которые помогут вам решить, что вам нужно.
Эта глава начинается с детальной оценки стандарта IEEE 829 Документация тестирования программного обеспечения. Мы понимаем, что вы никогда не читали и даже не слышали об этом стандарте - IEEE продает стандарт по достаточно высокой цене, вероятно, чтоб убедить не покупать копии. Мы видели достаточно людей, имеющих собственную копию стандарта 829. Немного наших клиентов или работодателей покупали IEEE стандарты. Тем не менее многие шаблоны документации тестирования близки или являются производными от стандарта IEEE 829. Таким образом, даже не зная название стандарта, просто работая в поле некоторое время, вы столкнетесь с IEEE 829
Если вы еще не сталкивались со стандартом 829 и не заинтересованы в шаблонах документации тестирования, мы рекомендуем вам перейти сразу к Lesson 147 Проанализируйте требования перед тем, как решить, как вы будете создавать продукт. Это правило в той же степени относится к документации, как и к программе.
Последний документ, учреждающий Стандарт 829 это Software Engineering Body of Knowledge, который мы здесь и будем обсуждать.
Мы процитировали Software Engineering Body of Knowledge (SWEBOK Version 0.95, 2001) в предисловии. Подробней об этом мы будем говорить в главе 10 Ваша карьера в тестировании ПО. В этой главе мы описываем SWEBOK с позиции документирования тестирования.
Документация тестирования и рабочий продукт
Документация является неотъемлимой частью формализации процесса тестирования. Стандарт IEEE для тестовой документации ПО [829] дает описание тестовых документов, их взаимосвязей друг с другом и с процессом тестирования. Тестовые документы, кроме всего прочего, включают план тестирования, описание архитектуры тестирования, описание процедур тестирования, описание тестовых сценариев, логи тестов, протоколы инцидентов или сообщений об ошибках.
Тестируемая программа с указанной версией и зафиксированными требованиями к началу тестирования, документируется как предмет тестирования. Тестовая документация должна создаваться и постоянно обновляться по тем же стандартам, что и остальная документация продукта.
Мы попытались разработать стиль документации, подобный IEEE 829, также мы видели результаты усилий нескольких компаний в нескольких отраслях. Мы не были довольны результатами. На самом деле, по нашему опыту, от стандарта 829 больше вреда, чем пользы.
Причиной нашего разочарования от стандарта 829 является беды, которые нажили себе группы тестирования, пытаясь им следовать. Группа за группой создавали тест-план на основе шаблонов 829, за ним следовали другие бесполезные документы. Сначала мы думали, что проблема в том, что люди неправильно следуют стандартам. Позже мы пришли к выводу, что проблема глубже, так как стандарт был широко распостранен и попал к людям, которых мы уважали.
Паттерн (или анти-паттерн), заключается в том, что группа тестирования будет создавать или брать готовый шаблон и тратить много времени на большое количество изначально малоинформативных документов. Затем группы осознают расходы на такие документы, связанные с ними ограничения и постепенно отказываются от них. Это заставило многие группы заниматься только ad hoc тестированием, так как они растратили свое время и бюджеты на составление документов, которые они все равно не будут использовать.
Отказ от усилий не означает публичный отказ от выполнения работы; как правило, они просто молча прекращали читать и обновлять такого рода документы. Если вы спросите их о тестовой документации, то они, вероятно, выдадут большой объем бумаг (которые никто не читал и не обновлял). Несколько компаний проходили через этот цикл раз за разом, надеясь сделать лучше в следующий раз, обвиняя себя в том, что они что-то делают неправильно.
Проблема не в том, что они неправильно исполняли стандарт 829.
Проблема в том, что стандарт 829 - это неправильный путь удовлетворения потребностей этих комапаний.
Альбом: office
Я добрался до 6-го чаптера.
Ура-ура.
Слово Канеру
Глава 6 Документирование тестирования
Обзор
Мы написали эту главу, чтоб помочь вам изучить требования к тестовой документации. Мы не дадим примеров документации (См. главу 3, техники тестирования, примеры матриц и таблиц). Вместо этого зададим вопросы, которые помогут вам решить, что вам нужно.
Эта глава начинается с детальной оценки стандарта IEEE 829 Документация тестирования программного обеспечения. Мы понимаем, что вы никогда не читали и даже не слышали об этом стандарте - IEEE продает стандарт по достаточно высокой цене, вероятно, чтоб убедить не покупать копии. Мы видели достаточно людей, имеющих собственную копию стандарта 829. Немного наших клиентов или работодателей покупали IEEE стандарты. Тем не менее многие шаблоны документации тестирования близки или являются производными от стандарта IEEE 829. Таким образом, даже не зная название стандарта, просто работая в поле некоторое время, вы столкнетесь с IEEE 829
Если вы еще не сталкивались со стандартом 829 и не заинтересованы в шаблонах документации тестирования, мы рекомендуем вам перейти сразу к Lesson 147 Проанализируйте требования перед тем, как решить, как вы будете создавать продукт. Это правило в той же степени относится к документации, как и к программе.
Последний документ, учреждающий Стандарт 829 это Software Engineering Body of Knowledge, который мы здесь и будем обсуждать.
Мы процитировали Software Engineering Body of Knowledge (SWEBOK Version 0.95, 2001) в предисловии. Подробней об этом мы будем говорить в главе 10 Ваша карьера в тестировании ПО. В этой главе мы описываем SWEBOK с позиции документирования тестирования.
Документация тестирования и рабочий продукт
Документация является неотъемлимой частью формализации процесса тестирования. Стандарт IEEE для тестовой документации ПО [829] дает описание тестовых документов, их взаимосвязей друг с другом и с процессом тестирования. Тестовые документы, кроме всего прочего, включают план тестирования, описание архитектуры тестирования, описание процедур тестирования, описание тестовых сценариев, логи тестов, протоколы инцидентов или сообщений об ошибках.
Тестируемая программа с указанной версией и зафиксированными требованиями к началу тестирования, документируется как предмет тестирования. Тестовая документация должна создаваться и постоянно обновляться по тем же стандартам, что и остальная документация продукта.
Мы попытались разработать стиль документации, подобный IEEE 829, также мы видели результаты усилий нескольких компаний в нескольких отраслях. Мы не были довольны результатами. На самом деле, по нашему опыту, от стандарта 829 больше вреда, чем пользы.
Причиной нашего разочарования от стандарта 829 является беды, которые нажили себе группы тестирования, пытаясь им следовать. Группа за группой создавали тест-план на основе шаблонов 829, за ним следовали другие бесполезные документы. Сначала мы думали, что проблема в том, что люди неправильно следуют стандартам. Позже мы пришли к выводу, что проблема глубже, так как стандарт был широко распостранен и попал к людям, которых мы уважали.
Паттерн (или анти-паттерн), заключается в том, что группа тестирования будет создавать или брать готовый шаблон и тратить много времени на большое количество изначально малоинформативных документов. Затем группы осознают расходы на такие документы, связанные с ними ограничения и постепенно отказываются от них. Это заставило многие группы заниматься только ad hoc тестированием, так как они растратили свое время и бюджеты на составление документов, которые они все равно не будут использовать.
Отказ от усилий не означает публичный отказ от выполнения работы; как правило, они просто молча прекращали читать и обновлять такого рода документы. Если вы спросите их о тестовой документации, то они, вероятно, выдадут большой объем бумаг (которые никто не читал и не обновлял). Несколько компаний проходили через этот цикл раз за разом, надеясь сделать лучше в следующий раз, обвиняя себя в том, что они что-то делают неправильно.
Проблема не в том, что они неправильно исполняли стандарт 829.
Проблема в том, что стандарт 829 - это неправильный путь удовлетворения потребностей этих комапаний.