Предлагаю закончить с системами стандартизации :)
Чтобы не складывалось ощущение, что на ГОСТ-ах, 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...
Показаны сообщения с ярлыком sqa. Показать все сообщения
Показаны сообщения с ярлыком sqa. Показать все сообщения
понедельник, 6 июля 2009 г.
четверг, 2 июля 2009 г.
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...
четверг, 11 июня 2009 г.
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 июня 2009 г.
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...
Представляю вашему вниманию информацию, собранную из разных источников, сгруппированную и слегка обработанную.
Возможно, для кого-то она будет полезной...
ГОСТ (Государственный стандарт) — одна из основных категорий стандартов в СССР, сегодня межгосударственный стандарт в СНГ. Принимается Межгосударственным советом по стандартизации, метрологии и сертификации (МГС).
В советские времена все ГОСТ являлись обязательными для применения в тех областях, которые определялись преамбулой самого стандарта.
Стандарт имеет силу (если не заменён национальным стандартом) в следующих странах:
* Азербайджанская Республика
* Республика Армения
* Республика Беларусь
* Республика Грузия
* Республика Казахстан
* Киргизская Республика
* Республика Молдова
* Российская Федерация
* Республика Таджикистан
* Туркменистан
* Республика Узбекистан
* Украина
Национальный стандарт РБ - СТБ.
Национальный орган по стандартизации - Комитет по стандартизации, метрологии и сертификации при Совете Министров Республики Беларусь.
А вот и полезные ссылки, касающиеся ГОСТ-ов по разработке ИС, АС, ПС:
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...
пятница, 15 мая 2009 г.
Стандарты, модели, методологии - краткий обзор
Выражаю огромную благодарность всем интернет-источникам, специалистам, ведущим блоги и участвующих в обсуждениях на форумах, всей перечитанной литературе, и особенно Алексею Баранцеву за научный подход к тестированию и вообще, и Сергею Орлику за его перевод 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...
пятница, 8 мая 2009 г.
Читайте нас в Quality Matters, Issue 2
Немного с опозданием, но хочу поделиться с вами очередной приятной новостью!
Во 2-м выпуске журнала Quality Matters напечатали мою статью по развитию и обучению тестировщиков.
Второй выпуск журнала можно скачать здесь.
Постараемся не останавливаться на достигнутом! ;)
Присоединяйтесь!
Всегда ваша,
Наташа Искорцева (Густыр)
Read more...
понедельник, 2 февраля 2009 г.
Сертификация: За и Против
Пора!
Пора и мне, наконец, сказать, что я думаю по поводу сертификации тестировщиков и как я себе ее вижу.
Начну с хорошего.
1. Как и любое обучение, подготовка к сертификации немного дисциплинирует. На это нужно, как бы вы не сопротивлялись, отводить свое драгоценное время, будь то рабочее или внерабочее, когда при других обстоятельствах вы могли бы занять это время чем-то более интересным.
2. Сертификация помогает систематизировать знания. Особенно тем, кто не приобретал профессию тестировщика в университетах, а постигал все это на практике. Знаете, это как в школе: вам рассказывают уйму материала, например, по математике в течение 11 лет, но вы так и не можете понять, что, с чем и как связано. Вроде бы и по системе преподают, а системы в знаниях нет как таковой. И только когда вы начинаете готовиться к экзаменам, когда задачи затрагивают перекрестные темы, только тогда вы начинаете видеть и понимать, что к чему (хотя, тоже не все). Точно так же и здесь: у вас уже много практических навыков, а при подготовке к сертификации вы начинаете связывать их в логическую цепочку, понимаете, что и какими словами правильно называется в теории.
3. Сертификация позволяет приобрести дополнительные теоретические знания (хотелось бы подчеркнуть - теоретические). Как бы там ни было, даже если вы прочитали миллион книг и статей, то при подготовке к сертификации вы, если и не сделаете для себя открытие в теории, то, по крайней мере, услышите чье-то другое мнение по некоторым аспектам изучаемой области, другой взгляд на те же вещи.
4. Иногда сертификат может помочь при принятии на работу: либо обрести позицию повыше, либо попросить денег побольше.
5. Международная сертификация позволяет специалисты во всем мире говорить на одном профессиональном языке, а также по одной шкале оценивать знания.
Всего, что описано выше, можно добиться и другими методами. Однако, речь не об этом.
А теперь немного горькой пилюли.
1. Сертификации бывают разные… К сожалению, не всякой сертификации можно доверять (а можно ли вообще хоть какой-то?). Глупые вопросы, ни коим образом не проверяющие даже знание теории, не могут быть показателем уровня специалиста.
2. К сожалению, с помощью сертификации, если и можно что-то оценить, то это только теоретические знания, но никак не навыки. И, если практика без теории всего лишь слепа, то теория без практики, как известно, мертва. Думаю, мало кому в команде нужен чистой воды теоретик...
3. Точно так же, как сертификат иногда помогает найти лучшую работу, он может и затруднить ее поиски. Я, например, знакома с системным архитектором, имеющим целый ряд сетрификатов и по девелопменту, и по менеджменту, но не способному настроить Windows-сервис по инструкции.
Есть мнение, что, не имея достаточно аргументов, чтобы доказать свой профессионализм, люди стараются получить как можно больше сертификатов. Поэтому к обилию сетрификатов я отношусь более, чем скептически :)
В заключение хочу сказать, что сертификат можно получать только в случае необходимости или острого желания иметь таковой. А вот какой-то экстраординарной пользы я от них не вижу.
Всегда ваша,
Наташа Густыр
Read more...
Пора и мне, наконец, сказать, что я думаю по поводу сертификации тестировщиков и как я себе ее вижу.
Начну с хорошего.
1. Как и любое обучение, подготовка к сертификации немного дисциплинирует. На это нужно, как бы вы не сопротивлялись, отводить свое драгоценное время, будь то рабочее или внерабочее, когда при других обстоятельствах вы могли бы занять это время чем-то более интересным.
2. Сертификация помогает систематизировать знания. Особенно тем, кто не приобретал профессию тестировщика в университетах, а постигал все это на практике. Знаете, это как в школе: вам рассказывают уйму материала, например, по математике в течение 11 лет, но вы так и не можете понять, что, с чем и как связано. Вроде бы и по системе преподают, а системы в знаниях нет как таковой. И только когда вы начинаете готовиться к экзаменам, когда задачи затрагивают перекрестные темы, только тогда вы начинаете видеть и понимать, что к чему (хотя, тоже не все). Точно так же и здесь: у вас уже много практических навыков, а при подготовке к сертификации вы начинаете связывать их в логическую цепочку, понимаете, что и какими словами правильно называется в теории.
3. Сертификация позволяет приобрести дополнительные теоретические знания (хотелось бы подчеркнуть - теоретические). Как бы там ни было, даже если вы прочитали миллион книг и статей, то при подготовке к сертификации вы, если и не сделаете для себя открытие в теории, то, по крайней мере, услышите чье-то другое мнение по некоторым аспектам изучаемой области, другой взгляд на те же вещи.
4. Иногда сертификат может помочь при принятии на работу: либо обрести позицию повыше, либо попросить денег побольше.
5. Международная сертификация позволяет специалисты во всем мире говорить на одном профессиональном языке, а также по одной шкале оценивать знания.
Всего, что описано выше, можно добиться и другими методами. Однако, речь не об этом.
А теперь немного горькой пилюли.
1. Сертификации бывают разные… К сожалению, не всякой сертификации можно доверять (а можно ли вообще хоть какой-то?). Глупые вопросы, ни коим образом не проверяющие даже знание теории, не могут быть показателем уровня специалиста.
2. К сожалению, с помощью сертификации, если и можно что-то оценить, то это только теоретические знания, но никак не навыки. И, если практика без теории всего лишь слепа, то теория без практики, как известно, мертва. Думаю, мало кому в команде нужен чистой воды теоретик...
3. Точно так же, как сертификат иногда помогает найти лучшую работу, он может и затруднить ее поиски. Я, например, знакома с системным архитектором, имеющим целый ряд сетрификатов и по девелопменту, и по менеджменту, но не способному настроить Windows-сервис по инструкции.
Есть мнение, что, не имея достаточно аргументов, чтобы доказать свой профессионализм, люди стараются получить как можно больше сертификатов. Поэтому к обилию сетрификатов я отношусь более, чем скептически :)
В заключение хочу сказать, что сертификат можно получать только в случае необходимости или острого желания иметь таковой. А вот какой-то экстраординарной пользы я от них не вижу.
Всегда ваша,
Наташа Густыр
Read more...
среда, 28 января 2009 г.
Дебаты вокруг сертификации тестировщиков
И снова здравствуйте! :)
И сразу, как говорится, вопрос в лоб:
Коллеги, а многие ли среди ваших знакомых тестировщиков имеют сертификаты?
А многие ли хотят иметь?
А многие ли столкнулись с необходимостью их иметь?
А как вы относитесь к сертифицированным специалистам?
Как ни странно, но тема сертифицирования тестировщиков очень актуальна в последнее время...
Писали об этом уже и Алесей Баранцев в статье "Какие сертификаты нужны тестировщикам",
и Александр Орлов в статье "Шашечки или ехать". Кстати, надо сказать, что в голосовании, которое устроил тот же Александр Орлов наблюдается весьма интересная картина по результатам...
А ваше мнение какое?
Кстати сказать, я тоже имею что сказать на этот счет, но скажу буквально очень скоро :)
Всегда ваша,
Наташа Густыр
Read more...
И сразу, как говорится, вопрос в лоб:
Коллеги, а многие ли среди ваших знакомых тестировщиков имеют сертификаты?
А многие ли хотят иметь?
А многие ли столкнулись с необходимостью их иметь?
А как вы относитесь к сертифицированным специалистам?
Как ни странно, но тема сертифицирования тестировщиков очень актуальна в последнее время...
Писали об этом уже и Алесей Баранцев в статье "Какие сертификаты нужны тестировщикам",
и Александр Орлов в статье "Шашечки или ехать". Кстати, надо сказать, что в голосовании, которое устроил тот же Александр Орлов наблюдается весьма интересная картина по результатам...
А ваше мнение какое?
Кстати сказать, я тоже имею что сказать на этот счет, но скажу буквально очень скоро :)
Всегда ваша,
Наташа Густыр
Read more...
среда, 14 января 2009 г.
SQA days 2008: текст доклада "Причины пожара на проектах"
Мы уже писали о выступлении на конференции SQA days и обещали опубликовать свои доклады. Наташа и Сергей сдержали обещание. Теперь моя очередь :) Я постаралась максимально приблизить печатную версию к устной, чтобы сохранить дух "живого" выступления.
«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования. Данный доклад - попытка ответить на вопрос: «Почему тестировщики не укладываются в сроки?».
Недавно мне «посчастливилось» принимать участие в проекте, на котором отставание от сроков – обычное дело. Сразу хочу пояснить, что я понимаю под отставанием от сроков. Это разница между реально потраченным и запланированным временем (см. рисунок 1).
В докладе рассматриваются причины невыполнения в срок задач тестовой команды, хотя многое из того, о чём будет говориться ниже, актуально для любых проектных активностей.
Несколько слов о проекте, который вдохновил меня на подготовку этого доклада. Проект был сложный… :) Причём, я сейчас говорю не о сложности задач, которые стояли перед нашей командой, а о сложной структуре проекта. На рисунке 2 представлена схема этого проекта, где З1...З8 – задачи, из которых состоит реализация проекта, К1…К8 – компании (подрядчики), которые принимают участие в проекте. Как видно, каждый подрядчик отвечает за свою задачу. И даже заказчик выполняет часть работ по созданию программного обеспечения.
Многое из того, о чём пойдёт речь дальше, навеяно именно этим сложным проектом, но также я использовала опыт участия в более простых проектах (Рисунок 3).
Думаю, понятно, что вероятность «пожаров» на проектах со сложной структурой больше. Естественно, здесь много зависимостей. Если один из подрядчиков на начальном этапе не уложился в сроки, то «поплывут» даты в планах у остальных компаний-подрядчиков. На сложном проекте часто возникает ситуация: «а это не я». Это когда на выявление ошибки уходит час, а на выявление ответственного за неё тратятся дни или даже недели. Каждая компания пытается сделать крайним кого-то другого. Такая проблема обычно возникает из-за плохой организации взаимодействия между участниками проекта и нечёткого разграничения обязанностей.
Теперь непосредственно о самих причинах. Одна из самых очевидных причин «пожаров» - нереальные сроки. Как эти «нереальные» сроки появляются? Например, заказчик говорит: «нужно, чтобы эта функциональность (F1...Fn) была готова к такому-то числу». И тут начинается попытка уместить всю требуемую функциональность в указанные сроки (хотя бы в плане проекта, который потом не соответствует действительности). В данном случае ошибка в том, что не исполнитель оценивает временные затраты, а заказчик устанавливает дату. Если времени для реализации требуемой функциональности явно недостаточно, то нужно выбирать: или урезанная функциональность в указанные сроки или смещение сроков для реализации полного объёма задач.
Также часто я наблюдала пожары, когда требования менялись в ходе проекта. Если не переписать план в связи с изменением требований, то вероятность своевременного окончания проекта невелика :)
Для тестировщиков, которые выполняют задачи по уже составленному менеджером плану, часто очень актуальной проблемой становится неполный учёт задач в плане. Например, часто забывают о том, что уходит время на новичков, на помощь разработчикам в воспроизведении дефектов, на подготовку тестовых данных, на подготовку внеплановых отчётов для руководства. Плохой анализ требований и спецификации может привести к тому, что в тест-кейсах будут присутствовать не все проверки, а, следовательно, будет неправильно оценено время на тестирование. Даже одна пропущенная строка в спецификации может послужить искрой, из которой вырастет пожар. Например, в требованиях сказано: «Система должна работать под ОС Win 98, 2000, XP, Vista». Если в тест-кейсах об этом нет ничего, то тестирование будет проводиться на любой доступной тестировщику ОС (XP, например). Дальше заказчик начинает принимать Систему (на 98-й, например) – и начинается… Неожиданные ошибки, перепроверка Приложения на всех требуемых ОС, исправление дефектов и т.д. Пожар на лицо :)
Допустим, оценка временных затрат проводилась компанией – разработчиком (а не заказчиком), в плане учтены все задачи ориентируясь на абстрактного среднестатистического тестировщика. Вроде, всё хорошо. Но и здесь могут возникнуть проблемы. Не все тестировщики одинаковые. У них может быть разная квалификация. Здесь можно рассмотреть несколько случаев:
– человек просто плохой работник: или он делает всё слишком медленно (гораздо медленнее, чем среднестатистический сотрудник отдела тестирования), или делает быстро, но так, что доверять результатам нельзя, или и то, и другое... Т.е. человек не на своём месте.
– новичок в профессии (в компании, на проекте) – понятно, что человеку нужно время на адаптацию, и его не сразу можно считать полноценным ресурсом.
– неправильных подбор персонала на проект или неправильное распределение задач внутри тестовой команды на проекте. Например, человек всё время занимался тестированием десктоповских приложений, и тут его назначают на тестирование приложений для мобильных технологий. Понятно, что нужно время на то, чтобы вникнуть в предметную область. Или другой пример: тестировщика, который всегда занимался мануальным тестированием, назначают на проект по автоматизации тестирования. Т.е. при назначении людей на проект и при распределении задач внутри команды тест-менеджер должен учитывать сильные и слабые стороны своих подчинённых. НО: нельзя всегда выдавать человеку однотипные задачи только потому, что он хорошо их выполняет. Рано или поздно тестировщику станет скучно :)
Как правило, задачи в планах плавно перетекают одна в другую, т.е. между ними нет перерывов. Но ведь часто возникают вынужденные простои. Например, увеличение сроков анализа, разработки и других предшествующих тестированию этапов ведёт к простою команды тестирования. Ещё одна причина простоя - блокирующая критическая ошибка, до исправления которой тестировать невозможно или нет смысла. Недоступность приложения также блокирует работу тестировщика. Причины недоступности приложения:
– недоступен сам сервер (сгорел, на нём проводят профилактические работы, например, увеличивают кол-во памяти);
– идёт установка новой версии приложения;
– на тестовой платформе разработчики проводят исследования и эксперименты;
– на тестовой платформе проводится нагрузочное тестирование;
– на тестовой платформе проводится приёмочное тестирование заказчиком.
Т.е. здесь возникает проблема взаимодействия команд тестирования, разработки, внедрения. Сюда же можно отнести проблему коммуникации между участниками проекта, которые находятся далеко друг от друга: в разных странах, а ещё хуже, в разных часовых поясах. Здесь увеличивается время на обсуждения и принятие решений. Также существует проблема «свободного» графика работы, который так популярен в IT сфере. Допустим, в команде есть носитель «тайных знаний», без которого «работа стоит». Если этот «тайный носитель» любит поспать, то плохо дело :) Нужно или передавать знания (а ещё лучше оформить их в виде документации), или договариваться о более строгом графике работы.
И в заключение причины «пожаров», которые предусмотреть сложно – это форс-мажорные обстоятельства. Например, авария на серверах, отсутствие электричества, отсутствие тестировщика на рабочем месте (заболел, уволился и т.п.).
Естественно, я не перечислила всех возможных причин отставаний от запланированных сроков. Главное, о чём я хотела рассказать: нельзя надеяться на то, что всё будет идти идеально. Хотя надеяться можно, но «соломку лучше подстелить», т.е. заложить в план риски. Нужно тщательно проанализировать тип проекта, его размеры и структуру, оценить команду и составить адекватный план, по которому будет комфортно работать. Не будет лишних переживаний ни у Вас, ни у заказчика :)
С Уважением,
Ольга Балашенко
Read more...
«Горящий» проект – не редкость в IT сфере. Отставание от плана может возникать на разных стадиях: от инициализации проекта до тестирования. Данный доклад - попытка ответить на вопрос: «Почему тестировщики не укладываются в сроки?».
Недавно мне «посчастливилось» принимать участие в проекте, на котором отставание от сроков – обычное дело. Сразу хочу пояснить, что я понимаю под отставанием от сроков. Это разница между реально потраченным и запланированным временем (см. рисунок 1).
В докладе рассматриваются причины невыполнения в срок задач тестовой команды, хотя многое из того, о чём будет говориться ниже, актуально для любых проектных активностей.
Несколько слов о проекте, который вдохновил меня на подготовку этого доклада. Проект был сложный… :) Причём, я сейчас говорю не о сложности задач, которые стояли перед нашей командой, а о сложной структуре проекта. На рисунке 2 представлена схема этого проекта, где З1...З8 – задачи, из которых состоит реализация проекта, К1…К8 – компании (подрядчики), которые принимают участие в проекте. Как видно, каждый подрядчик отвечает за свою задачу. И даже заказчик выполняет часть работ по созданию программного обеспечения.
Многое из того, о чём пойдёт речь дальше, навеяно именно этим сложным проектом, но также я использовала опыт участия в более простых проектах (Рисунок 3).
Думаю, понятно, что вероятность «пожаров» на проектах со сложной структурой больше. Естественно, здесь много зависимостей. Если один из подрядчиков на начальном этапе не уложился в сроки, то «поплывут» даты в планах у остальных компаний-подрядчиков. На сложном проекте часто возникает ситуация: «а это не я». Это когда на выявление ошибки уходит час, а на выявление ответственного за неё тратятся дни или даже недели. Каждая компания пытается сделать крайним кого-то другого. Такая проблема обычно возникает из-за плохой организации взаимодействия между участниками проекта и нечёткого разграничения обязанностей.
Теперь непосредственно о самих причинах. Одна из самых очевидных причин «пожаров» - нереальные сроки. Как эти «нереальные» сроки появляются? Например, заказчик говорит: «нужно, чтобы эта функциональность (F1...Fn) была готова к такому-то числу». И тут начинается попытка уместить всю требуемую функциональность в указанные сроки (хотя бы в плане проекта, который потом не соответствует действительности). В данном случае ошибка в том, что не исполнитель оценивает временные затраты, а заказчик устанавливает дату. Если времени для реализации требуемой функциональности явно недостаточно, то нужно выбирать: или урезанная функциональность в указанные сроки или смещение сроков для реализации полного объёма задач.
Также часто я наблюдала пожары, когда требования менялись в ходе проекта. Если не переписать план в связи с изменением требований, то вероятность своевременного окончания проекта невелика :)
Для тестировщиков, которые выполняют задачи по уже составленному менеджером плану, часто очень актуальной проблемой становится неполный учёт задач в плане. Например, часто забывают о том, что уходит время на новичков, на помощь разработчикам в воспроизведении дефектов, на подготовку тестовых данных, на подготовку внеплановых отчётов для руководства. Плохой анализ требований и спецификации может привести к тому, что в тест-кейсах будут присутствовать не все проверки, а, следовательно, будет неправильно оценено время на тестирование. Даже одна пропущенная строка в спецификации может послужить искрой, из которой вырастет пожар. Например, в требованиях сказано: «Система должна работать под ОС Win 98, 2000, XP, Vista». Если в тест-кейсах об этом нет ничего, то тестирование будет проводиться на любой доступной тестировщику ОС (XP, например). Дальше заказчик начинает принимать Систему (на 98-й, например) – и начинается… Неожиданные ошибки, перепроверка Приложения на всех требуемых ОС, исправление дефектов и т.д. Пожар на лицо :)
Допустим, оценка временных затрат проводилась компанией – разработчиком (а не заказчиком), в плане учтены все задачи ориентируясь на абстрактного среднестатистического тестировщика. Вроде, всё хорошо. Но и здесь могут возникнуть проблемы. Не все тестировщики одинаковые. У них может быть разная квалификация. Здесь можно рассмотреть несколько случаев:
– человек просто плохой работник: или он делает всё слишком медленно (гораздо медленнее, чем среднестатистический сотрудник отдела тестирования), или делает быстро, но так, что доверять результатам нельзя, или и то, и другое... Т.е. человек не на своём месте.
– новичок в профессии (в компании, на проекте) – понятно, что человеку нужно время на адаптацию, и его не сразу можно считать полноценным ресурсом.
– неправильных подбор персонала на проект или неправильное распределение задач внутри тестовой команды на проекте. Например, человек всё время занимался тестированием десктоповских приложений, и тут его назначают на тестирование приложений для мобильных технологий. Понятно, что нужно время на то, чтобы вникнуть в предметную область. Или другой пример: тестировщика, который всегда занимался мануальным тестированием, назначают на проект по автоматизации тестирования. Т.е. при назначении людей на проект и при распределении задач внутри команды тест-менеджер должен учитывать сильные и слабые стороны своих подчинённых. НО: нельзя всегда выдавать человеку однотипные задачи только потому, что он хорошо их выполняет. Рано или поздно тестировщику станет скучно :)
Как правило, задачи в планах плавно перетекают одна в другую, т.е. между ними нет перерывов. Но ведь часто возникают вынужденные простои. Например, увеличение сроков анализа, разработки и других предшествующих тестированию этапов ведёт к простою команды тестирования. Ещё одна причина простоя - блокирующая критическая ошибка, до исправления которой тестировать невозможно или нет смысла. Недоступность приложения также блокирует работу тестировщика. Причины недоступности приложения:
– недоступен сам сервер (сгорел, на нём проводят профилактические работы, например, увеличивают кол-во памяти);
– идёт установка новой версии приложения;
– на тестовой платформе разработчики проводят исследования и эксперименты;
– на тестовой платформе проводится нагрузочное тестирование;
– на тестовой платформе проводится приёмочное тестирование заказчиком.
Т.е. здесь возникает проблема взаимодействия команд тестирования, разработки, внедрения. Сюда же можно отнести проблему коммуникации между участниками проекта, которые находятся далеко друг от друга: в разных странах, а ещё хуже, в разных часовых поясах. Здесь увеличивается время на обсуждения и принятие решений. Также существует проблема «свободного» графика работы, который так популярен в IT сфере. Допустим, в команде есть носитель «тайных знаний», без которого «работа стоит». Если этот «тайный носитель» любит поспать, то плохо дело :) Нужно или передавать знания (а ещё лучше оформить их в виде документации), или договариваться о более строгом графике работы.
И в заключение причины «пожаров», которые предусмотреть сложно – это форс-мажорные обстоятельства. Например, авария на серверах, отсутствие электричества, отсутствие тестировщика на рабочем месте (заболел, уволился и т.п.).
Естественно, я не перечислила всех возможных причин отставаний от запланированных сроков. Главное, о чём я хотела рассказать: нельзя надеяться на то, что всё будет идти идеально. Хотя надеяться можно, но «соломку лучше подстелить», т.е. заложить в план риски. Нужно тщательно проанализировать тип проекта, его размеры и структуру, оценить команду и составить адекватный план, по которому будет комфортно работать. Не будет лишних переживаний ни у Вас, ни у заказчика :)
С Уважением,
Ольга Балашенко
Read more...
понедельник, 5 января 2009 г.
Перевод глоссария ISTQB на русский язык
Проект реализован силами участников портала Software-Testing.RU, в числе которых нахожусь и я, Наташа Густыр, под руководством Сергея Гринкевича.
Также готовый перевод Глоссария можно найти здесь. Авторами этого перевода является рабочая группа RSTQB в составе трех человек:
Андрей Конушин (Россия)
Алексей Александров (Россия)
Александр Александров (Россия)
Read more...
пятница, 21 ноября 2008 г.
Молоток для тестировщика, или Один из способов формирования дружеской атмосферы в команде
Ни для кого не секрет, что зачастую отношения между разработчиками и тестироващиками оставляют желать лучшего. Одни считаются создателями (разработчики), а другие разрушителями (соответственно, тестировщики).
Разработчики порой очень остро реагируют на найденные в их коде ошибки, на невоспроизводимое описание ошибки и особенно на те ошибки, которые таковыми не являются (например, зарегистрировано, что какая-то функция не работает, а на деле оказывается, что тестировщик не произвел каких-либо настроек или неправильно собрал билд, или что-то еще...)
Подобного рода казусы вызывают гнев у разработчиков и они начинают отчаянно поливать грязью своих коллег-тестировщиков. Как этого избежать?
Один из способов - относиться к этому с юмором, если только подобного рода ситуации не являются признаком непрофессионализма вашего тестировщика. Помните - всем свойственно ошибаться.
Например, в моей нынешней команде ситуация решается вот таким забавным образом.
Однажды моему техлиду на День Рождения подарили молоток (!). И не простой молоток, а резиновый! - очень по-дружески...
Молотком этим пользуется вся команда разработки. Инструкция по использованию такая:
1) Если вы не довольны работой тестировщика, не злитесь, возьмите молоток в руки.
2) Подойдите к тестировщику с улыбкой на лице и молотком за спиной.
3) С этой же неизменной добродушной улыбкой достаньте молоток из-за спины и аккуратно положите его рядом с тестировщиком.
4) Придвиньте стул, сядьте и, продолжая мило улыбаться, спросите "Так что у нас не работает?"
Не поверите - либо все сразу заработает, либо очень быстро и безболезненно удастся разобраться.
P.S. А тот смех, который возникает у всех членов команды и окружающих при виде молотка очень положительно сказывается на общем бодром и дружеском настроении и взаимоотношениях в коллективе!
Найдите и вы свой "молоток"!
Всегда ваша,
Наташа Густыр
Read more...
Разработчики порой очень остро реагируют на найденные в их коде ошибки, на невоспроизводимое описание ошибки и особенно на те ошибки, которые таковыми не являются (например, зарегистрировано, что какая-то функция не работает, а на деле оказывается, что тестировщик не произвел каких-либо настроек или неправильно собрал билд, или что-то еще...)
Подобного рода казусы вызывают гнев у разработчиков и они начинают отчаянно поливать грязью своих коллег-тестировщиков. Как этого избежать?
Один из способов - относиться к этому с юмором, если только подобного рода ситуации не являются признаком непрофессионализма вашего тестировщика. Помните - всем свойственно ошибаться.
Например, в моей нынешней команде ситуация решается вот таким забавным образом.
Однажды моему техлиду на День Рождения подарили молоток (!). И не простой молоток, а резиновый! - очень по-дружески...
Молотком этим пользуется вся команда разработки. Инструкция по использованию такая:
1) Если вы не довольны работой тестировщика, не злитесь, возьмите молоток в руки.
2) Подойдите к тестировщику с улыбкой на лице и молотком за спиной.
3) С этой же неизменной добродушной улыбкой достаньте молоток из-за спины и аккуратно положите его рядом с тестировщиком.
4) Придвиньте стул, сядьте и, продолжая мило улыбаться, спросите "Так что у нас не работает?"
Не поверите - либо все сразу заработает, либо очень быстро и безболезненно удастся разобраться.
P.S. А тот смех, который возникает у всех членов команды и окружающих при виде молотка очень положительно сказывается на общем бодром и дружеском настроении и взаимоотношениях в коллективе!
Найдите и вы свой "молоток"!
Всегда ваша,
Наташа Густыр
Read more...
понедельник, 20 октября 2008 г.
Впервые в Минске пройдет Международная конференция специалистов в области обеспечения качества ПО SQA Days-2008
4-я Международная конференция специалистов в области обеспечения качества ПО SQA Days-2008 впервые пройдёт в столице Республики Беларусь, Минске, 17 ноября 2008 г. в Международном образовательном центре - IBB (пр-т Газеты Правда, 11) при поддержке Парка высоких технологий и Инфопарка. Организатором мероприятия выступает компания SQALab (г. Москва), в качестве генерального партнера - компания EPAM Systems, в качестве золотого партнера - Exigen Services, в качестве со-организатора - Белорусский Государственный Университет Информатики и Радиоэлектроники (БГУИР). Информационную поддержку оказывают компании Qulix Systems, HeadHunter, edu)ITOnline, Текама, крупнейшие интернет-порталы рунета и байнета, а также тематические ИТ-СМИ Беларуси.
Конференция посвящена вопросам функционального тестирования, тестирования производительности, автоматизации тестирования, выбора и использования инструментальных средств, конфигурационного тестирования, тестирования удобства использования (usability) и защищенности, статических методов обеспечения качества, а также особенностям внедрения тестирования на предприятии, управления процессами обеспечения качества ПО, вопросам менеджмента команд тестировщиков и инженеров качества ПО и другим сферам интересов QA-специалистов.
Идея собрать вместе заинтересованных специалистов и обменяться опытом в сфере тестирования ПО созрела в 2007 году на площадке московской компании "Кворум". После обсуждений был выбран наилучший формат такого общения - открытая встреча, в которой могли принять участие все желающие. Так возник круг конференций под общим названием "Software Quality Assurance Days" (SQA Days).
На данный момент SQA Days - это одно из крупнейших событий в сфере современных информационных технологий в области обеспечения качества ПО на постсоветском пространстве, которое объединяет ведущих специалистов международного уровня. В 2008 году SQA Days впервые будет проводиться на территории Республики Беларусь (три предыдущие конференции проводились в Москве).
На SQA Days-2008 в Минске планируется обобщить накопленный международный опыт в области обеспечения качества и создать платформу сотрудничества для реализации совместных проектов в сферах тестирования, предполагающей возможность для каждого специалиста обмена информацией и повышения уровня образования по актуальным вопросам.
Конференция пройдет под эгидой IT-CONF.RU - ресурса, объединяющего высококачественные конференции для ИТ-специалистов на территории СНГ, а также стран ближнего и дальнего зарубежья. Формат мероприятия - один день. По итогам конференции будет издан сборник докладов. На официальном сайте конференции будут размещены тезисы докладов и видеоролики с записями выступлений.
4-я Международная конференция специалистов в области обеспечения качества SQA Days-2008 будет интересна специалистам по тестированию и обеспечению качества программных систем, разработчикам, аналитикам, техническим писателям, архитекторам систем, руководителям среднего и высшего звена, а также всем заинтересованным лицам.
"Современный рынок белорусских информационных технологий привлекает внимание всего европейского сообщества не только благодаря наличию сильных традиций белорусской ИТ-школы. В последнее время точкой притяжения становятся широкие возможности белорусских айтишников для реализации крупных высокотехнологичных проектов мирового масштаба. Этот потенциал нужно активно использовать, поэтому для 4-ой Международной конференции SQA Days-2008 Минск был выбран не случайно. Идея организовать конференцию такого уровня в Беларуси созрела у меня давно. Кроме того, мне всегда импонировала теплая и одновременно деловая атмосфера белорусского ИТ-сообщества, высокий уровень профессионализма белорусских специалистов и их свежий взгляд на актуальные вопросы тестирования и обеспечения качества ПО", - прокомментировал выбор места проведения конференции Владислав Орликов, председатель оргкомитета SQA Days-2008, генеральный директор компании SQALab, Москва, Россия.
Получить полную информацию о программе SQA Days-2008 и подать заявку на участие для слушателей, докладчиков и потенциальных партнеров можно на официальном сайте конференции http://www.it-conf.ru/
Последний срок подачи заявки на участие в форме доклада - 24 октября 2008 г.
Последний срок подачи тезисов докладов - 26 октября 2008 г.
Последний срок подачи слайдов презентаций и текстов докладов - 02 ноября 2008 г.
Последний срок оплаты участия (не докладчики) - 10 ноября 2008 г.
* По решению оргкомитета сроки могут быть сдвинуты ближе к дате проведения конференции
Read more...
Вас приветствует команда SQAdotBy
Добрый день, дорогие друзья, уважаемые коллеги!
Команда SQAdotBy в составе 4-х человек рада приветствовать вас на нашей профессиональной площадке!
Мы, Наталья Густыр, Сергей Талалев, Ольга Балашенко и Виктория Головнева, будем рады поделиться с вами своими мыслями и идеями, касающимися нашей сферы деятельности - тестирования и обеспечения качества программных продуктов!
Несколько слов о нас:
Наталья Густыр
Ведущий QA специалист, менеджер проектов, руководитель направления обучения, преподаватель-консультант компании Qulix Systems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования и QA – 5 лет, в области преподавания – 3 года.
Автор курса "Введение в тестирование ПО" и семинаров "Взаимодействие команд разработки и тестирования", "Карьера тестировщика" и "Откровения тестировщика".
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург, Екатеринбург), Казахстане (Астана, Алматы).
Сергей Талалаев
Куратор направления автоматизации тестирования, преподаватель-консультант.
Преподаватель учебного центра «Интерфейс», Москва.
Области специализации: IBM/Rational: Robot, FT, Test Manager; HP/Mercury: WinRunner, LoadRunner, QTP; FreeWare: Grinder, Watir.
Опыт работы в сфере автоматизации – 7 лет. Опыт преподавания – 5 лет.
Автор курса «Введение в автоматизированное нагрузочное тестирование программного обеспечения». Соавтор курса «Основы функционального тестирования с использованием инструментов IBM Rationa.
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург), Казахстане (Астана).
Ольга Балашенко
Ведущий специалист по мануальному и автоматизированному тестированию компании QulixSystems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования – 4 года.
Опыт автоматизации тестирования для проектов различного уровня сложности с использованием следующих средств автоматизации: HP/Mercury WinRunner, HP/Mercury QTP, Segue Silk Test, IBM/Rational Robot.
Соавтор курса «Введение в автоматизированное функциональное тестирование программного обеспечения».
Читает курс в Беларуси (Минск) и России (Москва).
Виктория Головнева
Read more...
Команда SQAdotBy в составе 4-х человек рада приветствовать вас на нашей профессиональной площадке!
Мы, Наталья Густыр, Сергей Талалев, Ольга Балашенко и Виктория Головнева, будем рады поделиться с вами своими мыслями и идеями, касающимися нашей сферы деятельности - тестирования и обеспечения качества программных продуктов!
Несколько слов о нас:
Наталья Густыр
Ведущий QA специалист, менеджер проектов, руководитель направления обучения, преподаватель-консультант компании Qulix Systems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования и QA – 5 лет, в области преподавания – 3 года.
Автор курса "Введение в тестирование ПО" и семинаров "Взаимодействие команд разработки и тестирования", "Карьера тестировщика" и "Откровения тестировщика".
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург, Екатеринбург), Казахстане (Астана, Алматы).
Сергей Талалаев
Куратор направления автоматизации тестирования, преподаватель-консультант.
Преподаватель учебного центра «Интерфейс», Москва.
Области специализации: IBM/Rational: Robot, FT, Test Manager; HP/Mercury: WinRunner, LoadRunner, QTP; FreeWare: Grinder, Watir.
Опыт работы в сфере автоматизации – 7 лет. Опыт преподавания – 5 лет.
Автор курса «Введение в автоматизированное нагрузочное тестирование программного обеспечения». Соавтор курса «Основы функционального тестирования с использованием инструментов IBM Rationa.
Читает курсы в Беларуси (Минск), России (Москва, Санкт-Петербург), Казахстане (Астана).
Ольга Балашенко
Ведущий специалист по мануальному и автоматизированному тестированию компании QulixSystems, Минск.
Преподаватель учебного центра «Интерфейс», Москва.
Опыт в области тестирования – 4 года.
Опыт автоматизации тестирования для проектов различного уровня сложности с использованием следующих средств автоматизации: HP/Mercury WinRunner, HP/Mercury QTP, Segue Silk Test, IBM/Rational Robot.
Соавтор курса «Введение в автоматизированное функциональное тестирование программного обеспечения».
Читает курс в Беларуси (Минск) и России (Москва).
Виктория Головнева
Read more...
Подписаться на:
Сообщения (Atom)
