Тестирование. Все про автоматизированные, нагрузочные, ручные тесты. Все про обеспечение и контроль качества

Дипломатия или решаем проблемы грамотно

noreply@blogger.com (Алексей Булат) — Mon, 23 Jan 2012 03:59:15 PST

Когда вокруг рассеялся дым курительной трубки, старик уже сидел в позе лотоса и медитировал с закрытыми глазами. Минуту стояла полная тишина. Ученики знали, что в такие моменты ему лучше не мешать, дабы не спугнуть ту самую искру вдохновения, выбирающую тему урока, зародившуюся в его голове.

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

- Учитель, а что они сами не понимают, как оно должно работать? - спросила рыженькая девочка с веснушками на щеках.

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

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

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

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

- Эх, - вздохнул учитель, который тоже задавался такими вопросами вначале своего пути. - Может и не захотят, может и посмеются. Но! Смеется тот, кто смеется последним. У вас есть секретное оружие - система багтрекинга. Заносите туда описание ошибки, назначайте её на того, кого надо. Если программист вернул её Вам обратно, требуйте его написать комментарий, по какой причине он не хочет исправлять ошибку. Если вы все еще не согласны с тем, что проблему можно оставить, переназначьте её на менеджера, чтобы он принял окончательное решение. Но! Не забудьте обосновать почему, по-вашему, ошибка должна быть исправлена. Таким образом именно менеджер возьмет на себя всю ответственность за проблемы, связанные с той ошибкой.

- Учитель, на летней практике, у меня был случай, когда я был уверен, что нашел ошибку, но, как оказалось, о подобном сценарии ничего не говорилось в спецификации. Разработчик просто отклонил багрепорт с комментарием "Цэ не баг, цэ фiча". Я был расстроен, но поделать ничего не мог. Как быть в такой ситуации? - спросил "молодой боец" с гелевым ежиком на голове.

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

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

* * * * *

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

Процесс, который алмазы точит...

noreply@blogger.com (Алексей Булат) — Mon, 23 Jan 2012 03:59:15 PST

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

- Я расскажу вам, что вас ждет, что вам надо будет выучить и что - сделать. Слушайте внимательно и не упускайте ни одной мелочи...

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

- какие у него будут фичи?

- какие тесты вы проведете?

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

И вот пришло время, вы получаете первый комплект артефактов: спецификации, мокапы, планы...

Старик замолчал на мгновение, вспоминая свой первый тест план.

- Учитель, а что же дальше? Что дальше? - зашептали ученики почти в один голос.

- Не перебивайте, будьте терпеливей. - сказал старик и продолжил...

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

- Учитель, а что такое автоматизация? - перебил его очкарик в первом ряду.

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

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

Разработчики подготовили первый билд и небрежно кидают его вам, и просят левым глазком взглянуть на него. Не проходит и часа, как вы уже возвращаете его назад и говорите, что "ЭТО" тестировать невозможно, что через клик приложение "валится", да и ни одна функция не работает, как того требует спецификация. Говорите, что все найденные дефекты записаны в багтрекер и отправляете отчет "smoke test failed!!!"

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

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

- Учитель, а зачем надо дефекты в багтрекер заносить? Ведь эту версию-то все равно возвращаем обратно. - Спросила рыжая девочка с ярко зеленым глазами.

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

- Учитель, а зачем вообще нужен этот smoke test? Неужели без него нельзя? - спросил паренек в малиновом пиджаке.

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

К утру следующего дня вам дают новый билд, однако уже с ним приходит письмо со списком того, что якобы готово на 100%, а что пока трогать нет смысла, т.к. ребята в поте лица стараются сделать все, что в их силах, но пока "никак не выходит у них каменный цветок".

На этот раз Вас не обманули - все критические баги, находящиеся на поверхности, были исправлены. С гордостью за разработчиков и за их труды вы отправляете отчет, что smoke test passed.

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

Вы же, открыв багтрекер, начинаете регрессионное тестирование (Regression testing) и санитарное тестирование (Sanity testing). Вы перепроверяете дефекты, которые разработчики перевели в статус Fixed (Исправлено), Rejected, Can't Reproduce и т.д. Замечу, что статусы Rejected и Can't Reproduce для вас самые неприятные - это явное свидетельство того, что либо вы недостаточно хорошо локализовали дефект, не очень понятно описали шаги для воспроизведения, либо разработчик поленился воспроизвести ситуацию.

- Учитель, а как надо закрывать дефекты и причем тут эти “регрессионное и санитарное” тестирования? - поинтересовалась девочка с iPhone-ом в руке

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

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

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

Менеджер проекта закипает от количества дефектов и ужасного качества, не обращая внимания на то, что это всего навсего вторая попавшая в тестирование версия.

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

- Учитель, а-а что лучше: т-тестирование по т-т-тест кейсам или и-и-исследовательское? Какой путь в-в-выбрать? - заикаясь спросил кучерявый ботаник на первой парте.

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

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

* * * * * * * * * * * *

- На этом мы закончим сие поверхностное описание процесса тестирования. Надеюсь что вы запомнили, последовательность выполненных видов тестирования:

Дымовое > Регрессионное > все остальные виды тестирования

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

Авторы: Алексей Булат и Алексей Лемешев.

Happy vs Unhappy клиент

noreply@blogger.com (Алексей Булат) — Tue, 06 Dec 2011 04:35:50 PST

Найдите одно отличие:

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

РЕЗЮМЕ:

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

Алексей Булат

Бизнес процессы! Дмитрий Потапенко - О рознице

noreply@blogger.com (Алексей Булат) — Mon, 06 Jun 2011 04:21:50 PDT

Посмотрел недавно очень неплохое видео и решил поделитсья с общественностью!

Итак прошу любить и жаловать - "Дмитрий Потапенко - О рознице":

Основные аспекты создания скриптов для нагрузочного тестирования

noreply@blogger.com (Алексей Булат) — Mon, 16 May 2011 10:45:03 PDT

Введение

Напомним, что само по себе нагрузочное тестирование - это автоматизированное тестирование, а значит это разработка, отладка, контрольный запуск и анализ результатов, а не просто запись и запуск (Record & Playback). В данной статье мы постараемся рассмотреть основные аспекты создания набора тест скриптов для нагрузочного тестирования, не углубляясь в технические особенности инструментов, языков программирования и технологий. Итак приступим.

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

Содержание

Стандартизация тестового набора для тестирования производительности
Порядок действий при разработке скриптов для тестирования производительности
Конфигурация тестового набора для тестирования производительности
Вывод
Литература

Стандартизация тестового набора для тестирования производительности

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

В любом случае, свое внимание стоит обратить на следующие аспекты:

Структура каталогов
Архитектура (структура) тест скриптов
Именование объектов

Структура каталогов тестового набора

Наличие одинаковой структуры каталогов значительно облегчает работу ([1] Страница 5). Вы всегда будете знать, где и что находится. Вам не придется искать, где же находятся, к примеру, параметры для тестового набора, написанного другим тестировщиком. Предлагаем Вам следующую структуру каталогов:

parameters - директорий глобальных параметров тестового сценария (более подробное описание глобальных параметров смотрите ниже в разделе "название параметров")
scripts - директорий хранения тестовых скриптов
scenarios - директорий хранения сценариев или тестовой модели

Архитектура тест скриптов

Аналогично со структурой тест кейсов, скрипты для нагрузочного тестирования так же рекомендуется разделять на 3 части: precondition, test case action, postcondition. Данное разделение очень удобно, т.к. разные части тестов имеют разную частоту выполнения.

Тестовые скрипты в HP LoadRunner изначально разделены на 3 части:

Init - используется для инициализации VUser, т.е. в него целесообразно помещать те части скрипта, которые не требуют постоянных повторений, такие как вход в тестируемую систему, конечно если мы не тестируем именно эту часть приложения. (Может быть пустым)
Action - рабочая часть скрипта. В него помещают те действия, которые будут выполняться, и результаты которых будут измеряться и сохраняться, а в последствии анализироваться. (Количество блоков Action может быть разным, в зависимости от архитектуры тестового скрипта)
End - корректное завершение теста.(Может быть пустым)

Соглашение об именовании

Программируя на разных языках, мы используем правила наименования (объектов, переменных, функций) присущие данному языку. В качестве примера рекомендуем ознакомиться с таковыми правилами для Java [4] (Ch. 3 Naming Conventions)

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

название скриптов
названия параметров
название транзакций

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

Названия тест скриптов

Для удобства работы с скриптами рекомендуется всем членам команды использовать одинаковый формат названий скриптов:

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

Пример: название скрипта по созданию компаний будет AddCompaign. Если компании надо создавать для заранее заданного количества пользователей (предположим - 100), то название будет следующим: AddCompaign_100

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

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

Условно разобьем параметры на 2 типа:

глобальные - параметры, использующиеся в большом количестве скриптов внутри сценария, например: хост тестируемого приложения, параметры доступа к БД и т.д. Глобальные параметры хранятся в каталоге parameters проектной директории. В скрипте же, путь к файлу параметров зададим относительно папки скрипта, а именно: "..\parameters\"
локальные - параметры конкретного тестового скрипта. Хранятся внутри директории каждого конкретного скрипта VUser-а.

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

Название транзакций

Для измерения производительности, необходимо определить необходимые транзакции. Каждая транзакция измеряет время, необходимое для получения ответа сервера на запрос виртуального пользователя. Для удобства чтения рекомендуется транзакции называть с большой буквы, начинается с кейворда TX [5], каждый последующий кейворд разделен подчеркиванием.

Пример: по аналогии с примером из пункта 2.3.1 Названия тест скриптов, название транзакций будет TX_ADD_COMPAIGN и TX_ADD_COMPAIGN_100 соответственно.

Порядок действий при разработке скриптов для тестирования производительности

Условно разобьем процесс разработки тестового набора на 3 фазы:

Подготовка
Создание и отладка
Хранение

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

Далее рассмотрим более подробное описание фаз разработки тестовых скриптов для нагрузочного тестирования.

Подготовка

Задачи:

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

Создание и отладка

Задачи:

создание шаблона скрипта (под шаблоном подразумевается не параметризованный скрипт, без каких-либо проверок)
параметризация параметров скрипта
добавление проверок в скрипт
настройки параметров VUser-ов (скриптов) и окружения
отладка при 1 итерации
отладка при Х итерациях
добавление скрипта в общий сценарий
обновление глобальных параметров (при необходимости)

Хранение

Задачи:

сохранение глобальных параметров - папка \parameters\
сохранение сценариев- папка \scenarios\
сохранение скриптов - папка \scripts\

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

При использовании SVN [6] в качестве системы контроля версий, рекомендуется воспользоваться общепринятой организацией репозитория [7]:

/trunk - актуальная (последняя) версия тестового набора
/branches - тестовые наборы, находящиеся в разработке
/tags - завершенные тестовые наборы

Примечание: Для получения более детальной и точной информации о системе контроля версий рекомендуется обратиться к команде разработчиков. По работе с репозиторием любой программист будет рад провести короткий мастер-класс для QA.

В двух словах, порядок работы, используя репозиторий, будет следующий: создается новый branch для тестового набора, сохраняются в него новые тестовые скрипты или изменения, после завершения работы сливается (merge) все в trunk. Когда все участники команды залили результаты своей работы (скрипты, сценарии, параметры) в trunk, создается новый tag, как показатель завершенности некоторой версии тестового набора.

В итоге, структура каталогов репозитория будет следующая:

/perfSuite1
     /trunk
         /parameters
         /scenarios
         /scripts
     /branches
        /branch1
         /parameters
         /scenarios
         /scripts
       /branch2
         /parameters
         /scenarios
         /scripts
       ...
     /tags
       /v0.1
         /parameters
         /scenarios
         /scripts
       /v0.2
         /parameters
         /scenarios
         /scripts
       ...
    /perfSuite2
     /trunk
      ...
     /branches
      ...
     /tags
      ...

Конфигурация тестового набора для тестирования производительности

Тестовые наборы или сценарии тестирования конфигурируются на основании имеющихся моделей нагрузки. Для этого, хранящиеся в репозитории скрипты, группируют в сценарии и назначают требуемое количество виртуальных пользователей, для получения нужной нагрузки (в HP LoadRunner для этих целей используется Controller). Полученные файлы с конфигурацией сценариев сохраняют, также как и скрипты, в репозитории - папка \scenarios\.

Заметим, что предусловием для конфигурации тестового набора является подготовка необхдимых скриптов.

Задача:

создание тестового набора (сценария) для нагрузочного тестирования
конфигурация тестового набора
отладка работы сценария
сохранение тестового набора в репозитории

Вывод

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

Литература

[1] HP LoadRunner software—tips and tricks for configuration, scripting and execution (https://h10078.www1.hp.com/bto/download/loadrunner-configuration.pdf)

[2] Блог Алексея Булата “Про Тестинг” - стандартизируем нагрузочные тесты на LoadRunner

[3] Блог Алексея Булата “Про Тестинг” - методика создания нагрузочных тест-скриптов

[4] Java Coding Style Guide (http://www.cs.bilgi.edu.tr/pages/standards_project/java_CodingStyle.pdf)

[5] tx=transaction (http://www.proz.com/kudoz/english_to_polish/finance_general/1859198-tx.html)

[6] Subversion - version control system (http://subversion.apache.org/)

[7] Subversion - Branch Maintenance - Chapter 4. Branching and Merging - Repository Layout (http://svnbook.red-bean.com/en/1.1/ch04s07.html)

Информация взята с сайта Про Тестинг: Статья "Основные аспекты создания скриптов для нагрузочного тестирования"

ЗЫ Комментарии приветствуются, критика тоже... жду отзывов...

Домино, Рыба или Кошка в горошек...

noreply@blogger.com (Алексей Булат) — Fri, 18 Feb 2011 04:08:48 PST

Они уже среди нас, баги везде, баги вокруг, баги, баги, баги...

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

Если вы не заметили ничего необычного, то вот вам еще одна картинка:

Если ли же и на этот раз для Вас все в норме, то есть варианты:
1. Вы еще не до конца тестер
2. Вы счастливый обладатель замыленного глаза
3. Посмотрите еще внимательнее на картинки домино!!! (Подсказка: надо смотреть на кошку на средней доминошке)

С уважением,
Алексей Булат

Конфигурация тестового стенда для нагрузочного тестирования

noreply@blogger.com (Алексей Булат) — Thu, 28 Oct 2010 11:26:21 PDT

Введение

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

Содержание

Конфигурация vs Производительность
Конфигурация тестового стенда
Анализ результатов при разных конфигурациях
- Использование переходного коэффициента
- Использование экспертной оценки
Выводы
Литература

Конфигурация vs Производительность

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

Конфигурация тестового стенда

Отметим те части конфигурации, которые требуют особого внимания:

Hardware
- процессор (тип, частота, количество ядер и т.д)
- оперативная память (тип, объем, тайминг, эффективная частота и т.д.)
- жесткие диски (тип, скорость и т.д.)
Software
- Операционная система
- Драйвера
Network
- топология сети
- пропускная способность
- протокол передачи данных
Application
- Архитектура
- База данных (структура + данные)
- программное обеспечение, необходимое для работы приложения (например, для Java приложений - JVM)

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

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

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

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

Требуется конфигурация: Proc Intel Clarkdale Core I5, 16 Gb памяти DDR3-800, OS SLES11

Конфигурация тестового стенда: Proc AMD Deneb Phenom II X4, 16 Gb DDR2-800, OS SLES10

Казалось бы отличия незначительны, однако есть нюансы:

Разные типы процессоров
Разный тип памяти
Разные версии операционной системы

Итак:

Cравним процессоры [3]:

Название ядра	Intel Clarkdale Core I5	AMD Deneb Phenom II X4
Тактовые частоты, Мгц	2800-3600	2800-3000
Частоты системной шины, Мгц	2500	2000-1800
Пропускная способность шины процессор-чипсет	2 ГБ/сек (1 ГБ/сек в одном направлении)	14.4-16 ГБ/сек (7.2-8 ГБ/сек в одном направлении)
Размер кэша L1, Кб	64 х2	128 х4
Размер внутреннего кэша L2, Кб	256 x2	512 х4
Ширина шины L2 кеша, бит	256 (двунаправленная)	256 (по 128 в каждом направлении)
...	...	...

Примечание: Неправда ли, не просто будет сравнивать без помощи специалистов? Тем более вывести коэффициент на сколько какой процессор быстрее и по каким параметрам.

Cравним память [4]:

Стандартная задержка (latency) типичная для DDR2 5-5-5-15, а для DDR3 памяти 7-7-7-15. Однако даже с большей задержкой DDR3 память (в отличие от старого стандарта DDR2) обладает большей пропускной способностью (bandwidth) из-за более высокой тактовой частоты (clock speed). Что становится причиной того, что DDR3 память работает немного медленнее, чем DDR2 с такой же частотой 800MHz.

Таким образом, память на тестовом стенде будет немного быстрее чем в требуемой конфигурации.

Cравним операционные системы

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

Таким образом предположим, что SLES 11 будет незначительно быстрее SLES 10.

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

Анализ результатов при разных конфигурациях

Как же быть с тем фактом, что приложение будет протестировано на одной платформе, а работать ему придется на другой? Как провести анализ результатов? Как сделать окончательные выводы и спрогнозировать работу приложения под нагрузкой в будущем?

Использование переходного коэффициента

В своей статье [1] Вячеслав Берзин, предложил при анализе результатов использовать “переходный коэффициент”, показывающий численно отличие производительности тестовой платформы от промышленной:

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

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

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

Использование экспертной оценки

Рассмотрим мнение Андрея Широбокова [2] (сертифицированный специалист в области нагрузочного тестирования, имеющий более 15 лет рабочего опыта в IT):

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

версия ОС и статс паки

версия и тип СУБД

версия серверов приложений и патчей

Естественно, что версия тестируемого приложения должна быть актуальна.
Если совпадает платформа (ОС и тип процессоров), то допускается "пропустить" конфигурацию, например, в случае если проведены эксперименты на конфигурациях 8х16 (8 прц х 16 Гб) и 32х64 (32 прц х 64 Гб), то можно "аппроксимировать" недостающую конфигурацию 24х48 (24 прц х 48 Гб). Обратим внимание, что памяти для такой методики должно пропорционально быть в 2 раза больше во всех случаях.
Если не совпадает платформа, ОС, типы процессоров, объемы памяти, то можно делать только очень общие выводы, наподобие: "В реальности будет не хуже". Но времена откликов и другие детали могут быть малозначимы."

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

Выводы

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

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

Литература

Технология нагрузочного тестирования информационных систем с большим объемом данных , Вячеслав Берзин, Oracle Magazine, [01.12.04]
Блог Андрея Широбокова (http://ashirobokov.blogspot.com)
Сравнение характеристик процессоров
DDR3 RAM and DDR2 Memory Comparison

Информация взята с сайта Про Тестинг: Статья "Конфигурация тестового стенда для нагрузочного тестирования"

Модель нагрузки, как отправная точка при тестировании производительности

noreply@blogger.com (Алексей Булат) — Wed, 27 Oct 2010 05:12:21 PDT

Введение

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

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

Содержание

Что же такое нагрузочное тестирование?
Анализ требований
- Анализ требований в зависимости от типа проекта
Анализ целевой аудитории
Определение базового профиля нагрузки
Разработка моделей нагрузки
Выводы
Литература

Что же такое нагрузочное тестирование?

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

Основные виды нагрузочных тестов:

Тестирование производительности
Стрессовое тестирование
Объемное тестирование
Тестирование стабильности или надежности

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

разработка моделей нагрузки
конфигурация тестового стенда
разработку скриптов
проведение тестирования
анализ результатов

Далее в статье речь пойдет преимущественно о первом и на мой взгляд самом важном этапе – о разработке моделей нагрузки.

Примечание: Согласно некоторым данным этот этап может занимать до 50% времени по нагрузочному тестированию.

Разобьем работу над моделью нагрузки на несколько частей и определим, что необходимо будет делать на каждой из них:

анализ требований
анализ целевой аудитории
определение базового профиля нагрузки
разработка моделей нагрузки

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

Анализ требований

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

Время отклика (время необходимое для открытия страницы или получения ожидаемого результата)
Интенсивность (число запросов в секунду – (Qps)
Используемые ресурсы (загрузка процессора, кол-во используемой памяти, дисковое и сетевой I/O)
Максимальное количество пользователей (определяет число пользователей, способных работать с системой в условиях заданной конфигурации)

А также некоторые метрики связанные с работой бизнес сценариев (например, количество бизнес операций в единицу времени, время выполнения бизнес операции и т.д.)

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

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

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

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

Анализ требований в зависимости от типа проекта

При анализе требований необходимо учесть разрабатывается ли новое (startup project) или же проект направлен на профилирование нагрузки для уже находящегося в эксплуатации приложения (profiling project).

Рассмотрим на основании чего разрабатываются требования по производительности в зависимости от типа проекта.

Для startup проектов:

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

Для profiling проектов:

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

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

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

Анализ целевой аудитории

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

Примечание: В случае, если тестируемая система уже находится в эксплуатации, пользовательские сценарии и распределенее запросов в течении дня, можно получить проанализировав логи приложения и сервера.

В результате мы получим:

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

Например: Утром операторы проверяют журналы посещения, обрабатывают сообщения клиентов, после обеда вводят новые товары в базу, и в конце рабочего дня снова анализируют журналы и сообщения. Значит основная нагрузка на журналы посещения и базы сообщений будет в начале и в конце рабочего дня.

Определение базового профиля нагрузки

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

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

Например:

В группе “Администраторы” работает 10 админов. Они выполняют 2 основные операции - “добавить пользователя” и “забанить пользователя”.

Распределим выполнение операций следующим образом: 5 админов выполняют операцию добавления и 5 забанивают пользователей. Проведем перерасчет интенсивности выполнения операций:

В течении дня 10 администраторов добавляют 240 пользователей. Значит, интенсивность выполнения операции добавления для 1 администратора = 1 операция в час. Но в нашем случае только 5 админов будут выполнять операцию добавления, значит нам необходимо увеличить интенсивность так, чтобы количество добавленных пользователей осталось прежним. Итого, мы получим, что выполняя по 2 операции в час, 5 админов будут добавлять те же 240 пользователей. Проведя аналогичный перерасчет интенсивности для операции “забанить пользователя”, мы получим профиль нагрузки для группы Администраторы:

группа	кол-во юзеров	операция	интенсивность опер./час
админы	5	добавить пользователя	2
админы	5	забанить пользователя	5

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

группа	кол-во юзеров	операция	интенсивность опер./сек
админы	Z	добавить пользователя	N
админы	Z	забанить пользователя	N
...
покупатели	Z	вход/выход в систему	N
покупатели	Z	поиск товара	N
покупатели	Z	покупка товара	N
...
продавцы	Z	просмотр посещения	N
продавцы	Z	добавление/удаление/ товара	N

Именно это таблица и будет являться полным базовым профилем нагрузки для тестируемого приложения.

Разработка моделей нагрузки

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

Так разным может быть:

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

Проще всего изменения проводить, варьируя параметрами в базовом профиле нагрузки и инструменте для тестирования производительности (например, в HP LoadRunner Controller).

Модель тестирования производительности

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

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

Модель стрессового тестирования

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

Модель объемного тестирования

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

Модель тестирования стабильности или надежности

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

Выводы

Четкое следование всем вышеописанным инструкциям по разработке моделей нагрузки, позволит нам:

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

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

Литература

Технология нагрузочного тестирования информационных систем с большим объемом данных , Вячеслав Берзин, Oracle Magazine, [01.12.04]
Блог “Нагрузочное тестирование ПО” (http://ashirobokov.blogspot.com), Андрей Широбоков
Сайт “ПроТестинг.RU” (http://www.protesting.ru/automation/performance.html)
Performance Testing Guidance for Web Applications, J.D. Meier, Carlos Farre, Prashant Bansode, Scott Barber, and Dennis Rea; Microsoft Corporation; September 2007

Информация взята с сайта Про Тестинг: Статья "Модель нагрузки, как отправная точка при тестировании производительности"

Пишем систему автоматизированных тестов "с нуля"

noreply@blogger.com (Алексей Булат) — Mon, 27 Sep 2010 05:31:00 PDT

Добрый день,

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

Заранее спасибо,
Алексей Булат

Автоматизированное тестирование: работа со статическими ресурсами

noreply@blogger.com (Алексей Булат) — Wed, 08 Dec 2010 04:43:59 PST

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

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

Существует 2 основных варианта организации работы со статическими данными, которые имеют свои преимущества и недостатки:

Прописывание данных внутри кода - hardcode (см. использование констант в Java)
Недостатки:
- при изменении данных необходимо будет по-новой пере-собирать тесты
- все статические ресурсы загружаются и хранятся в памяти и не могут быть освобождены.
Преимущества:
- доступ к данным максимально упрощен
Вынесение статических значений из кода (в БД, в файлы и т.д.)
Недостатки:
- операция чтения из БД или файлов занимает определенное время и может значительно замедлить выполнение тестов.
- файл или таблица БД может "залочиться", в случае одновременного использования одних и тех же ресурсов
Преимущества:
- возможность структурирования статических ресурсов в БД или файловой системе
- возможность изменения статических ресурсов без последующего изменения в коде и пере-собирания тестов
- ресурсы из файла могу быть прочитаны, использованы тестом, удалены из памяти, а затем при необходимости снова прочитаны

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

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

Несколько слов о том, что такое проперти файл (Properties).

Это обычный текстовый файл, данные в котором хранятся в виде key = value Пример: LoginPage.properties

----------------
field.username.id = UserName
field.password.id = Password
button.login.id = LoginButton
----------------

Пример Java кода, который читает LoginPage.properties файл и получает необходимую информацию:

----------------
// инициализация LoginPage.properties
Properties properties = new Properties();
File propertyFile = new File(LoginPage.properties);
properties.load(new FileReader(propertyFile));
// чтение данных
String userNameID = properties.getProperty("field.username.id");
String passwordID = properties.getProperty("field.password.id");
String loginButtonID = properties.getProperty("button.login.id");
----------------

Конечно избавиться от хардкода нам не удастся на все 100%, однако в последнем случае жестко прописаны ключи к для доступа к данным, а не сами данные. Что является уже не хардкодом, а скажем "параметризацией".

Теперь на базе этого я расскажу, как построен тестовый фреймворк основанный на примере описанном в предыдущей статье PageObjects pattern + Selenium (Java)

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

LoginPage.properties

----------------
field.username.locator = id
field.username.arg = UserName
field.password.locator = id
field.password.arg = Password
button.login.locator = id
button.login.arg = LoginButton
----------------

HomePage.properties

----------------
text.username.locator = id
text.username.arg = userName
link.logout.locator = id
link.logout.arg = LogoutLink
----------------

ErrorLoginPage.properties

----------------
text.errormessage.locator = id
text.errormessage.arg = ErrorMessage
link.backtologin.locator = id
link.backtologin.arg = BackLink
----------------

Создав все необходимые ресурсы, перейдем к написанию Java кода, который будет осуществлять загрузку, хранение и чтение данных. Для хранения загруженных ресурсов создадим класс DataStorage. В нем будет храниться Map данных (Map propertiesMap), ключом в котором будет являться название объекта страницы, а значением объект Properties со списком статических данных.

DataStorage.java

public class DataStorage {
   private Map propertiesMap;

   private DataStorage() {
       this.propertiesMap = new HashMap();
   }

   public static DataStorage getInstance() {
       return new DataStorage();
   }

   public void setProperty(String key, Properties properties) {
       propertiesMap.put(key, properties);
   }

   public Properties getProperty(String key) {
       return propertiesMap.get(key);
   }

   public boolean exists(String key) {
       return propertiesMap.get(key) != null;
   }
}

Добавим ссылку на него в рабочем контексте, а также несколько сервисных методов для работы с ним (выделено жирным в листинге класса):

Context.java

public class Context {
   public static final String BROWSER_IE = "*iexplore";
   public static final String BROWSER_FF = "*firefox";
   public static final String BROWSER_CH = "*chrome";
   private static final String RESOURCES_PATH = "resources/${NAME}.properties";    

   public static String siteUrl;
   private static Context context;
   private DataStorage dataStorage;
   private Selenium selenium;
   private SeleniumServer seleniumServer;

   private Context() {
       this.setDataStorage(DataStorage.getInstance());
   }

   public static void initInstance(String browserType, String siteURL) {
       context = new Context();
       siteUrl = siteURL;
       context.setSelenium(new DefaultSelenium("localhost", 4444, browserType, siteURL));
       context.start();
   }

   public static Context getInstance() {
       if (context == null) {
           throw new IllegalStateException("Context is not initialized");
       }
       return context;
   }

   public Selenium getSelenium() {
       if (selenium != null) {
           return selenium;
       }
       throw new IllegalStateException("WebBrowser is not initialized");
   }

   public void start() {
       try {
           seleniumServer = new SeleniumServer();
           seleniumServer.start();
       } catch (Exception e) {
           e.printStackTrace();
       }
       selenium.start();
   }

   public void close() {
       selenium.close();
       selenium.stop();
       seleniumServer.stop();
   }

   public String getSiteUrl() {
       return siteUrl;
   }

   public void setSelenium(Selenium selenium) {
       this.selenium = selenium;
   }

   public String getResourcesPath(String name) {
       return RESOURCES_PATH.replaceAll("\\$\\{NAME\\}", name);
   }

   private void setDataStorage(DataStorage dataStorage) {
       this.dataStorage = dataStorage;
   }

   public DataStorage getDataStorage() {
       return dataStorage;
   }
}

Теперь добавим в класс Page инициализацию ресурсов и сервисные методы для загрузки и чтения данных из файлов. Наиболее интересным из них будет являться метода initProperties(), который анализируя иерархию классов объекта страницы загружает необходимый проперти файл.

Page.java

public abstract class Page {
   private Context context;
   private String currentPage;
   private Properties properties;
   
   protected Page(String pageUrl) {
       this.currentPage = pageUrl;
       setContext(Context.getInstance());
       initProperties();
       init();
       parsePage();
   }

   private void initProperties() {
       String className = getClass().getSimpleName();
       if (!getContext().getDataStorage().exists(className)) {
           this.properties = new Properties();
           List superClasses = ClassUtils.getAllSuperclasses(getClass());
           File file = null;
           for (int i = superClasses.size() - 2; i >= 0 ; i--) {
               Class aClass = (Class) superClasses.get(i);
               file = new File(getResourcesPath(aClass.getSimpleName()));
               if (getContext().getDataStorage().getProperty(aClass.getSimpleName())== null) {
                   if (file.exists()) {
                       putAllProperties(file);
                       updateStogare(aClass.getSimpleName(), getProperties());
                   }
               } else {
                   putAllProperties(getContext().getDataStorage().getProperty(aClass.getSimpleName()));
               }
           }
           file = new File(getResourcesPath(className));
           putAllProperties(file);
           updateStogare(this, getProperties());
       } else {
           setProperties(getContext().getDataStorage().getProperty(getClass().getSimpleName()));
       }
   }
   
   protected abstract void init();
   protected abstract void parsePage();

   private void setContext(Context instance) {
       this.context = instance;
   }

   public Context getContext() {
       return context;
   }

   public String getCurrentPage() {
       return context.getSiteUrl() + this.currentPage;
   }

   protected Selenium getSelenium() {
       return context.getSelenium();
   }

   private String getResourcesPath(String name) {
       return getContext().getResourcesPath(name);
   }
   
   private Properties getProperties() {
       return properties;
   }
   
   private void setProperties(Properties properties) {
       this.properties = properties;
   }
   
   protected String getProperty(String key) {
       return properties.getProperty(key);
   }
   
   private void putAllProperties(File proertiesFile) {
       try {
           this.properties.load(new FileReader(proertiesFile));
       } catch (IOException e) {
           e.printStackTrace();
       }
   }
   
   private void putAllProperties(Properties properties) {
       this.properties.putAll(properties);
   }

   private void updateStogare(Object parentKeyObj, Properties properties) {
       updateStogare(parentKeyObj.getClass().getSimpleName(), properties);
   }

   private void updateStogare(String className, Properties properties) {
       getContext().getDataStorage().setProperty(className, (Properties)properties.clone());
   }

   protected String buildLocator(String type, String arg) {
       // Сервисный метода для создания Selenium локатора 
       // по двум параметрам тип и аргумент
       return type + "=" + arg;
   }

   // ....
   // service methods...
   // ....
}

Заменив в объектах станиц, конкретные значения статических ресурсов на чтение их значений из объектов Properties мы получаем их следующую реализацию:

LoginPage.java

public class LoginPage extends Page {
   public static final String PAGE_URL = "http://www.testlogin.com/login.html";

    protected LoginPage() {
        super(PAGE_URL);
    }

    public static LoginPage openLoginPage() {
        LoginPage loginPage = new LoginPage();
        loginPage.getSelenium().open(PAGE_URL);
        return loginPage;
    }

    private void setUserName(String userName) {
        // код для заполнения поля Username
        getSelenium().type(buildLocator(getProperty("field.username.locator"),getProperty("field.username.arg")), userName);
   }

    private void setPassword(String password) {
        // код для заполнения поля Password
        getSelenium().type(buildLocator(getProperty("field.password.locator"), getProperty("field.password.arg")), password);
   }

    private void pushLoginButton() {
        // код для нажатия на кнопку Login
        getSelenium().click(buildLocator(getProperty("button.login.locator"), getProperty("button.login.arg")));
   }

    protected void parsePage() {
        // Разбор элементов страницы
        // Заполнение необходимых переменных данными со страницы
    }

    protected void init() {
        // Инициализация страницы
        // Проверка корректности загрузки
        if(!getSelenium().getLocation().equals(PAGE_URL)) {
            throw new IllegalStateException("Invalid page is opened");
        }
    }

    private void loginAs(String userName, String password) {
        setUserName(userName);
        setPassword(password);
        pushLoginButton();
    }

    public HomePage login(String userName, String password) {
        loginAs(userName, password);
        return new HomePage();
    }

    public ErrorLoginPage loginInvalid(String userName, String password) {
        loginAs(userName, password);
        return new ErrorLoginPage();
    }
}

HomePage.java

public class HomePage extends Page {
    public static final String PAGE_URL = "http://www.testlogin.com/home.html";
    private String loggedinUserName;

    protected HomePage() {
        super(PAGE_URL);
    }

    protected void init() {
// Инициализация страницы
    }

    protected void parsePage() {
// Разбор элементов страницы
        this.loggedinUserName = getSelenium().getText(buildLocator(getProperty("text.username.locator"), getProperty("text.username.id")));
   }

    public String getLoggedinUserName() {
        return loggedinUserName;
    }

    public LoginPage logout() {
        getSelenium().click(buildLocator(getProperty("link.logout.locator"), getProperty("link.logout.id")));
       return new LoginPage();
    }
}

ErrorLoginPage.java

public class ErrorLoginPage extends Page {
    public static final String PAGE_URL = "http://www.testlogin.com/loginError.html";
    private String errorMessage;

    protected ErrorLoginPage() {
        super(PAGE_URL);
    }

    protected void init() {
// Инициализация страницы
    }

    protected void parsePage() {
        this.errorMessage = getSelenium().getText(buildLocator(getProperty("text.errormessage.locator"), getProperty("text.errormessage.id")));
   }

    public String getErrorMessage() {
        return this.errorMessage;
    }

    public LoginPage backToLoginPage() {
        getSelenium().click(buildLocator(getProperty("link.backtologin.locator"), getProperty("link.backtologin.id")));
       return new LoginPage();
    }
}

Скачать исходный код примеров по работе со статическими ресурсами

Обратите внимание, что в теперешней реализации мы вынесли все статические ресурсы в файлы. И теперь в случае, если какие-то данные будут изменены, например, id “UserName” изменится на “user_name” и нужно будет изменить тип локатора для поиска c “id” на “xpath”, то нам всего навсего надо будет заменить значение в файле, оставив код фреймворка без изменения:

field.username.locator = xpath
field.username.arg = //input[@id=’user_name’]

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

ЗЫ Комментарии приветствуются, критика тоже... жду отзывов...

Да приумножится Ваша Автоматизация, Алексей Булат

PageObjects pattern + Selenium (Java)

noreply@blogger.com (Алексей Булат) — Wed, 10 Nov 2010 04:28:22 PST

Попробуем на небольшом примере показать как, используя PageObjects pattern и Selenium (Java), можно достаточно быстро реализовать фреймоворк для автоматизированного тестирования, и начать писать понятные, легко поддерживаемые, а главное работающие тесты.

Пример:

Страница LoginPage состоит из двух полей ввода User и Password, кнопки Login. При отправке корректного логина и пароля открывается страница Home на которой есть имя пользователя и ссылка Logout. При отправке НЕкорректного логина и пароля открывается страница ErrorLogin, на которой есть сообщение об ошибке и ссылка Back To Login Page.

Задание:

Написать тестовые скрипты:
1. Корректный Login -> проверка имени пользователя -> Logout
2. Некорректный Login -> проверка сообщения об ошибке -> Back To Login Page

Решение:

1. Создаем рабочий контекст на базе Selenium

Context.java:

public class Context {
    public static final String BROWSER_IE = "*iexplore";
    public static final String BROWSER_FF = "*firefox";
    public static final String BROWSER_CH = "*chrome";
    
    private static Context context;
    private static String siteUrl;
   
    private Selenium browser;
    private SeleniumServer seleniumServer;

    private Context() {
    }

    public static void initInstance(String browserType, String siteURL) {
        context = new Context();
        siteUrl = siteURL;
        context.setBrowser(new DefaultSelenium("localhost", 4444, browserType, siteURL));
        context.start();
    }

    public static Context getInstance() {
        if (context == null) {
            throw new IllegalStateException("Context is not initialized");
        }
        return context;
    }

    public Selenium getBrowser() {
        if (browser != null) {
            return browser;
        }
        throw new IllegalStateException("WebBrowser is not initialized");
    }
    
    public String getSiteUrl() {
       return siteUrl;
    }

    public void start() {
        try {
            seleniumServer = new SeleniumServer();
            seleniumServer.start();
        } catch (Exception e) {
            e.printStackTrace();
        }
        browser.start();
    }
    
    public void close() {
        browser.close();
        browser.stop();
        seleniumServer.stop();
    }
        
    public void setBrowser(Selenium browser) {
        this.browser = browser;
    }
}

2. Добавляем в абстрактный суперкласс Page ссылку на рабочий контекст context, а также сервисный метод для получения из него объекта Selenium getBrowser().

Page.java:

public abstract class Page {
    private Context context;
    private String currentPage; 
    
    protected Page(String pageUrl) {
        this.currentPage = pageUrl;
        setContext(Context.getInstance());
        init();
        parsePage();
    }

    private void setContext(Context instance) {
        this.context = instance;
    }

    protected abstract void init();
    protected abstract void parsePage();

    public String getCurrentPage() {
  return context.getSiteUrl() + this.currentPage;
    }
   
    protected Selenium getBrowser() {
        return context.getBrowser();
    }

    // ....
    // service methods...
    // ....
}

3. Реализуем классы страниц, необходимые при написании тестов для нашего примера, а именно: LoginPage, HomePage и ErrorLoginPage. И добавляем в сервисные методы реальный ввод данных в поля, нажатие кнопок и клики на ссылки

LoginPage.java:

public class LoginPage extends Page {
   public static final String PAGE_URL = "/login.html";

   protected LoginPage() {
       super(PAGE_URL);
   }

   public static LoginPage openLoginPage() {
       LoginPage loginPage = new LoginPage();
       loginPage.getBrowser().open(PAGE_URL);
       return loginPage;
   }

   private void setUserName(String userName) {
       // код для заполнения поля Username
       getBrowser().type("id=UserName", userName);
   }

   private void setPassword(String password) {
       // код для заполнения поля Password
       getBrowser().type("id=Password", password);
   }

   private void pushLoginButton() {
       // код для нажатия на кнопку Login
       getBrowser().click("id=LoginButton");
   }

   protected void parsePage() {
       // Разбор элементов страницы
       // Заполнение необходимых переменных данными со страницы
   }

   protected void init() {
       // Инициализация страницы, например проверка адреса (URL) страницы:   
       if(!getBrowser().getLocation().equals(PAGE_URL)) {
           throw new IllegalStateException("Invalid page is opened");
       }
       // Можно также добавить проверки наличия необходимых для дальнейшей работы 
       // объектов и т.д.
   }

   private void loginAs(String userName, String password) {
       setUserName(userName);
       setPassword(password);
       pushLoginButton();
   }

   public HomePage login(String userName, String password) {
       loginAs(userName, password);
       return new HomePage();
   }

   public ErrorLoginPage loginInvalid(String userName, String password) {
       loginAs(userName, password);
       return new ErrorLoginPage();
   }
}

HomePage.java:

public class HomePage extends Page {
   public static final String PAGE_URL = "/home.html";
   private String loggedinUserName;

   protected HomePage() {
       super(PAGE_URL);
   }

   protected void init() {
       // Инициализация страницы
   }

   protected void parsePage() {
       // Разбор элементов страницы
       this.loggedinUserName = getBrowser().getText("id=userName");
   }

   public String getLoggedinUserName() {
       return loggedinUserName;
   }

   public LoginPage logout() {
       getBrowser().click("id=LogoutLink");
       return new LoginPage();
   }
}

ErrorLoginPage.java:

public class ErrorLoginPage extends Page {
   public static final String PAGE_URL = "/loginError.html";
   private String errorMessage;
 
   protected ErrorLoginPage() {
       super(PAGE_URL);
   }

   protected void init() {
       // Инициализация страницы
   }

   protected void parsePage() {
       // Разбор элементов страницы
       this.errorMessage = getBrowser().getText("id=ErrorMessage");
   }

   public String getErrorMessage() {
       return this.errorMessage;
   }

   public LoginPage backToLoginPage() {
       getBrowser().click("id=BackLink");
       return new LoginPage();
   }
}

4. Пишем тесты на базе JUnit:

public class TestLogin extends TestCase {
   public void setUp() {
        // Инициализация контекста. 
        Context.initInstance(Context.BROWSER_IE, "http://www.testtesttestlogin.com");
    }

   public void testLoginLogout() {
        String userName = "tester";
        String password = "testPass";
        LoginPage loginPage = LoginPage.openLoginPage();
        HomePage homePage = loginPage.login(userName, password);
        assertEquals(userName, homePage.getLoggedinUserName());
        homePage.logout();
    }

    public void testInvalidLogin() {
        String userName = "$tester@#";
        String password = "********";
        String expectedMessage = "Invalid username or password"; 
        LoginPage loginPage = LoginPage.openLoginPage();
        ErrorLoginPage errorLoginPage = loginPage.loginInvalid(userName, password);
        assertEquals(expectedMessage, errorLoginPage.getErrorMessage());
        errorLoginPage.backToLoginPage();
    }

    protected void tearDown() throws Exception {
        // закрытие браузера
       Context.getInstance().close(); 
    }
}

Скачать исходный код примеров по PageObjectPattern

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

Алексей Булат
Да прибудет с Вами автотестинг.

PageObjects pattern или работаем по науке

noreply@blogger.com (Алексей Булат) — Thu, 15 Jul 2010 09:24:44 PDT

Хочется поговорить об автоматизированных тестах, а точнее даже об организации фреймворков для них, а если быть более точным об одном из самых распространенных подходов в автоматизации тестирования через GUI - о PageObjects pattern.

Мое первое знакомство с ним состоялось 5 лет назад, когда ничего не подозревая, мой коллега предложил, организовать наш тестовый фреймворк таким образом, чтобы каждой странице соответствовал один класс, тогда мы называли его парсер (Page Parser). Идея прошла свое крещение и была воплощена, а самое главное, живет и до сих пор.

В двух словах про реализацию.

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

public abstract class Page {
protected Page() {
   init();
   parsePage();
}
protected abstract void init();
protected abstract void parsePage();

// ....
// service methods...
// ....
}

Далее, все классы реальных страниц наследуют супер-класс Page, реализует абстрактные и добавляет свои методы для функций выполняющихся на этой конкретной странице, причем методы взаимодействия с элементами управления, которые не содержат логики описываем как private void, методы выполняющие действия пользователя, вызывающие открытие новой или обновление активной страницы - public с возвращением ожидаемого объекта (public HomePage).

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

Пример:
Страница Login Portal состоит из двух полей ввода User и Password, кнопки Login.

Как будет выглядеть наш PageObject?

public class LoginPortalPage extends Page {

protected LoginPortalPage() {
   super();
}

private void setUserName(String userName) {
  // код для заполнения поля Username
}

private void setPassword(String password) {
  // код для заполнения поля Password
}

private void pushLoginButton() {
  // код для нажатия на кнопку Login
}

protected void parsePage() {
  // Разбор элементов страницы
  // Заполнение необходимых переменных данными со страницы
}

protected void init() {
  // Инициализация страницы
  // Проверка корректности загрузки
}
}

Из данного примера видно, что методы в данном классе LoginPortalPage соответствуют тем действиям, которые может делать пользователь на этой странице, а именно ввести имя (setUserName), пароль (setPassword), нажать кнопку Login (pushLogin).

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

private void loginAs(String userName, String password) {
    setUserName(userName);
    setPassword(password);
    pushLoginButton();
}

public HomePage login(String userName, String password) {
    loginAs(userName, password);
    return new HomePage();
}

public ErrorLoginPage loginInvalid(String userName, String password) {
    loginAs(userName, password);
    return new ErrorLoginPage();
}

Таким образом в своем “окончательном” варианте класс LoginPortalPage будет выглядеть следующим образом:

public class LoginPortalPage extends Page {

protected LoginPortalPage() {
   super();
}

private void setUserName(String userName) {
  // код для заполнения поля Username
}

private void setPassword(String password) {
  // код для заполнения поля Password
}

private void pushLoginButton() {
  // код для нажатия на кнопку Login
}

protected void parsePage() {
  // Разбор элементов страницы
  // Заполнение необходимых переменных данными со страницы
}

protected void init() {
  // Инициализация страницы
  // Проверка корректности загрузки
}

private void loginAs(String userName, String password) {
    setUserName(userName);
    setPassword(password);
    pushLoginButton();
}

public HomePage login(String userName, String password) {
    loginAs(userName, password);
    return new HomePage();
}

public ErrorLoginPage loginInvalid(String userName, String password) {
    loginAs(userName, password);
    return new ErrorLoginPage();
}
}

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

Кириллические домены уже среди нас - УРА товарищи!!!

noreply@blogger.com (Алексей Булат) — Mon, 17 May 2010 09:31:56 PDT

За прошедшей на днях конференцией SQA Days 7, достаточно незаметно промелькнула новость, что Россия наконец-таки зарегистрировала первые кириллические домены:
президент.рф
правительство.рф

Странно, что сообщество тестировщиков обошло стороной это событие. Поэтому пользуясь тем, что пока еще никто не озвучил ничего по этому поводу, напишу некоторые свои наблюдения:
1. Google Chrome наотрез отказался открывать вышеупомянутые сайты при вводе адреса в вышеупомянутом виде: президент.рф. Однако, открыл их по полному адресу: http://www.президент.рф или http://президент.рф
2. Safari и FireFox - открыли, но покосячили имя домена, заменив их на что-то подобное: http://www.xn--d1abbgf6aiiy.xn--p1ai/
3. IE 8 и Opera - открыли нормально. Однако, при работе с подсказками в адресной строке, кириллическое доменное имя преобразуется в аналогичное указанному в пункте 2 (http://www.xn--d1abbgf6aiiy.xn--p1ai/)

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

http://правительство.рф/online/
http://президент.рф/news

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

С вами был,
Алексей Булат

Тестирование по факту или/и по предоплате

noreply@blogger.com (Алексей Булат) — Thu, 15 Jul 2010 09:29:38 PDT

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

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

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

При этом основным бонусом будет не нахождение багов в готовом продукте, а предотвращение их появления в нем. Для этого существует большое количество статических техник, таких как: ревизия дизайна, кода, анализ причин ошибок. Либо автоматизированное тестирование на уровне модулей, объектов, систем перед сборкой приложения.
Конечно, работа по "предоплате" не удовлетворит все наши нужды на 100%, поэтому людям, занимающимся тестированием по факту, всегда будет место, но вот улов багов у них будет совершенно иной.
P.S. Навеяно требованиями к Software Engineer in Test в компании google

Разработка тест кейсов или практическое применение тест дизайна

noreply@blogger.com (Алексей Булат) — Thu, 18 Mar 2010 07:58:21 PDT

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

Мы постарались коротко, на небольшом примере, описать процесс разработки тест кейсов для небольшой формы приема заявок.

Ах, да, вот ссылка на статью: Практическое применение техник тест дизайна при разработке тест кейсов

Хотелось бы послушать Ваши комментарии и предложения по улучшению материала.

С уважением,
Алексей Булат

А судьи кто?

noreply@blogger.com (Алексей Булат) — Mon, 01 Mar 2010 08:22:22 PST

Читать всем, кто связан с проведением собеседований,
наматывать на ус всем, кто хочет улучшить этот процесс!

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

Во многих компаниях собеседование на позицию Test or QA Manager мало чем отличается от интервью на позицию Software Tester (или QA Engineer). Причем, как мне показалось, люди назначенные проводить интервью, не всегда умеют это делать. Кто в итоге страдает? Конечно же - компания.
-- Поручайте проведение собеседований правильным людям.

Часто от друзей слашу: "О, сегодня собеседуем крутого тестера, надо его покруче поспрашивать!" - А какой смысл-то? Завалить можно кого угодно, а потом сказать, что он не знал элементарных вещей. А в итоге компания не получит хорошего работника, и все потому что те кто собеседуют, в зависимости от уровня кандидата, варьируют сложность и количество вопросов. (Это как в школе, ты, учась в спецклассе, получаешь 4, решая задачи повышенной сложности, а твой кореш Вася из реального класса, получает 5, решив пару элементарных примеров).
-- На одну и ту же позицию требования к кандидатам должны быть одинаковыми. В случае если он с легкостью отвечает на все Ваши вопросы, не значит ли это, что кандидат overqualified? Но тут могут быть нюансы, которые сложно предположить...

А вот еще история из курилки наших девелоперов. (Коротко о проекте: веб приложение = Jboss, Spring, DB2...) Пришел к ним на интервью парень с очень толстым резюме. Читает наш собеседователь его и видит там слово WebSphere и думает: "О, крутой чувак - вебсферу знает". И давай его про эту саму сферу и спрашивать, в итоге заваливает и парня не берут к нам. Вывод, зачем было его гонят по технологиям, не используемым в компании? - Да просто так, чтобы удовлетворить свое самолюбие.
-- Вопросы на собеседовании должны быть тесто связаны с тем, чем кандидату придется заниматься, в случае положительного исхода интервью. Конечно это не означает, что не должно быть и других вопросов - ДОЛЖНЫ, но вот при принятии решения нужно опираться на основные требуемые знания, а не второстепенные.

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

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

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

ВЫВОД

Немного подитожим описанное выше.

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

С моей точки зрения самый логичный вариант проведения интервью следующий:
1. Знакомство (обе стороны представляются, озвучивается позиция на которую будет проводиться собеседование и отведенные на беседу временные рамки)
2. Себеседователи задают интересующие вопросы. (когда они закончили и "не имеют больше что спросить", кандидату дается возможность узнать интересующую его информацию)
3. Кандидат задает вопросы
4. Кандидату сообщают о том в каком виде и когда будут доступны результаты собеседования. Если собеседование многоуровневое и возможно еще несколько раундов - имеет смысл сообщить об этом кандидату заранее
5. При получении положительного результата, Вам назначается следующий этап интервью, либо делается окончательное предложение. (При получении отказа Вы плачете в подушку.)
6. Вы либо принимаете предложение, либо вежливо отказываетесь.

P.S. В компании, где я когда-то работал очень серьезно относились к процессу подбора специалистов. Бывали случаи, когда мы говорили "НЕТ, не берем" кандидата с 10-15 годами опыта, из головного офиса, нас просили дать письменные объяснения, почему именно мы не берем человека с резюме весомее наших всех вместе взятых. И поверьте мне отмазки в стиле "он нам лично не понравился" не прокатывали.

P.S.S. Иногда, проводящие интервью специалисты относятся к кандидатам как соперники, опираясь на следующие принципы:
- брать кого-то умней себя опасно - в последствии можно не получить повышение.
- брать кого-то на должность выше своей тоже не очень хочется, вдруг, если никого не найдут - тебя назначат?
БУДЬТЕ БДИТЕЛЬНЫ: Не допускайте таких людей к процессу проведения интервью.

Встречают по одежке, а провожают по уму

noreply@blogger.com (Алексей Булат) — Mon, 25 Jan 2010 12:07:22 PST

Недавно за кофе подняли вопрос: "В чем ходить на интервью?". Многие хором сказали, что только в костюме, что типа респектабельный вид и т.д. Соглашусь вид респектабельный, но как выглядит интервью, если вы пришли в костюме, а вас собеседуют "чуваки" в байках и майках? Если Вы выглядите респектабельно, то они явная Ваша противоположность.

Конечно тут многое зависит от компании и позиции, которую вам предлагают. Если это серьезная организация типа NASA и позиция заместитель генерального директора, то костюмчик подыскать все же придется, а если это IT компания из 30 человек и позиция младший помощник старшего администратора, то "на кой ляд Вам этот пинжак"? Вы его оденете 1 раз, повесите в шкаф и забудете про него до следующего интервью (а когда оно еще будет-то?)

Если так все просто, то в чем на интервью идти QA инженеру / руководителю группы / менеджеру? В костюме или просто нужно быть опрятно одетым? Как перед интервью определить в чем на него идти?

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

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

Ошибки вместо отображения исходного кода страницы в Google Chrome

noreply@blogger.com (Алексей Булат) — Mon, 15 Feb 2010 11:42:51 PST

Случайно натолкнулся на багу в сравнительно молодом, но очень перспективном браузере Google Chrome.

Не теряя времени перейду к делу!

Шаги для воспроизведения:
1. Открываем страницу http://protesting-jft.appspot.com/
2. Заполняем Number of Fields: 1
3. Кликаем Next
--> Страница High Level Initialization открыта
4. Просматриваем Исходных Код Страницы

И что мы имеем? А вот что:

Ничего странного не замечаете??? :)

В FF, IE, Safari все работает и код страницы отображается верно...

P.S. надеюсь, что данная бага будет пофикшена в скором будущем!

Да прибудет с Вами Source Code.
Алексей Булат

Интервью с тестировщиком: "Тестирование изменит подход к жизни раз и навсегда"

noreply@blogger.com (Алексей Булат) — Wed, 02 Dec 2009 01:55:57 PST

Добрый день, многоуважаемые читатели.

Всегда приятно поговорить с красивой девушкой, тем более если она работает в тестировании и еще является заместителем председателя Белорусской национальной коллегии тестировщиков (BySTQB).

Приветствуем в нашей студии Ирину Тетерук.

[АПЛОДИСМЕНТЫ]

Ирина, добрый день, надеюсь ты добралась до студии без приключений и можешь ответить на некоторые вопросы? Итак начнем. :)

Где ты сейчас работаешь и чем конкретно занимаешься?
- Я работаю на позиции инженера по обеспечению качества в небольшой IT компании, которая разрабатывает банковский софт.

В данный момент ты работаешь в маленькой IT компании, а как же твоя громкая позиция "заместителем председателя Белорусской национальной коллегии тестировщиков"?
- В своё время скучая в компании, где я на тот моент работала, заинтересовалась вопросом сертификации для тестировщиков, т.к. программисты постоянно "хвастались" новыми "бумажками" + хотелось изучить тестирование на основе книжек, т.к. к тому моменту у меня был только опыт и знания, полученные на основе практики. Сдать на сертификт я смогла только в России, естественно стало интересно организовать у нас возможность прохождения сертификации + донести информацию до людей. Нужен ли сертификат вопрос спорный, но то, что подготовка к нему время полезное думаю никто спорить не будет. После того как состоялся первый экзамен в Минске - начали думать над официальным представлением ISTQB в Минске, я была среди тех, кто всё организовывал. Название позиции громкое и как часто бывает за названием ничего не стоит кроме человека, который хочет, чтобы у тестировщика был не только практический опыт, но и теоретические знания.

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

Получается, что вы все работаете в BySTQB, ничего не получая за это?
- кроме морального удовлетворения - нет :-) но это уже приятно.

Каковы твои основные обязанности как председателя BySTQB?
- зампред ;-) . А если серьезно, то мы работаем в команде, поэтому подменяем друг друга, распределение должностей было формальностью, чтобы зарегистрировать белорусский board. Я участвую в организации экзаменов, веду переписку с людьми, у которых есть вопросы, перевожу на русский язык Силабус (Syllabus), а сейчас ещё нужно разрабатывать программу деятельности на будущий год.

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

Когда состоится следующий сертификаионный экзамен на BySTQB?
- экзамен будет в эту субботу 5 декабря, по поводу следующих пока не ясно. Будем разговаривать с представителем немецкой стороны.

Пожелаем удачи всем, кто в эту субботу будет сдавать экзамен.

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

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

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

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

С купюрками лучше не экспериментировать - ПРЕСЛЕДУЕТСЯ ЗАКОНОМ, а в остальном я с тобой согласен. Большое спасибо за время проведенное с нами, удачи тебе во всех начинаниях...

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

[АПЛОДИСМЕНТЫ]

Алексей Булат,
Ведущий рубрики "Интервью с тестировщиком".

Интервью с тестировщиком: "В общем, я попал в яблочко"

noreply@blogger.com (Алексей Булат) — Wed, 25 Nov 2009 09:18:46 PST

Надоело слушать интервью разных гуру, и тех представителей IT, чьи книги и блоги ты зачитываешь до дыр. Хочется увидеть тех, кого мы замечаем редко, и в основном в случаях когда наши проекты терпят неудачу, тех кого многие обвиняют во всех смертных и бессмертных грехах, а именно хочется поговорить с рядовым тестировщиком, который не ищет славы, которому просто нравится делать свою работу. Итак, приветствуем в нашей студии Алексея Лемешева, считающего тестирование своей родной стихией.

[АПЛОДИСМЕНТЫ]

Привет, Алексей, как настроение?
- Привет. В последнее время выше среднего

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

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

А возросла ли нагрузка к концу года?
- Я бы не сказал. Все идет в таком же темпе, как и раньше. Заказчики, что удивительно, не давят

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

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

А как ты пришел в тестирование? Что повлияло на твой выбор? С чего все началось?
- Хм, в тестирование меня привел случай, может даже и банальный. Вернувшись из штатов и просидев несколько месяцев дома, я подумал, что неплохо было бы и работу найти. Но чем именно заняться я не знал - на тот момент меня интересовало одновременно всё и ничего. И волею случая моя знакомая предложила мне попробовать тестирование, т.к. такому зануде как я это непременно должно было понравиться. Немножко почитав основы, я ринулся в кузницу кадров - Белхард, прошел собеседование и приступил к работе. И тут случилось то, что я еще никогда не испытывал в жизни - я шёл на работу с радостью. Скорее даже не шёл, а бежал. После окончания рабочего дня я всегда думал о том, чем я займусь завтра. В общем, я попал в яблочко.

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

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

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

В последнее время стало модно проводить разного рода конференции, тренинги, воркшопы и т.д., что ты думаешь об этом? Принимал ли ты участие в подобных мероприятиях?
- Честно признаться, я пока не был ни на одной конференции, хотя и пытался попасть на одну из SQA Days. В данный момент мое мнение о конференциях состоит из суждений моих друзей и коллег. Кто-то говорит, что это полезно, кто-то - что это просто вытягивание денег. Истина, как всегда, наверняка где-то посередине. Просто надо знать, что ты хочешь получить от этой конференции и ходить не на всё подряд, а лишь на те темы, которые действительно тебя интересуют. И еще: говорят, что общение и знакомство с людьми до и после конференции часто бывает куда полезней, чем сама конференция.

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

А через 20?
- А через 20 я уже буду состоятельным человеком в счастливом браке, с огромным счетом банке и несколькими виллами... И что-нибудь в духе: "А может быть в притонах Сан-Франциско лиловый негр вам подавал манто...". Шучу.

А через 30?
...
шучу, можно не отвечать...
Ну а если честно, Алексей, ты связываешь свое будущее с IT?
- Да связываю, но до какого-то определенного момента. Почему-то сложно представить себя 60тилетним QA менеджером. Но в ближайшие лет 10 лет я скорей всего продолжу работать в этой сфере - мне же это нравится.

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

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

[АПЛОДИСМЕНТЫ]

С Вами был Алексей Булат,
Ведущий рубрики "Интервью с тестировщиком".

ВОЛОСАТУЮ руку искать надо...

noreply@blogger.com (Алексей Булат) — Mon, 07 Dec 2009 04:03:10 PST

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

Итак начнем:

За месяц был выполнен целый 1 заказ. (Протестили сайтик ~30 страниц, в IE6,7,8, FF, Opera, Chrome, Safari. Потратили времени ~5 человекочасов. Найдено ~40 багов разных severity. За все это получили честно заработанные 12 WMZ :)
Вели переговоры еще по 1-му достаточно интересному проекту написанному на C++ .Net. Неделю заказчик мурыжил нас, а в итоге после личной встречи ушел в молчанку, наверное осознав, что то что он хочет - это не тестирование, а дебаг.
Выслали запросы на проведение работа по ~10 проектам, в итоге - ни ответа ни привета.

Выводы:

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

С уважением,
Алексей Булат

Оглядываясь назад, под монотонный стук дождя...

noreply@blogger.com (Алексей Булат) — Tue, 24 Nov 2009 06:08:25 PST

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

Я и подумать не мог, что такой простой вопрос вызовет во мне такую бурю разнообразных эмоций. Вспомнил все от начала и до конца. Вспомнил все проекты начиная с первой работы и до сегодняшнего дня. Везде было по своему сложно, увлекательно и в тоже время круто. Первый опыт первые шишки, первые шаги как автоматизатора, первые баги, найденные скриптами, первые завалы сервера под обычной нагрузкой, первые OutOfMemory после 48-ми часового теста... Эх... все было круто. Но что именно выделить? Вот в чем вопрос...

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

Я с ним согласен, но хочу сказать, что начало - это приключение, которое тебе предстоит пережить, далее идет работа, а в конце удовлетворение или упаси Боже - разочарование... И чтобы стать специалистом, просто необходимо пройти все эти стадии и испытать всю гамму чувств.

Но все-таки самое главное это то, что есть что вспомнить. Так как никто кроме Вас не поймет, чем вам понравился тот или ной проект, что он Вам дал, и чем он Вам так дорог.

Поэтому, ЦЕНИТЕ вашу работу и ЛЮБИТЕ то, что вы делает, и будет Вам счастье.

"Не ходите дети в Африку гулять" или "неудачная попытка фриланса"

noreply@blogger.com (Алексей Булат) — Fri, 13 Nov 2009 07:08:22 PST

Есть такая профессия - людей кидать
...
Дмитрий Олейников - дальше по тексту Заказчик

Говорила мне мама: "Не верь никому кроме самого себя". Не послушал я её.
А вот как все начиналось...

Решил я немного подработать, в простонародье заняться фрилансом. Сами понимаете, копейка лишней быть не может. Нашел на просторах инета сайтик по фрилансингу, зарегистрировался и давай искать проекты. Как по заказу, именно в этот день выложили там объявление: "тест и проверка сайт" ...
Ну и решил я попытать судьбу. Сделал свое предложение (тогда оно не показалось мне двусмысленным):

oт 3 до 4 часов
от $10 до $12
Alexey Bulat [boltick] [23.10 2009 | 19:19]
Оплата почасовая. Сделаем все быстро и качественно.

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

Весь следующий день от заказчика не было никакой реакции. Ближе к вечеру я ему написал:
- Получили ли Вы мое письмо с отчетом по работе?
Ответ последовал незамедлительно:
- все отлично куда кидать деньги?
Оставил я номер своего кошелька и жду... через минут 20 получаю на счет ровно 12 уе, а не 12 умножить на 4 часа работы, как рассчитывал.
Пишу заказчику:

boltick, 23.10.2009 17:25:34:
Хм... я так понял мы немного не правильно поняли друг друга...

на счет я получил только 12 уе, в то время как мое предложение на сайте было:
Alexey Bulat [boltick] [23.10 2009 | 19:19]
Оплата почасовая. Сделаем все быстро и качественно."
и т.д.

Оплата почасовая означает что 10-12 уе за час

И сегодня я уточнил это еще раз:
23.10.2009, 16:33
ну мы договаривались на 3-4 часа... но получилось 5 с хвостиком... :(
по деньгам говорили 10 - 12 за час... давайте усредним 11 уе...
------------------------

Ответ в принципе уже был мне очевиден, не буду приводить полную историю переписки, но в сокращенной форме она такова:

Demon©, 23.10.2009 17:26:13:
хмм за час
Demon©, 23.10.2009 17:26:31:
5 часов по 11 это 55 дол что ли?
Demon©, 23.10.2009 17:28:44:
зачем такие подставы кидать я же спросил какая сумма у меня было куча более дешевых предложений
boltick, 23.10.2009 17:29:30:
спасибо на счет подстав...
но в данном случае подставлен я, т.к. выполнил работу и не получил того на что рассчитывал

И в конце концов последовало вот такое предложение:

Demon©, 23.10.2009 17:32:47:
я в ближайшее время вам подгоняю еще одну работу что бы компенсировать эту ситуацию

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

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

В заключении как мораль:

ЗАРАНЕЕ ЧЕТКО ОГОВАРИВАЙТЕ ВСЕ УСЛОВИЯ ОПЛАТЫ ВАШЕЙ РАБОТЫ.

Далее публикую все контакты человека, который меня вполне возможно "кинул", ну или повел себя не очень правильно в конце нашего общего дела:
Имя - Дмитрий Олейников
ICQ - 96870096
Email - oleinikov@gmail.com
Vkontakte - http://vkontakte.ru/id565811

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

Всегда Ваш,
Алексей Булат

it4business.ru ушёл в DOWN

noreply@blogger.com (Алексей Булат) — Wed, 14 Oct 2009 05:44:40 PDT

Голландское время 14:33. Умираю от желания почитать форум тестеровщиков. Выбираю адресок из закладок и... получаю вот что:

"Верните форум на родину!!!" - закричал я от неожиданности... А в ответ тишина... Беспорядочно стал перебирать линки и играть с URL (ввожу чистый http://it4business.ru/), но опять ничего...

Спасите, помогите, верните последний оплот качества на просторах интернета...
Умираю но не сдаюсь...
Верю в возрождение птицы Феникс-it4business.ru

Всегда с Вами,
Алексей Булат

Тестирование. Все про автоматизированные, нагрузочные, ручные тесты. Все про обеспечение и контроль качества

Дипломатия или решаем проблемы грамотно

Процесс, который алмазы точит...

Happy vs Unhappy клиент

Бизнес процессы! Дмитрий Потапенко - О рознице

Рекомендации молодым багоборцам.

Основные аспекты создания скриптов для нагрузочного тестирования

Введение

Содержание

Стандартизация тестового набора для тестирования производительности

Структура каталогов тестового набора

Архитектура тест скриптов

Соглашение об именовании

Названия тест скриптов

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

Название транзакций

Порядок действий при разработке скриптов для тестирования производительности

Подготовка

Создание и отладка

Хранение

Конфигурация тестового набора для тестирования производительности

Вывод

Литература

Домино, Рыба или Кошка в горошек...

Конфигурация тестового стенда для нагрузочного тестирования

Введение

Содержание

Конфигурация vs Производительность

Конфигурация тестового стенда

Анализ результатов при разных конфигурациях

Использование переходного коэффициента

Использование экспертной оценки

Выводы

Литература

Модель нагрузки, как отправная точка при тестировании производительности

Введение

Содержание

Что же такое нагрузочное тестирование?

Анализ требований

Анализ требований в зависимости от типа проекта

Анализ целевой аудитории

Определение базового профиля нагрузки

Разработка моделей нагрузки

Модель тестирования производительности

Модель стрессового тестирования

Модель объемного тестирования

Модель тестирования стабильности или надежности

Выводы

Литература

Пишем систему автоматизированных тестов "с нуля"

Автоматизированное тестирование: работа со статическими ресурсами

PageObjects pattern + Selenium (Java)

PageObjects pattern или работаем по науке

Кириллические домены уже среди нас - УРА товарищи!!!

Тестирование по факту или/и по предоплате

Разработка тест кейсов или практическое применение тест дизайна

А судьи кто?

Встречают по одежке, а провожают по уму

Ошибки вместо отображения исходного кода страницы в Google Chrome

Интервью с тестировщиком: "Тестирование изменит подход к жизни раз и навсегда"

Интервью с тестировщиком: "В общем, я попал в яблочко"

ВОЛОСАТУЮ руку искать надо...

Оглядываясь назад, под монотонный стук дождя...

"Не ходите дети в Африку гулять" или "неудачная попытка фриланса"

it4business.ru ушёл в DOWN