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

Предлагаю закончить с системами стандартизации :)
Чтобы не складывалось ощущение, что на ГОСТ-ах, 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."
Спасибо, Алексей!

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

Read more...

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

И снова здравствуйте!
Предлагаю продолжить обозревать системы стандартизации. И на этот раз вашему вниманию предлагается 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

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


Read more...

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

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




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

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

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

Read more...

BYSTQB быть!!!

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


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

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

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

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

Read more...

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

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

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

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

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

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

Read more...

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

Доброго времени суток, коллеги.
Снова вернемся к стандартам - на этот раз пройдемся по 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

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

Read more...

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

Автор: 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. Использование автоматизации в качестве средства выявления ошибок


Read more...

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

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

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


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

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

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

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

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

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

А вот и полезные ссылки, касающиеся ГОСТ-ов по разработке ИС, АС, ПС:
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/

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


Read more...

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

Уважаемые коллеги, последовательно продвигаясь к светлой цели (перенос мировой столицы тестирования в Минск, если кто забыл) предлагаем вашему вниманию очередную порцию информации о такой известной организаци как Международная коллегия тестировщиков (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/


Read more...

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

Для меня слово справочник прочно ас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-файл со всеми реализованными в статье примерами.


Read more...

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

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

Можно!


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

Порция 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. Большое спаисбо также нашим Российским колегам за бережно собранную информацию.

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


Read more...

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

Друзья, мы сами поздно узнали, поэтому поздно делимся информацией с вами.
Однако, еще есть шанс успеть сдать экзамен на сертификат 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.

Спешите!
Read more...

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

Выражаю огромную благодарность всем интернет-источникам, специалистам, ведущим блоги и участвующих в обсуждениях на форумах, всей перечитанной литературе, и особенно Алексею Баранцеву за научный подход к тестированию и вообще, и Сергею Орлику за его перевод 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)
* и др...

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

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

Read more...

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

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

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

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

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

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

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

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

Read more...

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

Автор: 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), которыми должен руководствоваться инженер автоматизации при реализации требуемого кода.

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

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


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


3. В-третьих, 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) в проекте автоматизации относительно поддерживаемости, читаемости, масштабируемости, расширяемости и тестируемости. Следующие статьи расширят данную тему и покажут читателям, как получить выигрыш от реализации в фреймворке других шаблонов проектирования, помимо изложенных в рамках этой статьи.


Read more...