Вы просили фото? Пожалуйста! :)
(молоток. вид сверху)
(молоток в руке разработчика. боевое состояние)
Всегда ваша,
Наташа Густыр
Read more...
четверг, 11 декабря 2008 г.
Молоток существует!
Друзья, в одном из своих постов, я писала о том, какой замечательный мотивационный инструмент есть у меня в команде - это МОЛОТОК!
Вы просили фото? Пожалуйста! :)
(молоток. вид сверху)
(молоток в руке разработчика. боевое состояние)
Всегда ваша,
Наташа Густыр
Read more...
Вы просили фото? Пожалуйста! :)
(молоток. вид сверху)
(молоток в руке разработчика. боевое состояние)
Всегда ваша,
Наташа Густыр
Read more...
среда, 10 декабря 2008 г.
SQA Days 2008 - полная версия флипа "Использование MS Excel в качестве унифицированного хранилища данных для автоматизированных тестов"
Для меня было несколько неожиданно, что мой нишевой флип вызовет такой интерес у коллег-тестировщиков. Поэтому (а еще и потому что временные рамки не позволяли изложить весь имеющийся материал) было решено после конференции собраться с силами и подготовить развернутую версию.
Итак силы были собраны и я приглашаю вас ознакомится с полной "режиссерской" версией доклада.
Аннотация
Доклад затрагивает проблему выбора унифицированного хранилища тестовых данных для проведения автоматизированных функциональных и нагрузочных тестов.
Приводимый в докладе подход никоим образом не претендует на истину в последней инстанции и отражает лишь удачный опыт автора в практическом применения данных механизмов в ходе реализации проектов функциональной автоматизации.
1.1 Предыстория
1.1.1 Автоматизация: от эйфории до созерцания
Есть несколько типичных ошибок, которые допускются при первых попытках внедрения автоматизации функционального тестирования. Эти ошибки допускаются естественно из-за отсутствия опыта в такого вида разработках и кроме того в некоторой степени ”поощряются” кажущейся легкостью работы в современных тестовых фреймворках при использовании механизмов макрозаписи (трансляции действий пользователя напрямую в тестовый скрипт). К сожалению подход при котором вся тестовая команда записывает килотонны кода, что вызывает невиданный прилив энтузиазма как у самих членов команды так и у руководства, приводит в конце концов к плачевным результатам.
Рано или поздно наступает тяжелый момент, когда нужно остановиться, отдышаться и трезвым взглядом посмотреть на дело рук своих, чтобы трезво оценить во что же выльется переделка.
В нашем случае ситуация оказалась настолько запущенной, что было принято решении отказаться от существующих скриптов такого вида и написании их с нуля в строгом соотвествии с оговоренными правилами которые впоследствии оформились в документ под названием “Test scriprting guideline”.
Я сознательно ушел от подробного разбора причин, которые привели к необходимости столь радикальных действий, чтобы детально рассмотреть их в следующей части доклада.
1.1.2 Проблема больших чисел
Сформулировать её можно следующим образом: при увеличении масштаба процесса на первый план выходят совершенно неучтенные и казалось бы незначительные факторы.
Правило очень актуальное для экспериментальных областей физики и химии оказывается как нельзя кстати и в процессе разработки автоматизированных тестов. Существует много возможностей для применения этого правила с точки зрения оптимизации процесса, но мы остановимся на следующей зависимости:
Количество скриптов : Время затрачиваемое на их поддержку
Если отобразить эту зависимость в виде графика где по оси Х будет отображаться количество скриптов а по оси Y – время необходимое для поддрежки этого количства скриптов, то мы получим три варианта развития событий.
Первый вариант – график выше линейного, говорит о том, что при разработке скриптов не использовались методики оптимизации, наверняка есть повторимость кода и структура скриптов не унифицирована.
Второй вариант – линейный, очевидно гораздо лучше первого рассмотренного варианта, но тем не менее он предлагает обычный экстенсивный путь развития при котором чем большее количество скриптов мы хотим реализовать тем большая команда автоматизации нам потребуется.
Третий вариант – очевидно,что именно к нему и нужно стремится, предполагает, что при увеличении скриптов время требуемое на их поддрежку растет незначительно.
Для того чтобы поддержка скриптов не легла непосильным бременем на тестовую команду при разработке тестов нужно обязательно уделять внимание таким моментам как:
• Унификация структуры сриптов (с последующим документированием этой структуры)
• Вынос общих бизнес-функций в библиотеки/классы
• Использование внешних источников данных
Несомненно все три озвученных практики являются важными, но согласно выбранной тематики доклада детальному разбору подвергем лишь последнюю из этого списка.
1.1.3 Идентификация проблемы.
Попытаемся сформулировать требования, которым должно удовлетворять внешнее хранилище данных и на основании этих требований оценить возможные варианты реализации.
Существуют 3 независимых пользователя нашего хранилища тестовых данных со своими, совершенно казалось бы непересекающимися требованиями:
Основным требованием предъявляемым со стороны тестовой команды (а здесь мы имеем ввиду именно функциональных тестировщиков) является простота создания и поддержки тестовых данных и отсутствие необходимости изучения каких-либо узкоспециализированных инструментов и сложных техник.
Со стороны команды автоматизации основное требование – это простота интеграции в существующие скрипты. По крайней мере процесс интеграци долджне быть не сложнее чем при применении стандартных встроенных хранилищ.
Не всегда но тем не менее со стороны заказчика тоже просыпается интерес к тестовым данным, которые используются при проведении автоматических тестов. И основное требование с этой стороны – это доступное визуальное оформление этих тестовых данных.
В следующей части доклада я постараюсь показать вам, что есть стандартные инструменты готовые удовлетворить все три потока требований. Но сначала рассмотрим, что предоставляется для реализации хранилищ самим инструментарием с которым мне приходилось сталкиваться в ходе работы.
1.2 Стандартные решения – достоинства и недостатки
1.2.1 Реализация внутренних хранилищ в семействах продуктов IBM Rational
В качестве встроенного хранилища данных в семействе продуктов Rational используются так называемые Датапулы (Datapools). Они представляют собой некий урезанный вариант таблиц базы данных.
Из положительных сторон можно отметить:
- встроенный механизм генераци данных
- родная поддержка на уровне скрипта
- возможность использования как для функционального так и для нагрузочного тестирования
Из минусов:
- неудобство редактирования данных
- отсутствие возможности группировки данных
1.2.2 Реализация внутренних хранилищ в семействах продуктов HP Mercury
В качестве встроенного хранилища данных в семействе продуктов HP Mercury используются стандартные Excel файлы.
Из положительных сторон можно отметить:
- удобство редактирования
- родная поддержка на уровне скрипта
Из минусов:
- при редактировании через встороенный редактор из файла удалятся всё форматирование
- отсутствие возможности группировки данных
1.2.3 Другие варианты хранения данных
• CVS файлы
Неудобство работы напрямую в файле. При использовании того же Excel в качестве редактора получаем 2-х проходную работу. Проблемы с группировкой и отсутсвием валидации на входе.
• XML файлы
Персонал должен как минимум понимать структуру XML, владеть одним из редакторов для манипуляции с файлами такого вида. Сложно задается валидация входных значений.
1.3 Поиск компромисса
1.3.1 Почему Excel?
При выборе варианта хранилища данных мы в качестве основного критерия выбрали удобство подготовки и редактирования данных. Акцент при выборе был сознательно смещен в эту сторону так как продукт был действительно большим и сложным и без помощи функциональной тестовой команды автоматизаторам было бы нереально подготовить такой объем данных.
Со стороны команды автоматизации было сделано допущение (впоследствии оно оказалось верным), что на уровне скрипта мы сможем создать механизмы по крайней мере не уступающие стандартным в удобстве использования. С этой позиции Excel был лучшим кандидатом, но в ходе реализации выяснялись некоторые особенности изучив которые мы смогли получить эффективную отдачу от выбранного инструмента. О них поговорим в следующей части доклада.
1.3.2 Хитрости и трюки
Для того чтобы получить видимые для ODBC таблицы в Excel- файле вы должны определенным образом разметить интересующие вас подмножества ячеек. Для этой цели служит функциональность называемая Names (именованные диапазоны). Создать именованный диапазон можно через “Define name” диалог (Insert > Name > Define) или через Formulas > Define Name в 2007-ом офисе.
После такого выделения ваши имена становятся доступны как таблицы для ODBC драйвера. Для проверки того что диапазон задан верно необходимо выделить помеченые ячейки и в Navigation bar должно отбразиться заданное имя.
1.3.3 «Ложка дегтя»: ограничения использования
Конечно все это было бы слишком хорошо если бы не было каких-либо ограничивающих факторов и они к сожалению есть:
- мы не сможем использовать наши тестовые данные для нагрузочных тестов как например в случае использования “родных” хранилищ Rational;
- у нас не будет возможности запускать наши тесты в многоплатформенной среде даже если сама тестовая платформа это позволяет.
Но из своей практики могу отметить, что эти ограничения не являются критичными для большинства тестовых проектов.
1.4 Из личного опыта: «Датадривен – это просто»
1.4.1 Задача: разработать автоматические тесты с возможностью кастомизации без изменения кода.
Кастомизация предполагалась следующая:
- скрипты должны были выполнятся как в рамках Smoke тестов так и в рамках основного цикла тестирования
- существовала необходимость использовать скрипты в том числе для загрузки некоторых специфичных начальных тестовых данных с UI (общесистемные данные грузились напрямую в БД на этапе сборки билда)
То есть было необходимо предусмотреть возможность запуска скриптов с разными наборами тестовых данных и также возможность отключения точек проверки для случая заполнения данных.
1.4.2 Вариант решения
- Использование property файлов для группы скриптов, в которых для каждого скрипта задаются его тестовые данные (в нашем случае имя Excel файла)
- На уровне самого скрипта задался набор данных по умолчанию, который позволял запускать скрипты без параметров
- На уровне property файлов также была возможность отключить отработку точек проверки
Реализация озвученных механизмов естественно потребовала четкой унификации структуры разрабатываемых скриптов, что было зафиксировано в руководстве по разработке скриптов.
1.4.3 Анализ полученного результата
В результате мы получили достаточно гибкую структуру решающую все поставленные задачи. Кроме того строгая унификация подходов к разработке избавляла нас от серьезных временных затрат при вхождении нового человека в команду автоматизации и при отладке скриптов после изменения UI.
Из минусов можно отметить следующий момент. Так как фреймворк реализовывался на обычном процедуральном языке (расширение VB) то все сервисные механизмы по работе с property файлами должны были присутствовать на уровне скриптов. И хотя реального кода там было не более 10 строк тем не менее это захламляло скрипт.
Дальнейшая реализация такого же подхода в рамках OO-языка (Functional Tester + Java) показала насколько эффективно сервисный код может быть скрыт на верхнем уровне иерархии.
1.5 Непознанный мир Excel
1.5.1 Возможность использования Excel в качестве источника XML-данных
Начиная с 2003-ей версии офиса в Excel появилась возможность интеграции с XML, причем как в сторону загрузки данных в Excel таблицы так и в сторону экспорта табличных данных в XML файл. Эта функциональность (называемая в офисе 2003 Lists а в 2007 – Tables) добавила еще больше гибкости в процедуру подготовки тестовых данных. Теперь появилась возможность оперировать с текстовыми данными практически любого вида. Единственно, что требуется дополнительно реализовать - это XSLT преобразование из полученного в процесе экспорта XML файла к требуемому для приложения виду.
1.5.2 Варианты применения
Лежащий на поверхности путь преобразования – это подготовка прямых SQL операторов для прямой заливки данных в базу. Кроме того могут понадобиться какие-либо специфичные форматы данных в основе которых лежат табличные данные (например, данные для Web- сервисов).
Очевидное преимущество получаемое от такой схемы работы – это простота поддержки и модификации наряду с гибкостью по отношению к выходным форматам.
1.6 Из личного опыта: «Пойди туда, не знаю куда – найди то, не знаю что»
1.6.1 Задача: протестировать процедуру миграции БД
Особенность задачи состояла в том, что заказчик (очень крупная страховая компания) неохотно шел на предоставление информации о структуре данных в старой БД. Не могу сказать что это было вызвано прямым нежеланием сотрудничать с нами. Вероятнее всего желание сотрудничества терялось где-то в хитросплетениях бюрократических процедур и просто не доходило до конкретного исполнителя. Тем не менее сроки для нас были поставлены достаточно жесткие и аппелировать потом к совести заказчика потрясая кипой грозных писем с нашей стороны особого желания не было.
На тот момент функционал по миграции уже более менее был готов к тестированию и для набивки тестовых данных не хватало детализации старой структуры в которую требовалось эти данные загружать.
Таким образом мы понимали, что подготовленные нами данные (а они естественно должны были быть в виде скриптов БД) обязательно потребуют модификации после уточнения оставшихся вопросов.
1.6.2 Вариант решения
Вот тут как нельзя кстати пригодилась новая функциональность Excel позволяющая выгружать данные в XML.
Мы сначала подготовили данные для понятных нам тестовых случаев и согласно предполагаемой структуре сделали прослойку для генерации скриптов (то есть приготовили набор XSL файлов необходимый для конвертации выгружаемых XML в требуемый нам формат).
Имея на руках уже готовые тестовые данные разговаривать с заказчиком стало гораздо проще. Стало очевидным что с нашей стороны были сделаны все шаги и без их активного участия дальше двигаться невозможно. Поэтому началось активное общение с разбором возникающих проблем и постепенное доведение наших скриптов до рабочего состояния.
1.6.3 Анализ полученного результата
Из несомненных плюсов примененного подхода хочется отметить, что мы смогли начать работу даже не имея на руках полностью разжеванной спецификации по БД, что при любых других вариантах решения привело к большим затратам по модификации готовых сриптов. Нам этого удалось избежать, сохранив по максиму уже подготовленные данные.
Из минусов или скажем так из особенностей нужно отметить что на стороне тестовой команды должен был присутствовать человек имеющий опыт работы с XML+XSLT. Но это, я считаю, является очень хорошим стимулом к изучению на практике новых областей не совсем типичных для просто функционального тестирования.
1.7 Из личного опыта: «Хотели бы помочь, но по-своему»
1.7.1 Задача: получить тестовые данные для проведения UAT от заказчика
В ходе работ по ”оживлению” старого демо-приложения выяснилось, что мы не можем убедиться в корректности работы функциональности отчетов в восстановленном функционале из-за полного отсутствия документации на эту часть приложения. Заказчик воспринял ситуацию адекватно и предложил свою помощь в разрешении проблемы, а именно предложил нам взять на себя подготовкку тестовых данных для этой части функционала. Наша радость к сожалению была очень недолгой, когда мы увидели в каком виде к нам начали приходить эти данные. Ни о какой организованной струтуре речи ни шло. Данные для полей с ограниченным набором списковых значений например могли отличаться от набора к набору ( как пример в одном наборе период назывался “semi-annual”, а в другом – “Semi annual”). Мы пришли к выводу, что на вычистку таких данных уйдет больше времени, если они не будут жестко следовать предопределенному формату.
1.7.2 Вариант решения
Решено было на основании уже полученных первых данных от заказчика и дальнейших консультаций подготовить шаблон для ввода данных с жесткими ограничениями на вводимые данные. В качестве оболочки для создания такого шаблона был выбран Excel с его функциональностью по валидации вводимых данных. Использовались такие типы валидаии как
- ограничение вводимых значений только значениями из списка
- задание диапазонов допустимых значений
В дальнейшем предполагалось использовать механизм выгрузки подготовленных данных в XML формат и конвертацию полученных XML файлов в последовательность SQL-операторов для загрузки данных напрямую в БД.
1.7.3 Анализ полученного результата
Шаблоны были успешно подготовлены, опробованы и отосланы заказчику для продолжения работы по набивке данных. Но видимо первый порыв альтруизма уже прошел и дальнейшего продолжения эта история увы не получила. Тем не менее мы со своей стороны получили опыт в реализации шаблонов для входных данных, который несомненно пригодится в будущем.
С уважением,
Сергей Талалаев
Read more...
Итак силы были собраны и я приглашаю вас ознакомится с полной "режиссерской" версией доклада.
Аннотация
Доклад затрагивает проблему выбора унифицированного хранилища тестовых данных для проведения автоматизированных функциональных и нагрузочных тестов.
Приводимый в докладе подход никоим образом не претендует на истину в последней инстанции и отражает лишь удачный опыт автора в практическом применения данных механизмов в ходе реализации проектов функциональной автоматизации.
1.1 Предыстория
1.1.1 Автоматизация: от эйфории до созерцания
Есть несколько типичных ошибок, которые допускются при первых попытках внедрения автоматизации функционального тестирования. Эти ошибки допускаются естественно из-за отсутствия опыта в такого вида разработках и кроме того в некоторой степени ”поощряются” кажущейся легкостью работы в современных тестовых фреймворках при использовании механизмов макрозаписи (трансляции действий пользователя напрямую в тестовый скрипт). К сожалению подход при котором вся тестовая команда записывает килотонны кода, что вызывает невиданный прилив энтузиазма как у самих членов команды так и у руководства, приводит в конце концов к плачевным результатам.
Рано или поздно наступает тяжелый момент, когда нужно остановиться, отдышаться и трезвым взглядом посмотреть на дело рук своих, чтобы трезво оценить во что же выльется переделка.
В нашем случае ситуация оказалась настолько запущенной, что было принято решении отказаться от существующих скриптов такого вида и написании их с нуля в строгом соотвествии с оговоренными правилами которые впоследствии оформились в документ под названием “Test scriprting guideline”.
Я сознательно ушел от подробного разбора причин, которые привели к необходимости столь радикальных действий, чтобы детально рассмотреть их в следующей части доклада.
1.1.2 Проблема больших чисел
Сформулировать её можно следующим образом: при увеличении масштаба процесса на первый план выходят совершенно неучтенные и казалось бы незначительные факторы.
Правило очень актуальное для экспериментальных областей физики и химии оказывается как нельзя кстати и в процессе разработки автоматизированных тестов. Существует много возможностей для применения этого правила с точки зрения оптимизации процесса, но мы остановимся на следующей зависимости:
Количество скриптов : Время затрачиваемое на их поддержку
Если отобразить эту зависимость в виде графика где по оси Х будет отображаться количество скриптов а по оси Y – время необходимое для поддрежки этого количства скриптов, то мы получим три варианта развития событий.
Первый вариант – график выше линейного, говорит о том, что при разработке скриптов не использовались методики оптимизации, наверняка есть повторимость кода и структура скриптов не унифицирована.
Второй вариант – линейный, очевидно гораздо лучше первого рассмотренного варианта, но тем не менее он предлагает обычный экстенсивный путь развития при котором чем большее количество скриптов мы хотим реализовать тем большая команда автоматизации нам потребуется.
Третий вариант – очевидно,что именно к нему и нужно стремится, предполагает, что при увеличении скриптов время требуемое на их поддрежку растет незначительно.
Для того чтобы поддержка скриптов не легла непосильным бременем на тестовую команду при разработке тестов нужно обязательно уделять внимание таким моментам как:
• Унификация структуры сриптов (с последующим документированием этой структуры)
• Вынос общих бизнес-функций в библиотеки/классы
• Использование внешних источников данных
Несомненно все три озвученных практики являются важными, но согласно выбранной тематики доклада детальному разбору подвергем лишь последнюю из этого списка.
1.1.3 Идентификация проблемы.
Попытаемся сформулировать требования, которым должно удовлетворять внешнее хранилище данных и на основании этих требований оценить возможные варианты реализации.
Существуют 3 независимых пользователя нашего хранилища тестовых данных со своими, совершенно казалось бы непересекающимися требованиями:
Основным требованием предъявляемым со стороны тестовой команды (а здесь мы имеем ввиду именно функциональных тестировщиков) является простота создания и поддержки тестовых данных и отсутствие необходимости изучения каких-либо узкоспециализированных инструментов и сложных техник.
Со стороны команды автоматизации основное требование – это простота интеграции в существующие скрипты. По крайней мере процесс интеграци долджне быть не сложнее чем при применении стандартных встроенных хранилищ.
Не всегда но тем не менее со стороны заказчика тоже просыпается интерес к тестовым данным, которые используются при проведении автоматических тестов. И основное требование с этой стороны – это доступное визуальное оформление этих тестовых данных.
В следующей части доклада я постараюсь показать вам, что есть стандартные инструменты готовые удовлетворить все три потока требований. Но сначала рассмотрим, что предоставляется для реализации хранилищ самим инструментарием с которым мне приходилось сталкиваться в ходе работы.
1.2 Стандартные решения – достоинства и недостатки
1.2.1 Реализация внутренних хранилищ в семействах продуктов IBM Rational
В качестве встроенного хранилища данных в семействе продуктов Rational используются так называемые Датапулы (Datapools). Они представляют собой некий урезанный вариант таблиц базы данных.
Из положительных сторон можно отметить:
- встроенный механизм генераци данных
- родная поддержка на уровне скрипта
- возможность использования как для функционального так и для нагрузочного тестирования
Из минусов:
- неудобство редактирования данных
- отсутствие возможности группировки данных
1.2.2 Реализация внутренних хранилищ в семействах продуктов HP Mercury
В качестве встроенного хранилища данных в семействе продуктов HP Mercury используются стандартные Excel файлы.
Из положительных сторон можно отметить:
- удобство редактирования
- родная поддержка на уровне скрипта
Из минусов:
- при редактировании через встороенный редактор из файла удалятся всё форматирование
- отсутствие возможности группировки данных
1.2.3 Другие варианты хранения данных
• CVS файлы
Неудобство работы напрямую в файле. При использовании того же Excel в качестве редактора получаем 2-х проходную работу. Проблемы с группировкой и отсутсвием валидации на входе.
• XML файлы
Персонал должен как минимум понимать структуру XML, владеть одним из редакторов для манипуляции с файлами такого вида. Сложно задается валидация входных значений.
1.3 Поиск компромисса
1.3.1 Почему Excel?
При выборе варианта хранилища данных мы в качестве основного критерия выбрали удобство подготовки и редактирования данных. Акцент при выборе был сознательно смещен в эту сторону так как продукт был действительно большим и сложным и без помощи функциональной тестовой команды автоматизаторам было бы нереально подготовить такой объем данных.
Со стороны команды автоматизации было сделано допущение (впоследствии оно оказалось верным), что на уровне скрипта мы сможем создать механизмы по крайней мере не уступающие стандартным в удобстве использования. С этой позиции Excel был лучшим кандидатом, но в ходе реализации выяснялись некоторые особенности изучив которые мы смогли получить эффективную отдачу от выбранного инструмента. О них поговорим в следующей части доклада.
1.3.2 Хитрости и трюки
Для того чтобы получить видимые для ODBC таблицы в Excel- файле вы должны определенным образом разметить интересующие вас подмножества ячеек. Для этой цели служит функциональность называемая Names (именованные диапазоны). Создать именованный диапазон можно через “Define name” диалог (Insert > Name > Define) или через Formulas > Define Name в 2007-ом офисе.
После такого выделения ваши имена становятся доступны как таблицы для ODBC драйвера. Для проверки того что диапазон задан верно необходимо выделить помеченые ячейки и в Navigation bar должно отбразиться заданное имя.
1.3.3 «Ложка дегтя»: ограничения использования
Конечно все это было бы слишком хорошо если бы не было каких-либо ограничивающих факторов и они к сожалению есть:
- мы не сможем использовать наши тестовые данные для нагрузочных тестов как например в случае использования “родных” хранилищ Rational;
- у нас не будет возможности запускать наши тесты в многоплатформенной среде даже если сама тестовая платформа это позволяет.
Но из своей практики могу отметить, что эти ограничения не являются критичными для большинства тестовых проектов.
1.4 Из личного опыта: «Датадривен – это просто»
1.4.1 Задача: разработать автоматические тесты с возможностью кастомизации без изменения кода.
Кастомизация предполагалась следующая:
- скрипты должны были выполнятся как в рамках Smoke тестов так и в рамках основного цикла тестирования
- существовала необходимость использовать скрипты в том числе для загрузки некоторых специфичных начальных тестовых данных с UI (общесистемные данные грузились напрямую в БД на этапе сборки билда)
То есть было необходимо предусмотреть возможность запуска скриптов с разными наборами тестовых данных и также возможность отключения точек проверки для случая заполнения данных.
1.4.2 Вариант решения
- Использование property файлов для группы скриптов, в которых для каждого скрипта задаются его тестовые данные (в нашем случае имя Excel файла)
- На уровне самого скрипта задался набор данных по умолчанию, который позволял запускать скрипты без параметров
- На уровне property файлов также была возможность отключить отработку точек проверки
Реализация озвученных механизмов естественно потребовала четкой унификации структуры разрабатываемых скриптов, что было зафиксировано в руководстве по разработке скриптов.
1.4.3 Анализ полученного результата
В результате мы получили достаточно гибкую структуру решающую все поставленные задачи. Кроме того строгая унификация подходов к разработке избавляла нас от серьезных временных затрат при вхождении нового человека в команду автоматизации и при отладке скриптов после изменения UI.
Из минусов можно отметить следующий момент. Так как фреймворк реализовывался на обычном процедуральном языке (расширение VB) то все сервисные механизмы по работе с property файлами должны были присутствовать на уровне скриптов. И хотя реального кода там было не более 10 строк тем не менее это захламляло скрипт.
Дальнейшая реализация такого же подхода в рамках OO-языка (Functional Tester + Java) показала насколько эффективно сервисный код может быть скрыт на верхнем уровне иерархии.
1.5 Непознанный мир Excel
1.5.1 Возможность использования Excel в качестве источника XML-данных
Начиная с 2003-ей версии офиса в Excel появилась возможность интеграции с XML, причем как в сторону загрузки данных в Excel таблицы так и в сторону экспорта табличных данных в XML файл. Эта функциональность (называемая в офисе 2003 Lists а в 2007 – Tables) добавила еще больше гибкости в процедуру подготовки тестовых данных. Теперь появилась возможность оперировать с текстовыми данными практически любого вида. Единственно, что требуется дополнительно реализовать - это XSLT преобразование из полученного в процесе экспорта XML файла к требуемому для приложения виду.
1.5.2 Варианты применения
Лежащий на поверхности путь преобразования – это подготовка прямых SQL операторов для прямой заливки данных в базу. Кроме того могут понадобиться какие-либо специфичные форматы данных в основе которых лежат табличные данные (например, данные для Web- сервисов).
Очевидное преимущество получаемое от такой схемы работы – это простота поддержки и модификации наряду с гибкостью по отношению к выходным форматам.
1.6 Из личного опыта: «Пойди туда, не знаю куда – найди то, не знаю что»
1.6.1 Задача: протестировать процедуру миграции БД
Особенность задачи состояла в том, что заказчик (очень крупная страховая компания) неохотно шел на предоставление информации о структуре данных в старой БД. Не могу сказать что это было вызвано прямым нежеланием сотрудничать с нами. Вероятнее всего желание сотрудничества терялось где-то в хитросплетениях бюрократических процедур и просто не доходило до конкретного исполнителя. Тем не менее сроки для нас были поставлены достаточно жесткие и аппелировать потом к совести заказчика потрясая кипой грозных писем с нашей стороны особого желания не было.
На тот момент функционал по миграции уже более менее был готов к тестированию и для набивки тестовых данных не хватало детализации старой структуры в которую требовалось эти данные загружать.
Таким образом мы понимали, что подготовленные нами данные (а они естественно должны были быть в виде скриптов БД) обязательно потребуют модификации после уточнения оставшихся вопросов.
1.6.2 Вариант решения
Вот тут как нельзя кстати пригодилась новая функциональность Excel позволяющая выгружать данные в XML.
Мы сначала подготовили данные для понятных нам тестовых случаев и согласно предполагаемой структуре сделали прослойку для генерации скриптов (то есть приготовили набор XSL файлов необходимый для конвертации выгружаемых XML в требуемый нам формат).
Имея на руках уже готовые тестовые данные разговаривать с заказчиком стало гораздо проще. Стало очевидным что с нашей стороны были сделаны все шаги и без их активного участия дальше двигаться невозможно. Поэтому началось активное общение с разбором возникающих проблем и постепенное доведение наших скриптов до рабочего состояния.
1.6.3 Анализ полученного результата
Из несомненных плюсов примененного подхода хочется отметить, что мы смогли начать работу даже не имея на руках полностью разжеванной спецификации по БД, что при любых других вариантах решения привело к большим затратам по модификации готовых сриптов. Нам этого удалось избежать, сохранив по максиму уже подготовленные данные.
Из минусов или скажем так из особенностей нужно отметить что на стороне тестовой команды должен был присутствовать человек имеющий опыт работы с XML+XSLT. Но это, я считаю, является очень хорошим стимулом к изучению на практике новых областей не совсем типичных для просто функционального тестирования.
1.7 Из личного опыта: «Хотели бы помочь, но по-своему»
1.7.1 Задача: получить тестовые данные для проведения UAT от заказчика
В ходе работ по ”оживлению” старого демо-приложения выяснилось, что мы не можем убедиться в корректности работы функциональности отчетов в восстановленном функционале из-за полного отсутствия документации на эту часть приложения. Заказчик воспринял ситуацию адекватно и предложил свою помощь в разрешении проблемы, а именно предложил нам взять на себя подготовкку тестовых данных для этой части функционала. Наша радость к сожалению была очень недолгой, когда мы увидели в каком виде к нам начали приходить эти данные. Ни о какой организованной струтуре речи ни шло. Данные для полей с ограниченным набором списковых значений например могли отличаться от набора к набору ( как пример в одном наборе период назывался “semi-annual”, а в другом – “Semi annual”). Мы пришли к выводу, что на вычистку таких данных уйдет больше времени, если они не будут жестко следовать предопределенному формату.
1.7.2 Вариант решения
Решено было на основании уже полученных первых данных от заказчика и дальнейших консультаций подготовить шаблон для ввода данных с жесткими ограничениями на вводимые данные. В качестве оболочки для создания такого шаблона был выбран Excel с его функциональностью по валидации вводимых данных. Использовались такие типы валидаии как
- ограничение вводимых значений только значениями из списка
- задание диапазонов допустимых значений
В дальнейшем предполагалось использовать механизм выгрузки подготовленных данных в XML формат и конвертацию полученных XML файлов в последовательность SQL-операторов для загрузки данных напрямую в БД.
1.7.3 Анализ полученного результата
Шаблоны были успешно подготовлены, опробованы и отосланы заказчику для продолжения работы по набивке данных. Но видимо первый порыв альтруизма уже прошел и дальнейшего продолжения эта история увы не получила. Тем не менее мы со своей стороны получили опыт в реализации шаблонов для входных данных, который несомненно пригодится в будущем.
С уважением,
Сергей Талалаев
Read more...
суббота, 6 декабря 2008 г.
Курс "Основы функционального тестирования с использованием инструментов IBM Rational"
В первые (хотелось бы сказать морозные :) но не могу) деньки зимы, а точнее с 1-го по 3-е декабря прочитал курс (см. заголовок) в компании Интерфейс.
Группа была небольшой и очень подготовленной с профессиональной точки зрения. Практически все слушатели уже имели некоторый опыт работы с данным фреймворком и задаваемые вопросы носили вполне конкретную прикладную направленность.
Курс получился очень полным с точки зрения реализации не только основного обязательного материала, но и дополнительных практик и методов накопленных за время работы с данными продуктами (и не только с ними). Хотел бы отметить, что я сам получил огромное удовольствие от работы с ТАКОЙ группой.
Дмитрий, Александр, Олег, Станислав, огромное вам спасибо, коллеги. Меня очень подстегивали и мотивировали ваши практические вопросы "из жизни". В свою очередь надеюсь, что вы получили на них полноценные ответы и теперь четко представляете себе дальнейший вектор движения в рамках внедрения автоматизированного тестирования.
В напутствие хотелось бы пожелать, чтобы полученные знания получили возможность быть примененными на практике.
С уважением,
Сергей Талалаев
Read more...
Группа была небольшой и очень подготовленной с профессиональной точки зрения. Практически все слушатели уже имели некоторый опыт работы с данным фреймворком и задаваемые вопросы носили вполне конкретную прикладную направленность.
Курс получился очень полным с точки зрения реализации не только основного обязательного материала, но и дополнительных практик и методов накопленных за время работы с данными продуктами (и не только с ними). Хотел бы отметить, что я сам получил огромное удовольствие от работы с ТАКОЙ группой.
Дмитрий, Александр, Олег, Станислав, огромное вам спасибо, коллеги. Меня очень подстегивали и мотивировали ваши практические вопросы "из жизни". В свою очередь надеюсь, что вы получили на них полноценные ответы и теперь четко представляете себе дальнейший вектор движения в рамках внедрения автоматизированного тестирования.
В напутствие хотелось бы пожелать, чтобы полученные знания получили возможность быть примененными на практике.
С уважением,
Сергей Талалаев
Read more...
пятница, 5 декабря 2008 г.
Урок 6: Работайте с программистами сообща
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр
Поддержка программистов – это, наверное, ключевая часть вашей миссии. Когда вы тестируете вещи, которые программисты разрабатывают прямо сейчас, или недавно разработали, ваши отзывы помогут им работать более эффективно. Когда они что-то доставляют, вы тестируйте это. Когда они вносят какое-либо изменение, вы тестируйте это изменение. Ставьте перед собой цель предоставлять обратную связь наиболее коротким и быстрым путем. Пока программисты «пережевывают» баги, которые вы только что нашли, вы свободны для того, чтобы искать еще больше новых багов. Идеальная ситуация (для тестировщиков) – это та, в которой разработчики заняты исправлением проблем настолько, что вы можете явно дать понять, кто в проекте – узкое место (они, а не вы!).
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр
Поддержка программистов – это, наверное, ключевая часть вашей миссии. Когда вы тестируете вещи, которые программисты разрабатывают прямо сейчас, или недавно разработали, ваши отзывы помогут им работать более эффективно. Когда они что-то доставляют, вы тестируйте это. Когда они вносят какое-либо изменение, вы тестируйте это изменение. Ставьте перед собой цель предоставлять обратную связь наиболее коротким и быстрым путем. Пока программисты «пережевывают» баги, которые вы только что нашли, вы свободны для того, чтобы искать еще больше новых багов. Идеальная ситуация (для тестировщиков) – это та, в которой разработчики заняты исправлением проблем настолько, что вы можете явно дать понять, кто в проекте – узкое место (они, а не вы!).
Read more...
вторник, 25 ноября 2008 г.
Урок 238: Нанимайте людей, которые любят свою работу
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Обращайте внимание на энтузиазм кандидата и будьте осторожны с кандидатами имевшими разногласия с руководством на предыдущих местах работы. Особенно будьте недоверчивы к людям которые были чем-либо обижены на предыдущем месте работы.
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Обращайте внимание на энтузиазм кандидата и будьте осторожны с кандидатами имевшими разногласия с руководством на предыдущих местах работы. Особенно будьте недоверчивы к людям которые были чем-либо обижены на предыдущем месте работы.
Read more...
понедельник, 24 ноября 2008 г.
Урок 244: После принятия решения - оперативно завершайте процедуру найма
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Быстрое проведение документов кандидата по каналам компании должно иметь максимальный приоритет, иначе из-за вашей задержки хороший кандидат может принять предложение другой компании.
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Быстрое проведение документов кандидата по каналам компании должно иметь максимальный приоритет, иначе из-за вашей задержки хороший кандидат может принять предложение другой компании.
Read more...
пятница, 21 ноября 2008 г.
Молоток для тестировщика, или Один из способов формирования дружеской атмосферы в команде
Ни для кого не секрет, что зачастую отношения между разработчиками и тестироващиками оставляют желать лучшего. Одни считаются создателями (разработчики), а другие разрушителями (соответственно, тестировщики).
Разработчики порой очень остро реагируют на найденные в их коде ошибки, на невоспроизводимое описание ошибки и особенно на те ошибки, которые таковыми не являются (например, зарегистрировано, что какая-то функция не работает, а на деле оказывается, что тестировщик не произвел каких-либо настроек или неправильно собрал билд, или что-то еще...)
Подобного рода казусы вызывают гнев у разработчиков и они начинают отчаянно поливать грязью своих коллег-тестировщиков. Как этого избежать?
Один из способов - относиться к этому с юмором, если только подобного рода ситуации не являются признаком непрофессионализма вашего тестировщика. Помните - всем свойственно ошибаться.
Например, в моей нынешней команде ситуация решается вот таким забавным образом.
Однажды моему техлиду на День Рождения подарили молоток (!). И не простой молоток, а резиновый! - очень по-дружески...
Молотком этим пользуется вся команда разработки. Инструкция по использованию такая:
1) Если вы не довольны работой тестировщика, не злитесь, возьмите молоток в руки.
2) Подойдите к тестировщику с улыбкой на лице и молотком за спиной.
3) С этой же неизменной добродушной улыбкой достаньте молоток из-за спины и аккуратно положите его рядом с тестировщиком.
4) Придвиньте стул, сядьте и, продолжая мило улыбаться, спросите "Так что у нас не работает?"
Не поверите - либо все сразу заработает, либо очень быстро и безболезненно удастся разобраться.
P.S. А тот смех, который возникает у всех членов команды и окружающих при виде молотка очень положительно сказывается на общем бодром и дружеском настроении и взаимоотношениях в коллективе!
Найдите и вы свой "молоток"!
Всегда ваша,
Наташа Густыр
Read more...
Разработчики порой очень остро реагируют на найденные в их коде ошибки, на невоспроизводимое описание ошибки и особенно на те ошибки, которые таковыми не являются (например, зарегистрировано, что какая-то функция не работает, а на деле оказывается, что тестировщик не произвел каких-либо настроек или неправильно собрал билд, или что-то еще...)
Подобного рода казусы вызывают гнев у разработчиков и они начинают отчаянно поливать грязью своих коллег-тестировщиков. Как этого избежать?
Один из способов - относиться к этому с юмором, если только подобного рода ситуации не являются признаком непрофессионализма вашего тестировщика. Помните - всем свойственно ошибаться.
Например, в моей нынешней команде ситуация решается вот таким забавным образом.
Однажды моему техлиду на День Рождения подарили молоток (!). И не простой молоток, а резиновый! - очень по-дружески...
Молотком этим пользуется вся команда разработки. Инструкция по использованию такая:
1) Если вы не довольны работой тестировщика, не злитесь, возьмите молоток в руки.
2) Подойдите к тестировщику с улыбкой на лице и молотком за спиной.
3) С этой же неизменной добродушной улыбкой достаньте молоток из-за спины и аккуратно положите его рядом с тестировщиком.
4) Придвиньте стул, сядьте и, продолжая мило улыбаться, спросите "Так что у нас не работает?"
Не поверите - либо все сразу заработает, либо очень быстро и безболезненно удастся разобраться.
P.S. А тот смех, который возникает у всех членов команды и окружающих при виде молотка очень положительно сказывается на общем бодром и дружеском настроении и взаимоотношениях в коллективе!
Найдите и вы свой "молоток"!
Всегда ваша,
Наташа Густыр
Read more...
Подписаться на:
Сообщения (Atom)
