Следуя традиции, сложившейся в нашей команде 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...
Подписаться на:
Сообщения (Atom)
