пятница, 30 декабря 2011 г.

Традиционный новогоднего поздравления пост


Как-то принято подводить итоги уходящего года, но почему-то совсем не хочется этого делать :)) Хочется только поздравлять всех с тем, что достигнуто, желать исполнения всего задуманного на 2012 год и веселиться, веселиться, веселиться!
А еще спасибо всем, кто пришел на наш онлайн-корпоратив 27 декабря! Я даже не ожидала, что за сутки можно собрать в одном месте столько позитивчиков сразу ))) Все-таки тестировщики рулят )) И, кстати, они об этом знают, иначе откуда такие комментарии?
ура) мы молодцы)[Olesua Mazurchuk] 
 жжем)[Olesua Mazurchuk] 
у нас аццкая тестерская тусовка :)[Вадим Бердутин]  
спасибо за настроение! [Tatyana Durova]  
аццкий драйв! :)[Вадим Бердутин] 
вдохновительно. спасибо.[Evgeny Mukhin]  

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


Поздравления, которые не прозвучали в эфире, и не были написаны в твиттере, тут:
 всем привет из Магадана :)[Andrei Fralou]
Очень-очень хочу поздравить с наступающими праздниками все тестеровщиков и особенно  НОВОСИБИРСКИХ!) Удачи вам, побольше новых интересных багов и открытий! И побольше встреч на семинарах QA Sib)[Дария Ядренкина]  
всем привет из Минска :)[Вадим Бердутин] 
еще ижевску привет! =) с новым годом![Tatyana Durova]   
С наступающим всех!!![mas_mik asd] 

И от себя хочется добавить только:
С НОВЫМ ГОДОМ, ДРУЗЬЯ-ТЕСТИРОВЩИКИ!
До встречи в следующие 365 дней! ))))



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

Онлайн-корпоративу быть!


Дорогие друзья-тестировщики, а также те, кто мечтает стать тестировщиком, и даже те, кто еще не задумывался об этом!

В преддверии Нового года я приглашаю вас на тестерский онлайн-корпоратив, который состоится во вторник, 27 декабря, в 12-00 по Московскому времени.

Что нас ждет?
12:00 – 12:40 Ольга Киселева расскажет про тестирование игр на мобильных устройствах: мифы профессии и особенности тестирования.
12:45 – 13:00 Алексей Баранцев поздравит всех с наступающими праздниками и ответит на вопросы.
13:05 – 14:00 Татьяна Зинченко проведет мастер-класс по тест-дизайну (будем выделять подобласти и искать границы).
14:05 – 14:20 – Наталья Руколь поздравит всех с наступающими праздниками и ответит на вопросы.

Всё, что вы хотели узнать у Натальи и Алексея, но боялись спросить! :) Готовьте вопросы – задать их сможет каждый! А еще поздравить коллег и присутствующих с праздниками «в прямом эфире», получить новые знания и заряд позитива! Присоединяйтесь к нам!

Спешите, количество мест ограничено!
Участие бесплатное!
Для участия в онлайн-корпоративе зарегистрируйтесь по адресу: https://www1.gotomeeting.com/register/287071368

среда, 14 декабря 2011 г.

Новый Год уж близко, близко, и сердце бьется, как олень...

Товарищи тестировщики!
Новый год все ближе и ближе, а я все думаю мысль, которую писала тут: http://vestfalka.blogspot.com/2011/10/confet_21.html (про радио тестеров), а еще в твиттере (не знаю как дать ссылку на запись от 31 октября, но искать тут: https://twitter.com/#!/Vestfalka).
А было бы нам интересно собраться-таки онлайн?
Послушать умных людей, поздравить друг друга с праздниками? ))
В совершенно свободном формате: можно прийти, послушать, уйти, потом прийти еще раз ))
И, например, в таком виде:
Что-то полезное
Пауза с поздравлениями и музыкой
Что-то полезное
Пауза с поздравлениями и музыкой
И так далее...
И так часа 3-4 (чтоб все успели послушать и поприходить/поуходить).

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

В общем, высказывайте свое мнение :) Заодно: про время и дату - хочется же все пожелания учесть )))

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

Как я вредничала на SQA Days 10.

Трендом последних дней стало написание поста про прошедшие SQA Days в Москве. И я не стану исключением. ))
Для меня конференция началась в тот момент, когда Алексей Баранцев написал: "Хочешь стать членом программного комитета?" Вы б отказались? )))
Вообще Алексею (как, в общем-то, и всей чете Баранцевых) сложно отказать, когда он говорит о тестировании.
"Хочешь стать членом программного комитета?"
"Да!"
"Хочешь вести со мной тренинг?"
"Да!!!"
"Хочешь работать на моем проекте круглосуточно бесплатно и до конца дней своих?"
"Да! Да!! Да!!!"
Ну, как-то так. ))


понедельник, 28 ноября 2011 г.

(Вне)Очередная встреча тестировщиков? :)

Друзья мои (как любит говорить один мой дуал)!
А вот у меня возникла идея :)

Довольно часто мелькают сообщения: "Встреча московских/питерских/казанских/днепропетровских (нужное - подчеркнуть, недостающее - вписать) состоится там-то и тогда-то". А что делать тем, у кого в городе нет клуба тестировщиков? Ну или тем (признаемся честно хотя бы себе), кому лень куда-то идти на выходных или после работы?
У меня предложение: а давайте встретимся онлайн!
Соберемся в скайпе, побухтим, обсудим животрепещущие темы, может, даже послушаем кого-нибудь умного :)

Как вам такая идея? :)

Все мы родом из детства.

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

среда, 9 ноября 2011 г.

Учись учиться

Вычитала тут... В чем-то не согласна, а в чем-то: очень даже.
У нас не принято вложение в собственное образование считать инвестицией в собственное же будущее и благополучие. Может, этому виной перестроечное: "интеллигент вшивый" - когда получать образование даже как-то стыдно.
Может, причина в постперестроечном ВУЗовском образовании: когда получаем образование только для "корочки". У меня, например, диплом о высшем образовании требовали только когда я работала на госслужбе. А в ИТ - спрашивали только наличие высшего образования и то для галочки. Поэтому то, что их два (высших образований, а не то, что вы подумали), вообще как-то никого не волнует.

четверг, 27 октября 2011 г.

История возникновения баз данных.

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


Хождения по...

/* Все числа и даты выдуманы, любое совпадение с реальными людьми случайно */

На всякий случай предупредила сразу, а то вдруг кто-то особо обидчивый попадется, воспримет на свой счет, а мне потом прячь лицо и скрывайся по-всякому )))))

В общем, я про конференции хотела поговорить и про докладчиков. А что - имею право! Я в них и просто участвовала, и выступала, а теперь еще и в программном комитете одной из конференций состою.

понедельник, 24 октября 2011 г.

ConfeT&QA - завершающий этап.

Какой-то очередной мега-гуру обещал на сегодня конец света. Наверное, увидел где-то в своих затуманенных мозгах последний день ConfeT&QA и так расстроился, что не смог сдержаться.
А сегодня было на что посмотреть и что послушать.

Сначала Стас Косарев рассказывал про инструменты для майндмапов, чеклистов и тест-кейсов. Баги находились прямо онлайн ))) А я пополнила свой списочек must-to-use несколькими инструментами.
Потом Наташа Руколь, как всегда зажигательно, рассказала о способах оценки эффективности тестирования. Я не знаю как она это сделала, но когда мне казалось, что информации уже дан вагон и пора начать ее переваривать и осмыслять, выяснилось, что прошло только 10 минут ее доклада. Мистика ))))
Майкл Болтон рассказывал про проблемы тестирования и результаты тестирования. Признаюсь честно: где-то после 15-й минуты непрерывного английского мозг начал давать сбой и требовать отдыха ))) Но все равно было очень интересно послушать, посмотреть, выяснить ответы на вопросы и узнать контакты Майкла, по которым его можно теребить-теребить и теребить ))))

В твиттере уже возникли вопросы: будет ли следующая конференция?
И очень хочется знать: а будет ли? )))
А пока еще общаемся в форуме, задаем вопросы, делимся контактами и, конечно, выбираем лучших докладчиков и самого лучшего "спрашивающего" )))

пятница, 21 октября 2011 г.

Confet&QA - день четвертый

Прошло уже четыре дня с начала конференции. Лично мне с каждым днем все интереснее и интереснее становится ))) Записей в тетради все больше и больше, интересных инструментов, которые хотелось бы использовать, - тоже.
Первым докладчиком был Андрей Похилько с не испробованной еще методикой на конфе: записью своего выступления. Под такую "фонограмму" Андрей рассказывал про JMeter и лоадософию - мега-интересные для меня штуки, как для человека, интересующегося нагрузкой. Прямо-таки захотелось бежать и использовать, использовать, использовать! )))

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

А еще я вчера отвечала на вопросы, заданные в течение моего выступления. На все сразу ответить не получилось, к сожалению. Или к счастью, ведь если столько вопросов, значит, тема интересна ))) "Столько" - это 4 листа в ворде 12-м таймзом с полуторным интервалом )))) (это я тут немножко хвастаюсь).
Среди серьезных вопросов типа: "посоветуйте инструмент для такого-то языка" попадаются и совсем веселые: "На Software-testing.ru нужно организовать online радио с DJ Таня ;)". На первые уже ответила, вторые обязательно прокомментирую сегодня )))

Ну и сегодня у нас мега-интересный день! Даже не знаю, кого выделить: мне хочется послушать и Стаса, и Майкла, и Наташу ))) Буду ждать с нетерпением вечера.
Ну и  - спишемся в твиттере! )))

четверг, 20 октября 2011 г.

Confet&QA - экватор пройден!

День третий завершен. Экватор пройден! :)

Игорь Любин рассказывал про PowerShell и у меня в тетрадке появилась запись: разобраться с PowerShell. )))
Алексей Лупан, как всегда, выделился нестандартным подходом к вопросу. Во-первых, у него на рабочем столе - старая молдовская газета, название которой все айтишники читают первый раз как "Молдова Нулл" и очень при этом веселятся ))) А во-вторых, он читал доклад совершенно без слайдов - исключительно на живых инструментах, и исключительно интересно. И, между прочим, вселил в меня надежду, что не Selenium RC един человек. Selenium IDE тоже имеет право на существование и полноценное использование :)))))
Потом докладывалась я. Рассказывала про фаззинг и один из его иструментов - RATS. Надеюсь, что было интересно и понятно. И хотя сама себя оценивать не могу - уже напросилась на независимую и непредвзятую оценку одного из со-слушателей конференции.)))
Сегодня был не менее интересный день, подробнее о котором напишу завтра )))
А чай был черный с ванилью ))))

среда, 19 октября 2011 г.

ConfeT&QA - два дня позади

Минул второй день онлайн-конференции. Становится все интереснее слушать доклады - появляются даже предположения, что к пятнице мы все познаем дзен.
Обсуждение в твиттере становится все активнее и острее, но все равно весело. Пусть кусают локти все, кто не с нами )))
Вчера мы слушали Николая Юденко с докладом про явные и неявные требования. Я вот слушаю уже не первого докладчика от Люксофта и все они у меня ассоциируются со словом "преподаватель". Вот и тут в твиттере промелькнуло слово "лектор", видно, коллективный разум все же существует ))) Но сам доклад был интересен и прошел под общим девизом: "Перед тестированием включи мозги!"

Порадовал Андрей Мясников со своими особенностями юзабилити-производства. Он положил начало бурному твит-обсуждению уже с самого своего приветствия: "Меня зовут Андрей и я - тестировщик". Обсуждение было настолько фееричным, что некоторые даже начали задумываться о том, чтобы отозвать свои доклады даже с SQA Days, боясь такого "беспощадного гласа". Я вот тоже задумалась о своем сегодняшнем выступлении.)))) Закончил Андрей тоже феерично: "Давайте представим иерархическую лестницу которая сейчас появилась у меня в голове". И, что самое интересное, некоторые же представили! Семимильными шагами движемся к просветлению, товарищи!

Закончился день докладом Алексея Лянгузова про интенсивный тестовый цикл с неграми-тестировщиками и веселыми человечками с дырками в животе. Реально ли запланировать аврал?.. Алексей, как изобретатель методики, минусов в ней не нашел. ))))) Логично ))
Думаю, сегодня нас ждет не менее интересный день. Во всяком случае, список докладчиков лично меня радует ))) Ну а перед своим докладом надо постараться и как-нибудь уронить твиттер )))
Всем до встречи!
Услышимся!

ЗЫ. А чай сегодня зеленый с мятой )

вторник, 18 октября 2011 г.

Confet&QA - пятая часть конфеты тестирования сгрызена!

Чай сегодня не зеленый, но все равно очень вкусный: с корицей и гвоздикой. Настраиваюсь на новый конфетный день.
Вчерашний день порадовал техническо-направленными докладами. Илья Фомин рассказывал так понятно про "$intTotal полезных советов по логгированию автотестов", что даже мне стало предельно ясно.По итогам вчерашнего дня и с легкой руки BarbariсQA Илья теперь - человек, который умеет ставить правильно стрелочки на диаграммах.
Андрей Дзыня разговаривает в стиле многих моих знакомых программистов. Может, таки прав тот, кто говорит, что когда тестер начинает кодить - у него меняется мышление? Но опять же - все понятно и доступно. Хоть просто счас бери и начинай использовать Селениум. С Эклипсом такой уверенности уже, правда, нет ))))
Послушала еще доклад Геннадия Алпаева про TestComplete - надо же знать, что творится во "вражеском" лагере )))))

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

Встретимся на сегодняшних докладах! Будет здорово!

понедельник, 17 октября 2011 г.

Готовность номер один!

Считанные часы остались до онлайн-конференции ConfeT&QA. Конфеты закуплены, чай сделан с запасом, наушники подключены, мозг в ожидании новой и бесконечно полезной информации. :))))

Ура всем, кто будет с нами эту неделю ))) Услышимся и спишемся уже через несколько часов, вместе погрызем конфету науки )))
Ну и опишем то, что у нас происходит, в твиттер по хештегу #confetqa.

P.S. Реклама фирм, производящих мышки и ноутбуки, не проплачена, можно не обращать внимания :)

вторник, 11 октября 2011 г.

Дайте мне точку опоры и я изменю процесс

Еще со времени моего выступления на SQA Days в Казани мне хотелось поднять эту тему. Ну вот совсем не ожидала я, что в большинстве айтишных фирм одни и те же проблемы. Притом, вне зависимости от размера этих фирм: 20 в ней человек или 120, или 320. Иногда мне даже кажется, что у нас проблемы не в конкретной компании, а в отрасли в целом, но я гоню от себя эту шальную мысль.
Итак.
О чем это я? А я о процессах. Таких модных сейчас и актуально-гибких. А еще конкретнее: о процессе разработки фичи.

четверг, 15 сентября 2011 г.

Утренняя радость тестировщика






Вот такой прелестью порадовал (и продолжает радовать) gmail с утра ))) День задался!
Доброго дня и хорошего настроения всем ))

четверг, 8 сентября 2011 г.

О мастерах и интернетах ))

День тестировщика только завтра, а подарки сыпятся прям сегодня. ))) Хотела завтра об этом написать, но "держаться нету больше сил". )))

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

вторник, 23 августа 2011 г.

Про тест-дизайн и про все остальное...

Когда-то я была еще начинающим тестировщиком, занималась только мануальным тестированием и написание документации меня напрягало: зачем она нужна, если можно спросить у программиста, потом проверить и завести багу? Тест-кейсы еще писать какие-то, чек-листы...
Потом я стала более опытным тестировщиком, начала посещать тренинги... И, конечно, я выбирала "правильные" тренинги: как нагрузить систему, как тестировать безопасность, как автоматизировать... Зачем мне, например, какой-то там непонятный тест-дизайн или стандарты в тестировании?..
А потом я стала еще более опытным тестировщиком и стала задумываться: почему вот я такой уже "более опытный тестировщик", а мой тим-лид сходу в уже проверенном мной функционале находит ошибки?Я старалась запомнить какие именно данные он вводит, но на других частях функционала они работали, а вот именно тут - все валили. А почему?
Нет, я не буду писать историй в стиле "а потом я увидела тренинг "Практикум по тест-дизайну" и это стало панацеей от всех бед". Расскажу пару историй из практики.

пятница, 12 августа 2011 г.

И снова про SQL для тестировщиков ))

Когда мне предложили вести курс "SQL для тестировщиков" я не смогла отказаться. ;) Но задумалась: а что вообще должно быть в этом курсе? Чем он должен отличаться от тех курсов, которые проходят на любой специальности, связанной с ИТ: "Системы управления БД" и "SQL"? Ответы на многие вопросы я нашла в своей практике, но решила все же проверить правильны ли мои догадки.

Так появился опрос на Хабре и статья по его результатам.
Как они показали: вопрос и вправду неоднозначный. Кто-то считает, что знания SQL вредят тестировщикам, кто-то наоборот: что без них процесс тестирования неполноценен. Кто-то говорит, что SQL нужен только продвинутым тестировщикам для автоматизации, кто-то - что SQL не повредит и начинающим. Кто-то считает, что эта тема высосана из пальца, кто-то - что она важна. Сколько людей - столько мнений.

Ну а изучать SQL или нет каждый решает сам для себя :)

среда, 13 июля 2011 г.

Конфетка сезона

Наверное, я неправильный тестировщик. Или начало моей карьеры сказалось на мне таким образом, но мне недостаточно просто верифицировать соответствие или несоответствие тестируемого функционала требованиям. Мне нравится проверять программу на устойчивость, выявлять ее слабые стороны, искать не только "мы не подумали" или "мы забыли", или "мы предусмотрели, но забыли реализовать", но и то, что было предусмотрено, о чем было подумано и не забыто, но что все равно является "слабым звеном". Наверное, именно поэтому больше всего я люблю нагрузочное тестирование и тестирование безопасности.

среда, 6 июля 2011 г.

Ценность тестировщика: показать и рассказать.

Задумалась недавно над вопросом: а несет ли тестирование ценность и как рассказать об этом заказчику? Не секрет, что во многих фирмах тестировщиков нет именно потому, что "они только по кнопкам бездумно клацают, деньги на них тратишь, а реальной прибыли - никакой!"
И, как частенько происходит, на глаза попалась статья в тему: в блоге Джонатана Кохля (Jonathan Kohl) наткнулась на его старенькую, но все еще актуальную статью "How do I create value with my testing". Читается она очень легко, вряд ли есть смысл переводить полностью. Но есть одна идея, которая мне в свое время очень понравилась :)))

четверг, 16 июня 2011 г.

Как отдохнуть тестировщику?

Я уже давно привыкла с словосочетанию "тестерская карма". Но каждый раз удивляюсь, как ребенок, натыкаясь на очередную багу. :)

Вот и недавно. Отпуск мы запланировали давно, подогнали его под МХМ, который ежегодно проводится в Крыму. А тут решили заказать номер в пансионате.

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

вторник, 14 июня 2011 г.

"Deadline" взглядом тестировщика.

На днях прочитала широко известный в узких кругах "Роман об управлении проектами" Тома ДеМарко.

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

четверг, 9 июня 2011 г.

О преодолении границ.

Как всегда, в начале - ликбез ))))

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

понедельник, 16 мая 2011 г.

Организация процесса тестирования.

Когда-то страшно гордилась тем, что именно меня программисты забрали на новый проект. С течением времени от "страшно гордилась" осталось только "страшно". В лучших традициях гибких разработок нас на проекте шестеро (включая Project Owner и меня). И в лучших традициях тимлидами мы не обзавелись. А, значит, я сама себе аналитик, QA-лид и тестировщик. И если на первом проекте отсутствие первых двух было не так заметно, то тут времени на анализ стало больше. А, значит, и времени "побояться" тоже.

Итак, вопрос: чего у нас на проекте нет? Ответ: ничего у нас нет (подразумевается организация процесса тестирования). Встает вполне привычный вопрос всех времен: "Что делать?"

среда, 4 мая 2011 г.

Моя презентация на SQA Days 2011 в Казани.


Презентация
View more presentations from Tatiana Zinchenko

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

четверг, 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 как флага является эффективным решением для переключения между автоматизированными оракулами и позволяет нам создавать отдельные автоматизированные тесты. Даже с таким подходом я задаюсь вопросом: вызывает ли неожиданную ошибку комбинация недопустимого значения с допустимым входным значением, или, может, это ошибка какого-то одного модуля. Но если я действительно не знаю как недопустимые входные значения проверяются перед передачей соответствующей функции, тогда включение недопустимых значений в нашу модель может также увеличить общее покрытие тестами и повысить нашу уверенность, или теоретически раскрыть несколько действительно случайных ошибок!