четверг, 28 апреля 2011 г.

Лето. Море. Тестировщики.

Ура!!!
Наконец-то и у нас в Крыму (а не в традиционных Москве, Питере и Киеве) планируют побывать Алексей Баранцев и Наталья Руколь! ))))
Наконец-то не нужно будет стоять в душных очередях, чтобы заранее купить билет! Наконец-то не нужно будет ехать сутки в поезде или раздеваться в аэропортах! Самое главное - наконец-то можно совместить приятное с полезным: обучение и отдых!
А еще: морько, морько, морько, как я уже по нему соскучилась )))))
Отпуск уже распланирован, теперь ищу как сделать так, чтобы все же попасть на Летнюю школу тестировщиков. И непременно попаду! ))))

вторник, 26 апреля 2011 г.

Казань - брал! Шпака - не брал... (с)

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

День первый.
Конференция для нас началась с доклада Леонида Динерштейна "Разработка программ через тестирование поведения средствами Cucumber". Много можно было бы сказать о самой целесообразности использования таких средств вместо "ручных тестировщиков" (Леонид с командой работают по Agile и у них нет тестировщиков), но это - тема для отдельной беседы. Для нас важным было другое: проблема коммуникации с заказчиком. И этот вопрос был затронут в докладе.Подумать только: 56% всех ошибок - это результат неверного понимания или объяснения требования! А вовлеченность заказчика вообще стоит на первом месте в списке причин появления ошибок!
Что мы вынесли для себя: требования должны составляться только в союзе с заказчиком!
Цитата доклада: "Заказчика необходимо воспитывать!"

Дальше мы пошли на доклад Глеба Рыбалко "Цена качества. Как объяснить заказчику сколько стоит качество". Здесь опять говорилось о том, что обратная связь с заказчиком необходима! Такая связь является превентивной мере в появлении ошибок. А сама цена качества складывается из затрат на контроль и затрат на ошибки контроля.
Что мы вынесли для себя: на проекте должны обязательно присутствовать метрики качества. Необходимо выяснять чего хочет заказчик. Для заказчика необходимо готовить отчеты. Заказчик должен иметь инструмент для внесения изменений.
Цитата доклада: "Дайте заказчику возможность оценить вашу работу!"

Перед перерывом на обед посидели на докладе Андрея Кощеева "Мастерство управления качеством в полном цикле разработки". На примере инструментов компании НР нам было рассказано и показано как может происходить и контролироваться процесс создания продукта (анализа, разработки, тестирования и проч.).
Что мы вынесли для себя: мы - молодцы и все правильно делаем!

После обеда постарались пробиться на круглый стол Ильи Фомина "Проблемы автоматизируемости тестирования и их решения". Очень неоднозначный доклад, обсуждать который можно долго и нудно. ИМХО, чтобы заявить на конференции тестировщиков о том, что тестировщики не нужны, потому что есть автоматизация - нужно быть очень смелым человеком. ))))

Очир Абушинов рассказывал о "Применении fuzz-тестирования". Вообще, тема фаззинга только начинает проникать в наши страны, а она чрезвычайно интересна. Жаль только, что на докладе у Очира (как у всякого нормального тестировщика) заглючила программа, к чему он оказался не готов. А вот сама идея и построение доклада мне показались хорошими: я и сама сделала бы именно так. У меня даже возникла идея сделать мастер-класс по фаззингу, потому что там действительно поле непаханое того, что можно показать: фаззинг файлов, протоколов, драйверов, веб-приложений, исходного кода...
Что мы вынесли для себя: мы абсолютно верно применяем фаззинг на нашем проекте.
Цитата доклада: "Много фаззеров можно найти на code.google.com".

После доклада по фаззингу мы (логично) пошли на Сергея Полаженко с его "Security Testing: SQL Injection". SQL инъекции занимают первое место из всех способов взлома сайтов. В последнее время об этом слышали, наверное, все. Что уж говорить про сайты небольших фирм, если даже Oracle недавно был хакнут именно таким образом. В общем, актуальность темы не вызывает дополнительных вопросов. Сергей приводил цифры и факты, рассказывал о том, как писать красивый код, который не поддается инъекциям.
Что мы вынесли для себя: мы пишем абсолютно правильный код. Но даже используя все подряд методы предохранения, нет гарантии 100% защищенности.

Последним в день первый мы посетили мастер-класс Алексея Баранцева "Автоматизация тестирования веб-приложений при помощи Selenium". Алексей рассказывал о Селениуме с самых азов (от Selenium IDE) и до написания автотестов вручную и возможном их запуске "в облаках" (т.е. на виртуальных серверах).
Что мы вынесли для себя: не стоит пока использовать Selenium IDE 1.0.11 - он завис прямо во время мастер-класса. К тому же, эта версия использует css-локаторы вместо xpath.
Цитата доклада: "В Sauce Labs предоставляется облако на 200 минут в месяц для 2 виртуалок бесплатно!"

День второй начался для нас с доклада Михаила Мериина "Нагрузочное тестирование - когда все не так". Большинство из того, о чем рассказывал Михаил, мы не используем при нагрузочном тестировании. Так что еще внедрять и внедрять. )))) Основное внедрение, конечно, - это создание тестовых стендов. Адекватных тестовых стендов, а не того, что юзается сейчас.
Что мы вынесли для себя: идеальный тестовый стенд = продуктиву.
Цитата доклада: "Документ по нагрузке должен быть согласован со всеми участниками проекта".

Дальше мы пошли на Дмитрия Лобасева и его доклад: "Kanban - инструмент повышения качества разработки". Шикарная анимированная презентация от человека, который занимается внедрением гибких методологий и бережливого производства в компаниях. Мы и сами используем Канбан, поэтому ничего нового не узнали. Разве что выяснили, что остановки в Канбане называются по-умному "каденции". )))
Что мы вынесли для себя: с процессом у нас все хорошо.
Цитата доклада: (комментарий из зала) "Самоорганизующаяся команда - это то же самое, что самодокументирующийся код".

Перед обедом выступала я. Докладывалась о гибких методологиях. Тема: "Тестирование в Agile: испытание методологией". Общение получилось весьма и весьма плодотворным. После доклада подходили участники, задавали вопросы о проблемах и я поняла, что, несмотря на все различие, проблемы у компаний - общие. И те же грабли, которые были у нас, существуют и у других команд. Возникло даже желание написать большой пост с ответами на те вопросы, которые задавали участники. И, наверное, я это и сделаю в ближайшее время.
Что мы вынесли для себя: гибкие методологии все еще актуальны, несмотря на свой 10-летний возраст. ))
Цитата доклада: (взято из твиттера) "В скраме итерация представляет собой маленький водопадик"
"Было тяжело. Тестировщиков набрали по объявлению"
"Демоном мы называем человека, который отвечает за демо"
"У нас очень продвинутое начальство, несмотря на то, что программисты"
"Любите свою команду. И тогда она полюбит вас. Или нет. Но тогда ей же хуже"

После обеда участвовали в круглом столе Романа Твердохлебова "Вместе весело шагать, или как собрать тестировщиков в своем городе". Получила много пищи для размышлений. Сразу появилось невероятное желание собрать и у нас. ))) Еще было очень приятно увидеть воочию тех, с кем до сих пор общение происходило только в онлайн-режиме.
Что мы вынесли для себя: сообщества тестировщиков - это классно! Сегодня даже закинули пробный камень в наше руководство по поводу проведения тестировщицких сходок у нас.

Последний доклад, который мы слушали, был от Наташи Руколь и назывался "Улучшаем процесс тестирования через призму философии Kaizen". Почему мы туда пошли? Lean вышел именно оттуда и нам было интересно послушать с чего все начиналось.
Что мы вынесли для себя: отталкиваемся от проблем, а не скрываем их!
Цитата доклада: "Муда - все те действия, которые на самом деле не нужны"
"Гемба - то место, где делают работу"
"Выясняем причины проблемы используя принцип 5 Почему?"

А потом мы убежали собираться на самолет и уже не услышали, что мой доклад был признан одним из лучших. ))) Thanks, mom, thanks, dad, thanks god! ))))
На самом деле в секции С в это время собрались самые умные, веселые и приятные слушатели и вопросо-задаватели! Спасибо вам всем! )))

пятница, 15 апреля 2011 г.

Почему программисты не тестируют?

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

Один мой очень хороший друг, а по совместительству - программист и совладелец небольшой айтишной фирмы, когда-то сказал мне, что из тестировщиков получаются очень хорошие программисты. А вот обратное неверно (или верно, но очень редко).
Я лично считаю, что это потому, что у нас - тестировщиков - особый тип мышления. У программистов он более линейный, стандартизированный. Утрированно: его можно приравнять к тому коду, который они пишут: алгоритмы, циклы, четко представленная структура.
У нас все гораздо проще и сложнее одновременно. Нас всегда штормит: то туда, то сюда. Нам всегда интересно, что будет, если выйти за пределы дозволенного. Нам интересно нестандартное поведение. Наверное, именно поэтому при проверке функционала иногда слышу от программиста: "Ой, а об этом я не подумал!"

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

Почему тестирование программистами не так эффективно, как тестировщиками? Вы когда-нибудь видели, как программисты тестируют собственный продукт? Выглядит это примерно так: программист проходится по написанному функционалу и вдруг находит ошибку. После естественного недоумения: "Как в моем функционале может быть бага?!" на все помещение звучит: "Ребята, я нашел багу, вот тут слово с ошибкой написано!!". Тут же собирается консилиум из еще 2-3 программистов. Они рассматривают эту ошибку (потому что ее нашел ПРОГРАММИСТ!!), пытаются осмыслить как эта ошибка появилась, кто где налажал. Смотрят логи. Ищут виноватого. После детального анализа начинают фиксить. Работа стоит. Они нашли одну ошибку, они заняты.
Тестировщик находит ошибку, фиксирует ее, идет дальше, находит еще, опять фиксирует. Находит третью. Понимает, что тут возможно еще какое-то интересное поведение, начинает копать глубже. При этом он может выдавать эти баги программисту по одной, может - сразу ворохом "счастья". Работа не останавливается из-за того, что тестер находит багу. Чтобы добиться консилиума программистов, нужно найти что-нибудь ну очень серьезное: show-stopper, например.

Программисты очень умные ребята. Они пишут те программы, которые нам потом достаются на растерзание (что бы мы без них делали?). Они замечательно пишут юнит-тесты. Некоторые из них отлично автоматизируют на уровне API. Это, несомненно, помогает сразу же после выкладки новой версии или слияния веток, или какого-нибудь рефакторинга. Но вот тестирование все же лучше им не доверять. ))))

Берегите программистов!



понедельник, 11 апреля 2011 г.

Комбинаторное тестирование: тестирование с негативными значениями

Про комбинаторику много сказано, еще больше будет сказано, и мне бы тоже хотелось что-нибудь сказать, но т.к. я очень люблю рассматривать обе стороны медали, статья Bj Rollison'а Combinatorial Testing: Testing with Negative Values привлекла мое внимание. Автор использует инструмент PICT (заранее поясняю, т.к. об инструменте он ведет разговор с самого начала, а его название дает только в конце).

Перевод мой. ))

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

До сих пор в нашей дискуссии о комбинаторном тестировании наша модель и результирующие тесты были сфокусированы на допустимых входящих значениях [имеются в виду предыдущие статьи]. Это широко известно как позитивное тестирование, потому что все допустимые вводимые комбинации дают допустимые исходящие значения или состояния. Тестирование различных комбинаций допустимых значений для нескольких входных параметров, которые влияют на общее состояние исходящих значений или условий, иногда демонстрирует неожиданные ограничения, что также помогает  повысить общую достоверность тестирования фичи. Позитивное тестирование должно основываться на клиенте (большинство клиентов не используют отрицательные значения, чтобы увидеть сколько ошибок они могут найти) при оценке поведения или исходящих значений, а зачастую проще разработать автоматизированные оракулы для позитивных тестов, чем разрабатывать их для негативных тестов. В основном, автоматизированные оракулы для позитивных комбинаций тестов проверяют насколько исходящие условия или состояния соответствуют ожидаемым результатам, и не появляются ли такие неожиданности как сообщения об ошибках, необработанные исключения или других неисправности.

А не должны ли мы устроить проверку и для негативных значений? Это действительно хороший вопрос и я должен сказать, что не очень уверен в этом по двум причинам:

- большинство обработок эксепшенов является результатом ошибки только в одном режиме. Другими словами, давайте предположим, что у нас есть виндовые формы, содержащие 3 поля ввода для целых чисел, и вводимые данные не обрабатываются пока не нажата кнопка ОК или Apply. И давайте предположим, что мы вводим символ “А” в каждое поле ввода. Обычно когда юзер нажимает ОК или Apply эксепшен вызывается (и приложение отображает сообщение об ошибке) при обнаружении первого же неправильного значения. Если мы вводим несколько исключений, то программа либо не смотрит на повторяющиеся ошибки, либо пользователь получает каскад сообщений об ошибках.

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

Итак, зададим себе три вопроса:

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

- Должны ли мы предполагать, что нам необходимо интенсивно использовать тесты для различных комбинаций неправильных входных значений?

- Необходимо ли нам повторять такие тесты в продолжении всего жизненного цикла разработки продукта (SDLC)?

Это очень важные вопросы, поскольку если делать правильно и в правильном контексте, то комбинаторная техника входных значений получается более “дорогой” в сравнении с другими подходами к тестированию. Например, мы знаем, что комбинаторное тестирование может найти баги отдельных значений, но есть более эффективные (менее “дорогие”) пути найти такие ошибки. Тестирование комбинаций входных значений, которые оказывают влияние на общие выходные условия или состояния, определяется входными параметрами и вариациями этих параметров, моделированием входных данных, изучением исходящих, настройки модели, а в идеале: автоматизацией управляемых тестовых данных для тестов. Слишком трудоемко (“дорого”) проверять какие из неверных значений (например, символ “А”, введенный в поле, принимающее только целочисленные значения) дали нужный отклик (например, сообщение об ошибке). Еще один фактор: когда мы тестируем комбинацию негативных значений и появляется какая-то непонятная ошибка, то мы должны потратить некоторое время для выяснения - была ли аномалия вызвана этой комбинацией или это дефект какого-то одного из значений.

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

- если все вводимые значения допустимые, мы ожидаем отображения в нашем окне редактирования символов (на самом деле глиф), соответствующих вводимым значениям, и никаких сообщений об ошибках, непонятных эксепшенов и приложение не находится в статусе “не отвечает”.

- если значение цвета шрифта представляет собой любые недопустимые данные, тогда при нажатии кнопок ОК или Apply сообщение об ошибке не отображается, но цвет шрифта возвращается к последнему допустимому цвету шрифта (или к цвету шрифта по умолчанию).

- если размер шрифта меньше 1 или больше, чем 1638, появляется сообщение об ошибке и размер возвращается к последнему допустимому значению.

- если размер шрифта имеет десятичное значение, отличное от n.5, то появляется сообщение об ошибке (или значение может быть округлено до ближайшего целого или n.5 числа) и размер возвращается к последнему допустимому значению.

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

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

Тестирование множества неправильных входных значений.

Комбинаторное тестирование утверждает, что при взаимодействии двух (или больше) входных значений возможны неожиданные состояния или выходные значения. Поэтому, раз мы считаем, что 2 или более недопустимых значения могут привести к неожиданной аномалии, тогда мы можем просто добавить недопустимые входные значения в нашу модель. Например, в нашем примере диалога выбора шрифтов мы можем вставить недопустимые входные значения для цвета и размера шрифта, как это проиллюстрировано в модели ниже (выделено жирным):

# Model File for MyFontDialog
Font: Arial(50), Tahoma, BrushScript, MonotypeCorsive
Style: Bold, Italic, BoldItalic, None(10)
Effects: Strike, Underline, StrikeUnderline, None(10)
Colors: Black(10), White, Red, Green, Blue, Yellow, Purple, Orange, randomString, emptyString
Size: small, smallHalf, nominal(10), nominalHalf, large, largeHalf, xLarge, xLargeHalf, xxLarge, xxLargeHalf, emptyString, integerLessThan1, integerGreaterThan1638, floatValueOtherThan.5

# Conditional constraints necessary to prevent mutually exclusive variable settings
# See previous post for dealing with mutually exclusive variables
if [Font] = "BrushScript" then [Style] in { "Italic", "Bold/Italic" };
if [Font] = "MonotypeCorsive" then [Style] in { "None", "Bold/Italic" };

Набор тестовых комбинаций создается специальным инструментом, в который вводятся как позитивные, так и негативные тесты. Например, эта модель будет производить набор тестов, которые включают такие комбинации как цвет Color == emptyString с размером Size == emptyString, и цвет Color == Purple с размером Size == integerGreaterThan1638 с комбинациями значений для других входных параметров. Она также включает тесты типа: цвет Color == randomString с допустимыми входными данными для других параметров. В этом случае мы должны были бы пройти один за другим через весь набор тестов, произведенный нашим инструментом, и определять ожидаемые выходные значения для каждой комбинации. Такой подход был бы более практичным, если бы мы выполняли тестовые комбинации вручную и при этом оценивали результаты выполнения каждого теста. Но это будет очень длительный процесс и он потребует несколько комплексных оракулов, если мы захотим его автоматизировать.

Тестирование отдельных неправильных входных значений.

В некоторых случаях мы можем протестировать отдельно каждое неправильное значение входного параметра в комбинации c допустимым значением другого входного параметра, чтобы изучить конкретные ожидаемые состояния (например, появление ошибок). В таком случае мы должны определить неверные входные значения так, чтобы они не использовались в комбинации с другими недопустимыми значениями для других входных параметров. К счастью, PICT поддерживает такой тип анализа. В нашей модели входных данных мы можем выделить недопустимые значения значком тильды (~). Измененная модель файла ниже теперь включает недопустимые значения для параметров размера и цвета.

# Model File for MyFontDialog
Font: Arial(50), Tahoma, BrushScript, MonotypeCorsive
Style: Bold, Italic, BoldItalic, None(10)
Effects: Strike, Underline, StrikeUnderline, None(10)
Colors: Black(10), White, Red, Green, Blue, Yellow, ~randomString, ~emptyString
Size: small, smallHalf, nominal(10), nominalHalf, large, largeHalf, xLarge, xLargeHalf, xxLarge, xxLargeHalf, ~emptyString, ~integerLessThan1, ~integerGreaterThan1638, ~floatValueOtherThan.5

# Conditional constraints necessary to prevent mutually exclusive variable settings
# See previous post for dealing with mutually exclusive variables
if [Font] = "BrushScript" then [Style] in { "Italic", "Bold/Italic" };
if [Font] = "MonotypeCorsive" then [Style] in { "None", "Bold/Italic" };


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

Но мы все еще должны определить ожидаемые исходящие результаты для каждого теста в нашем наборе комбинаторных тестов, сгенерированных инструментом PICT. К счастью, у PICT есть незадокументированная фича: инструмент позволяет указать ожидаемые выходные данные или состояния. Чтобы смоделировать ожидаемый результат, нам нужно просто включить параметр, начинающийся со знака доллара ($). Например, мы можем изменить нашу модель включив в него параметр  “$Result” и присвоив ему ожидаемое выходное условие, как показано ниже.

# Model File for MyFontDialog
Font: Arial(50), Tahoma, BrushScript, MonotypeCorsive
Style: Bold, Italic, BoldItalic, None(10)
Effects: Strike, Underline, StrikeUnderline, None(10)
Colors: Black(10), White, Red, Green, Blue, Yellow, ~randomString, ~emptyString
Size: small, smallHalf, nominal(10), nominalHalf, large, largeHalf, xLarge, xLargeHalf, xxLarge, xxLargeHalf, ~emptyString, ~integerLessThan1, ~integerGreaterThan1638,  ~floatValueOtherThan.5

# Expected Results Parameter
$Result: ErrorMessage, DefaultColor

# Conditional constraints necessary to prevent mutually exclusive variable settings
# See previous post for dealing with mutually exclusive variables
if [Font] = "BrushScript" then [Style] in { "Italic", "Bold/Italic" };
if [Font] = "MonotypeCorsive" then [Style] in { "None", "Bold/Italic" };

# Expected Outputs
if [Colors] in {"randomString", "emptyString"} then [$Result] = "DefaultColor";
if [Size] in {"emptyString", "integerLessThan1", "integerGreaterThan1638", "floatValueOtherThan.5" } then [$Result] =
     "ErrorMessage";

Теперь в наши выходные значения PICT включил еще одну колонку для ожидаемых результатов (как на картинке). Обратите внимание, что в этом случае, если ожидаемый результат - это допустимые выходные значения (свойства шрифта соответствуют введенным значениям), колонка Result содержит знак вопроса (?). Если есть несколько ожидаемых состояний, то “допустимое” исходящее состояние будет отмечено знаком вопроса, как в этом примере.

Если ожидаемый результат бинарен (например, Error или NoError), мы можем использовать один вариант в нашей модели, как, например:

if [param] = “InvalidCondition” then [$Result] = “Error” else [$Result] = “NoError”;

Смысл параметра $Result в том, что мы можем использовать значения $Result как флаги при автоматизации тестов для переключения между различными оракулами автоматизации, чтобы помочь проверить указанный ожидаемый результат.

Такой подход моделирует как допустимые, так и с недопустимые входные значения, а инструмент PICT  генерирует как позитивные, так и негативные выходные тестовые комбинации. Использование параметра $Result как флага является эффективным решением для переключения между автоматизированными оракулами и позволяет нам создавать отдельные автоматизированные тесты. Даже с таким подходом я задаюсь вопросом: вызывает ли неожиданную ошибку комбинация недопустимого значения с допустимым входным значением, или, может, это ошибка какого-то одного модуля. Но если я действительно не знаю как недопустимые входные значения проверяются перед передачей соответствующей функции, тогда включение недопустимых значений в нашу модель может также увеличить общее покрытие тестами и повысить нашу уверенность, или теоретически раскрыть несколько действительно случайных ошибок!


вторник, 5 апреля 2011 г.

Сказка о потерянном времени.

Сказка о потерянном времени
Недавно Наталья Руколь подымала тему о том, почему опоздания стали нормой в нашей повседневной и рабочей жизни.
Я не люблю опаздывать. Я боюсь своих опозданий и всем сердцем ненавижу чужие. На одном социофоруме когда-то прочитала:
"Для меня время так же материально, как города и дома, и когда оно неожиданно заявляет о себе, эффект аналогичный землетрясению – я физически чувствую тяжесть обвалов...
Ожидание – это нечто крайне экспансивное, оно забирает все пространство мышления, я чувствую его как растянутое пространство, где один шаг в клетке моих нервов длится час, время превращается в кисель, и желание только одно - чтобы это все закончилось."
Это все - обо мне. Пытаюсь бороться с собой, но все равно меня всячески выводят из себя разнообразные задержки и неуспевания.
<крик души> В SCRUM существуют итерации, которые длятся от одной до 4 недель. Для такого человека, как я, это просто спасение. Каждые (допустим) 2 недели ты точно знаешь что должно быть, как, в какой последовательности и когда это все закончится. В Canban итераций как таковых не существует. Фича длится не "максимум две недели", а "пока не сделаем". Как так можно жить?! Как можно что-то контролировать так?! Как можно что-то планировать?!
</крик души>

Еще я заметила одну вещь. Программисты - жуткие оптимисты. Если они говорят, что фича будет сделана за 8 дней, можно смело прибавлять еще пару, т.е. треть. Я в последнее время прибавляю еще 4, т.е. половину. И не ошибаюсь. :) Недавно мы взяли новый проект истали прикидывать примерные сроки: когда мы сможем показать уже хоть что-нибудь (такой себе альфа-релиз). Наш Project Owner высказался за полгода. Я - за полтора. Мне не поверили, потому что: "Это слишком долго!"
Это напоминает мне ситуацию: "Подождите минуточку!" тогда, когда на самом деле нужно подождать 7 минут. Но сказать: "Подождите 7 минут!" почему-то могут не все. А некоторым почему-то так даже легче: прождать в 7 раз дольше обещанного, но не услышать правды про 7 минут.
Через пол года я расскажу чем все закончилось и закончилось ли. Не забудьте только мне напомнить! :)


понедельник, 4 апреля 2011 г.

Капчить или не капчить: вот в чем вопрос...

Сначала собственно о капче: что это такое и с чем его едят (для тех, кто еще в счастливом неведении).
Капча (CAPTCHA) - Completely Automated Public Turing test to tell Computers and Humans Apart - полностью автоматизированный публичный тест Тьюринга для различия компьютеров и людей (Википедия). Что такое "тест Тьюринга" можно посмотреть на ней же.
Проще говоря, капча - это тест, который может очень легко решить человек, но компьютеру это сделать гораздо сложнее или невозможно. Сейчас капча используется практически везде: при регистрации, при отправке сообщений, при запросе какой-либо информации и т.д.
Видов капчи бесконечное множество. Это может быть распознавание символов и последующее их введение:

Это может быть выполнение каких-то действий:


Я не буду сейчас перечислять все виды капчи или писать о методах ее обхода, или исследовать капчу в контексте экономического развития (я, кстати, скачала подобное творение и собираюсь прочесть). Проблема в другом.
Есть система, связанная с финансами. Зарегистрированный пользователь входит в систему (т.е. вводит свои данные в поле логин/пароль). При этом кроме логина/пароля с пользователя больше ничего не спрашивается. Ограничений на количество неправильных вводов пароля нет. Продукт прошел альфа-тестирование, бета-тестирование и собирается в "большое плавание".
Есть предложение обезопасить (хотя бы от брутфорса) данные пользователя введением капчи после третьего неверного ввода пароля. Контраргумент: брутфорс - это долго и неэффективно, а админские пароли - md5.
Была идея провести брутфорс системы, чтобы выяснить насколько быстро подберутся пароли (потому что обход md5 уже придумали). Но возникла мысль: а что, если это означает стучаться в одну дверь, когда где-то открыта другая? Ищу другую дверь в безопасность...

пятница, 1 апреля 2011 г.

Пятница 1-е

best-photo-gallery.co.cc
Что-то все работают, работают, работают и совсем забыли про то, что сегодня не просто пятница, а пятница - 1 апреля!!
А ведь это такой замечательный день!
Начать хотя бы с того, что в 1778 году Нью-орлеанский бизнесмен Оливер Поллок (Oliver Pollock) придумал знак доллара — $. Что бы мы сейчас без него делали? ))))

А в 1875 году английская «Таймс» стала первой в мире газетой, опубликовавшей недельный прогноз погоды. Теперь у нас есть целые телевизионные каналы, посвященные исключительно погоде.

Бесспорно, в 1944 году американская авиация нуждалась в тестировщиках, тогда она не разбомбила бы по ошибке швейцарский город Шафхаузен, и не погибло около 50 мирных жителей.

Во всем нужно искать хорошее, и даже в сообщении о том, что в 1998 году в Техасе в возрасте 34 лет умер кот Гранпа Рекс, самый старый кот в мировой истории. Почти все айтишники любят котов, а кот, живущий 34 года, - просто мечта!

В 2004 году открылась почта GMail от Google. А ведь кажется, что она была всегда!

Ну и, наконец, именно сегодня матфак Таврического Национального Университета празднует день факультета! Независимо от того, обидели их этим или нет - ура, товарищи!!! )))