Друзья!
Уже совсем скоро на ресурсе it-conf появится видео всех докладов.
В настоящий момент готовы видеоролики всех докладов 2-й секции, а также некоторых флип-чартов и частично вступлений 1-й секции.
Всем, кто не был на конференции, очень советую посмотреть видео - ощутите себя полноценным участником, за тем небольшим исключением, что всего лишь не будет возможности задать вопросы докладчикам.
Всем, кто присутствовал на конференции, советую посмотреть доклады еще раз. Таким образом можно освежить материалы в памяти и сделать акценты на тех вещах, которые остались за гранью вашего внимания при первом прослушивании.
Всегда ваша,
Наташа Густыр
Read more...
Показаны сообщения с ярлыком конференции. Показать все сообщения
Показаны сообщения с ярлыком конференции. Показать все сообщения
вторник, 6 января 2009 г.
четверг, 11 декабря 2008 г.
Интервью на www.software-testing.ru
Это еще отголоски конференции SQA Days 2008 в Минске.
После окончания конференци мне выпал шанс пообщаться в совершенно свободной атмосфере с нашими коллегами из других городов. Одним из них был Алексей Баранцев - ныне главный редактор ресурса www.software-testing.ru
Уже в завершении вечера Алексей спросил: "Наташа, а, может, скажешь несколько слов о конференции для ресурса?"
Я с удовольствием согласилась.
Алексей достал диктофон - и началось :)
Поскольку мне только дай поговорить, а времени было не очень много, и Алексея уже тянули за рукав его товарищи, торопившиеся на поезд, то о самой конференции я успела сказать только несколько слов, больше обо мне самой получилось...
Собственно, вот и само
"Интервью с Натальей Густыр на SQA Days 2008 Minsk".
Сегодня мы публикуем интервью с Натальей Густыр, менеджером проектов компании Qulix Systems. Наталья входила в состав оргкомитета и была ведущей секции тестирования на конференции SQA Days 2008 Minsk. Но поскольку интервью состоялось сразу же после окончания конференции, впечатления были ещё слишком свежи, так что мы решили задать вопросы, не связанные с конференцией.
Расскажи о себе, как ты попала в тестирование? Что тебе понравилось или не понравилось в тестировании?
История довольно простая и незатейливая. Когда я устраивалась на работу тестировщиком, то еще мало кто знал вообще, что это такое.
В России, например, тестирование появилось гораздо раньше, чем в Беларуси. Оно и сейчас идет на несколько шагов впереди.. Компании брали на работу тестировщиками людей без опыта. Обычно человек приходил на собеседование, не имея четкого понятия о тестировании, а все его представления об этой профессии были на чисто интуитивном уровне. И в тестировщики брали всех, кто имел к этому хоть какие-то задатки: структурировано излагал свои мысли, видел нестандартное поведение простых вещей.
На тот момент я работала на радиостанции, занималась продажами – продавала рекламное время, но с каждым днем я все больше и больше ненавидела свою работу. И меня постоянно посещали мысли о том, что я отучилась в университете, имею высшее математическое образование, а занимаюсь какой-то низкоквалифицированной ерундой. И почему бы мне не пойти работать в какую-нибудь IT-компанию, чтобы использовать, наконец, свои знания по назначению. Но чем там заниматься? Кроме программирования, я вообще не представляла себе, чем можно заниматься в IT-компании. Но я не видела себя программистом, поэтому ясно осознавала, что этот путь для меня закрыт.
Но у меня была подруга, которая уже попробовала работать тестировщиком. Она-то мне и посоветовала: «Наташа, не переживай! Рассылай резюме на тестировщика – сейчас всех берут». Я подала резюме, и буквально на следующий день меня пригласили на собеседование. Собеседование проводили два молодых человека с горящими глазами: мой нынешний генеральный директор и директор отдела качества. Один из них нарисовал формочку и предложили мне составить максимальное количество тестов. Я с легкостью выполнила это задание, даже пыталась спорить в какой-то момент! На вопрос, знаю ли я что такое тестирование, я ответила, что не знаю, но предполагаю, что я должна искать дефекты, т.е. смотреть, как работает программа, и если она где-то сломалась, значит, это дефект, вот собственно этим я и должна буду заниматься. Меня взяли, помучив ожиданиями дней пару.
Когда я начала работать, я поняла, что попала в свою среду. Я просто влюбилась в то, что делаю. Нет. Даже больше – я ловила огромный кайф. Я очень быстро набралась знаний и навыков, потому что постоянно интересовалась, и продолжаю интересоваться, чем занимаются другие люди в этой среде. Более того, у меня были очень интересные и разнообразные проекты и хорошие наставники. Я стараюсь следить за новинками литературы, стараюсь общаться с интересными людьми из этой сферы.
Кажется, Роберт Кийосаки говорил, что если ты хочешь зарабатывать много денег, надо общаться с богатыми людьми. Это правило работает, наверное, во всех сферах, и в нашей тоже. Поэтому если ты хочешь быть профессиональным тестировщиком, то надо обязательно общаться с тестировщиками-профессионалами. Именно это я и стараюсь делать.
Мы знаем, что ты читаешь курсы по тестированию в Москве. Почему именно в Москве, почему не в Минске?
Корни преподавательской деятельности в Москве идут от нашей компании. Ещё до моего прихода в Qulix Systems, компания уже сотрудничала с московским обучающим центром компании Интерфейс. Некоторые сотрудники, включая нашего генерального директора, читали свои курсы в Москве. Изначально курсы были связаны с инструментами Rational.
А я в какой-то момент поняла, что хочу делиться с коллегами теми знаниями и навыками, которые успела приобрести. Так родились несколько внутренних семинаров, которые как-то очень удачно сложились в курс. Так что когда меня пригласили прочитать курс «Введение в тестирование ПО», у меня не было никаких сомнений, что всё получится.
Есть и еще одна причина, почему минские специалисты читают курсы в Москве. Уровень зарплат в Москве и в Минске заметно различается, и учебным центрам выгоднее пригласить преподавателей из Минска, от чего уровень обучения, надо сказать, не снижается.
Кроме того, в Минске еще не сложился рынок внешних курсов, особенно в области тестирования. Если компания большая, такая как EPAM или IBA, она обычно имеет внутренний учебный центр, а в маленьких компаниях учат методом наставничества. По инструментам разработки или по базам данных можно найти внешние курсы, а вот по тестированию практически ничего нет.
Мы долгое время вели переговоры с ВУЗами, и не так давно наконец-то пришли к соглашению. Я буду читать курсы в БГУИР уже с нового года, а также на мех-мате БГУ проведу несколько занятий, чтобы заинтересовать студентов в дальнейшем обучении.
Несколько слов о конференции?
Сейчас, по горячим следам, я пока ещё чувствую такой сильный драйв, так что сложно оценить впечатления. Очень понравилась атмосфера. Это мой первый опыт организации конференции. Все отзывы, которые я слышала, – положительные. Я получила огромное удовольствие и от подготовки конференции и от проведения. Но, конечно, нам ещё предстоит пересмотреть анкеты участников, разобрать их отзывы, чтобы сделать следующие конференции еще лучше.
Спасибо!
Read more...
После окончания конференци мне выпал шанс пообщаться в совершенно свободной атмосфере с нашими коллегами из других городов. Одним из них был Алексей Баранцев - ныне главный редактор ресурса www.software-testing.ru
Уже в завершении вечера Алексей спросил: "Наташа, а, может, скажешь несколько слов о конференции для ресурса?"
Я с удовольствием согласилась.
Алексей достал диктофон - и началось :)
Поскольку мне только дай поговорить, а времени было не очень много, и Алексея уже тянули за рукав его товарищи, торопившиеся на поезд, то о самой конференции я успела сказать только несколько слов, больше обо мне самой получилось...
Собственно, вот и само
"Интервью с Натальей Густыр на SQA Days 2008 Minsk".
Сегодня мы публикуем интервью с Натальей Густыр, менеджером проектов компании Qulix Systems. Наталья входила в состав оргкомитета и была ведущей секции тестирования на конференции SQA Days 2008 Minsk. Но поскольку интервью состоялось сразу же после окончания конференции, впечатления были ещё слишком свежи, так что мы решили задать вопросы, не связанные с конференцией.
Расскажи о себе, как ты попала в тестирование? Что тебе понравилось или не понравилось в тестировании?
История довольно простая и незатейливая. Когда я устраивалась на работу тестировщиком, то еще мало кто знал вообще, что это такое.
В России, например, тестирование появилось гораздо раньше, чем в Беларуси. Оно и сейчас идет на несколько шагов впереди.. Компании брали на работу тестировщиками людей без опыта. Обычно человек приходил на собеседование, не имея четкого понятия о тестировании, а все его представления об этой профессии были на чисто интуитивном уровне. И в тестировщики брали всех, кто имел к этому хоть какие-то задатки: структурировано излагал свои мысли, видел нестандартное поведение простых вещей.
На тот момент я работала на радиостанции, занималась продажами – продавала рекламное время, но с каждым днем я все больше и больше ненавидела свою работу. И меня постоянно посещали мысли о том, что я отучилась в университете, имею высшее математическое образование, а занимаюсь какой-то низкоквалифицированной ерундой. И почему бы мне не пойти работать в какую-нибудь IT-компанию, чтобы использовать, наконец, свои знания по назначению. Но чем там заниматься? Кроме программирования, я вообще не представляла себе, чем можно заниматься в IT-компании. Но я не видела себя программистом, поэтому ясно осознавала, что этот путь для меня закрыт.
Но у меня была подруга, которая уже попробовала работать тестировщиком. Она-то мне и посоветовала: «Наташа, не переживай! Рассылай резюме на тестировщика – сейчас всех берут». Я подала резюме, и буквально на следующий день меня пригласили на собеседование. Собеседование проводили два молодых человека с горящими глазами: мой нынешний генеральный директор и директор отдела качества. Один из них нарисовал формочку и предложили мне составить максимальное количество тестов. Я с легкостью выполнила это задание, даже пыталась спорить в какой-то момент! На вопрос, знаю ли я что такое тестирование, я ответила, что не знаю, но предполагаю, что я должна искать дефекты, т.е. смотреть, как работает программа, и если она где-то сломалась, значит, это дефект, вот собственно этим я и должна буду заниматься. Меня взяли, помучив ожиданиями дней пару.
Когда я начала работать, я поняла, что попала в свою среду. Я просто влюбилась в то, что делаю. Нет. Даже больше – я ловила огромный кайф. Я очень быстро набралась знаний и навыков, потому что постоянно интересовалась, и продолжаю интересоваться, чем занимаются другие люди в этой среде. Более того, у меня были очень интересные и разнообразные проекты и хорошие наставники. Я стараюсь следить за новинками литературы, стараюсь общаться с интересными людьми из этой сферы.
Кажется, Роберт Кийосаки говорил, что если ты хочешь зарабатывать много денег, надо общаться с богатыми людьми. Это правило работает, наверное, во всех сферах, и в нашей тоже. Поэтому если ты хочешь быть профессиональным тестировщиком, то надо обязательно общаться с тестировщиками-профессионалами. Именно это я и стараюсь делать.
Мы знаем, что ты читаешь курсы по тестированию в Москве. Почему именно в Москве, почему не в Минске?
Корни преподавательской деятельности в Москве идут от нашей компании. Ещё до моего прихода в Qulix Systems, компания уже сотрудничала с московским обучающим центром компании Интерфейс. Некоторые сотрудники, включая нашего генерального директора, читали свои курсы в Москве. Изначально курсы были связаны с инструментами Rational.
А я в какой-то момент поняла, что хочу делиться с коллегами теми знаниями и навыками, которые успела приобрести. Так родились несколько внутренних семинаров, которые как-то очень удачно сложились в курс. Так что когда меня пригласили прочитать курс «Введение в тестирование ПО», у меня не было никаких сомнений, что всё получится.
Есть и еще одна причина, почему минские специалисты читают курсы в Москве. Уровень зарплат в Москве и в Минске заметно различается, и учебным центрам выгоднее пригласить преподавателей из Минска, от чего уровень обучения, надо сказать, не снижается.
Кроме того, в Минске еще не сложился рынок внешних курсов, особенно в области тестирования. Если компания большая, такая как EPAM или IBA, она обычно имеет внутренний учебный центр, а в маленьких компаниях учат методом наставничества. По инструментам разработки или по базам данных можно найти внешние курсы, а вот по тестированию практически ничего нет.
Мы долгое время вели переговоры с ВУЗами, и не так давно наконец-то пришли к соглашению. Я буду читать курсы в БГУИР уже с нового года, а также на мех-мате БГУ проведу несколько занятий, чтобы заинтересовать студентов в дальнейшем обучении.
Несколько слов о конференции?
Сейчас, по горячим следам, я пока ещё чувствую такой сильный драйв, так что сложно оценить впечатления. Очень понравилась атмосфера. Это мой первый опыт организации конференции. Все отзывы, которые я слышала, – положительные. Я получила огромное удовольствие и от подготовки конференции и от проведения. Но, конечно, нам ещё предстоит пересмотреть анкеты участников, разобрать их отзывы, чтобы сделать следующие конференции еще лучше.
Спасибо!
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...
четверг, 20 ноября 2008 г.
SQA Days 2008 - второй фотоотчет!
Вторая партия фотографий конференции - вашему вниманию!
Смотреть здесь.
Всегда ваша,
Наташа Густыр
Read more...
среда, 19 ноября 2008 г.
SQA Days 2008 - первый фотоотчет!
Наконец появились первые фотографии конференции!
Смотреть здесь .
Всегда ваша,
Наташа Густыр
Read more...
вторник, 18 ноября 2008 г.
По следам SQA Days 2008
Вчера, 17 ноября, в Минске состоялось грандиозное для наших мест событие - 4-я Международная Конференция по тестированию и обеспечению качетсва ПО.
Наконец-то свершилось! - скажу я вам.
Несколько месяцев активной подготовки не прошли зря.
Признаться, было немного страшно, как воспримется подобного рода мероприятие нашей минской аудиторией. И каково было наше удивление, когда 350+ пытливых, горящих глаз просто "проглатывали" докладчиков целиком.
Из отзывов наших московских друзей:
"Для меня было непривычно, что все сидят и слушают докладчиков! Я во время доклада вышел в коридор, а там - пусто! Мы привыкли активно общаться у флип-чартов, по интересам" - удивленно говорит Алексей Баранцев, главный редактор www.software-testing.ru
И причин тому может быть несколько:
- Мы долго зрели к такого рода, масштаба и качества конференции. Теперь мы готовы, и восприняли это со всей серьезностью. Мы просто еще не совсем понимаем, что можно делать на конференции помимо докладов, боимся, наверное, обидеть докладчиков, не уделив их выступлениям должного внимания, и поэтому общаемся только в перерывах.
- С другой стороны, такое внимание к докладам может быть вызвано их актуальностью и интересностью. Что, скажу я вам, крайне приятно.
А доклады, заслуживающие внимания, были. Я думаю, вы сами сможете оценить их, когда мы выложим видеоматериалы конференции в открытый доступ - обязательно буду держать вас в курсе событий.
Неожиданно приятным было и то, как участники конференции отнеслись к флип-чарт сессиям во время перерывов. Из отзывов стало понятно, что этот достаточной живой вид общения очень нравится людям, и также приносит пользу.
Слушатели требуют еще больше живого общения: круглых столов, мастер-классов, флипов. Над этим будем работать!
Хочется сказать огромное спасибо всем коллегам из ближнего и дальнего зарубежья, которые нашли возможность приехать, и не просто приехать, а еще и выступить с докладами. Среди них:
- Юля Нечаева, NIX Solutions, Харьков, Украина
- Андрей Кощеев, HP, Прага, Чехия
- Александр Орлов, Happy-PM.com, Санкт-Петербург, Россия
- Алексей Баранцев, ИСП РАН, Москва, Россия
- Александр Ихелис, Епам, Будапешт, Венгрия
- Сергей Гринкевич, Росгосстрах, Москва, Россия
- Павел Коноплицкий, UsabilityLab, Москва, Россия
- Дмитрий Ручко, ИнфоТеКС, Москва, Россия
- Дмитро Подзываловский, BOSSdev, Симферополь, Украина
По итогам конференции планируется напечатать сборник докладов и сделать также их online публикацию.
А со своими докладами мы можем вас познакомить уже сейчас.
Продолжение следует...
Всегда ваша,
Наташа Густыр
Read more...
Наконец-то свершилось! - скажу я вам.
Несколько месяцев активной подготовки не прошли зря.
Признаться, было немного страшно, как воспримется подобного рода мероприятие нашей минской аудиторией. И каково было наше удивление, когда 350+ пытливых, горящих глаз просто "проглатывали" докладчиков целиком.
Из отзывов наших московских друзей:
"Для меня было непривычно, что все сидят и слушают докладчиков! Я во время доклада вышел в коридор, а там - пусто! Мы привыкли активно общаться у флип-чартов, по интересам" - удивленно говорит Алексей Баранцев, главный редактор www.software-testing.ru
И причин тому может быть несколько:
- Мы долго зрели к такого рода, масштаба и качества конференции. Теперь мы готовы, и восприняли это со всей серьезностью. Мы просто еще не совсем понимаем, что можно делать на конференции помимо докладов, боимся, наверное, обидеть докладчиков, не уделив их выступлениям должного внимания, и поэтому общаемся только в перерывах.
- С другой стороны, такое внимание к докладам может быть вызвано их актуальностью и интересностью. Что, скажу я вам, крайне приятно.
А доклады, заслуживающие внимания, были. Я думаю, вы сами сможете оценить их, когда мы выложим видеоматериалы конференции в открытый доступ - обязательно буду держать вас в курсе событий.
Неожиданно приятным было и то, как участники конференции отнеслись к флип-чарт сессиям во время перерывов. Из отзывов стало понятно, что этот достаточной живой вид общения очень нравится людям, и также приносит пользу.
Слушатели требуют еще больше живого общения: круглых столов, мастер-классов, флипов. Над этим будем работать!
Хочется сказать огромное спасибо всем коллегам из ближнего и дальнего зарубежья, которые нашли возможность приехать, и не просто приехать, а еще и выступить с докладами. Среди них:
- Юля Нечаева, NIX Solutions, Харьков, Украина
- Андрей Кощеев, HP, Прага, Чехия
- Александр Орлов, Happy-PM.com, Санкт-Петербург, Россия
- Алексей Баранцев, ИСП РАН, Москва, Россия
- Александр Ихелис, Епам, Будапешт, Венгрия
- Сергей Гринкевич, Росгосстрах, Москва, Россия
- Павел Коноплицкий, UsabilityLab, Москва, Россия
- Дмитрий Ручко, ИнфоТеКС, Москва, Россия
- Дмитро Подзываловский, BOSSdev, Симферополь, Украина
По итогам конференции планируется напечатать сборник докладов и сделать также их online публикацию.
А со своими докладами мы можем вас познакомить уже сейчас.
Продолжение следует...
Всегда ваша,
Наташа Густыр
Read more...
четверг, 30 октября 2008 г.
Участие в конференции SQA Days 2008 в качестве докладчиков
Наталья Густыр
В статье Ханса Шафера "Что должен знать тестировщик в любое время, даже ночью" в переводе Андрея Конушина есть раздел 4 "Постоянное изучение", который заканчивается словами "... и посещайте конференции по тестированию".
Мы тоже придерживаемся этого правила, поэтому с удовольствием посетим конференцию по тестированию и обеспечению качества ПО SQA Days 2008 в Минске.
Более того, мы будем выполнять на конференции не только роли слушателей, но и активных участников:
- Наташа Густыр является одним из организаторов конференции и будет выступать с докладом "Вырасти себе тестировщика".
Мировой финансовый кризис оказывает значительное влияние на работу IT-компаний: сокращается количество потенциальных проектов и, соответственно, повышается конкуренция. В таких условиях компании вынуждены обратить особое внимание на обеспечение конкурентного преимущества, чтобы выжить и остаться на плаву. Приходится снижать ставки, и на первое место выходит продуктивность и эффективность работы каждого сотрудника. Решение проблемы заключается, с одной стороны, в оптимизации процессов работы компании и, с другой стороны, в развитии персонала.
Для того, чтобы процессы повышения продуктивности работы, обучения и развития были эффективными, они должны быть измеримыми. Для этого необходимо иметь точку отсчета.
За точку отсчета разумно принять оценку текущего состояния организации в целом и каждого сотрудника в частности.
В докладе рассматривается только одна сторона вопроса – тема оценки, аттестации, обучения и развития тестировщиков силами компании или силами внешних экспертов.
- Сергей Талалаев выступит с докладом "Использование MS Excel в качестве унифицированного хранилища данных для автоматизированных тестов".
Доклад затрагивает проблему выбора унифицированного хранилища тестовых данных для проведения автоматизированных функциональных и нагрузочных тестов.
- Оля Балашенко выступит с докладом "Причины "пожара" на проектах".
«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования.
Данный доклад – попытка ответить на вопрос «Почему тестировщики не укладываются в сроки?». Причем, оценка причин осуществляется как с позиции руководителя группы тестировщиков, который принимает участие в планировании тестирования, так и с позиции тестировщика, выполняющего задачи.
Акцент в докладе делается на разбор причин увеличения сроков, но также затрагивается тема предотвращения «пожаров».
Мы подумали и решили, что будем делиться своими практическими наработками, и хотим вызвать оживленную беседу в аудитории, поэтому в качестве формата выступления выбрали флип-чарты.
Приходите к нам!
Read more...
В статье Ханса Шафера "Что должен знать тестировщик в любое время, даже ночью" в переводе Андрея Конушина есть раздел 4 "Постоянное изучение", который заканчивается словами "... и посещайте конференции по тестированию".
Мы тоже придерживаемся этого правила, поэтому с удовольствием посетим конференцию по тестированию и обеспечению качества ПО SQA Days 2008 в Минске.
Более того, мы будем выполнять на конференции не только роли слушателей, но и активных участников:
- Наташа Густыр является одним из организаторов конференции и будет выступать с докладом "Вырасти себе тестировщика".
Мировой финансовый кризис оказывает значительное влияние на работу IT-компаний: сокращается количество потенциальных проектов и, соответственно, повышается конкуренция. В таких условиях компании вынуждены обратить особое внимание на обеспечение конкурентного преимущества, чтобы выжить и остаться на плаву. Приходится снижать ставки, и на первое место выходит продуктивность и эффективность работы каждого сотрудника. Решение проблемы заключается, с одной стороны, в оптимизации процессов работы компании и, с другой стороны, в развитии персонала.
Для того, чтобы процессы повышения продуктивности работы, обучения и развития были эффективными, они должны быть измеримыми. Для этого необходимо иметь точку отсчета.
За точку отсчета разумно принять оценку текущего состояния организации в целом и каждого сотрудника в частности.
В докладе рассматривается только одна сторона вопроса – тема оценки, аттестации, обучения и развития тестировщиков силами компании или силами внешних экспертов.
- Сергей Талалаев выступит с докладом "Использование MS Excel в качестве унифицированного хранилища данных для автоматизированных тестов".
Доклад затрагивает проблему выбора унифицированного хранилища тестовых данных для проведения автоматизированных функциональных и нагрузочных тестов.
- Оля Балашенко выступит с докладом "Причины "пожара" на проектах".
«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования.
Данный доклад – попытка ответить на вопрос «Почему тестировщики не укладываются в сроки?». Причем, оценка причин осуществляется как с позиции руководителя группы тестировщиков, который принимает участие в планировании тестирования, так и с позиции тестировщика, выполняющего задачи.
Акцент в докладе делается на разбор причин увеличения сроков, но также затрагивается тема предотвращения «пожаров».
Мы подумали и решили, что будем делиться своими практическими наработками, и хотим вызвать оживленную беседу в аудитории, поэтому в качестве формата выступления выбрали флип-чарты.
Приходите к нам!
Read more...
понедельник, 20 октября 2008 г.
Впервые в Минске пройдет Международная конференция специалистов в области обеспечения качества ПО SQA Days-2008
4-я Международная конференция специалистов в области обеспечения качества ПО SQA Days-2008 впервые пройдёт в столице Республики Беларусь, Минске, 17 ноября 2008 г. в Международном образовательном центре - IBB (пр-т Газеты Правда, 11) при поддержке Парка высоких технологий и Инфопарка. Организатором мероприятия выступает компания SQALab (г. Москва), в качестве генерального партнера - компания EPAM Systems, в качестве золотого партнера - Exigen Services, в качестве со-организатора - Белорусский Государственный Университет Информатики и Радиоэлектроники (БГУИР). Информационную поддержку оказывают компании Qulix Systems, HeadHunter, edu)ITOnline, Текама, крупнейшие интернет-порталы рунета и байнета, а также тематические ИТ-СМИ Беларуси.
Конференция посвящена вопросам функционального тестирования, тестирования производительности, автоматизации тестирования, выбора и использования инструментальных средств, конфигурационного тестирования, тестирования удобства использования (usability) и защищенности, статических методов обеспечения качества, а также особенностям внедрения тестирования на предприятии, управления процессами обеспечения качества ПО, вопросам менеджмента команд тестировщиков и инженеров качества ПО и другим сферам интересов QA-специалистов.
Идея собрать вместе заинтересованных специалистов и обменяться опытом в сфере тестирования ПО созрела в 2007 году на площадке московской компании "Кворум". После обсуждений был выбран наилучший формат такого общения - открытая встреча, в которой могли принять участие все желающие. Так возник круг конференций под общим названием "Software Quality Assurance Days" (SQA Days).
На данный момент SQA Days - это одно из крупнейших событий в сфере современных информационных технологий в области обеспечения качества ПО на постсоветском пространстве, которое объединяет ведущих специалистов международного уровня. В 2008 году SQA Days впервые будет проводиться на территории Республики Беларусь (три предыдущие конференции проводились в Москве).
На SQA Days-2008 в Минске планируется обобщить накопленный международный опыт в области обеспечения качества и создать платформу сотрудничества для реализации совместных проектов в сферах тестирования, предполагающей возможность для каждого специалиста обмена информацией и повышения уровня образования по актуальным вопросам.
Конференция пройдет под эгидой IT-CONF.RU - ресурса, объединяющего высококачественные конференции для ИТ-специалистов на территории СНГ, а также стран ближнего и дальнего зарубежья. Формат мероприятия - один день. По итогам конференции будет издан сборник докладов. На официальном сайте конференции будут размещены тезисы докладов и видеоролики с записями выступлений.
4-я Международная конференция специалистов в области обеспечения качества SQA Days-2008 будет интересна специалистам по тестированию и обеспечению качества программных систем, разработчикам, аналитикам, техническим писателям, архитекторам систем, руководителям среднего и высшего звена, а также всем заинтересованным лицам.
"Современный рынок белорусских информационных технологий привлекает внимание всего европейского сообщества не только благодаря наличию сильных традиций белорусской ИТ-школы. В последнее время точкой притяжения становятся широкие возможности белорусских айтишников для реализации крупных высокотехнологичных проектов мирового масштаба. Этот потенциал нужно активно использовать, поэтому для 4-ой Международной конференции SQA Days-2008 Минск был выбран не случайно. Идея организовать конференцию такого уровня в Беларуси созрела у меня давно. Кроме того, мне всегда импонировала теплая и одновременно деловая атмосфера белорусского ИТ-сообщества, высокий уровень профессионализма белорусских специалистов и их свежий взгляд на актуальные вопросы тестирования и обеспечения качества ПО", - прокомментировал выбор места проведения конференции Владислав Орликов, председатель оргкомитета SQA Days-2008, генеральный директор компании SQALab, Москва, Россия.
Получить полную информацию о программе SQA Days-2008 и подать заявку на участие для слушателей, докладчиков и потенциальных партнеров можно на официальном сайте конференции http://www.it-conf.ru/
Последний срок подачи заявки на участие в форме доклада - 24 октября 2008 г.
Последний срок подачи тезисов докладов - 26 октября 2008 г.
Последний срок подачи слайдов презентаций и текстов докладов - 02 ноября 2008 г.
Последний срок оплаты участия (не докладчики) - 10 ноября 2008 г.
* По решению оргкомитета сроки могут быть сдвинуты ближе к дате проведения конференции
Read more...
Подписаться на:
Сообщения (Atom)
