Следуя традиции, сложившейся в нашей команде SQAdotBy, пишу о своих ощущениях от проведения очередного курса по автоматизации функционального тестирования. Курс проходил 22-23 декабря на базе учебного центра "Интерфейс" в Москве.
Группа была небольшая (4 человека), но активная! Даже предновогоднее настроение не помешало нам сосредоточиться на автоматизации тестирования :) По количеству и качеству вопросов чувствовалось, что слушатели были заинтересованы в получении знаний. Причём, нашей общей целью было не просто изучение теории и освоения основных возможностей средств автоматизации тестирования ПО, а попытка применить знания к СВОЕМУ проекту.
Надеюсь, энтузиазм, который читался в глазах слушателей, не иссякнет, и через месяц- другой начинающие автоматизаторы будут наслаждаться работой своих скриптов!
С Уважением,
Ольга Балашенко
P.S.: Ещё я заметила, что со слушателями, которые уже посетили семинар Наташи Густыр "Введение в тестирование ПО", мы разговариваем на одном языке. Это значительно упрощает как чтение, так и прослушивание курса по автоматизации.
Read more...
воскресенье, 28 декабря 2008 г.
среда, 24 декабря 2008 г.
Курс по тестированию в Интерфейсе – уууууух!
Да-да-да – еще один курс по тестированию прочитан мною в Москве, в учебном центре Интерфейс.
С 17 по 19 декабря провела время в чудесной компании из 10-ти человек (сама 11-ая).
Почему «уууууух!»? Потому что группа была – ого-го!
Коллеги, вы выжали из меня все соки (в хорошем смысле этого слова)!
Три дня были настолько насыщенными в плане общения, потоков информации, позитива, что бодрый заряд энергии не иссякает до сих пор!
Мои уважаемые слушатели, вы такие разные: каждый со своим опытом и багажом знаний, со своими идеями, с массой замечательных вопросов! Особенно помню наши (и ваши между собой) споры – чего так иногда не хватает!
Было приятно видеть ваши разные (успешные и не очень) итоговые работы. Надеюсь, теперь вы знаете (или чувствуете, или хоть немного представляете), как работать в экстремальных условиях: короткие сроки, не совсем ясные или противоречивые требования, всегда недовольный заказчик.
Всем и каждому в отдельности (Саша Сидоров, Саша Бурдейный, Инна Пантелеева, Галина Репникова, Ерсаин Шалаев, Максим Иванов, Оля Уваркина, Алексей Трофимов, Николай и Николай (ломаю голову, вспоминая фамилии , если напомните - добавлю) ) – большое спасибо!
Хочется верить, что вы потратили время с пользой!
З.Ы. По итогам курса будет слегка сокращен теоретический материал и добавлено еще немного практики.
З.З.Ы. Фото нашей работы можно посмотреть здесь.
Всегда ваша,
Наташа Густыр
Read more...
вторник, 23 декабря 2008 г.
На Урале тоже тестируют софт
«Наташа, Вы у нас первая связь с внешним миром»
Александр Москвин, слушатель
Александр Москвин, слушатель
Зима выдалась насыщенной на курсы по тестированию.
Декабрь начался с Екатеринбурга.
8-10 декабря я провела в этом славном городе за работой – читала свой родной курс «Введение в тестирование ПО».
Группа на этот раз состояла из 6-ти человек, все из которых работают в одной компании.
Чем хороши корпоративные курсы:
• Ориентируешься на одинаковые нужды слушателей;
• Можно поближе познакомиться изнутри с разными видами бизнеса, и посмотреть, чем и как живут в них тестировщики;
• Есть больше возможностей помочь решить реальные проблемы.
Какие есть недостатки у корпоративных курсов:
• Слушатели могут не задавать вопросов или задавать их очень мало. О причинах могу только догадываться:
o Стесняются друг друга
o Если не поняли чего-то, то думают: «Ай, потом спрошу у кого-нибудь из наших. Кто-то наверняка понял.»
o что-то еще?..
• Слушатели продолжают время от времени отвлекаться по рабочим вопросам
Как к плюсам, так и к минусам можно отнести подготовленность класса для обучения, потому что случаи бывали диаметрально противоположные.
Каждый раз перед началом курса я интересуюсь у слушателей на предмет их ожиданий от курса, чтобы более гибко подходить к подаче материала, и делать акценты на тех разделах, которые в большей степени интересуют группу.
В этот раз пожелания были сформулированы довольно широко и расплывчато. Например, «Узнать что-то новое…», «Практика есть, хотелось бы знать, как это называется в теории…», «Узнать о тестировании больше…», «Посмотреть, как это делают другие…».
Если посмотреть в целом, то все перечисленные ожидания были удовлетворены. Хочется надеяться, что и не высказанные ожидания тоже хотя бы частично, но покрылись.
Теперь несколько слов о каждом участнике группе…
• Виктория была в группе звеном, следящим за дисциплиной и, наверное, чаще других выступала связистом между подаваемым материалом и реальной работой.
• Ксения помогала структурировать материал предыдущего дня и будила группу от утреннего сна.
• Светлана самый молодой и еще не определившийся со своим отношением к тестированию специалист, но очень бодрая и активная участница процесса.
• Александр Гнатюк оказался самым «живым» и самым шустрым тестировщиком.
• Александр Москвин вносил свои корректные дополнения и предложения, навеянные многолетним опытом работы.
• Наталья была в нашей группе критиком, без ее резких замечаний некоторые вопросы просто не могли бы быть рассмотрены с разных сторон.
Хочу пожелать всей группе успехов в работе! Разумного применения полученных знаний и навыков! И профессионального роста и развития!
P.S. Надеюсь на ваше прощение по поводу задержки с публикацией отчета – рвалась на части между другими командировками и работой…
P.P.S. Александр и Александр, я не перепутала ваши фамилии? :)
P.P.P.S. Остальные фотографии можно посмотреть здесь.
Всегда ваша,
Наташа Густыр
Read more...
четверг, 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...
Молоток существует!
Друзья, в одном из своих постов, я писала о том, какой замечательный мотивационный инструмент есть у меня в команде - это МОЛОТОК!
Вы просили фото? Пожалуйста! :)
(молоток. вид сверху)
(молоток в руке разработчика. боевое состояние)
Всегда ваша,
Наташа Густыр
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...
четверг, 20 ноября 2008 г.
SQA Days 2008 - второй фотоотчет!
Вторая партия фотографий конференции - вашему вниманию!
Смотреть здесь.
Всегда ваша,
Наташа Густыр
Read more...
it4business.ru - не только для бизнеса
Коллеги, в рубрике "обзоры" мы планируем проводить ревью книг, ресурсов и других источников полезной для нашей с вами профессиональной деятельности информации.
И первым в этом списке стал ресурс www.it4business.ru
Что вы можете найти на ресурсе:
- Новинки ИТ-отрасли
- Статьи различных специалистов
- Пресс-релизы
- Информация об обучении в отрасли ИТ
- Блоги и форум
- Вакансии
- Интересные исследования
- и многое-многое другое
Чем хорош ресурс:
Всегда актуальная информация.
Всегда живой, реально работающий форум!!!
Последние события на ресурсе:
Авторы собирают блоги специалистов, которые пишут на темы тестирования, качества, управления, разработки и т.д. Поэтому в скором будущем мы сможем познакомиться с массой новых интересных людей!
Наш блог там тоже уже есть!
Read more...
И первым в этом списке стал ресурс www.it4business.ru
Что вы можете найти на ресурсе:
- Новинки ИТ-отрасли
- Статьи различных специалистов
- Пресс-релизы
- Информация об обучении в отрасли ИТ
- Блоги и форум
- Вакансии
- Интересные исследования
- и многое-многое другое
Чем хорош ресурс:
Всегда актуальная информация.
Всегда живой, реально работающий форум!!!
Последние события на ресурсе:
Авторы собирают блоги специалистов, которые пишут на темы тестирования, качества, управления, разработки и т.д. Поэтому в скором будущем мы сможем познакомиться с массой новых интересных людей!
Наш блог там тоже уже есть!
Read more...
Тестирование - студентам!
Сегодня произошли два, на мой взгляд, очень важных события.
Первое - это лекция по тестированию на механико-математическом факультете Белгосуниверситета!
Это были студенты 1-го курса. В рамках предмета "Введение в информационные технологии" я рассказывала им, что же такое тестирование, стоит ли этим заниматься, кто такие тестировщики и далее в этом ключе. Мы даже попробовали немножко тестировать и регистрировать баги. И все это в дружеской атмосфере и незатейливой форме.
Я уже отвыкла от такого рода аудитории. Первокурсники сродни ученикам старших классов школы, с которыми мне приходилось работать в свое время - шумные, неугомонные, выставляющие себя напоказ, но очень дружелюбные. Дискуссии проходили живо и весело!
Правда, связкам тяжело :)
50 человек - это вам не шутки!
Но и это еще не все!
Сегодня я говорила с деканом одного из факультетов другого не менее рейтингового ВУЗа нашей страны - Белгосуниверситет Информатики и Радиоэлектроники.
Приняли решенеие о сотрудничестве!
Со следующего семестра начинаю читать курс по тестированию - студентам!
Всегда ваша,
Наташа Густыр
Read more...
Первое - это лекция по тестированию на механико-математическом факультете Белгосуниверситета!
Это были студенты 1-го курса. В рамках предмета "Введение в информационные технологии" я рассказывала им, что же такое тестирование, стоит ли этим заниматься, кто такие тестировщики и далее в этом ключе. Мы даже попробовали немножко тестировать и регистрировать баги. И все это в дружеской атмосфере и незатейливой форме.
Я уже отвыкла от такого рода аудитории. Первокурсники сродни ученикам старших классов школы, с которыми мне приходилось работать в свое время - шумные, неугомонные, выставляющие себя напоказ, но очень дружелюбные. Дискуссии проходили живо и весело!
Правда, связкам тяжело :)
50 человек - это вам не шутки!
Но и это еще не все!
Сегодня я говорила с деканом одного из факультетов другого не менее рейтингового ВУЗа нашей страны - Белгосуниверситет Информатики и Радиоэлектроники.
Приняли решенеие о сотрудничестве!
Со следующего семестра начинаю читать курс по тестированию - студентам!
Всегда ваша,
Наташа Густыр
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...
понедельник, 10 ноября 2008 г.
Курс "Введение в тестирование ПО" - еще раз +1
В очередной раз (5-7 ноября) я прочитала свой курс "Введение в тестирование ПО" в обучающем центре Интерфейс (г. Москва).
Очень хорошая, внимательная, трудолюбивая и ответственная группа.
Сочетали приятное с полезным: обсуждали серьезные вопросы и шутили.
Работать было одно удовольствие.
Вперед! К новым знаниям!
Еще и еще!
P.S. Следующий курс планируется на 17-19 декабря.
Всегда ваша,
Наташа Густыр
Read more...
Очень хорошая, внимательная, трудолюбивая и ответственная группа.
Сочетали приятное с полезным: обсуждали серьезные вопросы и шутили.
Работать было одно удовольствие.
Вперед! К новым знаниям!
Еще и еще!
P.S. Следующий курс планируется на 17-19 декабря.
Всегда ваша,
Наташа Густыр
Read more...
Урок 68: Не игнорируйте очевидные дефекты
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко
Некоторые лежащие на поверхности дефекты регистрируются только после их обнаружения бета-тестировщиками, т.к. все думают, что такой очевидный дефект уже явно зарегистрирован. Если Вам кажется, что ошибка уже зарегистрирована, проверьте в системе управления дефектами, как описан дефект, и каков его статус. Может, имеет смысл добавить ваши комментарии, чтобы ускорить исправление дефекта. Или нужно создать новый дефект, если старый был плохо описан и поэтому отклонён.
Такое случается даже с серьёзными дефектами. Все знают о существовании ошибки, и все думают, что кто-то другой её уже зарегистрировал. Однажды явный баг так и не был исправлен, пока Систему не отдали в эксплуатацию!
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко
Некоторые лежащие на поверхности дефекты регистрируются только после их обнаружения бета-тестировщиками, т.к. все думают, что такой очевидный дефект уже явно зарегистрирован. Если Вам кажется, что ошибка уже зарегистрирована, проверьте в системе управления дефектами, как описан дефект, и каков его статус. Может, имеет смысл добавить ваши комментарии, чтобы ускорить исправление дефекта. Или нужно создать новый дефект, если старый был плохо описан и поэтому отклонён.
Такое случается даже с серьёзными дефектами. Все знают о существовании ошибки, и все думают, что кто-то другой её уже зарегистрировал. Однажды явный баг так и не был исправлен, пока Систему не отдали в эксплуатацию!
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...
понедельник, 27 октября 2008 г.
Урок 237: Найм по согласованию
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Позвольте любому члену вашей команды и любому кто тесно работает с вашей командой участвовать в интервью с кандидатом. Дайте любому кто принимал участие в интервью возможность накладывать вето на кандидата, если это не связано с такими основаниями как пол, раса, возраст и любыми другими, не относящимися напрямую к способности кандидата выполнять его работу.
Несложно избежать принятия инстинктивных решений и отговорить кого-либо от применения права вето. Однако мы сделали несколько грубых ошибок при найме сотрудников, включая найм человека склонного к сексуальному домогательству, проигнорировав плохо аргументированную но очень эмоциональную реакцию одного из членов нашей команды. С вниманием выслушивайте опасения, выраженные любым из членов вашей команды и уважайте право вето, если только оно не базируется на дискриминационых принципах.
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев
Позвольте любому члену вашей команды и любому кто тесно работает с вашей командой участвовать в интервью с кандидатом. Дайте любому кто принимал участие в интервью возможность накладывать вето на кандидата, если это не связано с такими основаниями как пол, раса, возраст и любыми другими, не относящимися напрямую к способности кандидата выполнять его работу.
Несложно избежать принятия инстинктивных решений и отговорить кого-либо от применения права вето. Однако мы сделали несколько грубых ошибок при найме сотрудников, включая найм человека склонного к сексуальному домогательству, проигнорировав плохо аргументированную но очень эмоциональную реакцию одного из членов нашей команды. С вниманием выслушивайте опасения, выраженные любым из членов вашей команды и уважайте право вето, если только оно не базируется на дискриминационых принципах.
Read more...
Урок 9: Вы не найдете все баги
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр
Ваша задача – находить и описывать значимые баги. Но вы не найдете их все. Чтобы найти все баги, вы должны будете посмотреть везде, где только они могут появиться; вы должны проверить в тех местах всевозможные ситуации, которые могут возникнуть; вам понадобится описать надежный и понятный путь воспроизведения каждого вида бага, когда он возникнет. Если вы думаете, что можете это сделать, то у вас либо очень простой продукт либо очень ограниченное воображение.
Вы должны делать выбор в отношении того, как тратить свое время, зная и принимая то обстоятельство, что Вы не можете сделать абсолютно все.
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр
Ваша задача – находить и описывать значимые баги. Но вы не найдете их все. Чтобы найти все баги, вы должны будете посмотреть везде, где только они могут появиться; вы должны проверить в тех местах всевозможные ситуации, которые могут возникнуть; вам понадобится описать надежный и понятный путь воспроизведения каждого вида бага, когда он возникнет. Если вы думаете, что можете это сделать, то у вас либо очень простой продукт либо очень ограниченное воображение.
Вы должны делать выбор в отношении того, как тратить свое время, зная и принимая то обстоятельство, что Вы не можете сделать абсолютно все.
Read more...
пятница, 24 октября 2008 г.
Урок 19: Тестирование находится в вашей голове
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр
Разница между превосходным и посредственным тестированием заключается в том, как вы думаете: ваши варианты дизайна тестов, ваша способность интерпретировать то, что вы наблюдаете, и ваша способность поведать об этом. Все остальное тестирование – это просто офисная работа в большей части. Если вы видите двух тестировщиков, работающих рядом, вы не можете определить, работает ли один лучше, чем другой. Видимая часть их работы выглядит совершенно одинаково, что наталкивает на две мысли:
- Многие люди думают, что тестирование – это просто, потому что они без труда могут копировать видимую часть поведения хорошего тестировщика, и у них нет других стандартов для хорошего тестирования.
- Если вы хотите быть хорошим тестировщиком, научитесь думать, как он, а не выглядеть, как он.
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр
Разница между превосходным и посредственным тестированием заключается в том, как вы думаете: ваши варианты дизайна тестов, ваша способность интерпретировать то, что вы наблюдаете, и ваша способность поведать об этом. Все остальное тестирование – это просто офисная работа в большей части. Если вы видите двух тестировщиков, работающих рядом, вы не можете определить, работает ли один лучше, чем другой. Видимая часть их работы выглядит совершенно одинаково, что наталкивает на две мысли:
- Многие люди думают, что тестирование – это просто, потому что они без труда могут копировать видимую часть поведения хорошего тестировщика, и у них нет других стандартов для хорошего тестирования.
- Если вы хотите быть хорошим тестировщиком, научитесь думать, как он, а не выглядеть, как он.
Read more...
Урок 67: Регистрируйте дефекты сразу же после обнаружения
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко
Не откладывайте регистрацию дефекта на завтра. Во-первых, Вы можете забыть ключевые детали дефекта, что усложнит процесс воспроизведения дефекта разработчиками. Чем дольше вы ждёте, тем менее вероятно исправление дефекта.
Во-вторых, если менеджер знает, какую часть функциональности Вы тестируете, то отсутствие дефектов может навести его на мысль, что данная функциональность работает стабильно.
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко
Не откладывайте регистрацию дефекта на завтра. Во-первых, Вы можете забыть ключевые детали дефекта, что усложнит процесс воспроизведения дефекта разработчиками. Чем дольше вы ждёте, тем менее вероятно исправление дефекта.
Во-вторых, если менеджер знает, какую часть функциональности Вы тестируете, то отсутствие дефектов может навести его на мысль, что данная функциональность работает стабильно.
Read more...
Урок 66: Никогда не используйте систему регистрации дефектов для оценки эффективности работы тестировщиков
Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко
Если Вы (тест-менеджер) поощряете тестировщиков за количество найденных дефектов, то Вы можете добиться нежелательного эффекта:
- чтобы увеличить количество найденных дефектов, тестировщики, будут искать поверхностные, легко находимые дефекты и избегать сложно воспроизводимых дефектов;
- тестировщики будут чаще регистрировать несколько вариации одного и того же дефекта;
- увеличится количество «не дефектов», т.е. дефектов, которые на самом деле не являются ошибками;
- тестировщики будут тратить большую часть своего времени на поиск дефектов, что повлечёт за собой игнорирование других задач и обязанностей.
Read more...
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко
Если Вы (тест-менеджер) поощряете тестировщиков за количество найденных дефектов, то Вы можете добиться нежелательного эффекта:
- чтобы увеличить количество найденных дефектов, тестировщики, будут искать поверхностные, легко находимые дефекты и избегать сложно воспроизводимых дефектов;
- тестировщики будут чаще регистрировать несколько вариации одного и того же дефекта;
- увеличится количество «не дефектов», т.е. дефектов, которые на самом деле не являются ошибками;
- тестировщики будут тратить большую часть своего времени на поиск дефектов, что повлечёт за собой игнорирование других задач и обязанностей.
Read more...
вторник, 21 октября 2008 г.
Lessons Learned in Software Testing
В недавнем прошлом нам повезло держать в руках книгу – мечту каждого тестировщика!
Авторы Cem Kaner, James Bach и Bret Pettichord собрали воедино удивительный материал и нарекли его «уроками» - Lessons Learned in Software Testing.
“We follow the context-driven approach in software testing. We expect that a method that works wonderfully under some circumstances will not work under others” – в этих словах выражена основная идея книги.
« Lessons…» – не догма и даже не лучшие практики. Это – реальный опыт реальных людей. Многие из уроков до сих пор вызывают споры между самими авторами, и они были бы счастливы, если бы книга побуждала также и читателей к обсуждениям и дебатам.
Книга предназначена для тестировщиков с опытом, и крайне не рекомендуется новичкам. Последним она может показаться тяжелой и утомительной.
Книга состоит из 293 уроков, объединенных в 11 частей.
Некоторые уроки на русском (в собственном переводе) мы представим и вашему драгоценному вниманию!
Как пишут сами авторы, книгу запрещается (!) читать от начала и до конца. Ее нужно читать с любого места, по 1-2 урока за раз. И только после того, как вы осмыслите прочитанное, можно приступать к дальнейшему чтению. Мы, беспрекословно следуя советам авторов, не будем торопиться и соблюдать порядок уроков…
Наталья Густыр
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...
Вас приветствует команда SQAdotBy
Добрый день, дорогие друзья, уважаемые коллеги!
Команда SQAdotBy в составе 4-х человек рада приветствовать вас на нашей профессиональной площадке!
Мы, Наталья Густыр, Сергей Талалев, Ольга Балашенко и Виктория Головнева, будем рады поделиться с вами своими мыслями и идеями, касающимися нашей сферы деятельности - тестирования и обеспечения качества программных продуктов!
Несколько слов о нас:
Наталья Густыр
Ведущий QA специалист, менеджер проектов, руководитель направления обучения, преподаватель-консультант компании Qulix Systems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования и QA – 5 лет, в области преподавания – 3 года.
Автор курса "Введение в тестирование ПО" и семинаров "Взаимодействие команд разработки и тестирования", "Карьера тестировщика" и "Откровения тестировщика".
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург, Екатеринбург), Казахстане (Астана, Алматы).
Сергей Талалаев
Куратор направления автоматизации тестирования, преподаватель-консультант.
Преподаватель учебного центра «Интерфейс», Москва.
Области специализации: IBM/Rational: Robot, FT, Test Manager; HP/Mercury: WinRunner, LoadRunner, QTP; FreeWare: Grinder, Watir.
Опыт работы в сфере автоматизации – 7 лет. Опыт преподавания – 5 лет.
Автор курса «Введение в автоматизированное нагрузочное тестирование программного обеспечения». Соавтор курса «Основы функционального тестирования с использованием инструментов IBM Rationa.
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург), Казахстане (Астана).
Ольга Балашенко
Ведущий специалист по мануальному и автоматизированному тестированию компании QulixSystems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования – 4 года.
Опыт автоматизации тестирования для проектов различного уровня сложности с использованием следующих средств автоматизации: HP/Mercury WinRunner, HP/Mercury QTP, Segue Silk Test, IBM/Rational Robot.
Соавтор курса «Введение в автоматизированное функциональное тестирование программного обеспечения».
Читает курс в Беларуси (Минск) и России (Москва).
Виктория Головнева
Read more...
Команда SQAdotBy в составе 4-х человек рада приветствовать вас на нашей профессиональной площадке!
Мы, Наталья Густыр, Сергей Талалев, Ольга Балашенко и Виктория Головнева, будем рады поделиться с вами своими мыслями и идеями, касающимися нашей сферы деятельности - тестирования и обеспечения качества программных продуктов!
Несколько слов о нас:
Наталья Густыр
Ведущий QA специалист, менеджер проектов, руководитель направления обучения, преподаватель-консультант компании Qulix Systems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования и QA – 5 лет, в области преподавания – 3 года.
Автор курса "Введение в тестирование ПО" и семинаров "Взаимодействие команд разработки и тестирования", "Карьера тестировщика" и "Откровения тестировщика".
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург, Екатеринбург), Казахстане (Астана, Алматы).
Сергей Талалаев
Куратор направления автоматизации тестирования, преподаватель-консультант.
Преподаватель учебного центра «Интерфейс», Москва.
Области специализации: IBM/Rational: Robot, FT, Test Manager; HP/Mercury: WinRunner, LoadRunner, QTP; FreeWare: Grinder, Watir.
Опыт работы в сфере автоматизации – 7 лет. Опыт преподавания – 5 лет.
Автор курса «Введение в автоматизированное нагрузочное тестирование программного обеспечения». Соавтор курса «Основы функционального тестирования с использованием инструментов IBM Rationa.
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург), Казахстане (Астана).
Ольга Балашенко
Ведущий специалист по мануальному и автоматизированному тестированию компании QulixSystems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования – 4 года.
Опыт автоматизации тестирования для проектов различного уровня сложности с использованием следующих средств автоматизации: HP/Mercury WinRunner, HP/Mercury QTP, Segue Silk Test, IBM/Rational Robot.
Соавтор курса «Введение в автоматизированное функциональное тестирование программного обеспечения».
Читает курс в Беларуси (Минск) и России (Москва).
Виктория Головнева
Read more...
Подписаться на:
Сообщения (Atom)
