Home

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

(Майкл Ховард)

Автор: Татьяна Зинченко

Прошла первая конференция ConfeT&QA, на которой я выступала с докладом про фаззинг. Очень много отзывов было примерно такого содержания: «Очень интересный доклад, но я совсем не знаю, что такое фаззинг».

Что же такое фаззинг и с чем его едят?

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

У нас этот вид тестирования еще не очень распространен, а на западе им пользуются уже достаточно давно. Еще в 1988 году Барт Миллер опубликовал работу The Fuzz Generator, в которой впервые был определен термин Fuzzing. А особо активное использование началось в 2006 году, когда при помощи фаззинга была найдена масса уязвимостей в Internet Explorer, Microsoft Word и Microsoft Excel. Сейчас фаззинг является одним из самых эффективных методов выявления проблем безопасности кода.

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

Завершилось голосование на звание лучшего докладчика конференции, и мы рады объявить наших призёров:

• Наталья Руколь получает первый приз, игровую приставку Xbox 360 + сенсор Kinect, за интереснейший рассказ о способах оценки эффективности тестирования,
• Андрей Дзыня получает второй приз, планшетный компьютер Archos 7 Home Tablet, за живую демонстрацию того, как за 20 минут сделать тестовый фрейморк для веб-приложения.

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

По результатам этого опроса был определён самый активный участник, который также получает в качестве приза планшетный компьютер Archos 7 Home Tablet, и этим счастливчиком стал:

• Сергей Атрощенков

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

Обсудить в форуме

Завершилась первая на просторах бывшего СНГ онлайн-конференция тестировщиков ConfeT&QA. Она проходила с 17 по 21 октября в «прямом эфире», а «офлайновые» обсуждения продолжаются до сих пор.

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

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

Все презентации и видео-материалы собраны, сейчас проходит голосование на звание лучшего докладчика конференции и самого активного участника.

Многие докладчики и слушатели уже написали свои отзывы на прошедшую конференцию, ознакомиться с ними можно тут:

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Testing Problems Are Test Results
Перевод: Сергей Высоцкий и RA

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

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

В добавок к этому:

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

Ах да, вот еще:

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

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

Мы можем интерпретировать их как проблемы тестирования, или мы можем взглянуть на них с другой стороны: как на результаты тестирования.

В ноябре мы запускаем новый тренинг “Разработка тестов на Java с использованием Selenium 2.0”, который, как это видно из названия, посвящен новой версии инструмента автоматизации тестов для веб-приложений Selenium 2.0.

Вторая версия Selenium не является результатом эволюционного развития первой. Это абсолютно новый инструмент, с новым интерфейсом и новыми возможностями, которыми не обладала предыдущая версия. Основные отличия Selenium 2.0 и 1.0 описаны в статье "Раз селениум, два селениум", а подробное сравнение двух версий будет одной из ключевых тем данного тренинга -- демонстрация примеров будет производиться сразу для двух версий параллельно.

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

Освоения материала первого модуля слушателям будет достаточно для того, чтобы установить и настроить всё необходимое для разработки и выполнения тестов с использованием Selenium 2.0. Второй модуль посвящен рассмотрению различных расширений Selenium, в том числе не только для языка Java. Cреди этих расширений (только не удивляйтесь) встретится другой популярный инструмент автоматизации веб-тестов Watir (да-да!), инструменты для тестирования приложений в мобильных браузерах и даже инструменты для удаленного тестирования нативных Windows-приложений! В третьем модуле, наиболее сложном технически, будут обсуждаться различные тонкости программирования автотестов.

Начало 15 ноября.

Подробная программа и условия участия

В ноябре наши тренеры впервые планируют посетить с тренингами по тестированию ПО Самару.

• 10 ноября, Тестирование методом свободного поиска (exploratory testing), тренер Алексей Баранцев
• 11 ноября, Функциональное тестирование ПО, тренер Алексей Баранцев
• 19-20 ноября, Тест дизайн и все все все, тренер Александр Федоров

Места еще есть, регистрируйтесь!!!

Автор: Наталья Руколь

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

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Do You Need More Testers? A Context-Driven Exercise
Перевод: Сергей Высоцкий и RA

Эта дискуссия о лучших практиках в отрасли началась недавно на comp.software.testing:

Сколько тестировщиков на разработчика считается лучшей практикой при создании сложных веб-приложений с нуля? Я слышал о полутора тестировщиках на каждого разработчика. Что вы думаете по этому поводу?

Мой (слегка отредактированный для этого блога) ответ был...

• Если вы собираетесь найти все баги, то 100 тестеров на программиста будет куда лучше чем полтора. Ваши клиенты могут счесть это впечатляющим (если они захотят за это платить), но ваш финансовый директор взбесится. И все еще не будет никакой гарантии, что вы найдете все баги.
• Если вы хотите сэкономить, то 0 тестировщиков будет куда лучше, чем полтора на программиста. Это даже может сработать, но будет ли вы уверенны в том, что все важные вопросы о вашем продукте были заданы, а ответы на них были получены?
• Если уж вы собрались действительно сэкономить, то 0 тестеров на 0 программистов будет самым лучшим решением.

Мы еще не говорили о квалификации тестировщиков и программистов, вовлеченных в процесс. Мы ничего не сказали об области бизнеса и сопутствующих рисках. Мы еще не говорили о том, считаете ли вы тест менеджеров и админов тестерами, или можно ли считать ваших программистов тестировщиками, когда они тестируют. (Мы так же не поговорили о ситуации, возникающей, когда вы принимаете эти "1,5 тестера на программиста" как "лучшую практику" для команды из трех программистов буквально - какую половину от пятого тестировщика вы бы хотели сохранить? Подсказка: выбирайте ту, что с головой).