Just Test It!

Сегодня весны не будет!

2012-02-29T09:09:00.001+02:00

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

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

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

Пока другие думают - делай! :)

Онлайн Сообщество анонимных тестировщиков приглашает друзей :)

2012-01-26T15:20:00.000+02:00

Кто чем будет заниматься в воскресенье, 29 января 2012 г., в 13-00 по Москве, а мы собираемся послушать Анастасию Лемешко с докладом по юзабилити. Настя добилась совершенно здоровских результатов по юзабилити для своего проекта и у нас есть шанс послушать как она это сделала.
Куда и приглашаем всех, кому интересна эта тема :) Обещает быть весело и познавательно )))
Места для регистрации пока еще остались тут: https://www1.gotomeeting.com/register/624446865.
Регистрация бесплатная, поэтому если в процессе Вам кто-то предложит отправить СМС на короткий номер - не ведитесь на провокации! ))

Как это было...

2012-01-23T09:09:00.028+02:00

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

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

2011-12-30T15:42:00.000+02:00

Как-то принято подводить итоги уходящего года, но почему-то совсем не хочется этого делать :)) Хочется только поздравлять всех с тем, что достигнуто, желать исполнения всего задуманного на 2012 год и веселиться, веселиться, веселиться!
А еще спасибо всем, кто пришел на наш онлайн-корпоратив 27 декабря! Я даже не ожидала, что за сутки можно собрать в одном месте столько позитивчиков сразу ))) Все-таки тестировщики рулят )) И, кстати, они об этом знают, иначе откуда такие комментарии?

ура) мы молодцы)[Olesua Mazurchuk]

жжем)[Olesua Mazurchuk]

у нас аццкая тестерская тусовка :)[Вадим Бердутин]

спасибо за настроение! [Tatyana Durova]

аццкий драйв! :)[Вадим Бердутин]

вдохновительно. спасибо.[Evgeny Mukhin]

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

Поздравления, которые не прозвучали в эфире, и не были написаны в твиттере, тут:

всем привет из Магадана :)[Andrei Fralou]

Очень-очень хочу поздравить с наступающими праздниками все тестеровщиков и особенно НОВОСИБИРСКИХ!) Удачи вам, побольше новых интересных багов и открытий! И побольше встреч на семинарах QA Sib)[Дария Ядренкина]

всем привет из Минска :)[Вадим Бердутин]

еще ижевску привет! =) с новым годом![Tatyana Durova]

С наступающим всех!!![mas_mik asd]

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

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

2011-12-26T10:49:00.000+02:00

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

В преддверии Нового года я приглашаю вас на тестерский онлайн-корпоратив, который состоится во вторник, 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

Как я вредничала на SQA Days 10 (Часть II)

2011-12-24T23:05:00.000+02:00

Вот так вот я вредничала про юзабилити принципы на юбилейных SQA Days в Москве.

Warning! Heavy sarcasm may be present!

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

2011-12-14T10:23:00.000+02:00

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

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

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

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

2011-12-05T13:05:00.000+02:00

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

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

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

Воообще, я нигде столько не общалась, сколько на этой конференции. Жутко приятно было видеть моих ребят с SQL, тех, кому я помогала готовиться к конфе, тех, с кем уже давно и интересно переписываемся в различных твиттерах и соц сетях :) Море эмоций и позитива именно от кулуарного общения на SQA Days.

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

Второй день для меня начался с чая, общения с интересными людьми и вопроса: "Что делать с тем, что конференции онлайн так сильно отличаются от оффлайновых?".
Первый доклад, на который я пошла, был "Impact Analysis в тестировании" Анны Шеретовой. Доклад заинтересовал меня еще на стадии подготовки к конференции, но его успели "перехватить" до меня )) Интересная идея была у Анны, я даже задумалась о ее внедрении. Но тут помимо тестерского желания должен быть еще и соответствующий уровень разработчиков, иначе такая затея не имеет смысла.
Дальше в зале А слушала Александра Ильина с докладом про "Полезные метрики покрытия. Практический опыт и немного теории". У Александра очень успокаивающий голос что мне в тот момент (2 часа теперешней разницы во времени-таки сказывались) казалось основным препятствием на пути понимания всех тех мега-интересных вещей, которые он рассказывал. А примеры кода со словами: "Вот тут у нас ошибка в коде" заставляли еще и понемногу шевелиться непроснувшиеся еще мозги.
После обеда пошла на круглый стол Екатерины Ремизовой сотоварищи про "Сообщества тестировщиков. Старт дан. Что дальше?" Было особенно интересно прослушать про чужой опыт в свете того, что и сама хочу сделать нечто подобное, правда, онлайн. Думаю, скоро будем встречаться: нам есть о чем поговорить )))
Была на мастер-классе Алексея Петрова "Удаленное тестирование. Советы бывалого фрилансера". Ничего нового для себя не услышала в процессе доклада, но зато посмотрела на еще одного такого же трудоголика, как сама ))) Работа по 12-14 часов в сутки - наше все. Правда, Алексей рассказал и чем это закончилось для него. Пришлось задуматься о последствиях. После доклада подошла к нему с одним вопросом, который меня волновал больше всего: если убеждать заказчика в том, что ему нужно тестирование, то как не перейти ту грань, после которой заказчик считает, что тестирование поможет избавиться ему от ВСЕХ багов на проекте. Интересное получилось обсуждение.
Потом народ пошел на Орловапанкратова :)), а я - слушать Евгению Фирсову из Яндекса с докладом "Очередь на тестирование". На одном из своих проектов мы изучали проблемы очередей и даже успешно их решили и мне хотелось посмотреть как это происходит в Яндексе. Все чаще настигает мысль, которую усиленно гоню от себя: "Проблемы не в конкретной компании, а в отрасли в целом"...Собственно, после доклада мысль опять появилась, и я ее до сих пор думаю...
Потом пошла на стендовую секцию. Народа там было уже поменьше и я умудрилась даже услышать двух Алексеев: Лупана и Лянгузова. Рассказ Алексея Лянгузова уже видела на ConfeT&QA, а вот записи рассказа Алексея Лупана буду ждать, чтоб просмотреть еще раз.

И в заключение.
Спасибо еще раз всем тем, кто был с нами все эти 2 дня!
И огромная благодарность тем, кто был в первый день с 17-35 в секции В. Вы - мегапозитивные люди :)))

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

2011-11-28T21:04:00.000+02:00

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

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

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

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

2011-11-28T12:10:00.000+02:00

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

У меня есть сестра, с которой мы переписываемся с 1 класса. И она хранит письма от меня за все это время. Самым старым из них больше 20 лет! На одном из первых написано прям на конверте: "Ира сохрани это письмо. И вообще храни мои письма. Таня" (орфография и пунктуация автора сохранена полностью. Прошу учесть, что автор в 1 классе!)

Далее текст приводится полностью (курсивом - комментарии)

Здравствуй, Ира!
Пишу тебе письмо. Твое письмо я получила 5 ноября. Странно, почему ты не задаеш вопросы о делах в школе? (явное любопытство тестировщика)
У меня, в голову всё, как всегда лезет а? А? (тут я не поняла, что имела в виду)
Вот ты пишеш "Хочеш, я тебе следующее письмо напишу на украинском языке"? Конечно хочу! Скажи к тебе мои письма приходят с печатью или нет? на обратной стороне конверта. (явные зачатки общения с бета-тестерами)
Интересно как у вас на украине пишется слов "сделаешь"? Об этом напишеш в следушем письме. (тут уже пошли управленческие навыки)
А почему ты в слове Симферопольский пишеш р-н а марьинский пишешь район? Ира почему во всех письмах твоих написано "Зинченко нине григорьевне (для тани)" ав этом письме просто "Зинченко Тане"? (юзабилити тестирование однозначно!)
До свидания. Пиши.
11.07.90год

Ну и письмо, которое явно подтверждает, что тролль родился вместе со мной ))

Здравствуй Ира
Пишу тебе письмо.
Мы доехали хорошо. Я приеду на лето.
После того, какмы, приехали я села писать тебе письмо.
Ира ответь почему ты не пишеш на конверте свой адрес?
Я забыла тебе сказать я очень хочу кота если будет увас подариш? Или пса. А я не знаю где буду жить у вас или у бабушки. Мама говорит у вас ая у бабушки.
Ира пиши на конверте свой адрес.
Пока.

(и еще раз, видимо, для закрепления полученной информации, я написала "Пиши на конверте свой адрес" возле нарисованной на обороте листа принцесски)

Собственно, в таком стиле были все письма первых полутора лет. Ключевая фраза: "А теперь мои вопросы!"
Привычка доставать программистов вопросами сохранилась и по сей день.
Некоторые вещи неизменны..

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

2011-11-09T09:09:00.003+02:00

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

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

Ну и решила я спросить: а вы сколько готовы тратить на свое обучение? И готовы ли вообще тратить? Или ИТ для вас - только перевалочная база, а вообще вы мечтаете стать тренером по фитнесу/заполярником/вампиром из "Сумерек"?

Если вы готовы тратить, то на что? Что вам интересно, за что вы готовы платить и на какие курсы готовы тратить свое время?

/*тут стоит сделать небольшую ремарку. В последнее время все популярнее автоматизация тестирования и многие хотят стать крутыми автоматизаторами. Притом, недавний опрос, проведенный мной, показывает (выборка небольшая, так что прошу простить), что около 30% программистов и почти половина ПМов недовольны тем, как тестировщики заводят баги. Понятно, что хочется расти в автоматизаторы и получать больше, но нужно же реальнее смотреть на вещи*/

Как часто вы уделяете время своему самообразованию и каким образом это делаете? Посещаете ли курсы потому, что "компания послала, значит, нужно идти".

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

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

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

2011-10-27T22:20:00.000+03:00

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

Некоторые источники рассматривают историю возникновения баз данных начиная с древних времен и всех тех подручных средств, при помощи которых хранились и обрабатывались данные. Так, к первичным базам данных причисляются: узелковая письменность инков или средства хранения и учета казны у Шумеров. Хотя, скорее всего, такие средства можно причислить к собственно "письменности" или "архиву", но не к базам данных.

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

Сам термин "базы данных" (database) был введен на симпозиумах ,организованных фирмой System Development Corporation (SDC).

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

Тогда для участия в проекте Apollo правительством США была привлечена компания Rockwell. Для того, чтобы построить космический корабль, как многие, наверное, догадываются, нужно собрать несколько миллионов деталей. И в те далекие времена была создана система управления файлами, которая отслеживала информацию о каждой детали. Но когда решили проверить эту систему, то обнаружили, что данные в ней повторяются по нескольку раз. Налицо была огромная избыточность.
К сотрудничеству была привлечена и небезызвестная IBM, и в 1968 году была разработана автоматизированная система заказов (Information Management System - IMS), которая и заложила основную концепцию СУБД. Кардинальным нововведением было разделение функций деловой логики и данных, т.е. программисты смогли работать с информацией на логическом уровне, при этом база данных выполнянла функцию физического хранения. Это позволило существенно повысить производительность труда.
Эта СУБД существует и до сих пор, в ней реализована иерархическая модель данных. Такая модель данных имеет только один путь от корня к каждой ветви (записи). Она не только стала основой для систем управления данными, но и в последующем послужила причиной многих усовершенствований ввиду своей ограниченности.

Следующий большой шаг в истории развития баз данных сделал доктор Эдгар Кодд (Edgar Codd) - научный сотрудник все той же самой небезызвестной IBM. В 1970 году он опубликовал свою работу "Реляционная модель для больших банков совместно используемых данных", которая в корне изменила теорию баз данных. А еще принесла доктору Кодду премию Тьюринга.
В реляционной модели, придуманной Коддом, данные можно было свободно описывать в их естественном виде, без каких-либо ограничений, которые накладываются средой физического хранения. Это позволило создать язык высокого уровня, который может работать с данными вне зависимости от того, как именно они хранятся.
Первыми СУБД с реализацией реляционного модуля стали System R от уже неоднократно известной IBM и Ingres от Калифорнийского университета.
В это же время появился и структурированный язык запросов, но это уже совсем другая история. :)

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

2011-10-27T09:09:00.001+03:00

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

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

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

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

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

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

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

Почему-то в бытность свою начинающим тестировщиком ходила или на первые, или на вторые. Казалось, что третьего не дано. Ну а сейчас вот стараюсь ходить только на третьи )))

И еще про докладчиков. Ложка дегтя )))
/*все нижесказанное пишу на свой страх и риск*/
Напрягают ли вас нижеследующие моменты в докладах так, как они напрягают меня? ))

Например, меня напрягает, когда докладчик превозносит свое: "у меня опыт в тестировании 7 (10, 12, кто-больше) лет!" Не просто говорит, а именно ставит себе в заслугу. "Да я 5 лет в тестировании, молчи, сопляк 4,5-летний!" Ну вот и о чем нам (слушателям) должно это сказать? О том, что ты в отрасль пришел раньше? И что? У меня есть знакомые тестировщики, у которых опыта меньше, чем у меня, но мне уже есть чему у них поучиться. Есть знакомые тестировщики, которые вдвое дольше в отрасли, но я уже могу их научить многому. Какая кому разница сколько лет ты протираешь штаны в компании? Может, ты там 5 лет сидел и на одну кнопочку жал, а потом за 2 месяца книжек начитался. Я как-то собеседовала тестировщика с гораздо большим опытом, чем у меня, работающего в гораздо более крупной фирме и явно зарабатывающего больше. Я страшно боялась идти на это интервью. Ну а вдруг он меня там и опозорит. Нет, не так: ОН меня и опозорит. Я была страшно разочарована уровнем его знаний...

Еще очень напрягает: "Я работал тестировщиком в стольких-то городах/странах/компаниях!" Хочется спросить: "И что?" Сейчас в моей жизни такой период, что примерно пару раз в неделю мне предлагают работу. В крупных фирмах и больших городах. Но мне нравится мой город, мне нравится фирма, в которой я работаю. Я не собираюсь по два раза в неделю менять их. И это теперь что - автоматически значит, что я чем-то хуже? Или мне перед докладом объявлять: "Я сегодня отказала Гуглу, а вчера - Рамблеру!" Я от бабушки ушел, я от дедушки ушел, блин... Странная логика...

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

Я себе сейчас такую Дюдюку Барбидонскую напоминаю ))) Но во мне эта тема второй день живет, значит, можно писать )))
Ну и напоследок: кого еще что-то не устраивает? Давайте обсудим! )))

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

2011-10-24T09:09:00.002+03:00

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

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

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

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

2011-10-21T11:20:00.002+03:00

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

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

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

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

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

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

Ну и - спишемся в твиттере! )))

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

2011-10-20T19:53:00.000+03:00

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

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

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

2011-10-19T10:50:00.001+03:00

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

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

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

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

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

2011-10-18T09:16:00.000+03:00

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

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

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

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

2011-10-17T10:30:00.000+03:00

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

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

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

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

2011-10-11T09:49:00.001+03:00

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

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

Итак, возьмем в качестве примера процесс разработки простейшей фичи на 2 стори-поинта
(для простоты определим их равными 16 человеко/часам) по скраму.

Предположим, что процесс разработки у нас выглядит так:

Из имеющихся 16 часов на разработку 2 у нас занимает анализ, 2 - проектирование, 8 - разработка и 4 - тестирование. Допустим, что написание контента, работа дизайнеров, верстальщиков и пр. включены в разработку.

Предположим, что тестировщики нашли баг. Или даже баги. Наш процесс разработки сразу же перестает быть идеальным и начинает выглядеть так:

Фича возвращается на доработку программистам и сразу же оказывается на доске на шаг назад, т.е. снова в стадии Разработка. И вот тут начинается самое интересное. Допустим, что баги у нас не очень большие и критичные. И еще допустим, что программист еще не успел переключиться на контекст другой задачи, и тихо-мирно пьет чай или ничего не подозревая играет в какой-нибудь теннис. Или все по очереди - 4 часа все-таки тестирование занимало.
В общем, нам повезло, мы словили программиста с незанятыми мозгами и посадили его править баги. Допустим, он смог их исправить за 2 часа. И еще час нам нужен на регрессию.

Итого общее время разработки фичи получается уже не 16 часов, а 19. Казалось бы: ну и что? Подумаешь, 3 лишних часа!
Но ведь у нас - идеальная фича! Мы еще не учли, что из стадии разработки фича может вернуться, например, на стадию проектирования. Или что у программиста прорвало трубу и он срочно убежал домой улыбаться сантехникам. Или даже вот такую ситуацию (взято из реальной жизни, кстати):

Как такое происходит? Все очень просто. Релиз здесь равняется показу заказчика (или ПМу). И он (заказчико-ПМ) сообщает, что вообще все себе не так представлял! И что дизайн надо поправить в 20 местах, тексты переписать, а вот тут не покупка должна быть, а продажа. Ну и мало ли что еще бывает в головах у ПМов :)
Несложно подсчитать, что на разработку фичи у нас уходит уже 19+19 = 36 часов (потому что возвраты на тестирование никто не отменял). 36 часов на простейшую 2-поинтовую фичу.

Что делали в свое время мы.
Сначала мы постарались избавиться от этих "возвратов".
Чтобы не было возвратов в этап анализа, мы стали проводить его только при участии всех заинтересованных лиц (ПМа, разработчика, тестировщика и пр.).
Чтобы не было возвратов на этап проектирования, оно проводилось при участии как минимум 2 разработчиков.
Чтобы снизить количество возвратов на этап разработки активнее использовались unit-тесты, парное программирование и даже (!!!) TDD.

А сколько часов на возвратах теряете вы? ;)

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

2011-09-15T10:43:00.000+03:00

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

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

2011-09-08T15:38:00.000+03:00

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

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

Фабула: весь в проводах и документах, мастер уверенным шагом прошел к компьютерному столу и сел. Строго спросил: "Что это у Вас?" - глядя на открытый браузер с проектом. "Да это так, работаю я" - пропищала я, подавленная величием мастера. "Я вот Вам открыть хотела... - начала было, но запнулась, -"Вам вообще какой браузер нужен?"
"Да мне все равно, - строго глядя, ответил мастер, - можно гугл, можно яндекс!"
Не полагаясь на собственный слух я переспросила: "Браузер? Фаерфокс? Интернет-эксплорер?"
"А, браузер! Можно гугл" - отрезал мастер.
Уже не надеясь на улучшение скорости интернета, я обреченно открыла мастеру Хром, где было всего 2 вкладки (в отличие от нескольких десятков в ФФ).
Уверенной рукой прямо на вкладке рабочего проекта мастер открыл гугл и ввел в поиск слово "speedtest". Смело открыл первую же найденную ссылку и прошел по ней.
Запустил.
Строго посмотрел: "Хозяюшка, а чем Вас не устраивает скорость?"
На экране гордо светилось 18 на получение, 10 на отдачу. Провод от оборудования фирмы мастера тоскливо лежал рядом с ноутбуком.
"Так это же вай-фай, и фирма другая, вот же Ваш провод!" - робко воткнула провод в ноутбук. Мастер строго посмотрел, вытащил провод, осмотрел его и воткнул заново. Запустил спидтест еще раз. Результат оказался вдвое ниже на получение, а на отдачу и вовсе 0,4 Мбит.
Уже не надеясь на адекватный ответ, все же спросила: "А почему скорость на отдачу такая маленькая?"
Медленно, с расстановкой, будто говорит с душевнобольным детсадовцем, мастер прояснил: "Мы контролируем только скорость получения. Скорость отдачи мы не контролируем!"
Потеряв веру в свои ИТ-знания, спросила: "А кто контролирует?"
"Вы сами на своем ноутбуке контролируете!" - снисходительно посмотрел мастер.
"А как мы ее там контролируем?"
Устав от назойливых вопросов туповатой хозяйки мастер повторил еще, на этот раз еще медленнее: "Мы контролируем скорость входящую, у Вас она 9,4, что как раз и есть "до 10". А исходящую скорость мы не контролируем, Вы ее сами на своем ноутбуке контролируете. Еще какие-то претензии есть?"
Какие могут быть претензии, когда все и так ясно?
Посрамив очередного клиента глубиной своих знаний, гордый мастер ушел от туповатой хозяйки нести свет интернета и компьютерное просвещение в другие квартиры. Рабочий день только начинался.

Как-то таг... )))

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

2011-08-23T09:59:00.000+03:00

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

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

В теме о том, какие темы было бы интересно услышать на юбилейной SQA Days'10 сходу появилось такое вот мнение:

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

Эту фразу я прочитала уже очень давно, но она все не идет у меня из головы. Потому что ею одной выражено почти все состояние отрасли тестирования! Я вспоминаю проекты, на которых я занималась тестированием. Написание тестовой документацией всегда было проблемой как минимум для нескольких человек в команде.

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

Почти в каждой вакансии на должность тестировщика выше junior уровня требуется умение писать тестовую документацию. Об этом умении лично меня спрашивали на собеседовании в числе первых вопросов. Я сама спрашивала об этом на собеседованиях у соискателей.

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

Один мой очень хороший друг-программист написал как-то (в ответ на другой вопрос, но все же):

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

Собственно, то, что программисты называют "особенностями мышления", есть ни что иное, как страсть к исследованиям + навыки тест-дизайна.
Господа присяжные, у меня все! ))

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

2011-08-12T10:48:00.000+03:00

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

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

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

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

2011-07-13T12:05:00.000+03:00

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

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

Фаззинг - это процесс отсылки намеренно некорректных данных в исследуемый объект с целью вызвать ситуацию сбоя или ошибку. Настоящих правил фаззинга нет. Это такая технология, при которой успех измеряется исключительно результатами теста. Для любого отдельно взятого продукта количество вводимых данных может быть бесконечным. Фаззинг - это процесс предсказания, какие типы программных ошибок могут оказаться в продукте, какие именно значения ввода вызовут эти ошибки. Таким образом, фаззинг - это более искусство, чем наука. ("Fuzzing. Исследование уязвимостей методом грубой силы.")

И когда мне предложили участие в качестве докладчика в конференции ConfeT&QA - я не смогла отказаться. :)))) Русскоязычных источников по фаззингу не так много, а говоря откровенно: очень мало. Я постараюсь стать очередным таким "источником" и рассказать все самое "конфетно-вкусное" от основ и до использования конкретных инструментов. Фаззинг - это невероятно увлекательно!

А вообще программа еще формируется. Окончательную организаторы представят только за месяц до начала конференции, но из тех 6 докладов, что там есть уже сейчас, я хочу пойти на все 6! Благо, однопоточный формат конференции мне это позволит. :)))
А еще это будет осень, у меня за окном будет шуметь пожухлой листвой каштановое дерево, будет журчать небольшой водопадик на речке через дорогу, а я буду сидеть укутаная в плед, с чашкой горячего зеленого чая и самыми вкусными конфетами, которые найду в городе, с ноутбуком на коленях и буду слушать доклады именитых тестировщиков всея Мира. Совмещать приятное с приятным.
Согласитесь, такое себе можно позволить не на каждой конференции :)))

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

2011-07-06T15:37:00.000+03:00

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

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

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

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

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

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

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

2011-06-16T15:25:00.000+03:00

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

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

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

Возвращаюсь на сайт. Захожу на форму бронирования номеров. Заполняю. Жму "Отправить". Получаю пустую страницу. Возвращаюсь на предыдущую, заполняю заново, жму "Отправить". Получаю пустую страницу. Нажимаю все известные мне комбинации F5, Ctrl+F5 и иже с ними. Все та же радостная пустая, белая страница.
Прошу заполнить и отправить форму мужа - все-таки он программист, а я помню про тестерскую карму. Он заполняет, отправляет - тот же результат.

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

На этот раз отправка происходит успешно.

Примерно через несколько часов мне звонят и сообщают, что ВСЕ мои запросы к ним дошли (чуть больше 10 штук - я упорная), и форма бронирования номеров уже пофикшена.
Зато теперь они не могут отправить письмо с реквизитами мне в ответ!!!!!!

Договорились, что до августа еще далеко и время для фикса ответного письма у них еще есть :)))

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

2011-06-14T12:41:00.000+03:00

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

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

Угрозы - самый неподходящий вид мотивации, если вас волнует производительность сотрудников.

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

Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Ну, тут все просто. Об этом знаешь, это - прописная истина, но все равно почему-то часто забывается. Надо распечатать и повесить над рабочим местом. :)))

На людей можно надавить, но это не заставит их быстрее соображать.

На этой фразе мне вспомнился мой опыт работы на госслужбе. Вспомнился, вздрогнулся и попытался забыться опять. )))

Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.

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

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

Мы уверены, что регрессионное тестирование необходимо. Даже если оно не выявило багов в этой итерации, мы будем повторять его в следующей, потому что оно важно. А действительно ли оно важно? А если оно не выявит багов в -цатой итерации, стоит ли повторять эти тесты и тратить на них столь драгоценное в тестировании время?

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

2011-06-09T15:17:00.000+03:00

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

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

А теперь сама история.

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

Boundary Testing Forever!

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

2011-05-16T14:42:00.000+03:00

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

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

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

Кто-то очень умный сказал: "Все, что бы ты не придумал, уже было придумано кем-то раньше". Вот и я наткнулась на статью I've Just Been Assigned To Manage Testing, What Next?, которая не потеряла своей актуальности и до сих пор, хоть и была написана еще в 2007 году.

Если бы я встретила ее раньше, то могла бы сразу сказать с чего начать. Сейчас же просто подведу итоги. А кому-то, может, пригодится )))

Итак, для эффективного начала управления тестирования необходимо несколько активностей:
- Определение стратегии тестирования;
- Составление Тест-плана;
- Подготовка Тест-скриптов;
- Выполнение Тест-плана;
- Изучить Метрики.

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

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

Тест-скрипты в каждой фирме выглядят по-разному. Я взяла за основу то написание скриптов, которому научилась когда-то, работая на американцев. Используется простейший Excel, в который заносятся стандартные 3 столбца, а во время выполнения приписывается четвертый столбец с датой и идентификацией проверяющего.
Тест-скрипты - это то, что я умела делать изначально. Поэтому у нас они появились еще до того, как появились тест-планы. )))

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

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

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

2011-05-04T12:16:00.002+03:00

Презентация

View more presentations from Tatiana Zinchenko

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

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

За качество цитаты не отвечаю. Опять же - давно это было. Но вот, например, программирование в парах - это круто. А парное тестирование? Где оно работает? Как оно работает и работает ли вообще? И действительно же - программисты оптимизируют свой процесс, а нам - тестировщикам - приходится следовать за их курсом. Ведь мы - одна команда, мы делаем одну систему, удовлетворяем одного заказчика, следовательно, и процесс у нас один на всех.

Но если разработчикам легче войти в процесс, то о “ловцах багов” задумываются реже. Например, в Agile-методологии можно работать вообще без тестировщиков. Теоретически.

За свою не такую уж и долгую карьеру тестировщика мне посчастливилось ощутить на себе прелести уже нескольких методологий. И очень хочу поделиться своим опытом в том, как все же подстроиться под методологию так, чтобы тестировщиков слушали и слышали, и в то же время не скатиться в печальное противостояние “мы” и “они”.

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

Итак.

“Тестирование в Agile: испытание методологией” - дело № 24-05.

Действие происходит на просторах Agile.

Досье:

Agile - не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. Эта методология нацелена на минимизацию рисков путем сведения разработки к серии коротких циклов. Эти циклы называются итерациями и в большинстве случаев составляют одну-две недели (Википедия).

В 2011 году исполняется 10 лет с момента написания Agile-манифеста.

Существует множество методологий, которые следуют ценностям и принципам, заявленным в Agile. Наша команда использовала Scrum.

В методологии СКРАМ всего 3 роли:
- Скрам-мастер,
- Product Owner
- команда.

Кто такие “команда” и “Продакт Оунер”, надеюсь, понятно. А Скрам-мастер - это такой своеобразный буфер между командой и Product Owner, который отвечает за успех СКРАМ в проекте. Он ведет ежедневные планерки, освещает проблемы и отвечает за соблюдение командой практик и процесса.

Артефакты СКРАМ:

- Product Backlog - это имеющийся на данный момент список требований к системе.

- Спринт Bacкlog - это список тех фич, который команда взяла на спринт.

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

- Ежедневный СКРАМ митинг - это ежедневная планерка, на которой каждый участник команды рассказывает что он делал вчера, что планирует делать сегодня и с какими трудностями столкнулся.

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

Место действия:

Современный офис в столице автономии.

Agile. Все работают.

Все - это отряд разработчиков и ПО (Product Owner).

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

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

Почему программист не может тестировать свою фичу?

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

Вторая причина: у программистов мышление устроено немного иначе, чем у нас. Программист умеет думать логически, как программа. Мы умеем думать как блондинки. Программисту никогда не придет в голову покликать вот там 23 раза, а потом перейти сюда, покликать 15 раз, и тогда вот в том функционале через 3 клика будет бага.
У вас было такое, что вы приходите к разработчику, рассказываете ему каким образом вы получили эту багу, а он на вас смотрит и задает только один вопрос: “Зачем?”
Они искренне не понимают зачем делать так, если есть конкретный путь, который приводит к конкретным, НУЖНЫМ ТЕБЕ, результатам.

Но немногие разработчики отдают себе отчет в том, почему они не могут качественно протестировать свою же фичу. Как ни странно, даже некоторые тестировщики не понимают почему программист не может тестировать.

Если бы программисты умели еще и тестировать - нас бы не было! Мы были бы не нужны!

В общем, в определенный момент команда и руководство поняло, что “мы можем написать, но протестировать качественно мы не можем!” Так в команде появились тестировщики.

А через два месяца — релиз!

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

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

Методология гибкой разработки предусматривает, что команда — самоорганизующаяся.

При этом, есть скрам-мастер, который следит за процессом в целом. У разработчиков есть демон, который подготавливает и проводит демо, следит за тем, как разрабатывается фича и постоянно контактирует с ПО и девелопером. У разработчиков есть фичмен - человек, который берет на себя ответственность за подготовку какой-то конкретной фичи, притом, что разрабатывать ее могут несколько человек. У тестировщиков нет никого, кроме них самих.

Выяснилась и еще одна вещь. Проблема, которая известна многим. Тестирование стало узким местом всей работы.

Одна итерация длилась у нас 2 недели. Как вы думаете, сколько готовых для тестирования фич было в конце первой недели? А в конце второй?

Как результат: стало почти нормой, что на демо фича не попадает по причине того, что она не протестирована.

На тестировщиков обратили внимание и стали думать как вовлечь их в процесс наравне со разработчиками.

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

Так тестировщики стали оценивать фичи.

Кроме того, мы стали больше общаться с разработчиками. И это во многом помогло и нам, и им. Мы стали участвовать в этапе планирования фичи, т.е. еще до разработки делились с программистами своими идеями относительно тестовых случаев по фиче. Это помогла им: спланировать и написать сразу проще, чем потом искать куда приткнуть очередной тестовый случай. Это помогло нам: теперь мы реже ходили с вопросом: “А что, у нас не предусмотрен вариант с запуском двух процессов одновременно?”

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

Но и сам процесс тестирования начал контролироваться демоном. Разработчиком. Иногда это выглядело так: садится программист рядом с тестировщиком и говорит: “Ну, тестируй!”

Не знаю как кому, но вот лично мне сложно оценивать работу программистов. Я знаю, что они ТВОРЯТ, СОЗДАЮТ, ВАЯЮТ! А мы все это ковыряем, уничижаем и показываем дырки. Наверное, поэтому и программистам сложно оценивать нашу работу. Поэтому постепенно все начало приходить к тому, что тестировщики должны автоматизировать свой процесс: писать тесты на Селениуме, оптимизировать их, поддерживать, следить за результатом. То есть, им было проще контролировать нас тогда, когда мы делали то, что им знакомо и понятно. Мануальное тестирование задвигалось на второй план и было очень сложно убеждать в том, что не все поддается автоматизации, и что юнит-тесты, которые пишут программисты, уже являются автоматизированным тестированием.

Оставалась еще проблема очередей. Наверное, знакомо всем. Программист написал фичу, отдал ее на тестирование и со спокойной душой ушел делать другую. Или пить чай. Тут уже кому как повезет.

А ты находишь багу в этой, сданной фиче. И хорошо, если программист пьет чай и еще не вышел из контекста той фичи, что наваял. А если он - отчаянный трудяжка и уже начал ваять что-то еще? Тогда: “Подожди, сейчас я тут закончу и подойду”. Лично у меня рекорд - около 6 часов ожидания. Можно набрать на себя кучу фич за время такого ожидания. Но ведь проблема переключения с контекта на контекст актуальна и для тестировщика тоже.
А очередь стоит. И ждет.

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

Очень важно, чтобы руководство понимало проблемы тестировщиков. Очень просто, когда руководство тоже само когда-то занималось тестированием и прекрасно понимает твои проблемы. Подчас даже лучше, чем ты сам. Иногда ты даже не знаешь, что тебе это надо. А начальство уже за тебя подумало, придумало, решило и принесло.

Гораздо сложнее, когда руководство - разработчик. Еще сложнее - если оно никогда не сталкивалось с тестировщиками.

Как донести до начальства, что то, что тебе нужно - действительно важно?
Самое главное - как донести до него что-то ДО первых набитых шишек и случайно вырвавшегося: “Я же говорила”?

Тогда мы услышали про Канбан. Но это уже совсем другая история.

И напоследок....:

Не пытайтесь выяснить кто круче: тестировщики или программисты. Мы - единая команда. Мы делаем один продукт, мы - заодно, а не против друг друга.

У меня был опыт работы в компании, где программист мог прийти и запросто спросить: “Ну, что там еще эти тестеры сломали?!”, а тестировщики между собой могли обсмеять программиста, пишущего код с большим количеством багов.

Такого не должно быть. Мы не ломаем, мы помогаем найти слабые места! Мы все люди, мы все ошибаемся: ошибаются программисты, ошибаются тестировщики, ошибаются менеджеры и директора.

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

Как начинать с нуля, если Вы пришли на уже готовый проект с устоявшимся механизмом разработки? Многие предлагают начать с изучения документации. А если нет еще ничего? Я обычно начинаю с вопроса: “А на кого рассчитана наша система? Что она должна делать?” Согласитесь, сайт для домохозяек и система для веб-мастеров должны различаться. После этого провожу исследовательское тестирование, в ходе которого обычно сразу видны основные слабые места, а также какие виды тестирования пригодятся в дальнейшем.

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

Любите свою команду. И тогда она полюбит вас. Или нет. Но тогда ей же хуже.

Спасибо за внимание!

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

2011-04-28T17:19:00.000+03:00

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

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

2011-04-26T15:09:00.000+03:00

Ну вот и все - завершились 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! ))))
На самом деле в секции С в это время собрались самые умные, веселые и приятные слушатели и вопросо-задаватели! Спасибо вам всем! )))

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

2011-04-15T17:13:00.000+03:00

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

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

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

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

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

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

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

2011-04-11T15:08:00.000+03:00

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

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

2011-04-05T15:19:00.000+03:00

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

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

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

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

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

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

2011-04-04T18:52:00.000+03:00

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

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

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

Пятница 1-е

2011-04-01T12:47:00.000+03:00

best-photo-gallery.co.cc

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

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

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

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

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

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

Одиночка с интернетом

2011-03-31T13:00:00.000+03:00

Зашла вчера речь о профессиональном развитии.
Возможно ли развиваться в компании, где осуществляется постоянный жесткий мониторинг рабочего времени сотрудника?
Пришли к выводу, что все зависит от личности самого сотрудника.
А потом всплыл интересный факт. Оказывается, у больше половины сотрудников куча планов и желаний, для реализации которых понадобится несметная куча свободного от всего остального времени. И тут выяснилось, что в честной беседе наедине с собой бОльшая часть сотрудников обдумывает идею об одиночной камере с круглосуточным доступом в интернет.
Самыми продвинутыми, конечно, оказались наши Project Qwner'ы. )))
Один уже обдумал, что для изучения всего интересного ему понадобится как минимум 5 лет одиночки.
Второй "домечтался" даже до того, что если его поселят не в одиночку, то он обязательно нарушит режим, чтобы попасть в одиночку.
Вот не зря моя мама говорит, что все айтишники какие-то странные. )))

О пагинаторе, практиках тест-дизайна и развитии тестирования.

2011-03-29T13:30:00.000+03:00

Всем начинающим тестировщикам посвящается!

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

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

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

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

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

?page=2

Вот с этим "нечтом" мы и будем работать. ))))

Сразу скажу по-секрету, что вводить вместо цифры "2" можно все, что угодно: положительные и отрицательные числа, нули, дробные и слишком большие числа, числа в шестнадцатиричной системе, строки вида "inf" или "infinity" и много еще чего.
Мое "любимое" число - это множество девяток (свыше 11) целым числом или после запятой. Но наша система это выдерживала. Как, впрочем, и ввод отрицательных чисел, и дробных значений.
Я решила модифицировать его и разбавить нулями. Получилось число 990909009090909999. И вот оно-то и принесло то, чего я добивалась: прекрасный эксепшен с ошибкой 500.

Error 500 - внутренняя ошибка сервера. Ошибка 500 означает, что сервер столкнулся с обстоятельствами, которые не дают ему выполнить запрос клиента. Обстоятельства эти могут быть очень разные.

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

MySQL Error!
------------------------

The Error returned was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1.9818180181818E+19,20' at line 1

Error Number:
1064

Почему это происходит?
Введенное число попадает в MySQL в экспоненциальной форме, что приводит к ошибке синтаксиса (SQL не понимает такие числа).

Зачем нам это нужно?
Издавна в мире добро борется со злом. Так, врачи борятся с вирусами, огородники борятся с сорняками, а создатели программ - с хакерами.
Есть хорошие "взломщики" - это тестировщики. Есть плохие "взломщики" - это хакеры и всякие школьники, которые в поисках драйва тянут везде свои мышки с клавиатурами. И мы - тестировщики - должны успеть предупредить те действия, которые в дальнейшем может сделать какой-нибудь недобросовестный элемент.

Чем это нам грозит?
Приведенный пример можно считать элементарной SQL-инъекцией. По появившейся ошибке сервера опытный хакер поймет что делать дальше и как получить из нашей системы требуемые ему данные. А мы должны ему в этом помешать.

Будь внимателен к SQL, юный падаван!

"Обязательно все документируйте, хоть это и бессмысленно" (С)

2011-03-28T17:10:00.000+03:00

Давно собиралась написать большой и красивый пост про документацию в проекте (а мне тут есть о чем написать!), а тут еще и наткнулась на "Обязательно все документируйте" vs "документацию писать бессмысленно" на Хабре. И поняла, что пора. )))

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

Я вижу здесь три варианта развития событий.
Первый: таки мотивировать чем-то программистов (скорее всего, тут сработает только метод кнута - вопрос только в его эффективности), чтобы они и в дальнейшем писали документацию. Рассказать им про всякие принципы "лягушек", которых нужно есть с утра, и успокоиться.
Второй: спихнуть написание документации на Project Owner, который непосредственно общается с заказчиком и точно знает, что тот хочет. Основной затык здесь: стоимость времени РО, а также наличие этого самого времени, которого даже в настоящий момент едва хватает на проверку уже написанной документации.
Третий (и, наверное, не последний): поручить написание документации тем, кому это реально в кайф. Я думаю, что такие люди есть, но тщательно шифруются. Затык здесь: проектов несколько, а человек может быть один. Вникать в несколько проектов сразу ему может быть затруднительно.

Основные дискуссии велись вокруг первого и третьего вариантов.
Интересно, а какие еще варианты развития событий могут быть?

Оценка людей и идей

2011-03-23T15:59:00.000+02:00

Иногда читаешь какие-нибудь вещи, молча соглашаешься: "Ну да, так и есть, чего обсуждать-то?" и идешь читать что-нибудь другое.
А иногда читаешь, задумываешься. Перечитываешь. Думаешь постоянно. И как-то не идет из головы. Особенно если вычитаешь какие-то умные мысли, а повлиять на их практическую реализацию почти не можешь.
У Александра Орлова и Славы Панкратова есть бесплатный курс "Инструменты работы с людьми". Там несколько коротких видеороликов на разные темы. Наткнулась я на них как-то совершенно случайно. Просмотрела, согласилась со всем. Естественно, понравилось.
Но вот один видеоурок все никак не идет из головы. Называется "Оценки людей и идей". Речь идет о "принципе айсберга", когда принимается какое-то решение и действия осуществляются в соответствии с ним (верхушка айсберга), но совершенно не учитывается то, на что это может повлиять, как к этому отнесутся люди и кого это решение затронет (та часть, которая под водой).
И даже такие классные руководители, которые возглавляют айтишные команды, тоже частенько этим грешат. Или непроизвольно (я целыми днями "варюсь" в этой теме, как кто-то еще может не знать об этом?), или намеренно (зачем им об этом знать, это только мое решение!).
В заключительной части видеоурока сказано как менеджеру правильно задумываться о людях, на которых повлияет принятое решение. Но ничего не сказано о том, как повлиять на менеджера, чтобы он начал об этом задумываться.
Я долго думала о том, что делать тем, кто находится в правом нижнем квадрате матрицы, т.е. не имеет право голоса, но имеет заинтересованность в исходе дела. Как им повлиять на то, чтобы быть информированными?
Мне пришел в голову такой цикл:
Дать менеджерам послушать этот урок.
IF они прониклись идеей и следуют ее курсом
THEN наслаждаться процессом и общей информированностью
ELSE собрать небольшую инициативную группку и направиться к руководству разрушать миф о том, что "в нашей компании такого никогда быть не может". Но тут есть нюанс: в определенный момент придется сказать что-нибудь типа: "Это ты думаешь, что никакие слухи не ходят, а на самом деле Вася сказал, что закупка новых ноутбуков только для одной команды говорит о том, что программистов второй команды скоро уволят. И, между прочим, некоторые из них уже начали поиски новой работы!"
А, может, есть другой, какой-то более простой путь? Или более сложный?...
Вот такие мысли бродят в голове...

Развиваем свои таланты

2011-03-21T15:50:00.000+02:00

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

"Странно, правда - казалось бы, развиваться - это круто, не стоять на месте, динамика... Не надейтесь! Теория - это бесполезный балласт, который тянет назад, а не двигает вперёд.

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

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

"2. Спрашивать у знакомых и коллег. Что, как они думают, у вас хорошо получается?"

пошла к мужу (по совместительству - девелоперу на проекте) и спросила: "А что я делаю хорошо?" Как спросила, так и получила: "Пряники у тебя вкусные. И мне с тобой хорошо" (конечно, не зря мне позавчера всю ночь снилось, что я автотесты на пряники пишу: ищу у них точки входа, граничные значение, комбинации....).
Пришлось уточнять про тестирование. Ответ: "Ты находишь всякие заковыристые места", конечно, хороший. Хотя и не совсем то, чего я ожидала )))
А лично мне нравится исследовательское тестирование. Особенно - искать всякие ошибки в логике: "А вот что будет, если тут потереть, а потом вот здесь потрогать?" Иногда так зарываюсь во все эти "уровни", что теряю ощущение времени ))))
Я люблю тестировать безопасность. Особенно люблю такие ситуации, когда кто-то пытается влезть на проект, а ты точно знаешь, что вот здесь ты тестировала и именно отсюда зло не пройдет! И оно не проходит! Это круто!
Я люблю нагружать систему и проверять ее возможности. Тут уже я люблю сам процесс: все эти графики, циферки и разговоры с умным видом: на данном этапе наша система выдерживает единовременную нагрузку в 100 человек!
Я не люблю автоматизацию... Потому что думаю, что автоматизировать на 100% все равно невозможно. А еще потому, что я не очень люблю программировать. Да, я - тестировщик, который не мечтает стать программистом. )))
И тут уже назревает ответ на еще один вопрос:

"3. В серьёх призадуматься над вопросом: а что бы вы делали, если бы у вас было 4365987 миллионов долларов, и париться деньгами не нужно было бы?"

Я бы посещала самые крутые тестерские конференции и тестировала в свое удовольствие только самые классные проекты. ))) А еще, наверное, я бы преподавала в каком-нибудь ВУЗе какое-нибудь "Тестирование программного обеспечения", не брала бы взяток и выпускала только самых квалифицированных специалистов )))
Хотя, про "самых квалифицированных", наверное, я погорячилась...

Мерси за комплиман!

2011-03-18T15:40:00.000+02:00

Сегодня я получила второй лучший в моей жизни комплимент )))

Первый звучал так:

"Где ты это все находишь?!" (не помню кто)

Сегодняшний был таким:

"Таня, ну ты и привередливая!!" (Фишкиллер, привет!)

Считаю, что именно такие фразы - лучшее признание от девелопера тестировщику )))))
Буду ждать следующего и надеяться, что он будет не менее оригинален, чем первые два ))

Об SQA Days замолвите слово...

2011-03-17T15:01:00.000+02:00

Наверное, только ленивый тестировщик не писал в своем блоге о грядущем SQA Days 2011. Я буду имитировать трудолюбивого тестировщика и напишу. :) Но у меня есть и своя личная причина написать об этом. :)
Мало того, что

"SQA Days является конференцией №1 на пространстве СНГ и одним из главных мероприятий в Восточной Европе, посвященных тематике тестирования и обеспечению качества программного обеспечения".

Так еще и моя скромная персона будет там выступать!

Вдобавок конференция пройдет 22-23 апреля в Казани! А я еще никогда не была в Казани - это раз. А 21 апреля у меня день рождения - это два. :)
С учетом того, что в Казань мне добираться почти трое суток, день рождения мне светит отмечать в поезде. А у меня еще ни разу не было дня рождения в поезде )))))
Это ли не прекрасно? )))

С почином меня!

2011-03-16T18:35:00.000+02:00

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

Здесь должен быть жутко интресный первый пост блога о тестировании.