SQAdotBY

Quick look на системы стандартизации. Другие стандарты

2009-07-06T17:33:00.006+03:00

Предлагаю закончить с системами стандартизации :)
Чтобы не складывалось ощущение, что на ГОСТ-ах, ISO и CMMI системы стандартизации закончились, приведем еще несколько примеров и краткую информацию по ним.

ASTM International — международная добровольная организация, разрабатывающая и издающая стандарты для материалов, продуктов, систем и услуг.

Основана в 1898 г. в США и первоначально занималась стандартами для железных дорог.

Сегодня ASTM поддерживает около 12000 стандартов. Стандарты проверяются и переиздаются не реже, чем раз в пять лет.

Следование этим стандартам добровольное. В США правительство настоятельно рекомендует использовать эти стандарты везде, где это возможно.

Международная электротехническая комиссия (МЭК; англ. International Electrotechnical Commission, IEC) — международная организация по стандартизации в области электрических, электронных и смежных технологий. Некоторые из стандартов МЭК разрабатываются совместно с Международной организацией по стандартизации (ISO).

МЭК составлена из представителей национальных служб стандартов. МЭК была основана в 1906 году и в настоящее время в её состав входят более 60 стран. Первоначально комиссия была расположена в Лондоне, с 1948 года имеет штаб в Женеве.

МЭК способствовала развитию и распространению стандартов для единиц измерения, особенно гаусса, герца, и вебера. Также комиссия МЭК предложила систему стандартов, которая в конечном счёте стала единицами СИ. В 1938 году был издан международный словарь с целью объединить электрическую терминологию. Эти усилия продолжаются и Международный электротехнический словарь остаётся важной работой в электрических и электронных отраслях промышленности.

Институт инженеров электротехники и электроники — IEEE (англ. Institute of Electrical and Electronics Engineers) — международная некоммерческая ассоциация специалистов в области техники, мировой лидер в области разработки стандартов по радиоэлектронике и электротехнике.

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

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

UPD:
Очень полезный комментарий от Алексея Баранцева (для тех, кто не читает комменты, и просто для наглядности):
"За что IEEE обидели? IEEE Computer Society (www.computer.org) издаёт замечательные журналы. Стандарты их тоже очень даже связаны с разработкой ПО, и даже иногда с тестированием, вспоминаем IEEE 829 Standard for Software Test Documentation."
Спасибо, Алексей!

Всегда ваша,
Наташа Искорцева

Quick look на системы стандартизации. CMMI

2009-07-02T16:29:00.006+03:00

И снова здравствуйте!
Предлагаю продолжить обозревать системы стандартизации. И на этот раз вашему вниманию предлагается CMMI.

Модель зрелости процесса разработки (Capability Maturity Model) создана в Software Engineering Institute. CMM – это не технология, а средство оценки, используемое для определения зрелости технологии в организации по пятибалльной шкале.

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

Чтобы разрешить эту проблему, SEI (Software Engineering Institute) была предложена SEI CMMI (Capability Maturity Model Integration), которая более эффективно приспособлена к лучшему современному опыту, такому как проведение управляемой рисками разработки и итеративный подход. Вместо поощрения создания большей формализованности (как это делается в CMM), CMMI поощряет пользователей делать акцент на отдельных областях для улучшений, которые лучше всего отвечают деловым целям организации и минимизируют присущие организации области риска.

Уровни зрелости

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

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

Уровень 3: Уровень управляемости. В организации задокументированы и стандартизированы все бизнес-процессы. Система управления оказывается отделенной от всего персонала организации, т.е. появляется внутренний «свод законов». Этим законам следует весь персонал организации, включая топ-менеджмент.

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

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

Разница ISO и CMM

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

CMMI Online Browser: www.cmmi.de
Еще о CMMI можно читать на сайте самого SEI

Всегда ваша,
Наташа Искорцева

QTP: DP в 60-ти простых слайдах

2009-06-29T09:24:00.011+03:00

Автор: Yaron Assa
Перевод: Сергей Талалаев (SQAdotBY)
Оригинальная публикация: DP in 60 slides

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

В рамках данной небольшой презентации автор умудрился разложить по полочкам ключевые моменты Дескрипторного Программирования (DP) применяемого в QTP. Причем сделал это с драйвом и без лишней воды.

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

BYSTQB быть!!!

2009-06-19T17:10:00.004+03:00

Уважаемые коллеги, наконец свершилось событие, к которому мы так упорно стремились.
Cегодня в Вене была официально утверждена белорусская коллегия тестировщиков - BySQTB.

Спасибо всем, кто вместе с нами работал над осуществлением этого проекта. Надеемся, что наше успешное сотрудничество продолжится и в дальнейшем.

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

Мы уверены, что вместе нам по силам многие амбициозные проекты :)

С уважением,
команда SQAdotBY

На шаг ближе к основанию BySTQB

2009-06-12T14:17:00.003+03:00

9-го июня 2009 года в 18:00, в конференц-зале, любезно предоставленном компанией Exigen Services, состоялось очередное собрание инициативной группы по созданию национального представительства ISTQB в Беларуси.

Инициативная группа присутствовала на встрече в практически полном составе: Наталья Искорцева, Сергей Талалаев, Алексей Мартынюк, Ирина Тетерук, Алексей Лемешев, Александр Воронович, Сергей Ревко, Сергей Полаженко.

Основной целью собрания стало обсуждение текущих вопросов, связанных с регистрацией BySTQB, и подготовка к встрече с представителями заинтересованных компаний.
Во время собрания был повторно вынесен на обсуждение текст Конституции создаваемой национальной коллегии ISTQB, предварительно оговорена процедура принятия новых членов группы, описанная в 3-м подразделе Конституции. Инициативная группа рассмотрела варианты взаимодействия с ПВТ, в рамках их предложения о сотрудничестве, а также регламент встречи с представителями заинтересованных компаний. На повестке дня была озвучена ближайшая задача группы после создания национальной коллегии BySTQB по переводу на русский язык Syllabus-a – программы сертификации базовго уровня тестировщиков ПО.

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

По материалам новости от
Ирины Тетерук и Сергея Полаженко,
опубликованной на ресурсе www.sqa.by

Quick look на системы стандартизации. ISO

2009-06-11T14:27:00.003+03:00

Доброго времени суток, коллеги.
Снова вернемся к стандартам - на этот раз пройдемся по ISO и сделаем небольшой обзор.

Международная организация по стандартизации (International Organization for Standardization, ISO) — международная организация, занимающаяся выпуском стандартов.

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

При создании организации и выборе её названия учитывалась необходимость того, чтобы аббревиатура наименования звучала одинаково на всех языках. Для этого было решено использовать греческое слово isos — равный, вот почему на всех языках мира Международная организация по стандартизации имеет краткое название ISO (ИСО).

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

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

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

ISO 9000

ISO 9000 — серия международных стандартов ISO, регламентирующих управление качеством на предприятиях.

Система стандартов разработана Международной Организацией по Стандартизации (ISO, International Organization for Standardization), которая основывалась на разработках Британского института стандартов BS 5750.

Стандарты ISO 9000, принятые более чем 90 странами мира, применимы к любым предприятиям, независимо от их размера и сферы деятельности. Сама ISO не производит сертификацию по ISO 9000, этим занимаются специально сформированные аудиторские организации в отдельных странах. Фактически сертификация производится не по ISO 9000, а по спецификации ISO 9001:2000.

Сертификат ISO 9000 необходим предприятиям:
* работающим на международных рынках или с международными поставщиками, которые требуют наличия такого сертификата;
* работающим в секторах экономики, регулируемых правительством, или с правительственными организациями стран, в которых наличие сертификата ISO 9000 является обязательным.

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

Стандарт не гарантирует качество продукции.
Цель ISO 9000 — внести согласованность и объективность в действия системы контроля качества поставщика. Предполагается, что ISO 9000 будет использоваться в отношениях между компаниями, обычно в форме потребитель/поставщик. Стандарт помогает компаниям формализовать их систему управления процессом проверки качества и соответствия продукции.

Версии ISO 9000

В действительности ISO 9000 объединяет три стандарта:
* ISO 9000:2005 — Системы менеджмента качества. Основные положения и словарь
* ISO 9001:2000 — Системы менеджмента качества. Требования
* ISO 9004:2000 — Системы менеджмента качества. Рекомендации по улучшению деятельности

К стандартам этой серии также можно отнести ISO 19011:2003 — Рекомендации по аудиту систем менеджмента качества и/или охраны окружающей среды.

Конечные цифры в обозначении версии стандарта соответствуют году принятия, например:
* ISO 9000:1987 — совпадал с BS 5750, определял три модели управления качеством.
* ISO 9000:1994
* ISO 9000:2000

В основу построения организационной системы по ISO 9000-2000 закладываются следующие принципы:
* Концентрация на потребностях заказчика.
* Активная лидирующая роль руководства.
* Вовлечение исполнителей в процессы совершенствования.
* Реализация процессного подхода.
* Системный подход к управлению.
* Обеспечение непрерывных улучшений.
* Принятие решений на основе фактов.
* Взаимовыгодные отношения с поставщиками.

Защита от дурака

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

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

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

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

Официальный сайт ISO: http://www.iso.org/iso/home.htm

Всегда ваша,
Наташа Искорцева

10 Причин провала автоматизации

2009-06-11T00:01:00.002+03:00

Автор: Shrini Kulkarni
Перевод: Сергей Талалаев (SQAdotBY)
Оригинальная статья: 10 ways to make automation difficult or ineffective

Нашему коллеге, сформулировавашему эту десятку причин можно ставить памятник при жизни (согласен со всем на 100%). А глядя в его мудрые грустные глаза понимаешь, что расхлебывал все это он сам лично "Вот этими вот руками..." :)

Однозначно можно распечатывать и вешать на стенку.

10. Безумное желание о 100% автоматизации

9. Попытка автоматизировать существующие тест кейсы без тщательного анализа на предмет их пригодности к автоматизации

8. Линейное сопоставление тест кейсов и скриптов 1:1 – становясь жертвой обманчивого удобства в контроле над изменениями и отчетности.

7. Создания проекта автоматизации игнорируя модель “снизу-вверх”, нечеткое разбиение проекта на функциональные части.

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

5. Фокусировка только на задачах, связанных с выполнением тестов

4. Использование автоматизации как скриптования – игнорируя общепринятые практики разработки ПО.

3. Отказ от привлечения разработчиков на начальной стадии – не стремясь к улучшению тестируемости или автоматизируемости приложения

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

1. Отказ от поиска правильной пропорции между ручным и автоматизированным тестированием.

0. Использование автоматизации в качестве средства выявления ошибок

Quick look на системы стандартизации. ГОСТ

2009-06-10T17:57:00.004+03:00

Вернемся к системам стандартизации. Начнем с ГОСТ-ов.
Представляю вашему вниманию информацию, собранную из разных источников, сгруппированную и слегка обработанную.

Возможно, для кого-то она будет полезной...

ГОСТ (Государственный стандарт) — одна из основных категорий стандартов в СССР, сегодня межгосударственный стандарт в СНГ. Принимается Межгосударственным советом по стандартизации, метрологии и сертификации (МГС).

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

Стандарт имеет силу (если не заменён национальным стандартом) в следующих странах:

* Азербайджанская Республика
* Республика Армения
* Республика Беларусь
* Республика Грузия
* Республика Казахстан
* Киргизская Республика
* Республика Молдова
* Российская Федерация
* Республика Таджикистан
* Туркменистан
* Республика Узбекистан
* Украина

Национальный стандарт РБ - СТБ.

Национальный орган по стандартизации - Комитет по стандартизации, метрологии и сертификации при Совете Министров Республики Беларусь.

А вот и полезные ссылки, касающиеся ГОСТ-ов по разработке ИС, АС, ПС:
http://www.admhmao.ru/inform/law/zakon_gost.htm
http://www.e-school.ru/index.php?a=project&sub=8
http://www.internet-law.ru/law/gosts/

Всегда ваша,
Наташа Искорцева

ISTQB: цели, миссия, задачи

2009-06-08T21:56:00.006+03:00

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

ISTQB (International Software Testing Qualifications Board ) – это Международная Коллегия по Квалификации Тестировщиков Программного Обеспечения (далее ISTQB), которая была официально основана в Эдинбурге в 2002 году. На данный момент ISTQB входят 42 национальные коллегии с различных уголков света. ISTQB и все национальные коллегии являются независимыми и некоммерческими организациями.

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

Задачей ISTQB и всех национальных коллегий является поддержка единой общепринятой международной программы квалификации, разработанной ISTQB для профессионалов в сфере тестирования ПО. На основе программы составляются курсы, которые проводят инструкторы, аккредитованные национальными коллегиями. Каждый курс завершается экзаменом, который охватывает содержание всей программы, с выдачей сертификата "ISTQB Certified Tester" в случае успешного результата (может выдаваться местный вариант сертификата с логотипом соответствия нормам ISTQB).

Задачи ISTQB и каждой национальной коллегии:
1. Гарантирование качества и актуальности программы учебных курсов
2. Разработка и определение основной международной программы курсов для каждой квалификации
3. Определение и поддержка структуры экзаменов и свода правил
4. Определение и поддержка правил и положений аккредитации (для организаций, предоставляющих инструкторов/преподавателей)
5. Определение и поддержка правил и положений сертификации
6. Определение и поддержка правил и положений проходного балла для успешной сдачи экзамена
7. Мониторинг соблюдения национальными коллегиями правил и положений ISTQB
8. Прием и исключение национальных коллегий в/из ISTQB

Цели международной программы по квалификации тестировщиков ПО и международной коллегий по тестированию ПО:
1. Унифицировать умения и навыки специалистов по тестированию в разных странах
2. Создать общее понимание предмета тестирования в европейских/ мультинациональных проектах
3. Увеличить количество сертифицированных специалистов по всему миру
4. Развивать и продвигать общее пониманиепроцесса тестирования и знания по этому процессу через программу курсов и единого словаря терминов
5. Продвигать тестирование ПО как отдельную профессию
6. Увеличить эффективность в плане затрат (программу курсов и экзаменационные вопросы можно использовать, просто переведя на нужный язык; не нужно изобретать колесо)
7. Больше людей/мыслей/идей для создания общих материалов (экзаменационные вопросы, программа)
8. Специалистам тестирования ПО не обязательно знать английский язык, чтобы получить необходимую квалификацию
9. Международное признание специалистов тестирования ПО и их квалификаций, благодаря участию людей из разных стран
10. Экономическая выгода для организаций, предоставляющих инструкторов, преподавателей и консультантов

ISTQB Certified Tester – это первая и единственная международная программа, которая позволяет получить дальнейшее образование в сфере тестирования ПО. Она обладает следующими преимуществами:
1. Стандартизировать развития карьеры в сфере тестирования ПО
2. Добиться признания процесса тестирования ПО, как важнейшей специализации в сфере разработки ПО
3. Дать возможность профессиональным специалистам в сфере тестирования ПО быть признанными работодателями, клиентами и пользователями
4. Постоянно продвигать лучшие практики в тестировании ПО среди всех ИТ дисциплин
5. Определять наиболее важные и «горячие» темы в сфере тестирования ПО
6. Давать право производителям ПО нанимать сертифицированных специалистов, тем самым получая коммерческое преимущество на конкурентами и рекламируя свою политику найми специалистов тестирования
7. Обеспечить возможность специалистам тестирования ПО или тем, кто интересуется данным направлением, получать квалифицированные знания по данному предмету

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

Статья написана по материалам источников:
http://www.istqb.org/index.htm
http://www.astqb.org/

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

2009-06-01T10:01:00.000+03:00

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

1. Введение

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

2. Справочники и с чем их едят

Каждый, даже людям далеким от IT сферы приходится ежедневно сталкиваться с данной функциональностью ежедневно. Не верите - тогда небольшой тест. Есть ли у вас затруднения с пониманием следующих фраз?
- Основная валюта USA – это USD
- КГБ и ДМБ хоть и звучат похоже, но страшно далеки друг от друга
- DE, FR, IT, AU – кто-то здесь не из EU

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

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

Если начать копать глубже в сторону БД, что мы увидим, что там без справочников просто нельзя и шагу ступить. Но тема нашей статьи не теория реляционных БД, а практика работы с Eхcel, поэтому предлагаю в очередной раз посмотреть, что же мы можем сделать, имея в руках только молоток и гвозди Microsoft Office и светлую голову.

3. Чем может порадовать Excel?

Как я говорил в своей предыдущей статье Excel – это конечно не полноценная БД, но все-таки некоторые “базовские” функции присутствуют. Для работы со справочниками есть целый набор функций, доступный для выбранной категории “Lookup & Reference”

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

4. Варианты реализации

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

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

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

4.1. Попроще

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

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

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

=VLOOKUP(B2 ; Список_Штатов ; 2 ; FALSE)

B2 – это ячейка с кодом
Список_Штатов – это наш справочник, в котором нам интересна 2-ая колонка с полным названием штата

Будьте внимательны с последним параметром!!!
Последний параметр (FALSЕ) определяет правило поиска кода:
- Если он равен TRUE или пропущен – ищется ближайший вариант
- Если он равен FALSE – поиск ведется на полное соответствие

Попробуйте поиграть с этим параметром, чтобы, так сказать, почувствовать разницу.

Кстати, никто не обратил внимание, чего еще не хватает во входных параметрах функции VLOOKUP для полноты картины? А откуда она узнает в каком столбце нашего справочника содержится имено код?
А вот это уже ваша прямая обязаннность – обеспечить чтобы столбец с кодами был первым столбцом нашего справочника

4.2. Посложнее

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

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

Правило преобразования несложное и основывается на том, что при поиске подходящего значения (в данном случае уже имеется ввиду поиск приближенного значения) ищется ближайшее меньшее или равное искомому коду. А если по-русски и без заумных фраз, то
• для каждой пары вида ”A – B” должно остатья первое значение – ”A”
• выражения вида >A следут заменить на величину A+1
• выражения вида <A следут заменить на Min(A), то есть минимально допустимое значение

В итоге получаем следующую таблицу:

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

=VLOOKUP(D10 ; Возраст_автомобиля; 2 ; TRUE)

D10 – это ячейка с кодом
Возраст_автомбиля – наш доведенный до ума справочник

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

4.3. Высший пилотаж

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

Рассмотрим теперь ситуацию, когда мы не сможем опираться на такой удобный посыл. Предположим, что выбор искомой информации зависит от набора ключевых значений, например сильно упрощенная схема расчета страховой премии на страхование автомобиля в США зависит от следующих параметров:
- возраст автомобиля: 1-3, 4-7, 8-10, >10
- пол водителя (плевать они хотели на гендерное равенство): М, Ж
- стаж водителя: <2, 2-5, >5

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

Ответ – никак … без предварительной подгонки. Чем мы с вами и займемся чуть дальше.

Подгонка будет заключаться в создании дополнительного поля с кодом, уникально определяющего каждый набор, например
1-3, M, <2 преобразуется в 1M0
4-7, М, 2-5 преобразуется в 11Ж2

5. Хитрости и трюки

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

5.1. Использование столбца кода для валидации

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

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

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

=INDEX(Список_Штатов,0,1)

И “золотой ключик у вас в кармане”.

5.2. Связанные справочники

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

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

Все, что нам надо сделать – это подготовить именованные списки городов включающие в себя код штата, например
Города_FL для Флориды,
Города_TX для Техаса
И познакомится с еще одной замечательной фукцией INDIRECT, позволяющей формировать стандартную Excel-ссылку из строкового значения.

В итоге выражение для валидации будет выглядеть следующим образом:

=INDEX(INDIRECT("Города_"&B2);0;2)

B2 – адрес ячейки с выбранным кодом штата
И в реальной жизни выглядеть это будет вот так:

6. Выводы

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

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

Материалы по подготовке к экзамену на сертификат ISTQB

2009-05-29T14:07:00.009+03:00

Нет времени идти на курсы по сертификации?
Курсы дороги?
Не доверяете преподавателям?
Надеетесь на свои силы и хотите подготовиться к сертификации самостоятельно?

Можно!

Материалы, собранные по крупицам на просторах интернета (спасибо моей коллеге Катерине еще раз):

Порция 1
Порция 2
Порция 3

И официальный список литературы, который, поверьте, будет полезен не только как учебное пособие к сертификации:

Если вы планируете сдавать только на 1-ый уровень, то список очень короткий:
Software Testing Foundations – first level (basic)

Если будут планы продолжить углублять знания, то:
Advanced Software Testing - Vol. 1 and Vol. 2 – second level (advanced)
Software Testing Process: Test Management – management branch
The Software Test Engineer's Handbook – technical testing branch

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

Дерзайте!

P.S. Большое спаисбо также нашим Российским колегам за бережно собранную информацию.

С уважением,
Сергей Талалаев

Экзамен на сертификат ISTQB всего за 100 евро! Еще можно успеть!

2009-05-26T18:28:00.007+03:00

Друзья, мы сами поздно узнали, поэтому поздно делимся информацией с вами.
Однако, еще есть шанс успеть сдать экзамен на сертификат ISTQB всего за полцены - 100 евро, и в родном городе Минске!

Вот подробная информация!

4 June 2009: Public ISTQB examination
The International Software Quality Institute holds a public ISTQB Foundation Level examination on 4 June 2009 from 5pm to 6pm in Minsk. The exam will be in English language.
For this exam in Belarus iSQI offers a special price, so the exam fee per person is 100 Euro.
The exam is a multiple choice test and lasts 60 minutes. In order to pass the exam, the examinee must get at least 65% of the total credits.
The basis of the exam is the ISTQB syllabus.

To take the exam a formal registration until 1 June 2009 is necessary. Please fill in the registration form and send it to iSQI. This is possible either by fax to 0049 331 23181010 or as scanned copy to certification@isqi.org. For further questions please contact Ms. Silvia Huhse (silvia.huhse@isqi.org).

Это уже второй экзамен, который проводится по сертификации в Минске.
Первый экзамен был проведен 27 января компанией GASQ.

Спешите!

Стандарты, модели, методологии - краткий обзор

2009-05-15T17:49:00.013+03:00

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

- Мы разрабатываем софт по ISO...
- А мы по RUP-у...
- А у нас всех на Agile переводят...
- Ой, а мы только спиральную модель используем...

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

Я мучаюсь этим вопросом уже некоторое время как. Но, кажется, наконец, истина где-то рядом...

Стандарты

Стандарт (от англ. standard — норма, образец) в широком смысле слова — образец, эталон, модель, принимаемые за исходные для сопоставления с ними других подобных объектов.

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

Виды стандартов:
* Международный стандарт
* Отраслевой стандарт
* Стандарт фирмы, стандарт производителя
* Стандарт качества
* Социальный стандарт

Системы стандартизации:
* ГОСТ
* ISO
* CMMI

Модели жизненного цикла

Что такое жизненный цикл, на пальцах объясняет Алексей Баранцев в своей статье "Жизненный цикл разработки программного обеспечения -- что бы это значило?"
А более сухое определение звучит примерно так:

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

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

Модели жизненного цикла ПО:
* Водопадная
* Каскадная
* Спиральная

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

Мартин Фаулер [Фаулер, 2004, с.47] пишет:
"Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада."

А почему я разделила водопад и каскад - будет чуть позже в посте, посвященном специально моделям ЖЦПО.

Взаимосвязь стандартов и моделей

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

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

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

Взаимосвязь моделей и методологий

Опять же - словами из SWEBOK:

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

Методологии разработки ПО

И так плавно мы перешли к методологиям разработки ПО. Сейчас просто перечислю, что к ним можно отнести:

* RUP (Rational Unified Process)
* EUP (Enterprise Unified Process)
* MSF (Microsoft Solutions Framework)
* XP (eXtream Programming)
* RAD (Rapid Application Development)
* SCRUM
* FDD (Feature Driven Development)
* DSDM (Dynamic Systems Development Method)
* и др...

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

Всегда ваша,
Наташа Искорева (Густыр)

Первый курс в БГУИР пройден успешно!

2009-05-14T14:53:00.004+03:00

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

И все-таки несколько слов о пройденном этапе...

Группа 14 человек. До финиша дошли все :)
Курс проходил в виде факультатива, поэтому из кабинетов на меня смотрели только заинтересованные пары глаз...
Встречались на протяжении 3-х месяцев 2 раза в неделю по часу. В следующий раз попробуем новый формат - попытаемся отчитать курс по интенсивному графику за неделю. Мне почему-то кажется, что так будет эффективнее.
Было достаточно практики: научились составлять всевозможную документацию по тестированию (документы по работе с требованиями, планы, сценарии, листы проверки, отчеты о дефектах, другие отчеты). Научились проводить статическое тестирование требований, и делать это в команде, прошли полный цикл тесирования - от работы требованиями до финальных отчетов по проекту. Учились тестировать рационально и находить "хорошие" ошибки. Сделали много вспомогательных заданий, с помощью которых стали ясны сложные вещи типа классов эквивалентности. Как говорится, учились на кошках :)
И многое-многое другое!

Студенческие шутки, уловки на проверочных работах, душевная атмосфера - все это также помогло нам финишировать успешно и без потерь!

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

Будем продолжать в том же духе!

Всегда ваша,
Наташа Искорцева (Густыр)

QTP: Реализация GUI слоя при помощи классов

2009-05-12T09:14:00.030+03:00

Автор: Meir Bar-Tal
Перевод: Сергей Талалаев (SQAdotBY)
Оригинальная статья: Implementing a GUI Layer with Classes

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

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

Аннотация

Эта статья описывает действенную технику, которая используя ООП шаблоны проектирования, дескрипторное программирование (DP) и объект Dictionary позволяет объединить GUI объекты вместе с их бизнес функциями. Статья также включает ценное дополнение: эффективный прием, позволяющий избежать зависания QTP при попытке обращения к несуществующим GUI объектам во время выполнения.

Введение

Основная проблема в автоматизированном тестировании – это как уменьшить издержки по поддержке скриптов. Вопросы вида: “Должны ли мы использовать объектный репозиторий (Object Repository OR) или дескрипторное программирование (Descriptive Programming DP)? Если выбран OR, то должны ли мы использовать общий OR или локальный для каждого Action? Если выбран DP, тогда какой оптимальный вариант его реализации?” достаточно повсеместны и ответы на них могут зависеть как от конкретных особенностей проекта так, во многих случаях, и от людей, вовлеченных в процесс.

В этой статье я проанализирую концепцию Тестовых Объектов (Test Objects) в рамках принципов OO (Object Oriented). Я попытаюсь показать, что реализация объектного репозитория в QTP не соответствует этим принципам, и каково влияние этого факта на разработку автоматизированных тестов с точки зрения эффективности затрат и трудоемкости поддержки. Затем я опишу расширение OR-концепции, которое соответствует принципам OO – GUI слой (GUI Layer). Эта концепция была адаптирована экспертами компании SOLMAR, основываясь на том факте, что возможно максимизировать повторное использование кода (и таким образом улучшить поддерживаемость кода) используя OO подход, согласно которому автоматизируемый проект разбивается на несколько уровней абстракции.

Тестовые Объекты и Run-Time Объекты

Тестовый объект содержит в себе ссылку на run-time объект – объект реального мира, который инициирован в тестовом приложении. Тестовый объект содержит описание объекта, на который он ссылается, в виде набора атрибутов и значений служащих критерием для поиска нужного объекта в ходе тестового прогона. Это описание больше всего похоже на то, что вы себе представляете, идя на встречу с незнакомкой (“Я брюнетка, стройная и высокая, и буду одета в красное платье и туфли”)

Аналогично QTP использует описание для запроса к OS, загружен ли в настоящий момент объект в оперативную память. Если ответ положительный, то OS вернет адрес объекта (ссылку или указатель) и, следовательно, QTP получит доступ к публичным методам и свойствам объекта, в то время как частные методы и свойства остаются скрытыми от просмотра по определению (таким образом QTP никогда не вмешивается в частную область, чего вы бы хотели в отношении брюнетки, если повезет!)

Хотя это описание может быть слишком упрощено, но по существу это такой процесс, который позволяет нам взаимодействовать с GUI (и другими) объектами используя QTP или другое средство автоматизации (Test Partner, Test Complete, Rational Robot, AutoIt и т.д.) Более детальное объяснение различия между Тестовыми Объектами и Run-Time Объектами доступно в статье Yaron Assa "Differences and Connections between Runtime Objects and Test Objects" (2009).

Тестовые Объекты и Объектный Репозиторий

Рассказанное выше естественно заставляет нас думать о тестовых объектах как о данных. Что я имею в виду? Основываясь на описании, построенном из свойств и значений, QTP имеет возможность распознать GUI объект среди всех объектов, загруженных в данный момент в машинную память. Этот процесс подобен тому, как мы получаем необходимую запись из БД согласно условию WHERE в SQL запросе. Разница лишь в том, что в данном случае OS (Windows), а не БД возвращает запись. Кроме того, запись содержит только одно поле – ссылку на реальный run-time объект. Следуя данной мысли, это кажется вполне естественным хранить эти записи - тестовые объекты (Test Objects) – в базе данных, которой собственно Объектный Pепозиторий (Object Repository) и является (если вы обратили внимание на файлы с расширением bdb в QTP тестах, то знайте, что bdb в действительности означает Berkeley Data Base – продукт компании Oracle).

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

Это действительно, правда, что OR, при правильном использовании, предоставляет наилучшую технику, в соответствии с которой нам необходимо сохранить описание каждого GUI объекта всего лишь раз для уменьшения стоимости изменений. Тем не менее, чтобы достичь этого должны быть потрачены большие усилия на правильное управление тестовым проектом, потому что непродуманные запросы и недостаток ресурсов могут привести нарушению целостности этого ценного ресурса (OR). Например, предположим, что два инженера автоматизации работают одновременно с общим репозиторием, но один из них модифицирует скрипт для прошлой версии приложения, а другой – для новой. При условии, что GUI изменения выполняются регулярно от одной версии приложения к другой, не придется долго ждать, пока репозиторий окажется заполненным новыми лишними объектами необходимыми для работы с новой версией приложения. И это еще относительно неплохой результат. Гораздо более худший результат вы получите в случае, если каждый инженер изменяет набор свойств существующих объектов для отражения своих требований, безвозвратно разрушая ROI (возврат инвестиций) проекта автоматизации в целом. Конечно имеются решения и для таких ситуаций, такие как хранение отдельных версий репозитория для соответствующей версии приложения и использование специального ПО по управлению конфигурациями в рамках проекта автоматизации. Но, как говорилось ранее, это требует хорошего управления проектом, что не всегда доступно.

Кроме того поддержка версионности объектного репозитория оставляет открытой одну проблему. По причине того, что автоматические тесты являются регрессионными по своей сути, их модификация затрагивает не только OR, но также и код, который реализует непосредственные манипуляции с GUI объектами и проверки, также как и работу с входными данными и ожидаемым результатом. В общем случае, когда при переходе от одной версии приложения к другой меняются только описания объектов, использование объектного репозитория действительно будет оправданным. Тем не менее, чаще ситуация обратная, изменения в GUI отражают изменения в функциональности приложения, которые в свою очередь гораздо чаще сопровождаются более глубокими изменениями – на уровне БД, например. Таким образом, изменения в GUI требуют изменений как на уровне объектного репозитория, так и на уровне скрипта, который ссылается на тестовые объекты и плюс к этому на уровне входных данных для самого скрипта. Учитывая то факт, что скрипты чаще всего подвергаются модификации, а не разработке, вышеупомянутый анализ приводит меня к мысли, что нечто в концепции OR неправильно по отношении к управлению крупномасштабными проектами автоматизации.

Объектно-ориентированный взгляд

Концепция ООП базируется на трех основных принципах – инкапсуляции, наследовании и полиморфизме. Инкапсуляция означает упаковку вместе функциональности и данных, которые сосуществуют вместе и данная упаковка, через которую осуществляются обращения, называется классом. Фактически классы – это представление данных (например, Customer, Product и т.д.) Различие между полнофункциональным классом и обычной структурой данных в том, что класс содержит в себе функции по работе со своими данными - полями. Эти функции обычно называются методами класса. Например, типичный класс для Customer-а включал бы себя следующие поля, которые однозначно определяют покупателя (customerId, firstName, lastName, phoneNo и т.д.) вместе с методами setCustomerId, getCustomerId, которые присваивают и возвращают значения соответствующим полям, также как и getCustomerAge and getCustomerBalance выполняющими расчеты на основе текущих значений полей и возвращающие результат.

Наследование тесно связано с одной из важнейших целей ОО подхода – повторного использование кода. В объектно-ориентированных языках, таких как C++ и Java, повторное использование кода вступает в игру посредством возможности создавать новый класс, который “наследует” поля и методы уже созданного класса (называемого базовым классом) и расширяет их согласно специфическим требованиям, поставленным для нового класса.

Полиморфизм – это еще один мощный принцип, который делает возможным определять несколько версий одной функции (с одним именем, но с различным набором аргументов) для того чтобы прозрачно реагировать на различные ситуации в рамках контекста приложения. Например, у нас есть необходимость производить одну и ту же операцию с различным набором аргументов (float, int) и тогда вместо того, чтобы в одной функции реализовывать набор условных операторов для проверки типов переданных параметров, мы определим несколько функций с одинаковым именем, но с разной сигнатурой (различным набором аргументов). Следовательно, в нашем коде, использующем эти функции, нам не придется использовать приведение типов; мы будем использовать одинаковый интерфейс в обоих случаях, полагаясь на то, что корректный вызов будет осуществлен самой средой выполнения. Тем не менее, в QTP две последние концепции (наследование и полиморфизм) не могут быть реализованы в рамках VB скрипта, который обеспечивает только ограниченную поддержку работы с классами. Тем не менее, позже мы увидим, что это не причина отказываться от использования классов в автоматизации тестирования.

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

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

Автоматизация Тестирования и Разработка ПО

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

Задача автоматизации тестирования не должна рассматриваться иначе, чем любая другая контекстно-зависимая задача автоматизации. Вообще говоря, компьютерная программа, которая выполняет набор операций вместо человека – реализует автоматизацию. Таким образом, любой блок кода по сути можно рассматривать как автоматическое устройство или робота. Скрипты, которые производят операции над GUI объектами (как тесты в QTP) не отличаются от других частей ПО. Говоря другими словами, проект тестовой автоматизации, несомненно, является специфичным видом проекта по разработке ПО. И как любой программный продукт проект автоматизации также имеет свой собственный документ с функциональными требованиями (Software Requirements Specifications) и дизайн (Software Test Design) документ (либо тест дизайн в одном из промышленных фреймворков, например HP’s Quality Center или Orcanos’ QPack), которыми должен руководствоваться инженер автоматизации при реализации требуемого кода.

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

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

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

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

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

Концепция слоев

Я надеюсь, что объяснил достаточно подробно, почему подход с использованием Объектного Репозитория (OR), повсеместно используемый в скриптах, далек от оптимального. Теперь, продолжая начатое обсуждение, позвольте взглянуть на концепцию разработки кода, разделенного на слои или собственно концепцию GUI слоя. Вообще, слои весьма полезны для максимизации повторного использования кода (возвращаясь к предыдущему обсуждению принципов ООП). Я бы определил GUI слой как множество классов, которые объединяют (инкапсулируют) вместе необходимые интерфейсы для манипуляции GUI объектами тестового приложения для выделенной функционально части. Другими словами – это множество классов, обеспечивающих связь между GUI тестового приложения (то есть определенных тестовых объектов) и Бизнес или Прикладным Слоем, о котором мы поговорим позднее. Может быть, было бы более подходящим назвать его Слой GUI-Бизнес Адаптера, но среди экспертов уже устоялся термин GUI Слой, для краткости. Я проиллюстрирую ниже, как такой слой может быть создан и, какие преимущества достигаются при применении данного подхода в рамках тестовой автоматизации.

Реализация GUI Слоя

Инкапсуляция Тестовых Объектов в Классы

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

Class Login

End Class

Class MainWindow

End Class

Class CreateCustomer

End Class

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

'——————————————————————————-
Public Function CreateLogin()
'——————————————————————————-
'Function: CreateLogin
'Creates an instance of the Login class
'
'Remarks:
'
'Arguments:
' N/A
'
'Returns:
' Object - As Login
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
Dim objLogin

Set objLogin = New Login

Set CreateLogin = objLogin
'——————————————————————————-
End Function
'——————————————————————————-

Второй шаг, очевидно, определить список элементов внутри каждого класса. Теперь, так как каждый класс, согласно вышеизложенному – это контейнер других GUI объектов, мы будем использовать Scripting.Dictionary для хранения ссылок на тест-объекты находящиеся на окне, диалоге или странице. (объект Dictionary широко обсуждался в статьях опубликованных в AdvancedQTP’s базе знаний). Таким образом, первый элемент который я представлю здесь, будет общим для всех GUI Layer классов, и я определю его как m_htChildObjects:

Class Login
Private m_htChildObjects 'As Scripting.Dictionary

End Class

Class MainWindow
Private m_htChildObjects 'As Scripting.Dictionary

End Class

и так далее для каждого контекста приложения (ht – префикс для HashTable, чем объект Dictionary на самом деле и является). Частный элемент m_htChildObjects будет доступен через свойство класса ChildObjects. Это свойство определено как:

'——————————————————————————-
'Property: ChildObjects
'Get and Set the m_htChildObjects member field
'
'Remarks:
' R/W
'
'Arguments:
' dic
'
'Returns:
' m_htChildObjects As HashTable
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
Public Property Get ChildObjects()
'——————————————————————————-
Set ChildObjects = m_htChildObjects
'——————————————————————————-
End Property
'——————————————————————————-

'——————————————————————————-
Public Property Let ChildObjects(ByRef dic)
'——————————————————————————-
Set m_htChildObjects = dic
'——————————————————————————-
End Property
'——————————————————————————-

Третий шаг – определение всех объектов внутри каждого контекста. Для этой цели я определю публичный метод Init:

'——————————————————————————-
Public Function Init()
'——————————————————————————-
'Function: Init
'Initializes the context and child objects
'
'Dependencies:
' IsContextLoaded(htContext)
'
'Remarks:
' N/A
'
'Arguments:
' N/A
'
'Returns:
' True/False
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
ChildObjects = CreateObject("Scripting.Dictionary")

With ChildObjects
.Add "Browser", Browser("name:=My App")
.Add "Page", ChildObjects("Browser").Page("title:=My App \- Login")
.Add "Username", ChildObjects("Page").WebEdit("html id:=Username")
.Add "Password", ChildObjects("Page").WebEdit("html id:=Password")
.Add "Submit", ChildObjects("Page").WebButton("outertext:=Submit")
End With

'IsContextLoaded is a function that iterates through the Dictionary and checks if the GUI objects "exist"
Init = IsContextLoaded(ChildObjects)
'——————————————————————————-
End Function
'——————————————————————————-

Часть кода, показанного выше, описывает типичный метод Init для GUI Layer класса страницы логина в Web приложении. Тестовые объекты добавляются, как элементы словаря ChildObjects и их свойства определены посредством Дескрипторного программирования (DP). Читатель может легко провести аналогию с Объектным репозиторием (OR). Благодаря этому встроенному методу мы можем быть уверены, что GUI-объекты всегда определяются в одном месте. В конце кода метода вы можете отметить, что он возвращает результат вызова функции IsContextLoaded которая принимает в качестве аргумента словарь, содержащий ChildObjects.
IsContextLoaded определятся в отдельной общей библиотеке, следующим образом:

'——————————————————————————-
Public Function IsContextLoaded(ByRef htContext)
'——————————————————————————-
'Function: IsContextLoaded
'Checks that the current GUI context is loaded
'
'Iterates through the htContext (HashTable) items and executes the Exist method with 0 (zero) as parameter.
'
'Remarks:
' N/A
'
'Arguments:
' ByRef htContext - As HashTable
'
'Returns:
' True/False
'
'Owner:
' Meir Bar-Tal, SOLMAR Knowledge Networks Ltd.
'
'Date:
' 11-Nov-2008
'
'See Also:
'
'——————————————————————————-
Dim ix, items, keys, strDetails, strAdditionalRemarks

'—————————————————————————
items = htContext.Items
keys = htContext.Keys

For ix = 0 To htContext.Count-1
IsContextLoaded = IsContextLoaded And items(ix).Exist(0)
strDetails = strDetails & vbNewLine & "Object #" & ix+1 & ": '" & keys(ix) & "' was"
If IsContextLoaded Then
intStatus = micPass
strDetails = strDetails & ""
strAdditionalRemarks = ""
Else
intStatus = micWarning
strDetails = strDetails & " not"
strAdditionalRemarks = " Please check the object properties."
End If
strDetails = strDetails & " found." & strAdditionalRemarks
Next
'—————————————————————————

Reporter.ReportEvent intStatus, "IsContextLoaded", strDetails
'——————————————————————————-
End Function
'——————————————————————————-

И она возвращает Истину если все объекты, определенные в словаре идентифицированы или Ложь если хотя бы один из объектов не найден. Эта функция универсальная и используется для всех проектов, которые я веду для того чтобы быть уверенным, что QTP не зависнет при попытке выполнения операций с несуществующим GUI-объектом. Еще одно преимущество этого метода в том, что он указывает точно на тот объект, который вы хотите проверить и изменить, делая поддержку значительно более легкой.

Инкапсуляция бизнес методов в классы

Следующий шаг, после определения дочерних объектов для тестируемого контента – это определение операций, необходимых для выполнения бизнес-сценариев в рамках данного контента. Это легко реализуется через методы класса. Например, класс Login, описанный выше нуждается в следующих методах для начала работы с ним: SetUsername, SetPassword и Submit. Они показаны ниже:

'——————————————————————————-
Public Function SetUsername()
'——————————————————————————-
'Function: SetUsername
'Set the Username field
'
'Dependencies:
' N/A
'
'Remarks:
' N/A
'
'Arguments:
' N/A
'
'Returns:
' N/A
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
ChildObjects("Username").Set GlobalDictionary("Username")
'——————————————————————————-
End Function
'——————————————————————————-

'——————————————————————————-
Public Function SetPassword()
'——————————————————————————-
'Function: SetPassword
'Set the Password field
'
'Dependencies:
' N/A
'
'Remarks:
' N/A
'
'Arguments:
' N/A
'
'Returns:
' N/A
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
ChildObjects("Password").Set GlobalDictionary("Password")
'——————————————————————————-
End Function
'——————————————————————————-

'——————————————————————————-
Public Function Submit()
'——————————————————————————-
'Function: Submit
'Presses the Submit button
'
'Dependencies:
' N/A
'
'Remarks:
' N/A
'
'Arguments:
' N/A
'
'Returns:
' N/A
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
ChildObjects("Submit").Click

'TODO: Verify data submission performed successfully
'——————————————————————————-
End Function
'——————————————————————————-

Отметим использование GlobalDictionary для получения требуемых значений для функций (username, password) и использование свойства ChildObjects для получения через тестовый объект ссылки на выполняемый объект.

Следующим шагом будет перемещение на Бизнес Слой (Business Layer), который реализует бизнес сценарий, построенный на базе GUI Слоя (GUI Layer). Например, для того чтобы выполнить логин в систему на основе вышеописанного примера мы реализуем следующую функцию:

'——————————————————————————-
Public Function do_login()
'——————————————————————————-
'Function: do_login
'Implements the business logic of the do_login Action.
'
'Remarks:
'
'Arguments:
' None
'
'Returns:
' Status
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
Dim intStatus, objLogin

Set objLogin = CreateLogin()
If objLogin.Init() Then
objLogin.SetUsername()
objLogin.SetPassword()
objLogin.Submit()

'If login succeeds
intStatus = micPass
Else
intStatus = micFail
End If

do_login = intStatus
'——————————————————————————-
End Function
'——————————————————————————-

Отметим использование класса Login описанного выше и его функции Init как меру предосторожности для уверенности, что необходимый контент загружен и не завис, как обсуждалось ранее. Как вы можете видеть, код вышеописанной функции достаточно просто для понимания, и не перегружен ссылками на OR объекты, источники данных как при обычной реализации. Если изменения на GUI затронут объекты в данном контенте – все изменения будут сконцентрированы только в данном пакете, как те что касаются собственно свойств объектов так и механизмов работы с дочерними объектами. Еще одно преимущество данной методики – это стандартизация. Разрабатывая код по данной схеме, мы достигаем высокой степени унификации кода написанного разными разработчиками и таким образом улучшаем управляемость тестового проекта.

Более продвинутая альтернатива последнему примеру – это упаковка таких бизнес-функций, используя Command Wrapper шаблон проектирования, как это описано в моей статье Function Pointers in VB Script (revised). Например:

'VB Script Document
Option Explicit

'——————————————————————————-
Class do_login
'——————————————————————————-
'Class: do_login
'Encapsulates the do_login Action.
'
'Remarks:
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
'——————————————————————————-
'Methods
'——————————————————————————-
'——————————————————————————-
Public Default Function Run()
'——————————————————————————-
'Function: Run
'Implements the business logic of the do_login Action.
'
'Remarks:
'
'Arguments:
' None
'
'Returns:
' Status
'
'Owner:
' John Doe
'
'Date:
' dd-MMM-yyyy
'
'——————————————————————————-
Dim intStatus

Set objLogin = CreateLogin()
If objLogin.Init() Then
objLogin.SetUsername()
objLogin.SetPassword()
objLogin.Submit()

'If login succeeds
intStatus = micPass
Else
intStatus = micFail
End If

Run = intStatus
'——————————————————————————-
End Function
'——————————————————————————-
'——————————————————————————-
End Class
'——————————————————————————-

Адаптация данной методики делает возможным реализацию продвинутых универсальных контроллеров (generic controller), которые загружают свои сценарии из внешних источников данных, таких как XML файл. Такие управляющие структуры были разработаны мной и моими партнерами в SOLMAR Knowledge Networks как часть нашего универсального фреймворка - Object Oriented comprehensive automation framework - My System.

Выводы

В данной статье рассматривался альтернативный подход реализации тестов при автоматизации, основанный на объектно-ориентированной методологии. Я показал, что автоматизацию не следует рассматривать иначе, чем разработку программ. Более того, я постарался отразить, что логически следуя данной мысли, мы приходим к заключению, что проект автоматизации должен рассматриваться как программный проект в идеале, и предложил расширение концепции Объектного Репозитория (OR) (которая показала несоответствие OR методологии ООП) для инкапсуляции интерфейсов GUI объектов: GUI Слой.
В статье также приводился практический пример реализации такого слоя и его вызов, используя Бизнес-Слой, и разъяснены в деталях преимущества такого подхода для достижения максимального эффекта от вложенных инвестиций (ROI) в проекте автоматизации относительно поддерживаемости, читаемости, масштабируемости, расширяемости и тестируемости. Следующие статьи расширят данную тему и покажут читателям, как получить выигрыш от реализации в фреймворке других шаблонов проектирования, помимо изложенных в рамках этой статьи.

Читайте нас в Quality Matters, Issue 2

2009-05-08T16:52:00.003+03:00

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

Постараемся не останавливаться на достигнутом! ;)
Присоединяйтесь!

Всегда ваша,
Наташа Искорцева (Густыр)

Разоблачение Excel: Проверка вводимых данных - выпадающие списки

2009-04-16T09:45:00.021+03:00

Часто ли у вас возникало желание, после получения отчета в Excel (абсолютно на любую тематику), убить его автора? Если возникало и не раз – скорее всего вы наш пациент :)

1. Отчёт, отчёт и еще раз …?

Казалось бы чем можно убить любую здравую идею, подразумевающую некоторую информационную составляющую: ”Давайте соберем статистику использования различных операционок на проектах”, “Надо бы собрать сведения об используемом ПО для оптимизации расходов компании” и т.д.?

Правильно – бездарно собранной информацией!!!

Итак, смотрим, что мы получили в ответ на наш запрос:

Раз

И два

С одной стороны вроде и информация собрана, а с другой…

Бухгалтррия Плюс – это почти Бухгалтерия Плюс, но не совсем.
Антиврус (ПО) – это почти Антивирус (ПО), но не совсем.
Отдел сопровждения ПО – это почти Отдел сопровождения ПО, но не совсем.

И уж совсем ни одно и тоже Windows XP, Win XP, XP, WinXP.
Как впрочем и 1C Бухгалтерия, 1C, 1C Бухгалтерия 7.0.

Поэтому, засучив рукава, идем за большим напильником и начинаем … :)

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

2. Очень гибко хорошо, очень гибко плохо?

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

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

Все казалось бы верно, но возвращаясь к собранным отчетам, возникает чувство некоторой неполноценности: ”А можно, чтобы все также просто как в Excel, но еще и чтобы контроль данных был?” (перед глазами заботливо всплыл образ Никулина и его ”перламутровые пуговицы”).
И чтобы тоска от сознания необходимости ковырятся в VB for application, макросах, формулах не потушила робкую надежду, как минимум, дочитать эту статью до конца, а как максимум, реализовать то, что в ней написано, сразу ответим – можно и это не так уж сложно, как может показаться на первый взгляд.

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

3. Готовим прокрустово ложе.

Для начала нам нужно подготовить корректные значения для заполнения наших выпадающих списков правильными величинами. Это можно сделать на отдельной странице нашего Excel файла, назовем её просто и незатейливо – ”Списки (первый вариант)” и скопируем в нее наш список проектов.

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

И активируем диалог валидации данных ( Main menu>Data>Data Validation ) для выбранной ячейки

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

Первая страница диалога – Settings (в большинстве случаев её оказывается достаточно) позволяет вам ограничить входные данные согласно заданным правилам. Для настройки необходимого нам типа валидации следует выбрать значение выполнить установки согласно картинке ниже, то есть Allow = List.

Обратите внимание,что на странице появились дополнительные элементы управления:
In-cell dropdown – говорит, что значения предлагаются в виде выпадающего списка;
Source – указывает где брать допустимые значения.

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

Более удобный вариант подсказки предполагает использование вкладки Error Alert. При использовании этого варианта сообщения появляются при попытке выхода из поля при условии неправильного введенного значения.

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

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

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

3.1. Огласите весь список, пожалуйста.

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

Перечисление списка допустимых значений.
Первый и самый простой (именно этот способ и запечатлен на рисунке выше) – это перечисление списка значений через разделитель ; напрямую в поле Source первой вкладки:

Быстро, понятно, удобно и …
не стоит так делать (точнее делать можно, но предварительно хорошо подумав)

Представим ситуацию, когда таким образом провалидированные поля разбросаны щедрой рукой по всему Excel файлу и вдруг оказывается, что нужно добавить в список допустимых значений еще одну строчку!
Поэтому, хорошенько подумав такой стиль оформления применяйте только для абсолютно фиксированных небольших списков, например: {Да;Нет}, {M;Ж}, {Pass;Fail}

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

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

Именованный диапазон.
Оформив наш список значений в виде именованного диапазона с логичным и понятым для вас именем (в данном случае ”Проекты”). Мы можем вместо буквенно-числовой шифрограммы $A$2:$A$8 использовать осмысленное имя – Проекты.

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

4. Выводы

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

P.S. Для лентяев (к которым я причисляю и себя) в комментариях можно найти ссылу на Excel-файл, являющийся материализацией вышеизложенного материала.

С уважением,
Сергей Талалаев

Нас публикуют за рубежом!

2009-04-13T08:52:00.011+03:00

В рамках реализации проекта по перемещению мировой столицы тестирования в Минск (О.Бендер и Нью-Васюки нервно курят) состоялась публикация нашей статьи на специализированном сайте по автотестированию AdvancedQTP.com

А если серьезно, то ...

Я очень благодарен этому профессиональному сайту. Начиная с первой страницы (один слоган чего стоит: 'coz we're programmers - not users) становится понятно, что аудитория здесь собралась крайне серьезная. Мне очень повезло, что начиная свой путь с QTP я столкнулся именно с этим ресурсом. Многие сложные оказались предельно простыми после ознакомления с материалами, размещенными на сайте.
Кроме того, в силу ограничений коммерческого характера (и мне это абсолютно понятно), некоторые статьи не раскрывают все технические тонкости реализации какой-либо интересной функциональности, но дают представление об идее, которую приходится доводить до ума самостоятельно (что потрясающе интересно).

Думаю, что заслуженных диферамбов получилось достаточно :)

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

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

Поэтому, приглашаю вас во-первых, посетить этот действительно профессиональный ресурс, а во-вторых, порадоваться вместе с нами: AdvancedQTP-Universal class for data manipulations

С уважением,
Сергей Талалаев
С большой признательностью к моей коллеге Анне Валерьевне.

Учим тестированию студентов!

2009-04-06T13:59:00.004+03:00

В одном из своих постов я уже говорила о том, что среди прочих грандиозных планов - преподавание курса по тестированию ПО студентам БГУИР.

Свершилось!

И вот уже с 11-го марта дважды в неделю я наслаждаюсь общением со студентами на тему тестирования!
Признаться, до начала курса настороженно относилась к тому, как пойдет общение. Но, как ни странно, студенты ведут себя очень заинтересованно и активно. И что особенно приятно - они задают вопросы! А это значит, что:
- Они не боятся
- Они слушают
- Они пытаются разобраться
- Им небезразлично
- И, надеюсь, они, в итоге, усваивают
По поводу последнего утверждения могу сказать следующее: кое-что усваивают точно, потому что часто слышу: "а вот Вы говорили так-то", "а это называется так-то", "а такие-то тесты писать будем?" и т.д. и т.п.
Ну, а все остальное мы проверим на итоговой работе...

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

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

Пока, как говорится, "Учиться! Учиться! и еще раз - Учиться!"
Ждем результатов :)

Всегда ваша,
Наташа Густыр

QTP: Сравнивая с … Универсальный класс для работы с данными

2009-04-02T10:42:00.037+03:00

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

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

1. Введение

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

2. Работа с Excel-данными

Еще работая с WinRunner, я убедился, что встроенная реализация Excel хранилища не настолько гибка, как мне бы хотелось. Поэтому, как всегда, я приготовился к миграции своих процедур для работы с Excel. И был немного удивлен отсутствию встроенных средств работы с БД. Но эта задача вполне по силам, когда за плечами вся мощь VB :)

2.1. Основные задачи

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

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

Было до вмешательства из QTP:

Стало после редактирования из QTP:

Чтобы избежать подобных казусов я давно применяю прямую вычитку из Excel файлов в массивы, используя для этого стандартные ODBC источники. Данная техника успешно прижилась уже на следующих тестовых фреймворках: Rational Robot, IBM Rational Functional Tester, WinRunner и надеюсь QTP

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

2.2. Предварительные шаги

В Excel документах имеется функциональность которая позволяет выделять значимые для пользователя подмножества ячееек в специальные структуры. Такие структуры называемые “именованными диапазонами” обеспечивают возможность обращаться к ним к ним через логические имена.
Кроме того (что гораздо более значимо для нас) такие диапазоны становятся видны как стандартные ODBC таблицы из внешних приложений.

Итак, для оформления требуемой совокупности ячеек в качестве “именованного диапазона” необходимо выполнить следющую последовательность действий:
- выделить все ячейки, планируемые для оформления в именованный диапазон
- создать именованный диапазон через “Define name” диалог (Formulas > Define Name)

или напрямую введя имя диапазона в Navigation Bar.

Для проверки корректности вновь созданного именованного диапазона – выделите все ячейки диапазона и проверьте значение в Navigation Bar. Он должен содержать логическое имя вместо A1 нотации.

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

2.3. Со стороны функциональной библиотеки

После всех подготовительных шагов осталось совсем немного поработать руками, а точнее пописать код.
Раз уж QTP 9.5 предоставил нам замечательную возможность работать c “почти” объектами – грех было бы ей не воспользоваться. Поэтому весь наш функционал мы гордо завернем в класс с благозвучным названием TestData.

Стоит напомнить, что QTP не видит напрямую классы, объявленные во внешних библиотеках, поэтому для каждого класса должна присутствовать функция создания экземпляра класса, в данном случае – CreateTestData

Кроме того мы должны иметь возможность инициировать наш класс не только через загрузку из Excel источника но и напрямую из кода. Именно для этих целей появились два метода: SetData и GetData

Public Function CreateTestData ()
Set CreateTestData = new TestData
End Function

Class TestData
Private mTestTable()

Private Sub Class_Initialize()
End Sub

Private Sub Class_Terminate()
Erase mTestTable
End Sub

' @Documentation Initiates TestData object with external data
'-----------------------------------------------------------
Public Sub SetData (DataArr())
Dim i,j

ReDim mTestTable(UBound(DataArr, 1), UBound(DataArr, 2))
For i=0 to UBound(DataArr, 1)
For j=0 to UBound(DataArr, 2)
mTestTable(i,j) = DataArr(i,j)
Next
Next
End Sub

' @Documentation Extracts data from TestData object
'---------------------------------------------------
Public Sub GetData(DataArr())
Dim i,j

ReDim DataArr(UBound(mTestTable, 1), UBound(mTestTable, 2))
For i=0 to UBound(mTestTable, 1)
For j=0 to UBound(mTestTable, 2)
DataArr(i,j) = mTestTable(i,j)
Next
Next
End Sub

Итак, мы вплотную подобрались к центральной части нашего функционала – вычитке данных из Excel источника.
За данную часть функционала отвечают два взаимосвязанных метода: GetArrayFromStore и LoadFromStore
Первый позволяет нам выгрузить вычитанные данные во внешний массив, минуя наш класс, а второй наоборот – инициирует наш класс вычитанными данными.

' @Documentation Extracts test data from the Excel store
'------------------------------------------------------
Public Sub GetArrayFromStore(Arr(), TableName, StoreName)
Dim Connection
Dim i, j, fieldcount, rowsfetched
Dim ArrTemp()

Set Connection = CreateObject("ADODB.Connection")
Connection.ConnectionString = "DBQ=" + StoreName + _
";Driver={Microsoft Excel Driver (*.xls)}" + _
";DriverId=790;FIL=excel 8.0;MaxBufferSize=2048" + _
";MaxScanRows=8;PageTimeout=5;ReadOnly=1" + _
";SafeTransactions=0;Threads=3;UserCommitSync=Yes"
Connection.Open

Set ConnRs = CreateObject("ADODB.Recordset")
ConnRs.CursorType = 3
Call ConnRs.Open("select * from " + TableName, Connection)

fieldcount = ConnRs.Fields.Count
Redim ArrTemp(fieldcount - 1, 0)

'column names adding
for j=0 to fieldcount - 1
ArrTemp(j,0) = ConnRs.Fields(j).Name
next

rowsfetched = 0
ConnRs.MoveFirst()
While not ConnRs.Eof
rowsfetched = rowsfetched + 1
Redim Preserve ArrTemp(fieldcount - 1, rowsfetched)
for j=0 to fieldcount - 1
ArrTemp(j, rowsfetched + i) = ConnRs(j).value
next
ConnRs.MoveNext()
Wend
Connection.Close

'matrix transposition
Redim Arr(UBound(ArrTemp,2), UBound(ArrTemp,1))
for i=LBound(ArrTemp,1) to UBound(ArrTemp,1)
for j=LBound(ArrTemp,2) to UBound(ArrTemp,2)
Arr(j,i) = ArrTemp(i,j)
next
next

End Sub

' @Documentation Loads test data from Excel store to the TestData object
'-----------------------------------------------------------------------
Public Sub LoadFromStore (TableName, StoreName)
call GetArrayFromStore(mTestTable, TableName, StoreName)
End Sub

Как вы можете заметить, ничего сверхъестественного в реализации данного функционала нет. Более того очевидно, что с небольшими модификациями такую же процедуру можно применять для вычитки данных из любого ODBC источника.
Нам осталось добавить несколько сервисных методов, чтобы наш класс стал действительно удобным в использовании: GetCellByIndex, GetCellByName, ColumnCount, RowCount

' @Documentation Gets cell value by row-column indexes
'------------------------------------------------------
Public Function GetCellByIndex (RowIndex, ColumnIndex)
GetCellByIndex = mTestTable(RowIndex+1, ColumnIndex)
End Function

' @Documentation Gets cell value by column name and row index
'-------------------------------------------------------------
Public Function GetCellByName (ColumnName, RowIndex)
Dim j

for j = 0 to UBound(mTestTable,2)
If (ColumnName = mTestTable(0,j)) Then
Exit For
End if
next

GetCellByName = mTestTable(RowIndex+1, j)
End Function

' @Documentation Returns number of columns into the test data table
'------------------------------------------------------------------
Public Function ColumnCount()
ColumnCount = UBound(mTestTable, 2)
End Function

' @Documentation Returns number of rows into the test data table
'---------------------------------------------------------------
Public Function RowCount()
RowCount = UBound(mTestTable, 1) - 1
End Function

2.4. Со стороны тестового скрипта

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

Dim TestArr() ‘Dynamic array
Dim TestD

Set TestD = CreateTestData()

Сall TestD.LoadFromStore("NamedRange", "C:\ExcelStore.xls")
Сall TestD.GetArrayFromStore(TestArr, "NamedRange", "C:\ExcelStore.xls")
‘Call TestD.GetArrayFromURL(TestArr, "OrgChart@"+ "C:\ExcelStore.xls")

Call TestD.SetData(TestArr)
Erase TestArr
Call TestD.GetData(TestArr)

Print TestArr(1,1)
Print TestD.GetCellByIndex(2,2)
Print TestD.GetCellByName("Name", 2)
Print TestD.RowCount
Print TestD.ColumnCount

Обращаю ваше внимание, что массив (если вы решите выгружать данные из TestData объекта) должен быть динамическим, а не статическим.

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

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

Предлагаю вам реализовать данную функциональность самостоятельно.

3. Выводы

Возможно, кого-то, во время прочтения статьи, не покидало ощущение бесполезности реализации дополнительной функциональности имея стандартные средства работы с Eхcel. Частично я уже объяснял причины необходимости этого выше (Основные задачи). Но кроме этого хотелось бы еще добавить в копилку знаний несколько замечаний.

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

С уважением,
Сергей Талалаев
С большой признательностью к моей коллеге Анне Валерьевне.

Сертификация: За и Против

2009-02-02T15:37:00.008+02:00

Пора!

Пора и мне, наконец, сказать, что я думаю по поводу сертификации тестировщиков и как я себе ее вижу.

Начну с хорошего.

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

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

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

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

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

Всего, что описано выше, можно добиться и другими методами. Однако, речь не об этом.

А теперь немного горькой пилюли.

1. Сертификации бывают разные… К сожалению, не всякой сертификации можно доверять (а можно ли вообще хоть какой-то?). Глупые вопросы, ни коим образом не проверяющие даже знание теории, не могут быть показателем уровня специалиста.

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

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

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

Всегда ваша,
Наташа Густыр

Дебаты вокруг сертификации тестировщиков

2009-01-28T21:04:00.004+02:00

И снова здравствуйте! :)
И сразу, как говорится, вопрос в лоб:

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

Как ни странно, но тема сертифицирования тестировщиков очень актуальна в последнее время...

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

А ваше мнение какое?

Кстати сказать, я тоже имею что сказать на этот счет, но скажу буквально очень скоро :)

Всегда ваша,
Наташа Густыр

Урок 53: Оценочные (evaluation-based) техники фокусируются на том, как определить, что тест выполнен или провален

2009-01-26T22:38:00.005+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

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

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

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

Сравнение со спецификацией или другим авторитетным документом. Различие со спецификацией - это (возможно) ошибка.

Эвристическое соответствие. Соответствие - это важный критерий оценки
программы.Несоответствие может быть поводом для создания отчета об ошибке или отражать сознательное изменение дизайна. Мы используем в работе 7 основных соответствий:
1. Историческое соответствие. Текущие поведение функции соответствует её поведению в прошлом.
2. Соответствие в представлении. Поведение функции соответствует тому, что организация ожидала от проекта.
3. Соответствие со сравнимыми продуктами. Поведение функции соответствует поведению подобных функций в сравнимых продуктах.
4. Соответствие утверждениям. Поведение функции соответствует тому, как, по мнению людей, это должно быть.
5. Соответствие ожиданиям. Поведение функции соответствует тому, что, по вашему мнению, хочет пользователь.
6. Соответствие продукту. Поведение функции соответствует поведению сравнимых функций или функциональных шаблонов в продукте.
7. Соответствие цели. Поведение функции соответствует её истинной цели.

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

SQA days 2008: текст доклада "Причины пожара на проектах"

2009-01-14T15:53:00.028+02:00

Мы уже писали о выступлении на конференции SQA days и обещали опубликовать свои доклады. Наташа и Сергей сдержали обещание. Теперь моя очередь :) Я постаралась максимально приблизить печатную версию к устной, чтобы сохранить дух "живого" выступления.

«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования. Данный доклад - попытка ответить на вопрос: «Почему тестировщики не укладываются в сроки?».

Недавно мне «посчастливилось» принимать участие в проекте, на котором отставание от сроков – обычное дело. Сразу хочу пояснить, что я понимаю под отставанием от сроков. Это разница между реально потраченным и запланированным временем (см. рисунок 1).

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

Несколько слов о проекте, который вдохновил меня на подготовку этого доклада. Проект был сложный… :) Причём, я сейчас говорю не о сложности задач, которые стояли перед нашей командой, а о сложной структуре проекта. На рисунке 2 представлена схема этого проекта, где З1...З8 – задачи, из которых состоит реализация проекта, К1…К8 – компании (подрядчики), которые принимают участие в проекте. Как видно, каждый подрядчик отвечает за свою задачу. И даже заказчик выполняет часть работ по созданию программного обеспечения.

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

Думаю, понятно, что вероятность «пожаров» на проектах со сложной структурой больше. Естественно, здесь много зависимостей. Если один из подрядчиков на начальном этапе не уложился в сроки, то «поплывут» даты в планах у остальных компаний-подрядчиков. На сложном проекте часто возникает ситуация: «а это не я». Это когда на выявление ошибки уходит час, а на выявление ответственного за неё тратятся дни или даже недели. Каждая компания пытается сделать крайним кого-то другого. Такая проблема обычно возникает из-за плохой организации взаимодействия между участниками проекта и нечёткого разграничения обязанностей.

Теперь непосредственно о самих причинах. Одна из самых очевидных причин «пожаров» - нереальные сроки. Как эти «нереальные» сроки появляются? Например, заказчик говорит: «нужно, чтобы эта функциональность (F1...Fn) была готова к такому-то числу». И тут начинается попытка уместить всю требуемую функциональность в указанные сроки (хотя бы в плане проекта, который потом не соответствует действительности). В данном случае ошибка в том, что не исполнитель оценивает временные затраты, а заказчик устанавливает дату. Если времени для реализации требуемой функциональности явно недостаточно, то нужно выбирать: или урезанная функциональность в указанные сроки или смещение сроков для реализации полного объёма задач.

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

Для тестировщиков, которые выполняют задачи по уже составленному менеджером плану, часто очень актуальной проблемой становится неполный учёт задач в плане. Например, часто забывают о том, что уходит время на новичков, на помощь разработчикам в воспроизведении дефектов, на подготовку тестовых данных, на подготовку внеплановых отчётов для руководства. Плохой анализ требований и спецификации может привести к тому, что в тест-кейсах будут присутствовать не все проверки, а, следовательно, будет неправильно оценено время на тестирование. Даже одна пропущенная строка в спецификации может послужить искрой, из которой вырастет пожар. Например, в требованиях сказано: «Система должна работать под ОС Win 98, 2000, XP, Vista». Если в тест-кейсах об этом нет ничего, то тестирование будет проводиться на любой доступной тестировщику ОС (XP, например). Дальше заказчик начинает принимать Систему (на 98-й, например) – и начинается… Неожиданные ошибки, перепроверка Приложения на всех требуемых ОС, исправление дефектов и т.д. Пожар на лицо :)

Допустим, оценка временных затрат проводилась компанией – разработчиком (а не заказчиком), в плане учтены все задачи ориентируясь на абстрактного среднестатистического тестировщика. Вроде, всё хорошо. Но и здесь могут возникнуть проблемы. Не все тестировщики одинаковые. У них может быть разная квалификация. Здесь можно рассмотреть несколько случаев:
– человек просто плохой работник: или он делает всё слишком медленно (гораздо медленнее, чем среднестатистический сотрудник отдела тестирования), или делает быстро, но так, что доверять результатам нельзя, или и то, и другое... Т.е. человек не на своём месте.
– новичок в профессии (в компании, на проекте) – понятно, что человеку нужно время на адаптацию, и его не сразу можно считать полноценным ресурсом.
– неправильных подбор персонала на проект или неправильное распределение задач внутри тестовой команды на проекте. Например, человек всё время занимался тестированием десктоповских приложений, и тут его назначают на тестирование приложений для мобильных технологий. Понятно, что нужно время на то, чтобы вникнуть в предметную область. Или другой пример: тестировщика, который всегда занимался мануальным тестированием, назначают на проект по автоматизации тестирования. Т.е. при назначении людей на проект и при распределении задач внутри команды тест-менеджер должен учитывать сильные и слабые стороны своих подчинённых. НО: нельзя всегда выдавать человеку однотипные задачи только потому, что он хорошо их выполняет. Рано или поздно тестировщику станет скучно :)

Как правило, задачи в планах плавно перетекают одна в другую, т.е. между ними нет перерывов. Но ведь часто возникают вынужденные простои. Например, увеличение сроков анализа, разработки и других предшествующих тестированию этапов ведёт к простою команды тестирования. Ещё одна причина простоя - блокирующая критическая ошибка, до исправления которой тестировать невозможно или нет смысла. Недоступность приложения также блокирует работу тестировщика. Причины недоступности приложения:
– недоступен сам сервер (сгорел, на нём проводят профилактические работы, например, увеличивают кол-во памяти);
– идёт установка новой версии приложения;
– на тестовой платформе разработчики проводят исследования и эксперименты;
– на тестовой платформе проводится нагрузочное тестирование;
– на тестовой платформе проводится приёмочное тестирование заказчиком.
Т.е. здесь возникает проблема взаимодействия команд тестирования, разработки, внедрения. Сюда же можно отнести проблему коммуникации между участниками проекта, которые находятся далеко друг от друга: в разных странах, а ещё хуже, в разных часовых поясах. Здесь увеличивается время на обсуждения и принятие решений. Также существует проблема «свободного» графика работы, который так популярен в IT сфере. Допустим, в команде есть носитель «тайных знаний», без которого «работа стоит». Если этот «тайный носитель» любит поспать, то плохо дело :) Нужно или передавать знания (а ещё лучше оформить их в виде документации), или договариваться о более строгом графике работы.

И в заключение причины «пожаров», которые предусмотреть сложно – это форс-мажорные обстоятельства. Например, авария на серверах, отсутствие электричества, отсутствие тестировщика на рабочем месте (заболел, уволился и т.п.).

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

С Уважением,
Ольга Балашенко

Вырасти себе тестировщика

2009-01-12T01:44:00.007+02:00

По мотивам доклада на конференции SQA Days 2008 в Минске.

Мировой финансовый кризис оказывает значительное влияние на работу IT-компаний: сокращается количество потенциальных проектов и, соответственно, повышается конкуренция. В таких условиях компании вынуждены обратить особое внимание на обеспечение конкурентного преимущества, чтобы выжить и остаться на плаву. Приходится снижать ставки, и на первое место выходит продуктивность и эффективность работы каждого сотрудника. Решение проблемы заключается, с одной стороны, в оптимизации процессов работы компании и, с другой стороны, в развитии персонала.
Для того, чтобы процессы повышения продуктивности работы, обучения и развития были эффективными, они должны быть измеримыми. Для этого необходимо иметь точку отсчета.
За точку отсчета разумно принять оценку текущего состояния организации в целом и каждого сотрудника в частности.
В докладе рассматривается только одна сторона вопроса – тема оценки, аттестации, обучения и развития тестировщиков силами компании или силами внешних экспертов.

1. Оценка индивидуальной деятельности тестировщиков
Как и в любой другой деятельности, тестировщику важно понимать, что ему необходимо делать, чтобы его работа была эффективной.
С другой стороны, организации необходимо понимать, чего требовать от сотрудника, согласно каким критериям производить оценку его работы. Таким образом, перед руководителем отдела тестирования стоит задача в определении стандартов работы тестировщиков.
Достижение определенных стандартов также служит почвой для вознаграждения специалистов.
Независимо от того, какие критерии и стандарты индивидуальной работы используются, с самого начала их необходимо обсудить с тестировщиками, и получить их согласие и понимание. В этом случае, тестировщикам будет проще самостоятельно оценивать, соответствует ли их деятельность установленным критериям.
Таким образом, первый этап в развитии тестировщика – это постановка цели, которую нужно достичь, причем цель эта должна соответствовать небезызвестным критериям SMART (точная, измеримая, согласованная, реалистичная и ограниченная во времени).
Вторым шагом менеджер, совместно с тестировщиком, должен спланировать процесс достижения поставленной цели и определить необходимые для этого мероприятия.
И, конечно, нельзя оставлять спланированный процесс без наблюдения. Задачи, которые вы раздаете и не контролируете, могут не выполняться или выполняться с трудом.

Менеджер может использовать следующие методы мониторинга и оценки показателей персонала:
- Наблюдение и личное участие;
- Опрос и обсуждение;
- Регулярный сбор метрик;
- Другие отчеты;
- Аттестация – как оценка деятельности по истечении некоторого периода времени.

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

Весь цикл выглядит следующим образом:

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

2. Аттестация персонала
Аттестация – это формализованная обратная связь. В ходе этого мероприятия рассматриваются достижения и проблемы, подводятся итоги и строятся планы на будущее.
Выгодна она тем что:
- Подталкивает к осмыслению достижений и осознанию затруднений
- Определению направлений развития и карьерных устремлений
- Дает возможность мотивировать персонал
- Улучшать эффективность работы команды
- Улучшать обмен информацией
- И др.
Мы будем рассматривать только узкий аспект аттестации – оценка знаний и навыков тестировщиков с целью их дальнейшего развития. Все остальное – условия работы, соответствие трудовому договору, межличностные отношения и взаимодействие с другими людьми, управление временем и др. – в настоящей статье не затрагиваются.
И, кстати говоря, не рекомендуется использовать аттестацию для вознаграждения (хотя некоторые компании именно так и поступают). Первоначальная идея аттестации – создание дружественной атмосферы развития.
Стандартной процедуры проведения аттестации не существует, есть только некоторые общие принципы. Рассмотрим их.

Подготовка аттестации
Если организация тщательно готовилась к набору тестировщиков, то подготовка аттестации будет проводиться немного проще, нежели начинать ее с нуля.
Что необходимо сделать:
- Анализ работы. Должен ли тестировщик писать тестовую документацию, проводить статическое тестирование требований, писать скрипты, работать с определенными инструментами и т.д.?
- Анализ организации. Какие именно инструменты используются в организации, каковы процессы в организации (старт проекта по тестированию, передача программного обеспечения на тестирование, коммуникации внутри команды и др.), с какими заказчиками работает организация, какие проекты разрабатывает (веб, десктоп, специальные бизнес-области) и т.д.
- Должностная инструкция. На основании двух описанных видов анализа составляется должностная инструкция.
- Требования к исполнителю. На основании должностной инструкции определяются требования к тестировщику (или группе тестировщиков).

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

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

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

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

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

3. Разработка программ обучения
Что такое развитие? Это расширение способностей и навыков. Индивидуальное развитие должно увеличивать уверенность тестировщика в своих силах, его самосознание и знания. И в первую очередь, развитие – это ответственность самого человека.
Вы же, как менеджер, можете и должны содействовать развитию своих подчиненных. Для этого, как я уже говорила в самом начале, необходимо снова согласовать цели, установить, при необходимости, новые стандарты, а затем спланировать обучение. Вы должны выступать интегратором обучения своих тестировщиков на работе и вне ее.

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

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

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

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

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

Всегда ваша,
Наташа Густыр

Урок 49: People-based техники фокусируются на том, кто проводит тестирование.

2009-01-08T11:58:00.012+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

Вот несколько примеров таких техник, отличающихся исполнителями.

Пользовательское тестирование / User testing. Тестирование людьми, которые обычно используют ваш продукт. Пользовательское тестирование может выполняться в любой момент разработки на вашей стороне или их, в строгом соответствии с подготовленными сценариями или на усмотрение пользователя. Некоторым видам пользовательского тестирования, таким как анализ задач, больше подходит совместное исследование (с привлечением как минимум одного пользователя и одного члена вашей тестовой команды), чем тестирование одним человеком.

Альфа тестирование / Alpha testing. Внутреннее тестирование, выполняемое тестовой командой (и возможно другими заинтересованными, внутренними ресурсами).

Бета тестирование / Beta testing. Это вид пользовательского тестирования, проводимый потенциальными пользователями вашего продукта, а не тестировщиками вашей компании. Разработка тестирумого продукта обычно близка к завершению. Многие компании рассматривают любую передачу предрелизного кода клиенту как бета-тестирование; они обозначают все бета-тесты как "бета". Это ошибка. В действительности существует множество различных типов бета-тестов. Дизайн-бета тестирование, требующее от пользователей (в первую очередь экспертов) оценки дизайна, должно быть проведено как можно раньше, чтобы оставить время для внесения изменений по результатам тестирования. Маркетинг-бета тестирование, проводимое с целью убедить крупных клиентов в необходимости приобретения данного продукта и установки его на своих крупных сетях, должно проводиться существенно позже, когда продукт уже достаточно стабилен. При проведении бета-теста совместимости ваш клиент запускает ваш продукт на аппаратных и програмных платформах, полноценное тестирование на которых было сложным для вас. Данный вид тестирования должен проводиться до того момента, когда уже слишком поздно выявлять и исправлять проблемы совмеcтимости. Для любых типов бета-тестирования, которые вы проводите, вы должны сначала определить цели тестирования и лишь затем принимать решения о том, как и когда вы будете его проводить.

Баг-штурм / Bug bashes. Внутреннее тестирование с привлечением секретарей, программистов, менеджеров по продажам и всех, кто доступен. Обычный баг-штурм занимает пол-дня и проводится, когда продукт близок к релизу. (Замечание: мы рассматриваем данную технику в качестве примера, не настаивая на ней. Некоторые компании находят её полезной по различным причинам, другие - нет.)

Тематическое экспертное тестирование / Subject-matter expert testing. Передача продукта эксперту для проверки некоторых проблем, возникших с продуктом и требующих детального анализа (дефектов, замечаний и дополнений). Эксперт может и не являться возможным пользователем вашего продукта, ценность эксперта - это его знания, а не его значимость как потенциального покупателя.

Парное тестирование / Paired testing. Два тестировщика работают вместе над поиском ошибок. Обычно они делят один компьютер во время тестирования.

"Ешьте сами свою заливную рыбу" / Eat your own dogfood. Ваша компания использует предрелизную версию своего продукта, обычно дожидаясь, когда продукт станет достаточно устойчив для реальной работы до начала его продаж.

Видео конференции SQA Days 2008 в Минске

2009-01-06T12:33:00.002+02:00

Друзья!
Уже совсем скоро на ресурсе it-conf появится видео всех докладов.

В настоящий момент готовы видеоролики всех докладов 2-й секции, а также некоторых флип-чартов и частично вступлений 1-й секции.

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

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

Всегда ваша,
Наташа Густыр

Перевод глоссария ISTQB на русский язык

2009-01-05T14:50:00.008+02:00

Проект реализован силами участников портала Software-Testing.RU, в числе которых нахожусь и я, Наташа Густыр, под руководством Сергея Гринкевича.

Также готовый перевод Глоссария можно найти здесь. Авторами этого перевода является рабочая группа RSTQB в составе трех человек:
Андрей Конушин (Россия)
Алексей Александров (Россия)
Александр Александров (Россия)

Курс "Введение в автоматизированное функциональное тестирование"

2008-12-28T14:38:00.007+02:00

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

Группа была небольшая (4 человека), но активная! Даже предновогоднее настроение не помешало нам сосредоточиться на автоматизации тестирования :) По количеству и качеству вопросов чувствовалось, что слушатели были заинтересованы в получении знаний. Причём, нашей общей целью было не просто изучение теории и освоения основных возможностей средств автоматизации тестирования ПО, а попытка применить знания к СВОЕМУ проекту.

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

С Уважением,
Ольга Балашенко

P.S.: Ещё я заметила, что со слушателями, которые уже посетили семинар Наташи Густыр "Введение в тестирование ПО", мы разговариваем на одном языке. Это значительно упрощает как чтение, так и прослушивание курса по автоматизации.

Курс по тестированию в Интерфейсе – уууууух!

2008-12-24T17:51:00.002+02:00

Да-да-да – еще один курс по тестированию прочитан мною в Москве, в учебном центре Интерфейс.

С 17 по 19 декабря провела время в чудесной компании из 10-ти человек (сама 11-ая).
Почему «уууууух!»? Потому что группа была – ого-го!
Коллеги, вы выжали из меня все соки (в хорошем смысле этого слова)!
Три дня были настолько насыщенными в плане общения, потоков информации, позитива, что бодрый заряд энергии не иссякает до сих пор!

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

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

Всем и каждому в отдельности (Саша Сидоров, Саша Бурдейный, Инна Пантелеева, Галина Репникова, Ерсаин Шалаев, Максим Иванов, Оля Уваркина, Алексей Трофимов, Николай и Николай (ломаю голову, вспоминая фамилии , если напомните - добавлю) ) – большое спасибо!

Хочется верить, что вы потратили время с пользой!

З.Ы. По итогам курса будет слегка сокращен теоретический материал и добавлено еще немного практики.
З.З.Ы. Фото нашей работы можно посмотреть здесь.

Всегда ваша,
Наташа Густыр

На Урале тоже тестируют софт

2008-12-23T12:32:00.005+02:00

«Наташа, Вы у нас первая связь с внешним миром»
Александр Москвин, слушатель

Зима выдалась насыщенной на курсы по тестированию.
Декабрь начался с Екатеринбурга.
8-10 декабря я провела в этом славном городе за работой – читала свой родной курс «Введение в тестирование ПО».

Группа на этот раз состояла из 6-ти человек, все из которых работают в одной компании.

Чем хороши корпоративные курсы:
• Ориентируешься на одинаковые нужды слушателей;
• Можно поближе познакомиться изнутри с разными видами бизнеса, и посмотреть, чем и как живут в них тестировщики;
• Есть больше возможностей помочь решить реальные проблемы.

Какие есть недостатки у корпоративных курсов:
• Слушатели могут не задавать вопросов или задавать их очень мало. О причинах могу только догадываться:
o Стесняются друг друга
o Если не поняли чего-то, то думают: «Ай, потом спрошу у кого-нибудь из наших. Кто-то наверняка понял.»
o что-то еще?..
• Слушатели продолжают время от времени отвлекаться по рабочим вопросам

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

Каждый раз перед началом курса я интересуюсь у слушателей на предмет их ожиданий от курса, чтобы более гибко подходить к подаче материала, и делать акценты на тех разделах, которые в большей степени интересуют группу.
В этот раз пожелания были сформулированы довольно широко и расплывчато. Например, «Узнать что-то новое…», «Практика есть, хотелось бы знать, как это называется в теории…», «Узнать о тестировании больше…», «Посмотреть, как это делают другие…».
Если посмотреть в целом, то все перечисленные ожидания были удовлетворены. Хочется надеяться, что и не высказанные ожидания тоже хотя бы частично, но покрылись.

Теперь несколько слов о каждом участнике группе…
• Виктория была в группе звеном, следящим за дисциплиной и, наверное, чаще других выступала связистом между подаваемым материалом и реальной работой.
• Ксения помогала структурировать материал предыдущего дня и будила группу от утреннего сна.
• Светлана самый молодой и еще не определившийся со своим отношением к тестированию специалист, но очень бодрая и активная участница процесса.
• Александр Гнатюк оказался самым «живым» и самым шустрым тестировщиком.
• Александр Москвин вносил свои корректные дополнения и предложения, навеянные многолетним опытом работы.
• Наталья была в нашей группе критиком, без ее резких замечаний некоторые вопросы просто не могли бы быть рассмотрены с разных сторон.

Хочу пожелать всей группе успехов в работе! Разумного применения полученных знаний и навыков! И профессионального роста и развития!

P.S. Надеюсь на ваше прощение по поводу задержки с публикацией отчета – рвалась на части между другими командировками и работой…
P.P.S. Александр и Александр, я не перепутала ваши фамилии? :)
P.P.P.S. Остальные фотографии можно посмотреть здесь.

Всегда ваша,
Наташа Густыр

Интервью на www.software-testing.ru

2008-12-11T18:05:00.005+02:00

Это еще отголоски конференции SQA Days 2008 в Минске.
После окончания конференци мне выпал шанс пообщаться в совершенно свободной атмосфере с нашими коллегами из других городов. Одним из них был Алексей Баранцев - ныне главный редактор ресурса www.software-testing.ru

Уже в завершении вечера Алексей спросил: "Наташа, а, может, скажешь несколько слов о конференции для ресурса?"
Я с удовольствием согласилась.
Алексей достал диктофон - и началось :)

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

Собственно, вот и само

"Интервью с Натальей Густыр на SQA Days 2008 Minsk".

Сегодня мы публикуем интервью с Натальей Густыр, менеджером проектов компании Qulix Systems. Наталья входила в состав оргкомитета и была ведущей секции тестирования на конференции SQA Days 2008 Minsk. Но поскольку интервью состоялось сразу же после окончания конференции, впечатления были ещё слишком свежи, так что мы решили задать вопросы, не связанные с конференцией.

Расскажи о себе, как ты попала в тестирование? Что тебе понравилось или не понравилось в тестировании?

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

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

На тот момент я работала на радиостанции, занималась продажами – продавала рекламное время, но с каждым днем я все больше и больше ненавидела свою работу. И меня постоянно посещали мысли о том, что я отучилась в университете, имею высшее математическое образование, а занимаюсь какой-то низкоквалифицированной ерундой. И почему бы мне не пойти работать в какую-нибудь IT-компанию, чтобы использовать, наконец, свои знания по назначению. Но чем там заниматься? Кроме программирования, я вообще не представляла себе, чем можно заниматься в IT-компании. Но я не видела себя программистом, поэтому ясно осознавала, что этот путь для меня закрыт.
Но у меня была подруга, которая уже попробовала работать тестировщиком. Она-то мне и посоветовала: «Наташа, не переживай! Рассылай резюме на тестировщика – сейчас всех берут». Я подала резюме, и буквально на следующий день меня пригласили на собеседование. Собеседование проводили два молодых человека с горящими глазами: мой нынешний генеральный директор и директор отдела качества. Один из них нарисовал формочку и предложили мне составить максимальное количество тестов. Я с легкостью выполнила это задание, даже пыталась спорить в какой-то момент! На вопрос, знаю ли я что такое тестирование, я ответила, что не знаю, но предполагаю, что я должна искать дефекты, т.е. смотреть, как работает программа, и если она где-то сломалась, значит, это дефект, вот собственно этим я и должна буду заниматься. Меня взяли, помучив ожиданиями дней пару.

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

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

Мы знаем, что ты читаешь курсы по тестированию в Москве. Почему именно в Москве, почему не в Минске?

Корни преподавательской деятельности в Москве идут от нашей компании. Ещё до моего прихода в Qulix Systems, компания уже сотрудничала с московским обучающим центром компании Интерфейс. Некоторые сотрудники, включая нашего генерального директора, читали свои курсы в Москве. Изначально курсы были связаны с инструментами Rational.

А я в какой-то момент поняла, что хочу делиться с коллегами теми знаниями и навыками, которые успела приобрести. Так родились несколько внутренних семинаров, которые как-то очень удачно сложились в курс. Так что когда меня пригласили прочитать курс «Введение в тестирование ПО», у меня не было никаких сомнений, что всё получится.

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

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

Мы долгое время вели переговоры с ВУЗами, и не так давно наконец-то пришли к соглашению. Я буду читать курсы в БГУИР уже с нового года, а также на мех-мате БГУ проведу несколько занятий, чтобы заинтересовать студентов в дальнейшем обучении.

Несколько слов о конференции?

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

Спасибо!

Молоток существует!

2008-12-11T16:56:00.019+02:00

Друзья, в одном из своих постов, я писала о том, какой замечательный мотивационный инструмент есть у меня в команде - это МОЛОТОК!

Вы просили фото? Пожалуйста! :)

(молоток. вид сверху)

(молоток в руке разработчика. боевое состояние)

Всегда ваша,
Наташа Густыр

SQA Days 2008 - полная версия флипа "Использование MS Excel в качестве унифицированного хранилища данных для автоматизированных тестов"

2008-12-10T23:06:00.014+02:00

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

Аннотация

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

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 Анализ полученного результата

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

С уважением,
Сергей Талалаев

Курс "Основы функционального тестирования с использованием инструментов IBM Rational"

2008-12-06T17:23:00.006+02:00

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

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

Курс получился очень полным с точки зрения реализации не только основного обязательного материала, но и дополнительных практик и методов накопленных за время работы с данными продуктами (и не только с ними). Хотел бы отметить, что я сам получил огромное удовольствие от работы с ТАКОЙ группой.

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

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

С уважением,
Сергей Талалаев

Урок 6: Работайте с программистами сообща

2008-12-05T11:52:00.000+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр

Поддержка программистов – это, наверное, ключевая часть вашей миссии. Когда вы тестируете вещи, которые программисты разрабатывают прямо сейчас, или недавно разработали, ваши отзывы помогут им работать более эффективно. Когда они что-то доставляют, вы тестируйте это. Когда они вносят какое-либо изменение, вы тестируйте это изменение. Ставьте перед собой цель предоставлять обратную связь наиболее коротким и быстрым путем. Пока программисты «пережевывают» баги, которые вы только что нашли, вы свободны для того, чтобы искать еще больше новых багов. Идеальная ситуация (для тестировщиков) – это та, в которой разработчики заняты исправлением проблем настолько, что вы можете явно дать понять, кто в проекте – узкое место (они, а не вы!).

Урок 238: Нанимайте людей, которые любят свою работу

2008-11-25T22:01:00.001+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

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

Урок 244: После принятия решения - оперативно завершайте процедуру найма

2008-11-24T23:54:00.003+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

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

Молоток для тестировщика, или Один из способов формирования дружеской атмосферы в команде

2008-11-21T11:55:00.003+02:00

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

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

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

Например, в моей нынешней команде ситуация решается вот таким забавным образом.
Однажды моему техлиду на День Рождения подарили молоток (!). И не простой молоток, а резиновый! - очень по-дружески...
Молотком этим пользуется вся команда разработки. Инструкция по использованию такая:
1) Если вы не довольны работой тестировщика, не злитесь, возьмите молоток в руки.
2) Подойдите к тестировщику с улыбкой на лице и молотком за спиной.
3) С этой же неизменной добродушной улыбкой достаньте молоток из-за спины и аккуратно положите его рядом с тестировщиком.
4) Придвиньте стул, сядьте и, продолжая мило улыбаться, спросите "Так что у нас не работает?"
Не поверите - либо все сразу заработает, либо очень быстро и безболезненно удастся разобраться.

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

Найдите и вы свой "молоток"!

Всегда ваша,
Наташа Густыр

SQA Days 2008 - второй фотоотчет!

2008-11-20T19:40:00.003+02:00

Вторая партия фотографий конференции - вашему вниманию!
Смотреть здесь.

Всегда ваша,
Наташа Густыр

it4business.ru - не только для бизнеса

2008-11-20T19:18:00.003+02:00

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

И первым в этом списке стал ресурс www.it4business.ru

Что вы можете найти на ресурсе:
- Новинки ИТ-отрасли
- Статьи различных специалистов
- Пресс-релизы
- Информация об обучении в отрасли ИТ
- Блоги и форум
- Вакансии
- Интересные исследования
- и многое-многое другое

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

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

Тестирование - студентам!

2008-11-20T17:57:00.002+02:00

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

Первое - это лекция по тестированию на механико-математическом факультете Белгосуниверситета!

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

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

Правда, связкам тяжело :)
50 человек - это вам не шутки!

Но и это еще не все!
Сегодня я говорила с деканом одного из факультетов другого не менее рейтингового ВУЗа нашей страны - Белгосуниверситет Информатики и Радиоэлектроники.
Приняли решенеие о сотрудничестве!
Со следующего семестра начинаю читать курс по тестированию - студентам!

Всегда ваша,
Наташа Густыр

SQA Days 2008 - первый фотоотчет!

2008-11-19T13:39:00.006+02:00

Наконец появились первые фотографии конференции!
Смотреть здесь .

Всегда ваша,
Наташа Густыр

По следам SQA Days 2008

2008-11-18T13:34:00.006+02:00

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

Наконец-то свершилось! - скажу я вам.

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

Из отзывов наших московских друзей:
"Для меня было непривычно, что все сидят и слушают докладчиков! Я во время доклада вышел в коридор, а там - пусто! Мы привыкли активно общаться у флип-чартов, по интересам" - удивленно говорит Алексей Баранцев, главный редактор www.software-testing.ru

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

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

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

Хочется сказать огромное спасибо всем коллегам из ближнего и дальнего зарубежья, которые нашли возможность приехать, и не просто приехать, а еще и выступить с докладами. Среди них:
- Юля Нечаева, NIX Solutions, Харьков, Украина
- Андрей Кощеев, HP, Прага, Чехия
- Александр Орлов, Happy-PM.com, Санкт-Петербург, Россия
- Алексей Баранцев, ИСП РАН, Москва, Россия
- Александр Ихелис, Епам, Будапешт, Венгрия
- Сергей Гринкевич, Росгосстрах, Москва, Россия
- Павел Коноплицкий, UsabilityLab, Москва, Россия
- Дмитрий Ручко, ИнфоТеКС, Москва, Россия
- Дмитро Подзываловский, BOSSdev, Симферополь, Украина

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

Продолжение следует...

Всегда ваша,
Наташа Густыр

Курс "Введение в тестирование ПО" - еще раз +1

2008-11-10T18:46:00.004+02:00

В очередной раз (5-7 ноября) я прочитала свой курс "Введение в тестирование ПО" в обучающем центре Интерфейс (г. Москва).
Очень хорошая, внимательная, трудолюбивая и ответственная группа.
Сочетали приятное с полезным: обсуждали серьезные вопросы и шутили.
Работать было одно удовольствие.

Вперед! К новым знаниям!
Еще и еще!

P.S. Следующий курс планируется на 17-19 декабря.

Всегда ваша,
Наташа Густыр

Урок 68: Не игнорируйте очевидные дефекты

2008-11-10T18:30:00.005+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко

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

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

Участие в конференции SQA Days 2008 в качестве докладчиков

2008-10-30T14:25:00.007+02:00

Наталья Густыр

В статье Ханса Шафера "Что должен знать тестировщик в любое время, даже ночью" в переводе Андрея Конушина есть раздел 4 "Постоянное изучение", который заканчивается словами "... и посещайте конференции по тестированию".
Мы тоже придерживаемся этого правила, поэтому с удовольствием посетим конференцию по тестированию и обеспечению качества ПО SQA Days 2008 в Минске.

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

- Наташа Густыр является одним из организаторов конференции и будет выступать с докладом "Вырасти себе тестировщика".

Мировой финансовый кризис оказывает значительное влияние на работу IT-компаний: сокращается количество потенциальных проектов и, соответственно, повышается конкуренция. В таких условиях компании вынуждены обратить особое внимание на обеспечение конкурентного преимущества, чтобы выжить и остаться на плаву. Приходится снижать ставки, и на первое место выходит продуктивность и эффективность работы каждого сотрудника. Решение проблемы заключается, с одной стороны, в оптимизации процессов работы компании и, с другой стороны, в развитии персонала.
Для того, чтобы процессы повышения продуктивности работы, обучения и развития были эффективными, они должны быть измеримыми. Для этого необходимо иметь точку отсчета.
За точку отсчета разумно принять оценку текущего состояния организации в целом и каждого сотрудника в частности.
В докладе рассматривается только одна сторона вопроса – тема оценки, аттестации, обучения и развития тестировщиков силами компании или силами внешних экспертов.

- Сергей Талалаев выступит с докладом "Использование MS Excel в качестве унифицированного хранилища данных для автоматизированных тестов".

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

- Оля Балашенко выступит с докладом "Причины "пожара" на проектах".

«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования.
Данный доклад – попытка ответить на вопрос «Почему тестировщики не укладываются в сроки?». Причем, оценка причин осуществляется как с позиции руководителя группы тестировщиков, который принимает участие в планировании тестирования, так и с позиции тестировщика, выполняющего задачи.
Акцент в докладе делается на разбор причин увеличения сроков, но также затрагивается тема предотвращения «пожаров».

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

Урок 237: Найм по согласованию

2008-10-27T22:41:00.003+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

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

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

Урок 9: Вы не найдете все баги

2008-10-27T19:06:00.001+02:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр

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

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

Урок 19: Тестирование находится в вашей голове

2008-10-24T18:52:00.001+03:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр

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

Урок 67: Регистрируйте дефекты сразу же после обнаружения

2008-10-24T17:33:00.001+03:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко

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

Урок 66: Никогда не используйте систему регистрации дефектов для оценки эффективности работы тестировщиков

2008-10-24T13:11:00.014+03:00

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко

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

Lessons Learned in Software Testing

2008-10-21T23:18:00.005+03:00

В недавнем прошлом нам повезло держать в руках книгу – мечту каждого тестировщика!
Авторы 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 урока за раз. И только после того, как вы осмыслите прочитанное, можно приступать к дальнейшему чтению. Мы, беспрекословно следуя советам авторов, не будем торопиться и соблюдать порядок уроков…

Наталья Густыр

Впервые в Минске пройдет Международная конференция специалистов в области обеспечения качества ПО SQA Days-2008

2008-10-20T19:59:00.003+03:00

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 г.

* По решению оргкомитета сроки могут быть сдвинуты ближе к дате проведения конференции

Вас приветствует команда SQAdotBy

2008-10-20T18:50:00.013+03:00

Добрый день, дорогие друзья, уважаемые коллеги!

Команда 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.
Соавтор курса «Введение в автоматизированное функциональное тестирование программного обеспечения».
Читает курс в Беларуси (Минск) и России (Москва).

Виктория Головнева