Слово Канеру
Не используйте шаблоны документации тестирования: шаблон не поможет, если вы в нем не нуждаетесь
Шаблон документации тестирования не заменит навык в работе.
Шаблон это структура для создания документа. Заполните пробелы или секции и вы получите документ.
Проблема шаблонов в том, что они позволяют написать бессмысленный документ, который хорошо выглядит. Для некоторых людей это плюс. Но, чтоб использовать шаблон для написания документации к тестированию вы должны владеть темой. Вы должны понимать, что значит каждая секция шаблона, зачем она в нем вообще и в каком случае она может быть удалена. Если ты знаешь все это — тебе не нужен шаблон. Если не знаешь - не связывайся с шаблонами. Они поведут тебя в непродуктивном направлении, так как ты не понимаешь все требования и компромиссы, которые автор шаблона сбалансировал в своем сознании.
Мы видели ряд организаций, котторые создавали шаблоны для своих нужд, но использовали их неэффективно и непродуктивно. Человек, использующий шаблон, должен быть способен адаптировать его к текущим требованиям.
Если ты можешь написать эффективную документацию тестирования, не используя шаблоны, то ты обнаружишь, что шаблон позволяет писать ее быстрее.
вторник, 31 июля 2012 г.
Lesson 142
Как понять, что мне надоело работать тестировщиком и пора переквалифицироваться в токари?
Слово Канеру
Чтоб эффективно применить решение, необходимо ясно понимать проблему.
Нигде этот принцип не очевиден так, как в использовании и злоупотреблении документацией тестирования. Соответственно, мы перечислили в уроках точки зрения каждой их сторон дискуссии о стандартах документации тестирования. Мы надеемся, что вы будете думать в первую очередь о проблеме, которую документ должен решить, а затем использовать соответствующую форму.
Слово Канеру
Чтоб эффективно применить решение, необходимо ясно понимать проблему.
Нигде этот принцип не очевиден так, как в использовании и злоупотреблении документацией тестирования. Соответственно, мы перечислили в уроках точки зрения каждой их сторон дискуссии о стандартах документации тестирования. Мы надеемся, что вы будете думать в первую очередь о проблеме, которую документ должен решить, а затем использовать соответствующую форму.
суббота, 28 июля 2012 г.
Глава 6
А один из результатов планирования у нас выглядит примерно так:
Я добрался до 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 — это неправильный путь удовлетворения потребностей этих комапаний.
среда, 25 июля 2012 г.
Lesson 141
Слово Канеру
У вас может быть больше инструментов для тестирования, чем вы предполагаете
Секундомер — пример замечательного инструмента тестирования. Измерение отклика системы — важная часть тестирования. Секундомер прост в использовании, гибок и точен. Некоторые программисты и тестировщики могут подумать, что автоматизированный подход, с помощью вызова системного времени, лучше, но секундомер — лучший выбор для измерения времени работы черного ящика. Мы рекомендуем держать его под рукой.
Инструмент тестирования не обязательно должен быть помечен как «Инструмент тестирования». Тестировщики обнаружили десятки полезных инструментов. Вот некоторые из них:
Инструмент создания образов диска Позволяет быстро восстановить систему в нужное состояние.
Менеджер зависимостей Отображает динамический библиотеки, используемые приложением.
Файловый сканер Предоставляет список измененных файлов в системе
Монитор памяти Отслеживание использования памяти
Инструменты создания макросов Позволяют легко воспроизвести определенные действия.
«Маленькие языки», такие как Sed, Awk, Grep, and Diff Эти инструменты позволяют легко автоматически редактировать файлы, вывод процессов, искать данные, искать различия. Изначально разработанные для Unix, теперь они доступны для большинства платформ.
Многие системные утилиты и базовые средства программирования также удовлетворяют требованиям инструмента тестирования. Кроме того, они часто продаются по разумным ценам.
Вы могли бы найти массу позезных бесплатных, условно бесплатных и cheapware программ в сети. Несколько полезных программ доступны на http://www.zdnet.com, http://www.pcmagazine.com, http://www.cnet.com, http://www.qadownloads.com, и http://www.softpanorama.org. Elisabeth Hendrickson собирает коллекцию полезных инструментов по ссылке http://www.bughunting.com (с. также Hendrickson 2001b).
У вас может быть больше инструментов для тестирования, чем вы предполагаете
Секундомер — пример замечательного инструмента тестирования. Измерение отклика системы — важная часть тестирования. Секундомер прост в использовании, гибок и точен. Некоторые программисты и тестировщики могут подумать, что автоматизированный подход, с помощью вызова системного времени, лучше, но секундомер — лучший выбор для измерения времени работы черного ящика. Мы рекомендуем держать его под рукой.
Инструмент тестирования не обязательно должен быть помечен как «Инструмент тестирования». Тестировщики обнаружили десятки полезных инструментов. Вот некоторые из них:
Инструмент создания образов диска Позволяет быстро восстановить систему в нужное состояние.
Менеджер зависимостей Отображает динамический библиотеки, используемые приложением.
Файловый сканер Предоставляет список измененных файлов в системе
Монитор памяти Отслеживание использования памяти
Инструменты создания макросов Позволяют легко воспроизвести определенные действия.
«Маленькие языки», такие как Sed, Awk, Grep, and Diff Эти инструменты позволяют легко автоматически редактировать файлы, вывод процессов, искать данные, искать различия. Изначально разработанные для Unix, теперь они доступны для большинства платформ.
Многие системные утилиты и базовые средства программирования также удовлетворяют требованиям инструмента тестирования. Кроме того, они часто продаются по разумным ценам.
Вы могли бы найти массу позезных бесплатных, условно бесплатных и cheapware программ в сети. Несколько полезных программ доступны на http://www.zdnet.com, http://www.pcmagazine.com, http://www.cnet.com, http://www.qadownloads.com, и http://www.softpanorama.org. Elisabeth Hendrickson собирает коллекцию полезных инструментов по ссылке http://www.bughunting.com (с. также Hendrickson 2001b).
вторник, 24 июля 2012 г.
Lesson 140
За неделю написал 3 кейса и один тест.
Черт побери планирования, настройки CI, фиксирования требований, предсказание загрузки и мониторинг процесса... совсем не успеваю поработать.
Как там писал Сирил? Еще шаг и вот он, мой уровень некомпетентности. Или он уже тут?
Кот компетентен и спит.
Слово Канеру
Автоматизируйте то, что принесет быстрый результат
Очень многие люди считают, что автоматизация тестирования означает автоматизацию ручного тестирования. В результате ставится чрезмерный акцент на автоматизацию GUI тестирования.
Вместо того, чтоб думать о сценариях тестирования, найдите висящие низко плоды, которые позволят быстро повысить эффективность работы. Сфокусируйтесь на задачах, которые дадут максимальный эффект при минимальных усилиях. Вот несколько хороших стартовых точек:
Установка и предстартовая настройка системы Новые тестировщики часто бывают удивлены количеством времени, которое они тратят на установку и конфигурирование системы для подготовки ее к тестированию. Эта работа может быть автоматизирована. Образы дисков позволяют быстро сбросить систему к стандартным настройкам. Это могут быть скрипты установки. Тестовые данные могут быть быть загружены автоматически с помощью обычных инструментов программирования.
Помощь в диагностике Некоторые баги сложно воспроизвести. Дефекты связанные с нарушением целостности данных или утечками памяти, как правило, не могут быть обнаружены, пока данные доступны и память не переполнена. Инструменты диагностики позволят обнаружить такие дефекты, когда они случаются. Аналогично, доступны инструменты для тестирования памяти, а создание инструментов для проверки целостности данных и памяти вашего приложения не очень сложная задача. Работайте с программистами проекта. Они уже могут использовать такие инструменты сами.
Запись сессий Качественное сообщение об ошибке требует наличия полной информации о конфигурации. Программы могут собирать и предоставлять необходимую информацию автоматически. Также такие записи можно использовать для проверки того, что система настроена как нужно.
Генерация тестов Используйте техники автоматизации для генерации входных данных (Lesson 129).
Вам не нужно автоматизировать тест от начала до конца. В первую очередь получите от автоматизации реальную помощь в тестировании. Это поможет затем построить сложные комплексные решения.
Черт побери планирования, настройки CI, фиксирования требований, предсказание загрузки и мониторинг процесса... совсем не успеваю поработать.
Как там писал Сирил? Еще шаг и вот он, мой уровень некомпетентности. Или он уже тут?
Кот компетентен и спит.
 |
| Альбом: cat |
Слово Канеру
Автоматизируйте то, что принесет быстрый результат
Очень многие люди считают, что автоматизация тестирования означает автоматизацию ручного тестирования. В результате ставится чрезмерный акцент на автоматизацию GUI тестирования.
Вместо того, чтоб думать о сценариях тестирования, найдите висящие низко плоды, которые позволят быстро повысить эффективность работы. Сфокусируйтесь на задачах, которые дадут максимальный эффект при минимальных усилиях. Вот несколько хороших стартовых точек:
Установка и предстартовая настройка системы Новые тестировщики часто бывают удивлены количеством времени, которое они тратят на установку и конфигурирование системы для подготовки ее к тестированию. Эта работа может быть автоматизирована. Образы дисков позволяют быстро сбросить систему к стандартным настройкам. Это могут быть скрипты установки. Тестовые данные могут быть быть загружены автоматически с помощью обычных инструментов программирования.
Помощь в диагностике Некоторые баги сложно воспроизвести. Дефекты связанные с нарушением целостности данных или утечками памяти, как правило, не могут быть обнаружены, пока данные доступны и память не переполнена. Инструменты диагностики позволят обнаружить такие дефекты, когда они случаются. Аналогично, доступны инструменты для тестирования памяти, а создание инструментов для проверки целостности данных и памяти вашего приложения не очень сложная задача. Работайте с программистами проекта. Они уже могут использовать такие инструменты сами.
Запись сессий Качественное сообщение об ошибке требует наличия полной информации о конфигурации. Программы могут собирать и предоставлять необходимую информацию автоматически. Также такие записи можно использовать для проверки того, что система настроена как нужно.
Генерация тестов Используйте техники автоматизации для генерации входных данных (Lesson 129).
Вам не нужно автоматизировать тест от начала до конца. В первую очередь получите от автоматизации реальную помощь в тестировании. Это поможет затем построить сложные комплексные решения.
пятница, 20 июля 2012 г.
Lesson 139
Сегодня хороший день.
Мне нравится.
На днях мы перевалили за четыре сотни тестов, прошел один из самых веселых PR, меня и группу не выселят из кабинета, в понедельник из квартиры убирается кошка.
Ок, чо.
Слово Канеру
Дайте централизованной команде автоматизаторов ясные установки
Многие компании создают централизованные команды автоматизированного тестирования, поддерживающие несколько групп тестирования продуктов. Часто это является мудрым решением.
Если вы находитесь в такой команде, убедитесь, что у вас есть четкое описание того, какого рода помочь вы оказываете, какие запросы получаете и каким образом будете учитывать противоречивые требования. Это важно, так как команды, которые не могут решить свои проблемы в меньшей степени способны извлечь выгоды из автоматизации. Гораздо проще попросить помощи в автоматизации, которая является техническим скиллом, чем признаться, что они нуждаются в помощи по организации их работы, которую, скорее всего, они могут делать и сами.
Мы считаем, что вам нужно работать с командами, которые могут выделить сотрудников для работы с вами над проектом автоматизации. Это может дать ряд преимуществ:
- Вы сможете оценить свои обязательства и их актуальные проблемы
- Подготовив такого сотрудника вы уменьшите требования к вам по обслуживанию и анализу отказов
- Работая вместе с людьми, которым нужны ваши услуги, вы пишете требования к тестам с самого начала работы над проектом
В централизованной группе автоматизации у вас есть небольшая группа программирования с прямым доступом к людям, которые просят об услугах. Читайте Beck (1999) и Jeffries и соавт. (2000).
Мне нравится.
На днях мы перевалили за четыре сотни тестов, прошел один из самых веселых PR, меня и группу не выселят из кабинета, в понедельник из квартиры убирается кошка.
Ок, чо.
Слово Канеру
Дайте централизованной команде автоматизаторов ясные установки
Многие компании создают централизованные команды автоматизированного тестирования, поддерживающие несколько групп тестирования продуктов. Часто это является мудрым решением.
Если вы находитесь в такой команде, убедитесь, что у вас есть четкое описание того, какого рода помочь вы оказываете, какие запросы получаете и каким образом будете учитывать противоречивые требования. Это важно, так как команды, которые не могут решить свои проблемы в меньшей степени способны извлечь выгоды из автоматизации. Гораздо проще попросить помощи в автоматизации, которая является техническим скиллом, чем признаться, что они нуждаются в помощи по организации их работы, которую, скорее всего, они могут делать и сами.
Мы считаем, что вам нужно работать с командами, которые могут выделить сотрудников для работы с вами над проектом автоматизации. Это может дать ряд преимуществ:
- Вы сможете оценить свои обязательства и их актуальные проблемы
- Подготовив такого сотрудника вы уменьшите требования к вам по обслуживанию и анализу отказов
- Работая вместе с людьми, которым нужны ваши услуги, вы пишете требования к тестам с самого начала работы над проектом
В централизованной группе автоматизации у вас есть небольшая группа программирования с прямым доступом к людям, которые просят об услугах. Читайте Beck (1999) и Jeffries и соавт. (2000).
четверг, 19 июля 2012 г.
Lesson 138
Хорошо иметь тестеру опыт работы в техподдержке.
Вот у нас поздновечер, ряд программистов по домам.
Вдруг бида-бида, а менеджер говорит, что таки ой.
И тут я весь в черном и сером, с паролями, доступами и почими ssh из прошлой жизни запомненными, а также с навыками поднять, развернуть и мала-мала промигрировать.
Показываю, значит, так мол и так. Приятно осознавать свою нужность.
Хм. Все тот же гребаный лейтмотив...
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
Слово Канеру
Заблаговременно начинайте автоматизацию
Автоматизация — это сложная работа, требующая планирование, исследования и проектирования. Если вы планируете большое количество автоматических тестов, начинайте создавать их, пока продукт еще только проектируется. Вам часто придется быть свидетелем решения вопросов, влияющих на эффективность автоматизации. Сложно предсказать заранее, решения по тестируемости часто являются результатом проб и ошибок.
Программисты более открыты для вопросов тестируемости на ранних этапах создания приложения. Фичи легче добавить, пока дизайн гибок и находится в движении. Программист и руководитель проекта может поставить их в план и выделить на них бюджет. Неопределенность будущего дизайна мотивирует программистов помогать тестированию; меньше давление на программистов, если они знают, насколько хорошо будет проверяться их код.
Некоторые тест-менеджеры не стартуют так рано, но продолжают надеяться, что они успеют наверстать упущенное позже. Мы обнаружили, что чем позже начинается автоматизация, тем она сложнее. Вот ряд причин:
- Когда тестирование в самом разгаре, сложно отвлекать ресурсы на автоматизацию
- Когда тестировщики и процессы уже сориентированы на ручное тестирование, они сопротивляются переменам
- После того как архитектура стабилизируется, программисты становятся менее склонны к сотрудничеству в отношении требований тестируемости.
Если ты ждешь успешной автоматизации — не тяни. Тем не менее, мы настоятельно рекомендуем не пытаться автоматизировать все с самого начала. Заранее создайте инфраструктуру, но будьте разумны в выборе тестов для автоматизации.
Вот у нас поздновечер, ряд программистов по домам.
Вдруг бида-бида, а менеджер говорит, что таки ой.
И тут я весь в черном и сером, с паролями, доступами и почими ssh из прошлой жизни запомненными, а также с навыками поднять, развернуть и мала-мала промигрировать.
Показываю, значит, так мол и так. Приятно осознавать свою нужность.
Хм. Все тот же гребаный лейтмотив...
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
I must not lie. I must gain worth. I must not lie. I must gain worth.
Слово Канеру
Заблаговременно начинайте автоматизацию
Автоматизация — это сложная работа, требующая планирование, исследования и проектирования. Если вы планируете большое количество автоматических тестов, начинайте создавать их, пока продукт еще только проектируется. Вам часто придется быть свидетелем решения вопросов, влияющих на эффективность автоматизации. Сложно предсказать заранее, решения по тестируемости часто являются результатом проб и ошибок.
Программисты более открыты для вопросов тестируемости на ранних этапах создания приложения. Фичи легче добавить, пока дизайн гибок и находится в движении. Программист и руководитель проекта может поставить их в план и выделить на них бюджет. Неопределенность будущего дизайна мотивирует программистов помогать тестированию; меньше давление на программистов, если они знают, насколько хорошо будет проверяться их код.
Некоторые тест-менеджеры не стартуют так рано, но продолжают надеяться, что они успеют наверстать упущенное позже. Мы обнаружили, что чем позже начинается автоматизация, тем она сложнее. Вот ряд причин:
- Когда тестирование в самом разгаре, сложно отвлекать ресурсы на автоматизацию
- Когда тестировщики и процессы уже сориентированы на ручное тестирование, они сопротивляются переменам
- После того как архитектура стабилизируется, программисты становятся менее склонны к сотрудничеству в отношении требований тестируемости.
Если ты ждешь успешной автоматизации — не тяни. Тем не менее, мы настоятельно рекомендуем не пытаться автоматизировать все с самого начала. Заранее создайте инфраструктуру, но будьте разумны в выборе тестов для автоматизации.
вторник, 17 июля 2012 г.
Lesson 137
«Путь меча» оок. «Я возьму сам» на очереди. Разыскивается «Дайте им умереть» в мп3.
Кабирский цикл в частности и Олди вообще рекомендую.
Дюже годный цикл.
Слово Канеру
Тестируемость это прозрачность и контроль
Любые фичи, позволяющие наблюдать и контролировать ПО улучшают тестируемость. Люди часто просят у нас список таких фич. Вот наш список:
Доступ к исходному коду Многие компании не позволяют тестировщикам изменять исходный код. Тем не менее, вы можете по-прежнему просматривать исходный код. Это особенно важно для просмотра изменений в системе контроля версий.
Логирование Лог сообщений об ошибках, источники ошибок, профили использования, утилизация ресурсов и протоколы связей. Разрешите настройку различных уровней логирования. Механизмы логирования, возможно, уже присутствуют в компонентах вашей системы. Программисты используют их при отладке. Вы могли бы использовать их, чтоб быстрее обнаружить ошибки быстрее, проанализировать ошибку, получить более подробную информацию, оценить покрытие тестами, собрать информацию о использовании ПО клиентами и узнать больше о программе, которую вы тестируете (DiMaggio 2000, Johnson 2001 и Marick 2000).
Диагностика Диагностика может предупредить вас о потенциальных проблемах. Проверки — это первый пример. Проверка целостности данных убедит вас в том, что внутренние данные системы непротиворечивы. Встроенные в код проверки удостоверяют нас, что программа не была переписана или изменена. Проверки памяти проверяют, что память используется согласно распределению. Это может быть мощным инструментом в сочетании с логированием, позволяющим войти в режим отладки или снять дамп памяти при обнаружении ошибки (Kaner 2000b).
Эмуляция ошибки Ваш продукт имеет внутренние состояния, многие из коотрых труднодостижимы, особенно если их нужно систематически воспроизводить. Многие состояния с ошибками — такого типа. Ваше ПО должно быть в состоянии восстановиться после ошибок медиаконтента, нехватки памяти или места в хранилище, задержек сети или дисконнекта и тому подобных проблем. Вам может быть достаточно сложно найти условия для воспроизведения таких ошибок. Триггеры ошибочных состояний могут быть размещены на самом низком уровне продукта для облегчения тестирования и обработки ошибок (Также существуют инструменты для эмуляции подобных ошибок извне продукта (Houlihan, 2001)).
Контрольные точки Разрешите проверку или изменение данных в определенных точках работы системы (Cohen 2000).
Триггеры событий Уведомления о том, что внутренние задачи стартовали или завершились могут помочь синхронизировать тесты.
Чтение устаревших форматов данных Форматы данных могут изменяться несколько раз, пока продукт находится в разработке. Обеспечьте средство для конвертирования данных в новый формат, чтоб не создавать данные заново.
Интерфейсы тестирования Программные интерфейсы — основа тестируемости. Несколько продуктов, в действительности, добавили программные интерфейсы именно по этой причине.
Поддержка пользовательских контролов Поддержка инструментов тестирования через GUI — вероятно, одна из наиболее востребованных функций тестируемости.
Разрешение нескольких экземпляров Разрешите запуск нескольких клиентов или агентов на одном компьютере, даже если это не поддерживается. Это может позволить тестировщикам моделировать большие сети в небольшой лаборатории.
Многие продукты имеют недокументированные фичи тестируемости, которые программисты добавили, чтоб помочь своим тестировщикам. Спросите о них.
Noel Nyman говорит: «Два инструмента Windows используются, чтоб помочь найти ошибки в памяти. (1) Fill buffers with known patterns when they're initialized. Это поможет выявить утечки, дикие указатели и т.д.. (2) Put buffers at the end of allocated heap and work backwards into the heap. Это вызывает переполнение буфера и появления онка Window's с сообщением об ошибке».
В одном проекте встроенного ПО Kaner и Hoffman обнаружили, что группой разработки было написано более 1100 диагностических команд для проверки состояний программы и устройства. Все они были доступны и тестировщикам. Тестировщикам нужно было посто выстроить соответствующие команды для создания теста.
Кабирский цикл в частности и Олди вообще рекомендую.
Дюже годный цикл.
Слово Канеру
Тестируемость это прозрачность и контроль
Любые фичи, позволяющие наблюдать и контролировать ПО улучшают тестируемость. Люди часто просят у нас список таких фич. Вот наш список:
Доступ к исходному коду Многие компании не позволяют тестировщикам изменять исходный код. Тем не менее, вы можете по-прежнему просматривать исходный код. Это особенно важно для просмотра изменений в системе контроля версий.
Логирование Лог сообщений об ошибках, источники ошибок, профили использования, утилизация ресурсов и протоколы связей. Разрешите настройку различных уровней логирования. Механизмы логирования, возможно, уже присутствуют в компонентах вашей системы. Программисты используют их при отладке. Вы могли бы использовать их, чтоб быстрее обнаружить ошибки быстрее, проанализировать ошибку, получить более подробную информацию, оценить покрытие тестами, собрать информацию о использовании ПО клиентами и узнать больше о программе, которую вы тестируете (DiMaggio 2000, Johnson 2001 и Marick 2000).
Диагностика Диагностика может предупредить вас о потенциальных проблемах. Проверки — это первый пример. Проверка целостности данных убедит вас в том, что внутренние данные системы непротиворечивы. Встроенные в код проверки удостоверяют нас, что программа не была переписана или изменена. Проверки памяти проверяют, что память используется согласно распределению. Это может быть мощным инструментом в сочетании с логированием, позволяющим войти в режим отладки или снять дамп памяти при обнаружении ошибки (Kaner 2000b).
Эмуляция ошибки Ваш продукт имеет внутренние состояния, многие из коотрых труднодостижимы, особенно если их нужно систематически воспроизводить. Многие состояния с ошибками — такого типа. Ваше ПО должно быть в состоянии восстановиться после ошибок медиаконтента, нехватки памяти или места в хранилище, задержек сети или дисконнекта и тому подобных проблем. Вам может быть достаточно сложно найти условия для воспроизведения таких ошибок. Триггеры ошибочных состояний могут быть размещены на самом низком уровне продукта для облегчения тестирования и обработки ошибок (Также существуют инструменты для эмуляции подобных ошибок извне продукта (Houlihan, 2001)).
Контрольные точки Разрешите проверку или изменение данных в определенных точках работы системы (Cohen 2000).
Триггеры событий Уведомления о том, что внутренние задачи стартовали или завершились могут помочь синхронизировать тесты.
Чтение устаревших форматов данных Форматы данных могут изменяться несколько раз, пока продукт находится в разработке. Обеспечьте средство для конвертирования данных в новый формат, чтоб не создавать данные заново.
Интерфейсы тестирования Программные интерфейсы — основа тестируемости. Несколько продуктов, в действительности, добавили программные интерфейсы именно по этой причине.
Поддержка пользовательских контролов Поддержка инструментов тестирования через GUI — вероятно, одна из наиболее востребованных функций тестируемости.
Разрешение нескольких экземпляров Разрешите запуск нескольких клиентов или агентов на одном компьютере, даже если это не поддерживается. Это может позволить тестировщикам моделировать большие сети в небольшой лаборатории.
Многие продукты имеют недокументированные фичи тестируемости, которые программисты добавили, чтоб помочь своим тестировщикам. Спросите о них.
Noel Nyman говорит: «Два инструмента Windows используются, чтоб помочь найти ошибки в памяти. (1) Fill buffers with known patterns when they're initialized. Это поможет выявить утечки, дикие указатели и т.д.. (2) Put buffers at the end of allocated heap and work backwards into the heap. Это вызывает переполнение буфера и появления онка Window's с сообщением об ошибке».
В одном проекте встроенного ПО Kaner и Hoffman обнаружили, что группой разработки было написано более 1100 диагностических команд для проверки состояний программы и устройства. Все они были доступны и тестировщикам. Тестировщикам нужно было посто выстроить соответствующие команды для создания теста.
суббота, 14 июля 2012 г.
Lesson 136
Мы с бойцами организовали шахматный турнир, посему опрос, для интересу:
Слово Канеру
Тестируемость продукта часто является лучшей инвестицией, чем автоматизация.
Во многих случаях тесты можно поддержать улучшением тестируемости (поддержка тестов в продукте, обеспечивающая контроль и отображение объектов). Некоторые примеры:
- После установки продукта пользователям (или тестировщикам) приходится искать в логе ошибки установки, если таковые появились. Как можно автоматизировать эту проверку? Первая мысль — написать скрипт, который ищет в логе установки возможные ошибки. Вторая неплохая идея заключается в интеграции такой проверки в продукт. Возможно, это улучшит тестируемость и принесет выгоду пользователям.
- Тестировщикам необходимо сэмулировать ошибки на ленте бекапов ПО, чтоб поверить корректность восстановления из бекапа. Скорее всего, потребуется эмулятор накопителя на магнитной ленте. Вместо этого тестировщики могут работать с программистами, чтоб на низком уровне создать некорректные записи на ленту.
- Проверки значений в коде, которые сигнализируют об ошибке, если значение некорректно. Проверки могут быть помещены непосредственно в код приложения и проводиться до тестирования. Это часто поще и эффективней, чем писать внешний код для проверки приложения.
Слово Канеру
Тестируемость продукта часто является лучшей инвестицией, чем автоматизация.
Во многих случаях тесты можно поддержать улучшением тестируемости (поддержка тестов в продукте, обеспечивающая контроль и отображение объектов). Некоторые примеры:
- После установки продукта пользователям (или тестировщикам) приходится искать в логе ошибки установки, если таковые появились. Как можно автоматизировать эту проверку? Первая мысль — написать скрипт, который ищет в логе установки возможные ошибки. Вторая неплохая идея заключается в интеграции такой проверки в продукт. Возможно, это улучшит тестируемость и принесет выгоду пользователям.
- Тестировщикам необходимо сэмулировать ошибки на ленте бекапов ПО, чтоб поверить корректность восстановления из бекапа. Скорее всего, потребуется эмулятор накопителя на магнитной ленте. Вместо этого тестировщики могут работать с программистами, чтоб на низком уровне создать некорректные записи на ленту.
- Проверки значений в коде, которые сигнализируют об ошибке, если значение некорректно. Проверки могут быть помещены непосредственно в код приложения и проводиться до тестирования. Это часто поще и эффективней, чем писать внешний код для проверки приложения.
пятница, 13 июля 2012 г.
Lesson 135
Слово Канеру
Избегайте автоматизаторов не уважающих тестирование
Некоторые программисты смотрят на тестирование как на работу со слишком низким статусом для их способностей. Мы видели как таких программистов назначали на работу в тестировании. Они, естественно, стремились к автоматизации тестирования, в которой, как они были убеждены, они блеснут, раз они такие замечательные программисты.
Увидев сложность труда тестировщиков, у них пропадает стимул сделать тесты лучше. Вместо этого они ищут какие-то пути, чтоб сделать работу интересней, быстрее с помощью автоматизации и принимаются за разработку инструментов сомнительной ценности. Или они перепроектируют багтрекер, или создают модный GUI для запуска тестов — что угодно, чтоб избежать настоящего тестирования.
Мы не видели, что из этого получилось, мы не знаем, как эффективно использовать таких людей, мы советуем по возможности избегать их. Если это невозможно, убедитесь, что они не создают проблем остальным членам команды. Может, вам удастся перевести их на техническую поддержку (Не забудьте потребовать от соседнего ведомства печенек за оказание такой важной и оперативной поддержки).
Избегайте автоматизаторов не уважающих тестирование
Некоторые программисты смотрят на тестирование как на работу со слишком низким статусом для их способностей. Мы видели как таких программистов назначали на работу в тестировании. Они, естественно, стремились к автоматизации тестирования, в которой, как они были убеждены, они блеснут, раз они такие замечательные программисты.
Увидев сложность труда тестировщиков, у них пропадает стимул сделать тесты лучше. Вместо этого они ищут какие-то пути, чтоб сделать работу интересней, быстрее с помощью автоматизации и принимаются за разработку инструментов сомнительной ценности. Или они перепроектируют багтрекер, или создают модный GUI для запуска тестов — что угодно, чтоб избежать настоящего тестирования.
Мы не видели, что из этого получилось, мы не знаем, как эффективно использовать таких людей, мы советуем по возможности избегать их. Если это невозможно, убедитесь, что они не создают проблем остальным членам команды. Может, вам удастся перевести их на техническую поддержку (Не забудьте потребовать от соседнего ведомства печенек за оказание такой важной и оперативной поддержки).
Lesson 134
It was a very good... week.
Яростно запиливали лютое количество тестов, тестирование в ветках, тестирование до, после и во время коммита.
Лейтмотив - кто будет тестировать тесты
Лучи добра разработчикам ci jenkins.
Технические средства решают организационные проблемы.
Лучи неясного назначения разработчикам плагинов Git Plugin и Promoted Builds Plugin.
Переключение в одном workspace между ветками git невнятно работает без вайпа.
А сборки after-Promoted почему-то не признаются за дочерние, хотя кровь от крови же.
От жары спасаюсь в офисе. От отключения воды на районе - тоже в офисе, у нас внезапно есть душ, у нас круто, идите работать к нам, дада.
Выяснилось, что я не в восторге от кошек. А кошки и их хозяйки меня вполне себе недолюбливают, обходят стороной и всячески опасаются.
Так что в свое время буду заводить собаку, ведь все псы попадают в рай, ага?
Слово Канеру
Остерегайтесь автоматизаторов, не понимающих тестирования.
Автоматизация требует программистов. Какого вида программисты вам нужны?
Многие программисты думают, что они много знают о тестировании. Если они не очень безответственны, они часто проверяют свой код и считают, что должны проверить чужой, который они используют. Они знают много о тестировании, если, конечно, не считать человека, который фокусирует всю свою энергию на тестировании. Кого-нибудь вроде вас!
С точки зрения тестировщика, многие программисты на самом деле не очень много знают о тестировании ПО (как и большинство тестировщиков немного понимает в программировании). То, что они знают, часто основано на их собственном коде. Они переоценивают стратегии, соответствующие их собственным особенностям работы. Люди, понимающие требования к тестированию, обеспечат лучшие входные данные и качественней проведут анализ.
Отсутствие у программистов знаний в тестировании становится серьезной проблемой в сочетании с презрением, которое некоторые программисты испытывают к тестировщикам. Это связано с пренебрежительным мнением, что тестировщики недостаточно информированы о ПО в целом. Таким образом, программисты могут создать автоматизацию, которая довольно серьезно отличается от того, что было предложено или ожидалось. Чтоб защититься от этого планируйте ревью кода автоматизации тестирования. Программисты могут не полностью понимать новые требования. Они используют общую стратегию, которая заключается в том, чтоб написать программу, затем исправить ее на основе обратной связи. С учетом неопределенности и путаницы, которая часто наблюдается в требованиях и других запросах, эта стратегия вполне понятна.
Опасность возникает, когда такая стратегия используется для автоматизации тестирования. Не делайте ошибку, считая, что запуск теста покажет, работает ли он. Некоторые ошибки в тестах вызывают их падение, такие вы сможете найти и исправить. Другие позволят тестам пройти, хотя они должны были бы сработать и вы об этом никогда не узнаете. Используйте ревью, стратегии проектирования и тестирование для защиты от этого.
Некоторые ответственные программисты способны понять, что они не знают достаточно о тестировании, когда они работают на проекте автоматизации. Они могут замедлиться, давая себе возможность учиться. Вместо этого, мы призываем их двигаться вперед начиная с пилотных проектов и используя ревью кода тестировщиками. Или перевести их в тестирование, чтоб они могли узнать потребности тестировщиков из первых рук.
Яростно запиливали лютое количество тестов, тестирование в ветках, тестирование до, после и во время коммита.
Лейтмотив - кто будет тестировать тесты
Лучи добра разработчикам ci jenkins.
Технические средства решают организационные проблемы.
Лучи неясного назначения разработчикам плагинов Git Plugin и Promoted Builds Plugin.
Переключение в одном workspace между ветками git невнятно работает без вайпа.
А сборки after-Promoted почему-то не признаются за дочерние, хотя кровь от крови же.
От жары спасаюсь в офисе. От отключения воды на районе - тоже в офисе, у нас внезапно есть душ, у нас круто
Выяснилось, что я не в восторге от кошек. А кошки и их хозяйки меня вполне себе недолюбливают, обходят стороной и всячески опасаются.
Так что в свое время буду заводить собаку, ведь все псы попадают в рай, ага?
Слово Канеру
Остерегайтесь автоматизаторов, не понимающих тестирования.
Автоматизация требует программистов. Какого вида программисты вам нужны?
Многие программисты думают, что они много знают о тестировании. Если они не очень безответственны, они часто проверяют свой код и считают, что должны проверить чужой, который они используют. Они знают много о тестировании, если, конечно, не считать человека, который фокусирует всю свою энергию на тестировании. Кого-нибудь вроде вас!
С точки зрения тестировщика, многие программисты на самом деле не очень много знают о тестировании ПО (как и большинство тестировщиков немного понимает в программировании). То, что они знают, часто основано на их собственном коде. Они переоценивают стратегии, соответствующие их собственным особенностям работы. Люди, понимающие требования к тестированию, обеспечат лучшие входные данные и качественней проведут анализ.
Отсутствие у программистов знаний в тестировании становится серьезной проблемой в сочетании с презрением, которое некоторые программисты испытывают к тестировщикам. Это связано с пренебрежительным мнением, что тестировщики недостаточно информированы о ПО в целом. Таким образом, программисты могут создать автоматизацию, которая довольно серьезно отличается от того, что было предложено или ожидалось. Чтоб защититься от этого планируйте ревью кода автоматизации тестирования. Программисты могут не полностью понимать новые требования. Они используют общую стратегию, которая заключается в том, чтоб написать программу, затем исправить ее на основе обратной связи. С учетом неопределенности и путаницы, которая часто наблюдается в требованиях и других запросах, эта стратегия вполне понятна.
Опасность возникает, когда такая стратегия используется для автоматизации тестирования. Не делайте ошибку, считая, что запуск теста покажет, работает ли он. Некоторые ошибки в тестах вызывают их падение, такие вы сможете найти и исправить. Другие позволят тестам пройти, хотя они должны были бы сработать и вы об этом никогда не узнаете. Используйте ревью, стратегии проектирования и тестирование для защиты от этого.
Некоторые ответственные программисты способны понять, что они не знают достаточно о тестировании, когда они работают на проекте автоматизации. Они могут замедлиться, давая себе возможность учиться. Вместо этого, мы призываем их двигаться вперед начиная с пилотных проектов и используя ревью кода тестировщиками. Или перевести их в тестирование, чтоб они могли узнать потребности тестировщиков из первых рук.
суббота, 7 июля 2012 г.
среда, 4 июля 2012 г.
Lesson 133
Как все таки прекрасно, что вокруг много людей добрее и умнее меня.
Прям хорошо. Прям совсем-совсем.
Гы.
Слово Канеру
Поощряйте разработку наборов unit тестов.
Unit тесты сфокусированы на мельчайших единицах программного комплекса функциях, классах, методах которые создают программисты. Большинство менеджеров ожидают, что их программисты пишут unit тесты и большинство программистов утверждают, что они их пишут. На практике все очень по-разному и часто трудно узнать правду.
Настоящие unit тесты тестируют объекты изолированно. Заглушки создаются для обработки исходящих вызовов, драйверы — чтоб генерировать входящие. Создание таких заглушек может стоить значительных усилий.
Более популярная форма автоматизированного unit тестирования позволяет избежать создания заглушек путем тестирования объектов в контексте. Мы могли бы назвать это интеграционным unit тестированием. Для систем, создающихся «снизу вверх» эта форма автоматизации может быть достаточно легкой.
Вы будете нуждаться в строительных леса, такие как Junit и Xunit, для выполнения тестовых наборов. Это не слишком сложно или дорого. Код тестируется через обычный вызов интерфейсов, который поддерживают языки. Программисты пишут unit тесты на том же языке, что и продукт. Тесты для Java пишутся на Java, для С на С. Используй unit тесты для регрессионного тестирования, smoke тестирования и конфигурационного тестирования.
Мы против того, чтоб указывать программистам, что им делать. Но если менеджеры просят больше автоматизировать тестирование, то они должны знать много способов, которыми программисты и тестировщики могут им помочь. Если программисты заинтересованы в unit тестировании, предложите им свою помощь. Unit тестирования рассматривается как основная практика экстремального программирования и других гибких методов (Beck 1999 and Beck et al. 2001).
Прям хорошо. Прям совсем-совсем.
Гы.
Слово Канеру
Поощряйте разработку наборов unit тестов.
Unit тесты сфокусированы на мельчайших единицах программного комплекса функциях, классах, методах которые создают программисты. Большинство менеджеров ожидают, что их программисты пишут unit тесты и большинство программистов утверждают, что они их пишут. На практике все очень по-разному и часто трудно узнать правду.
Настоящие unit тесты тестируют объекты изолированно. Заглушки создаются для обработки исходящих вызовов, драйверы — чтоб генерировать входящие. Создание таких заглушек может стоить значительных усилий.
Более популярная форма автоматизированного unit тестирования позволяет избежать создания заглушек путем тестирования объектов в контексте. Мы могли бы назвать это интеграционным unit тестированием. Для систем, создающихся «снизу вверх» эта форма автоматизации может быть достаточно легкой.
Вы будете нуждаться в строительных леса, такие как Junit и Xunit, для выполнения тестовых наборов. Это не слишком сложно или дорого. Код тестируется через обычный вызов интерфейсов, который поддерживают языки. Программисты пишут unit тесты на том же языке, что и продукт. Тесты для Java пишутся на Java, для С на С. Используй unit тесты для регрессионного тестирования, smoke тестирования и конфигурационного тестирования.
Мы против того, чтоб указывать программистам, что им делать. Но если менеджеры просят больше автоматизировать тестирование, то они должны знать много способов, которыми программисты и тестировщики могут им помочь. Если программисты заинтересованы в unit тестировании, предложите им свою помощь. Unit тестирования рассматривается как основная практика экстремального программирования и других гибких методов (Beck 1999 and Beck et al. 2001).
суббота, 30 июня 2012 г.
Так
http://bormor.livejournal.com/713165.html
ЧСХ, бгг.
И да, моя бабушка рассказывала сказки о шайтане.
ЧСХ, бгг.
И да, моя бабушка рассказывала сказки о шайтане.
пятница, 29 июня 2012 г.
Lesson 132
Чтоб оценить, насколько яростно у нас все происходит — из последнего:
Выставили на всех серверах непрерывной интеграции в /etc/postgresql/9.1/main/postgresql.conf параметр
fsync=off
Слово Канеру
Автоматизируйте тесты используя программные интерфейсы.
В настоящее время многие продукты имеют программные интерфейсы (публичное API), которое может быть использовано для тестирования. Другие продукты, могут иметь скрытые API, которые могут быть открыты, если вы попросите. Просите.
Открытый API документируется как часть продукта. Они сильно не меняются и эта стабильность делает их привлекательными для автоматизации тестирования. Закрытый API может быть очень полезен, но необходимо выяснить, насколько он подвержен изменениям.
Не зная о подобных альтернативах, многие автоматизаторы фокусируются на видимой части ПО — на GUI. С сожалению, часто это самый сложный интерфейс для автоматизации. Практически любой программный интерфейс проще, надежней и стабильней. В предыдущих лекциях мы обсуждали некоторые проблемы, связанные с автоматизацией через GUI и предлагали стратегии борьбы с ними. Но лучший выход — избежать их вообще. Программные интерфейсы, как правило, обеспечивают стабильность. Также они способствуют обнаружению и изоляции дефектов.
Когда мы смотрим на усилия тестировщиков во многих программных продуктах, мы наблюдаем корреляцию между наличием программного интерфейса и сложностью тестовых наборов. Программные интерфейсы включают API, интерфейс командной строки, COM интерфейс, HTTP и другие. Вам нужно знать жаргон и технологии. Не ожидайте, что ваши программисты предоставят вам учебник. Чем дольше вы ждете, тем меньше времени. Если вы всерьез занимаетесь автоматизацией, вы изучите это сами или найдете кого-нибудь, кто сможет помочь.
Часто автоматизаторы GUI тестирования считают, что должны изучить в деталях технологии GUI. С технической точки зрения GUI сложнее других интерфейсов. Так или иначе, вам придется изучить технологии GUI по мере использования тестов. Это ваш выбор, а мы считаем, что GUI должен быть последним в списке.
Вот небольшой пример. Многие люди просят у нас совета по автоматизации инсталлятора с использованием инструмента графического тестирования. Лучший подход, как правило, выбросить инструмент. Большинство инсталляторов имеют скриптовый интерфейс, обеспечивающий лучший доступ. InstallShield, например, популярная система установки, используемая в инсталляторах многих продуктов. Многие тестировщики не знают, что они могут работать с InstallShield с возможностью записи выбранных опций установки. Они сохраняются в файл. В дальнейшем возможна автоматическая установка с помощью этого файла указывающая все настройки. Это просто, это дешево, этот файл легко читать и редактировать. Это экономически эффективный способ автоматизации установки (см. «Создание скрытой инсталляции» http://support.installshield.com/kb/display.asp?documents_id=101901).
Но вы не тестируете GUI! Сфокусируйте свое внимание на том, где автоматизация может помочь в большей степени. Иногда можно эффективно автоматизировать тестирование GUI, иногда нет. Не допускайте предвзятого мнения о том, что автоматизация выглядит как ограничивающая вас.
Опыт Douglas Hoffman'а похож на наш. «Наиболее драматичный успех я имел, когда работал с исвестным пакетом настольных издательских систем. Его движок был скрыт и продукт воспринимался с точки зрения WYSIWYG GUI. Поскольку планировалась полная переработка пользовательского интерфейса, мы избежали автоматизации тестирования GUI. Вместо этого мы использовали public API для функционального тестирования и вручную тестировали GUI. Мы зарепортили много дефектов (в основном обнаруженных при автоматизации тестов) и смогли гораздо легче отделять проблемы с GUI от проблем с функциональностью»
Paul Szymkowiak не согласен. «Мой опыт отличается. Я обнаружил, что многие GUI более стабильны, чем программные интерфейсы, в контексте елей автоматизации тестирования. Это происходит потому, что GUI виден клиентам, использующим напечатанные учебные материалы и руководства. Таким образом, существуют расходы, связанные с изменениями GUI. Я работал с рядом руководителей проектов, которые просили «заморозить» пользовательский интерфейс задолго до заморозки программного интерфейса. Многие программные интерфейсы плохо документированы. Я также нашел много багов в программных интерфейсах с более низким порогом юзабилити, чем это обычно ожидается от пользовательского интерфейса».
Выставили на всех серверах непрерывной интеграции в /etc/postgresql/9.1/main/postgresql.conf параметр
fsync=off
Слово Канеру
Автоматизируйте тесты используя программные интерфейсы.
В настоящее время многие продукты имеют программные интерфейсы (публичное API), которое может быть использовано для тестирования. Другие продукты, могут иметь скрытые API, которые могут быть открыты, если вы попросите. Просите.
Открытый API документируется как часть продукта. Они сильно не меняются и эта стабильность делает их привлекательными для автоматизации тестирования. Закрытый API может быть очень полезен, но необходимо выяснить, насколько он подвержен изменениям.
Не зная о подобных альтернативах, многие автоматизаторы фокусируются на видимой части ПО — на GUI. С сожалению, часто это самый сложный интерфейс для автоматизации. Практически любой программный интерфейс проще, надежней и стабильней. В предыдущих лекциях мы обсуждали некоторые проблемы, связанные с автоматизацией через GUI и предлагали стратегии борьбы с ними. Но лучший выход — избежать их вообще. Программные интерфейсы, как правило, обеспечивают стабильность. Также они способствуют обнаружению и изоляции дефектов.
Когда мы смотрим на усилия тестировщиков во многих программных продуктах, мы наблюдаем корреляцию между наличием программного интерфейса и сложностью тестовых наборов. Программные интерфейсы включают API, интерфейс командной строки, COM интерфейс, HTTP и другие. Вам нужно знать жаргон и технологии. Не ожидайте, что ваши программисты предоставят вам учебник. Чем дольше вы ждете, тем меньше времени. Если вы всерьез занимаетесь автоматизацией, вы изучите это сами или найдете кого-нибудь, кто сможет помочь.
Часто автоматизаторы GUI тестирования считают, что должны изучить в деталях технологии GUI. С технической точки зрения GUI сложнее других интерфейсов. Так или иначе, вам придется изучить технологии GUI по мере использования тестов. Это ваш выбор, а мы считаем, что GUI должен быть последним в списке.
Вот небольшой пример. Многие люди просят у нас совета по автоматизации инсталлятора с использованием инструмента графического тестирования. Лучший подход, как правило, выбросить инструмент. Большинство инсталляторов имеют скриптовый интерфейс, обеспечивающий лучший доступ. InstallShield, например, популярная система установки, используемая в инсталляторах многих продуктов. Многие тестировщики не знают, что они могут работать с InstallShield с возможностью записи выбранных опций установки. Они сохраняются в файл. В дальнейшем возможна автоматическая установка с помощью этого файла указывающая все настройки. Это просто, это дешево, этот файл легко читать и редактировать. Это экономически эффективный способ автоматизации установки (см. «Создание скрытой инсталляции» http://support.installshield.com/kb/display.asp?documents_id=101901).
Но вы не тестируете GUI! Сфокусируйте свое внимание на том, где автоматизация может помочь в большей степени. Иногда можно эффективно автоматизировать тестирование GUI, иногда нет. Не допускайте предвзятого мнения о том, что автоматизация выглядит как ограничивающая вас.
Опыт Douglas Hoffman'а похож на наш. «Наиболее драматичный успех я имел, когда работал с исвестным пакетом настольных издательских систем. Его движок был скрыт и продукт воспринимался с точки зрения WYSIWYG GUI. Поскольку планировалась полная переработка пользовательского интерфейса, мы избежали автоматизации тестирования GUI. Вместо этого мы использовали public API для функционального тестирования и вручную тестировали GUI. Мы зарепортили много дефектов (в основном обнаруженных при автоматизации тестов) и смогли гораздо легче отделять проблемы с GUI от проблем с функциональностью»
Paul Szymkowiak не согласен. «Мой опыт отличается. Я обнаружил, что многие GUI более стабильны, чем программные интерфейсы, в контексте елей автоматизации тестирования. Это происходит потому, что GUI виден клиентам, использующим напечатанные учебные материалы и руководства. Таким образом, существуют расходы, связанные с изменениями GUI. Я работал с рядом руководителей проектов, которые просили «заморозить» пользовательский интерфейс задолго до заморозки программного интерфейса. Многие программные интерфейсы плохо документированы. Я также нашел много багов в программных интерфейсах с более низким порогом юзабилити, чем это обычно ожидается от пользовательского интерфейса».
среда, 27 июня 2012 г.
Lesson 131
Слово Канеру
Используй стандартные скриптовые языки
Если ты тестировщик, который хочет узнать больше о программировании, мы предлагаем тебе изучить Perl, Visual Basic, TCL, JavaScript, Python или любой другой скриптовый язык, который, как ты знаешь, используют программисты вокруг тебя (Sweeney 2001). Некоторые скриптовые языки, такие как Unix shell или DOS batch files будут вокруг тебя еще долго. Скриптовые языки высокого уровня оптимизированы для удобства использования , а не производительности.
Многие программисты более продуктивны и совершают меньше ошибок, если они используют скриптовые языки программирования, а не системные языки, такие как C/C++ или Java.
Скриптовые языки подходят для большинства задач автоматизации тестирования. Ты можешь использовать их для генерации данных, доступа к интерфейсам программ, проверки результатов.
Многие инструменты тестирования имеют встроенный скриптовый язык. Другие разумно используют стандартные языки. Третьи создали свои проприетарные языки, которые мы называем vendorscripts. Мы не видим веских причин для их использования и отмечаем ряд проблем:
Они делают кодирование сложным Многие из них основаны на стандартном языке вроде С. Если ты можешь читать С, то ты, возможно, сможешь прочесть C-based vendorscript. Но ты потратишь чертовски много времени на написание правильного кода Эти vendorscripts не поддерживают многие стандартные идиомы языка и делают написание кода таким жи простым, как письмо на английском без использования буквы N.
Они сложны для изучения Сложность поиска тренинга или книги по vendorscripts делает их сложными для изучения. А если вы изучите такой язык, то все равно вы не сможете использовать его для чего-либо еще. Поэтому сложно мотивировать людей на изучение таких языков. А если вы ищете людей, то будет трудно найти людей, уже знающих этот vendorscripts.
Они мешают сотрудничеству тестировщиков и программистов Мы рекомендуем тестировщикам и программистам продукта сотрудничать с проектами по автоматизации тестирования. Это становится сложным, если вы используете разные языки.
Сложнее опираться на работу других Библиотеки, предоставляемые vendorscripts жалки по сравнению с теми, что доступны для стандартных языков. Это значит, что вы не сможете опереться на чужую работу, но будете тратить время на поддержку рудиментарных библиотек.
Мы рекомендуем избегать инструментов с vendorscripts. Больше и больше инструментов тестирования в настоящее время используют стандартные языки. Если вы вынуждены использовать инструмент с vendorscripts, постарайтесь уменьшить количество кода на этом языке и перенести столько обработки, сколько можно в отдельную языковую среду(Более подробно см. Pettichord, 2001a).
Используй стандартные скриптовые языки
Если ты тестировщик, который хочет узнать больше о программировании, мы предлагаем тебе изучить Perl, Visual Basic, TCL, JavaScript, Python или любой другой скриптовый язык, который, как ты знаешь, используют программисты вокруг тебя (Sweeney 2001). Некоторые скриптовые языки, такие как Unix shell или DOS batch files будут вокруг тебя еще долго. Скриптовые языки высокого уровня оптимизированы для удобства использования , а не производительности.
Многие программисты более продуктивны и совершают меньше ошибок, если они используют скриптовые языки программирования, а не системные языки, такие как C/C++ или Java.
Скриптовые языки подходят для большинства задач автоматизации тестирования. Ты можешь использовать их для генерации данных, доступа к интерфейсам программ, проверки результатов.
Многие инструменты тестирования имеют встроенный скриптовый язык. Другие разумно используют стандартные языки. Третьи создали свои проприетарные языки, которые мы называем vendorscripts. Мы не видим веских причин для их использования и отмечаем ряд проблем:
Они делают кодирование сложным Многие из них основаны на стандартном языке вроде С. Если ты можешь читать С, то ты, возможно, сможешь прочесть C-based vendorscript. Но ты потратишь чертовски много времени на написание правильного кода Эти vendorscripts не поддерживают многие стандартные идиомы языка и делают написание кода таким жи простым, как письмо на английском без использования буквы N.
Они сложны для изучения Сложность поиска тренинга или книги по vendorscripts делает их сложными для изучения. А если вы изучите такой язык, то все равно вы не сможете использовать его для чего-либо еще. Поэтому сложно мотивировать людей на изучение таких языков. А если вы ищете людей, то будет трудно найти людей, уже знающих этот vendorscripts.
Они мешают сотрудничеству тестировщиков и программистов Мы рекомендуем тестировщикам и программистам продукта сотрудничать с проектами по автоматизации тестирования. Это становится сложным, если вы используете разные языки.
Сложнее опираться на работу других Библиотеки, предоставляемые vendorscripts жалки по сравнению с теми, что доступны для стандартных языков. Это значит, что вы не сможете опереться на чужую работу, но будете тратить время на поддержку рудиментарных библиотек.
Мы рекомендуем избегать инструментов с vendorscripts. Больше и больше инструментов тестирования в настоящее время используют стандартные языки. Если вы вынуждены использовать инструмент с vendorscripts, постарайтесь уменьшить количество кода на этом языке и перенести столько обработки, сколько можно в отдельную языковую среду(Более подробно см. Pettichord, 2001a).
суббота, 23 июня 2012 г.
Lesson 130
Народ, кто-нибудь использорвал Robot Framework? Написал на нем пару сотен тестов? При этом делал русские алиасы?
Вы когда-нибудь просили программистов сделать ревью кода?
Если да, то были ли у них эмоции, отличные от бля, чо это за текст? Что с ним делать вообще?
Я к тому, что Robot Framework это все зашибись, но неплохо бы говорить с программистами на одном языке.
Ну то есть гораздо проще отдать программисту проект с mvn install verify, классами, интерфейсами и surefire, чем описание на корявом русском. Не?
Я понимаю, что алиасы для аналитики и прочих ПМов, но это все пока вы пишете первые тридцать тестов. А затем начинаются оптимизации, рефакторинги и тесты тянет показать какому-нибудь приличному программисту.
Обратно же, найденные баги править именно кодерам, а не аналитикам.
Слово Канеру
Отделите генерацию тестов от их выполнения.
Одна их стратегий, поддерживающая отделение тестовых данных от выполнения кода - data-driven автоматизация (Lesson 127). Это отделение облегчает генерацию тестов и имеет ряд преимуществ:
- Тесты будут простыми для понимания и просмотра
- Ты сможешь использовать разные инструменты тестирования или IDE для генерации и выполнения тестов.
- Отдельный генератор тестов легче проверить. Если вы используете случайные методы, вы должны знать, that random number algorithms packaged with programming environments are often weak. Данные могут быть не такими случайными, как вы ожидали. Проверьте их правильность(Park and Miller 1988). Kaner и Vokey (1984) обеспечили тщательное тестирование набора параметров из генератора случайных чисел, который легко запрограммировать в Java или любом другом языке, работающем с высокоточной целочисленной арифметикой (wtf?).
- Тесты легче воспроизвести, если данные сгенерированы предварительно. Мы видели тестовые скрипты, изменяющие тест каждый раз, когда они запускались. Если вы не можете генерировать данные предварительно, необходимо принять другие меры для обеспечения повторяемости, такие как логирование данных или использование зерен для генерации. Оснащение тестовых скриптов такими механизмами усложняет их.
- Вы сможете быстрее сообщать о найденных ошибках. Первая мысль программиста — поставить под сомнение ваш инструмент.
- Различные специалисты смогут сфокусироваться на разных аспектах автоматизированного тестирования с помощью любого инструмента или языка, который они считают подходящим.
Вы когда-нибудь просили программистов сделать ревью кода?
Если да, то были ли у них эмоции, отличные от бля, чо это за текст? Что с ним делать вообще?
Я к тому, что Robot Framework это все зашибись, но неплохо бы говорить с программистами на одном языке.
Ну то есть гораздо проще отдать программисту проект с mvn install verify, классами, интерфейсами и surefire, чем описание на корявом русском. Не?
Я понимаю, что алиасы для аналитики и прочих ПМов, но это все пока вы пишете первые тридцать тестов. А затем начинаются оптимизации, рефакторинги и тесты тянет показать какому-нибудь приличному программисту.
Обратно же, найденные баги править именно кодерам, а не аналитикам.
Слово Канеру
Отделите генерацию тестов от их выполнения.
Одна их стратегий, поддерживающая отделение тестовых данных от выполнения кода - data-driven автоматизация (Lesson 127). Это отделение облегчает генерацию тестов и имеет ряд преимуществ:
- Тесты будут простыми для понимания и просмотра
- Ты сможешь использовать разные инструменты тестирования или IDE для генерации и выполнения тестов.
- Отдельный генератор тестов легче проверить. Если вы используете случайные методы, вы должны знать, that random number algorithms packaged with programming environments are often weak. Данные могут быть не такими случайными, как вы ожидали. Проверьте их правильность(Park and Miller 1988). Kaner и Vokey (1984) обеспечили тщательное тестирование набора параметров из генератора случайных чисел, который легко запрограммировать в Java или любом другом языке, работающем с высокоточной целочисленной арифметикой (wtf?).
- Тесты легче воспроизвести, если данные сгенерированы предварительно. Мы видели тестовые скрипты, изменяющие тест каждый раз, когда они запускались. Если вы не можете генерировать данные предварительно, необходимо принять другие меры для обеспечения повторяемости, такие как логирование данных или использование зерен для генерации. Оснащение тестовых скриптов такими механизмами усложняет их.
- Вы сможете быстрее сообщать о найденных ошибках. Первая мысль программиста — поставить под сомнение ваш инструмент.
- Различные специалисты смогут сфокусироваться на разных аспектах автоматизированного тестирования с помощью любого инструмента или языка, который они считают подходящим.
Подписаться на:
Сообщения (Atom)