SlideShare ist ein Scribd-Unternehmen logo

Метрики автоматизированного тестирования на пальцах

•Als PPTX, PDF herunterladen•
•
SQALab
SQALab

Доклад Антона Семенченко на конференции SQA Days-19, 20-21 мая 2016 г., Санкт-Петербург

Bildung
1 von 126
Anton Semenchenko Метрики Автоматизированного тестирования на пальцах
About  Организатор сообществ www.COMAQA.BY и www.CoreHard.by, учередитель компании www.DPI.Solutions, «хитрый» менеджер в EPAM Systems. Почти 15 лет опыта в IT, основная специализация: Автоматизированное тестирование, разработка на С++ и ниже, менеджмент, продажи.
Agenda, part 1 (введение) • QA и QC • Определение понятия метрика • Потенциальные сложности • Где взять данные для рассчета метрик? • Алгоритм трансформации данных в информацию • Источники данных для рассчета метрик • Взаимосвязь метрик • Светофор – метрик • Эквалайзер - метрик • «Пожарные» метрики
Agenda, part 2 (основная) • 3 вида классификации метрик • Классификация с точки зрения тех специалистов • Классификация с точки зрения бизнеса • Классификация с точки зрения менеджмента на стороне исполнителя • Важность классификации • Стандартные QA Риски как вариант классификации метрик • 2 вида проектов • Ниболее популярные метрики АТ • Метрики – пожарные извещатели • Ниболее популярные метрики общие как для Ручного, так и для Автоматизированного тестирования • Метрики личной эффективности
Agenda, part 3 (заключение) • «Увлекательные» истории • “Актуальность” информации • “Источники” информации • “Take away” points • Что дальше? • «Внеклассное чтение»
QA и QC • Контроль качества (QC) — это измерение параметров качества продукта • Обеспечение качества (QA) – это измерение и управление качеством процесса (включая метрики), который используется для создания качества продукта (или качественного продукта).
Метрика • Метрика программного обеспечения — мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций. • Метрика – как механизм обратной связи • Том ДеМарко, «вы не можете контролировать то, что не можете измерить».
Потенциальные сложности • Что такое качество тестирования? • Не тривиальный вопрос, очень комплексное понятие. • Успеваем ли мы уложиться в проектные ограничения? • Дата Релиза • Бюджет
Потенциальные сложности • Как можно улучшить процесс тестирования и разработки ПО в целом? • Успешна ли АТ, текущий статус АТ, не отклонились ли мы от намеченной траектории • И многие другие
Где взять данные? • Этот вопрос регулярно задают не только молодые, но и опытные специалисты. Пример: фактически, значимая часть панельной дискусии на конференции CodeFest 2016, посвященная метрикам тестирования, была сфокусирована на вопросе «Где взять данные?»
Трансформация • Трансформация: • Данные • => • Информация (фильтрация данных) • => • Визуализация информации (сложение, вычитание, деление) • => • Работа с «Трендом» • Примеры: • Биржа • Любой BigData проект
Где взять данные? • Test Plan • Test Reports • Continues Integration (CI) • Bug Tracking Systems • Task Tracking Systems • Test Management Systems (TMS) • Test Strategy • Другие источники
Взаимосвязь метрик
Светофор - метрик • Светофор – как способ максимально быстро получить актуальную высокоуровневую информацию о проекте. Многие метрики можно и нужно использовать в стиле «светофор». • Красный – надо срочно обратить детальное внимание • Желтый – в зависимости от загруженности, либо обратить поверхностное внимание лично, либо дерелировать эту активность • Зеленый – не требует вмешательствавнимания
Эквалайзер - метрик • The power of music (Metrics )
«Пожарные» метрики
«Пожарные» метрики • Если процесс разработки и тестирования ПО налажен – вероятность того, что проект будет успешно реализован приемлемо высока. • Если же процесс разработки и тестирования ПО не эффективен – что бы мы ни делали, какими бы замечательными отдельные показатели не были, проект прочти наверняка «провалится». • «Пожарные» метрики + принцип светофора + принцип эквалайзера – дают гарантию того, что процесс разработки приемлемо высокого качества.
Классификация (IT stuff) • Классификация по «областям» • Качество Продукта (Quality) • Прогресс той или иной активности в тестировании (Progress) • Покрытие (Coverage) • Цена / время (Cost / time) • Процесс обеспечения качества и разработки в целом (Process)
Классификация (Business) • Классификация «Что должно быть исправлено в первую очередь» • Качество Продукта (Quality) • Время тестирования продукта / впуска продукта (Time) • Стоимость тестирования продукта (Costs/efforts) • Прозрачность тестирования продукта (Testing visibility) • Автоматизация тестирования (Test automation approach)
К-я менеджмента • Классификация менеджмента • Метрики – пожарные извещатели • Все остальные метрики
3 варианта классификации? • Классификация с точки зрения технического специалиста / исполнителя • Классификация с точки зрения заказчика • Классификация с точки зрения менеджмента • Любая классификация не идеальна и рассматривает «поблемную» область под определенным углом зрения • Метрика – инструмент • А классификация – инструмент для эффективной работы с инструментом-метрикой
Важность классификации
2 вида проектов? • Outsourcing • Own product development
Метрики АТ • Процент тестов, поддающихся автоматизации (ППА) • Прогресс автоматизации (ПА) • Процент покрытия автоматизированными тестами (ПП АТ) • Частота проведения регрессии (ЧР) • Стабильность Автоматизированных Тестов (САТ) • Колличество дефектов, на Автоматизированный Тест (ДАТ)
Метрики АТ • Окно автоматизации тестирования • Окно анализа результатов тестирования • Время на создание автоматизированного теста • Время на поддержку автоматизированного теста • Экономическая целесообразность АТ (ROI)
% т, поддающихся А (ППА) • Определение • Процент тестов, поддающихся автоматизации = # тест кейсов которые можно автоматизировать (ПА) / # общее количество тест кейсов (ОТК) • «Физический смысл» • Отражает адаптированность приложения к автоматизированному тестированию с точки зрения технологий и архитектуры
% т, поддающихся А (ППА) • Границы • Для большинства относительно новых приложений этот параметр, как правило, превышает 90% • Где взять информацию • Информация получается на базе тест-плана и экспертной оценки
% т, поддающихся А (ППА) • Примеры • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • Mature Secure VPN (Russian), технологический стек; • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • MS и Google;
% т, поддающихся А (ППА) • Визуализация • Более 90% - зеленый цвет • От 70% до 90% - желтый цвет • Менее 70% - красный цвет • Связь с другими метриками • Прогресс автоматизации (ПА) • Процент покрытия автоматизированными тестами (ПП АТ) • Категория: • Качество • Автоматизация тестирования
Прогресс А (ПА) • Определение • Прогресс автоматизации (ПА) = # количество автоматизированных на данный момент тест кейсов (АТК) / # общее количество тест кейсов автоматизации (ОАТК) • «Физический смысл» • Отражение статуса во времени для понимания достижимости или недостижимости поставленных целей • Как много тест кейсов команда покрыла Автоматизацией в течении последней итерации (Sprint, Release)? Способ убедиться в том, что текущий прогресс позволяет достичь намеченных целей до Deadline-а
Прогресс А (ПА) • Границы • Границы: 0 – 100% • Где взять информацию • Test Plan • Test Reports • Continues Integration (CI) • Test Management Systems (TMS)
Прогресс А (ПА) • Примеры • Mature Secure VPN (Russian), технологический стек;
Прогресс А (ПА) • Визуализация • Круговая диаграмма (2 типа): • Общее колличество запланированных для Автоматизации тестов к уже реализованным • Общее колличество запланированных часов к уже использованному
Прогресс А (ПА) • Связь с другими метриками • Процент покрытия автоматизированными тестами (ПП АТ); • Колличество найденных дефектов на Автоматизированный тест; • Окно Автоматизации Тестирования; • Окно Анализа результатов; • Экономическая целесообразность АТ (ROI); • Категория: • Прогресс • Автоматизация тестирования
% покрытия АТ (coverage) • Определение • Процент покрытия автоматизированными тестами (ПП АТ) = Покрытие автоматизированными тестами (ПАТ) / Общее покрытие (ОП) (KLOC, FP, etc.) • Метрику можно «интерпретировать» очень по- разному
% покрытия АТ (ПП АТ) • «Физический смысл» • Данная метрика помогает выявить, насколько «эффективна» / «разумна» автоматизация. • Выявить, какие тесты стоит Автоматизировать в первую очередь (например, начать со Smoke и Regression, если эти тест кейсы достаточно формализованы) и сравнить с текущим покрытием (подразумевается что АТ запускаются регулярно и выявляют дефекты). • Удостовериться, в том, что Автоматизированные тесты проверяют именно то, что должны проверять.
% покрытия АТ (ПП АТ) • Границы • Границы: 0 – 100% • Где взять информацию • Test Reports • Continues Integration (CI) • Test Management Systems (TMS)
% покрытия АТ (ПП АТ) • Примеры • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • MS and Windows Millennium • Data Protection Giant and Automation
% покрытия АТ (ПП АТ) • Визуализация • Термин test coverage matrix и traceability matrix взаимозаменяемы в большинстве случаев • Karen Johnson's использовать trace matrix как индикатор test coverage. • Связь с другими метриками • Процент покрытия автоматизированными тестами (ПП АТ); • Прогресс Автоматизации • Категория: • Покрытие • Автоматизация тестирования
Частота регрессии (ЧР) • Определение • Частота проведения регрессии (ЧР) = Как часто проводится автоматизированная регрессия? • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
Частота регрессии (ЧР) • Границы • Широкораспространенные границы / рекомендации: o smoke - каждую ночь o full-regression - каждые выходные • Где взять информацию • Automation reports • Continuous Integration (CI)
Частота регрессии (ЧР) • Примеры • ЧР и Экономическая целесообразность АТ (ROI); • Facebook и Bamboo • Kanban, ЧР, опыт WG • Доведенные до «абсолюта» «рекоммендации» • «Окно commit-а»
Частота регрессии (ЧР) • Визуализация • Не реже чем 1 раз в неделю - зеленый цвет • Не реже чем 1 раз в 2 недели - желтый цвет • Реже чем 1 раз в месяц - красный цвет • Чаще чем раз в день - красный цвет • Связь с другими метриками • Экономическая целесообразность АТ (ROI); • Окно автоматизации тестирования; • Окно анализа результатов тестирования; • “Окно commit-а“ • Категория: • Качество • Автоматизация тестирования
Стабильность АТ • Определение • Стабильность Автоматизированных тестов = процент тестов, которые либо успешно проходят либо падают, по причине нахождения дефекта • «Физический смысл» • Отражает качество автотестов и соответствие их текущему состоянию тестируемой системы
Стабильность АТ • Границы • Цель – процент «случайных» падений не превышает 5% • Где взять информацию • Test Reports
Стабильность АТ • Примеры • Множество проектов; • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
Стабильность АТ • Визуализация • Более 95% - зеленый цвет • Более 90%, менее 95% - желтый цвет • Менее 90% - красный цвет • Связь с другими метриками • Колличество дефектов на Автоматизированный тест • Категория: • Качество / Процесс • Автоматизация тестирования
# дефектов на АТ • Определение • Колличество дефектов на Автоматизированный Тест = ведется подсчет дефектов, как Автоматизированных, так и Ручных; • Если Автоматизированное тестирование не находит дефектов или лишь незначительное колличество дефектов, то: • Выделить области Автоматизации для улучшения; • Репреоретизировать усилия в Автоматизации; • Отказаться от Автоматизации;
# дефектов на АТ • «Физический смысл» • Отражает эффективность автотестов с точки зрения нахождения дефектов • Границы • Отсутствие найденных дефектов может являться индикатором неудачного фокуса автотестов • Где взять информацию • Test Reports
# дефектов на АТ • Примеры • Множество проектов; • Стандартная «проблема» Автоматизации ради Автоматизации • Стандартная «проблема» получения прибыли исполнителем в ущерб заказчику
# дефектов на АТ • Визуализация • Более 5% (минимальный процент зависит от фазы и деталей проекта) - зеленый цвет • От 1 до 5% - желтый цвет • Менее 1% - красный цвет • Связь с другими метриками • Стабильность Автоматизированных тестов • Категория: • Качество / Процесс • Автоматизация тестирования
«Окно» АТ • Определение • «Окно» Автоматизированного тестирования – как много физического времени занимает прогон Автоматизированных тестов (полное или подмножество) • «Окно» Автоматизированного тестирования – как много системного «лабороторного» времени занимает прогон Автоматизированных тестов (полное или подмножество)
«Окно» АТ • «Физический смысл» • Время, требуемое для прогона автотестов необходимо учитывать при оценке экономической эффективности автоматизации, при анализе ROI и сравнении с ручным тестированием. Метрика необходима как при принятии решения о целесообразности внедрения автоматизации, так и при оценке текущего состояния уже реализованной автоматизации с целью выявления узких мест.
«Окно» АТ • Границы • В зависимости от размера проекта может занимать от нескольких до многих часов. Как правило, Smoke после commit-а должен занимать не более часа, полная Регрессия не более двух дней (выходные) • Где взять информацию • Test Reports • Continuous Integration (CI)
«Окно» АТ • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Контр пример – физическое время • Контр пример – машинное время (Claud) • Технические детали: Stateless и Statefull Автоматизация, параллельный запуск • Технические детали: Эффективные ожидания • Технические детали: Преждевременная оптимизация
«Окно» АТ • Визуализация • Smoke <= 1 час, Full Regression <= 12 часов (ночь) - зеленый цвет • Smoke <= 2 часа, Full Regression <= 2 дня (выходные) - желтый цвет • Smoke > 2 часа, Full Regression > 2 дня (выходные) - красный цвет
«Окно» АТ • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
«Окно» анализа р-тов АТ • Определение • «Окно» анализа результатов Автоматизированного Тестирования = Сколько времени требуется чтобы проанализировать полученные данные? • «Физический смысл» • Метрика показывает, насколько исчерпывающими и читабильными являются отчеты. При слишком большом окне анализа меньше времени будет уделяться фактическому написанию тестов, или анализ будет проводиться недостаточно тщательно, что обесценит value Автоматизации
«Окно» анализа р-тов АТ • Границы • В зависимости от размера проекта может занимать от нескольких минут до многих часов. Как правило, анализ результатов Smoke тестов после commit - должен занимать считанные минуты, анализ результатов полной Регрессии – должен занимать считанные часы, в идеале, меньше часа. • Где взять информацию • Test Reports • Continuous Integration (CI) • Task Tracking Systems
«Окно» анализа р-тов АТ • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • Mature Secure VPN (Russian), технологический стек; • Контрпримеры
«Окно» анализа р-тов АТ • Визуализация • Smoke <= 10 минут, Full Regression <= 2 часа - зеленый цвет • Smoke <= 20 минут, Full Regression <= 4 часа - желтый цвет • Smoke > 20 минут, Full Regression > 4 часов - красный цвет
«Окно» анализа р-тов АТ • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
t разработки АТ-а • Определение • Среднее время разработки Автоматизированного Теста = # всех автоматизированных тестов / время на создание • «Физический смысл» • Информация о времени на разработку одного теста помогает при расчете ROI, является одним из важнейших стоимостных показателей при внедрении автоматизации. Позволяет оценить издержки и потенциальную прибыль от введения автоматизации на проекте
t разработки АТ-а • Границы • Границы: 1-16 часов на тест, в зависимости от сложности сценария, применяемых технологий (как в разработке приложения, так и в автоматизации), среднее время «по-больнице» 4 часа. • Где взять информацию • Task Tracking System
t разработки АТ-а • Примеры • Множество проектов • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
t разработки АТ-а • Визуализация • Менее 4 часов- зеленый цвет • Менее 8 часов, но более 4 часов - желтый цвет • Более 8 часов - красный цвет • Связь с другими метриками • Время на поддержку автоматизированного теста • Экономическая целесообразность АТ (ROI) • Категория: • Цена / время • Автоматизация тестирования
t поддержки АТ-а • Определение • Среднее время уделяемое поддержке Автоматизированного Теста в течении указанного периуда времени = # всех автоматизированных тестов / время на поддержку.
t поддержки АТ-а • «Физический смысл» • Любой программный продукт при работе по agile-методологиям особенно осклонен к изменчивости, соответственно адаптироваться под эту изменчивость должны и автотесты. Время, необходимое на доработку и адаптацию тестов, выделяется за счет времени на разработку новых тестов, а значит, чем выше этот показатель, тем хуже, тем меньше времени астается на другие активности. Высокий показатель данной метрики может быть индикатором того, что в автоматизации не были применены оптимальные архитектурные паттерны или вспомогательные программные инструменты.
t разработки АТ-а • Границы • Границы: от 0.5 часа на тест в год, до ... чуть ли не бесконечности (заниматься тонкой балансировкой Sleep-ов можно сколько угодно – стабилизация так и не наступит) ... Безусловно конкретные показатели зависят от множества факторов – стабильности требований, стабильности приложения, технологического стека – как приложения, так и автоматизации, но время не должно превышать 4 часов в большиснтве случаев. • Где взять информацию • Task Tracking System
t разработки АТ-а • Примеры • Множество проектов • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
t разработки АТ-а • Визуализация • Менее 0,5 часа на тест в год - зеленый цвет • Не более 1 часа на тест в год - желтый цвет • Более 2 часов на тест в год - красный цвет • Связь с другими метриками • Время на поддержку автоматизированного теста • Экономическая целесообразность АТ (ROI) • Категория: • Цена / время • Автоматизация тестирования
ROI (out of scope, but ) • Определение • Экономическая целесообразность Автоматизированного Тестирования (ROI) = Manual efforts – (Automation efforts + Automation investment) / QA investment * 100% • «Физический смысл» • Указывает на то, имеет ли смысл внедрять автоматизацию тестирования на данном проекте в данный момент. Может оказаться, что при определенных условиях автоматизация тестирования окажется экономически нецелесообразной, поскольку ручное тестирование даже в долгосрочной перспективе может оказаться дешевле.
ROI • Границы • Out of scope • Где взять информацию • Test Strategy • Test Plan • Test Management Systems (TMS)
ROI • Примеры • Множество проектов • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
ROI (+ доп выгоды) • Визуализация • Сравнение трендов • Ручное тестирование • Целый вариант опций введения / развития Автоматизированного тестирования • Выбор оптимальной команды-тренда здесь и сейчас
ROI • Связь с другими метриками • Процент тестов, поддающихся автоматизации (ППА) • Частота проведения регрессии (ЧР) • Стабильность Автоматизированных Тестов (САТ) • Окно автоматизации тестирования • Окно анализа результатов тестирования • Время на создание автоматизированного теста • Время на поддержку автоматизированного теста • Категория: • Цена / время • Автоматизация тестирования
Пожарные извещатели • Частота проведения регрессии (ЧР) - fire • % проанализированных тестов в Test Report-е • % ошибок / дефектов приложения • % ошибок Автоматизации Тестирования • % системных ошибок • «Окно» Автоматизированного тестирования (Время выполнения) - fire • Окно анализа результатов тестирования - fire
Частота регрессии (ЧР) - fire • Определение • Частота проведения регрессии как пожарный извещатель (ЧР) = Как часто проводится автоматизированная регрессия? • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
Частота регрессии (ЧР) - fire • Границы • Широкораспространенные границы / рекомендации: o smoke - каждую ночь o full-regression - каждые выходные • Где взять информацию • Automation reports • Continuous Integration (CI)
Частота регрессии (ЧР) - fire • Примеры • ЧР и Экономическая целесообразность АТ (ROI); • Facebook и Bamboo • Kanban, ЧР, опыт WG • Доведенные до «абсолюта» «рекоммендации» • «Окно commit-а»
Частота регрессии (ЧР) - fire • Визуализация • Не реже чем 1 раз в неделю - зеленый цвет • Не реже чем 1 раз в 2 недели - желтый цвет • Реже чем 1 раз в месяц - красный цвет • Чаще чем раз в день - красный цвет • Связь с другими метриками • Экономическая целесообразность АТ (ROI); • Окно автоматизации тестирования; • Окно анализа результатов тестирования; • “Окно commit-а“ • Категория: • Качество • Автоматизация тестирования
% of TA results analyzed - fire • Определение • Процент проанализированных негативных результатов запуска Автоматизированных тестов. Если негативные результаты не проанализированны, Автоматизация не принесла никакой пользы 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = TI / (PB+AB+SI+TI)
% of TA results analyzed - fire • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
% of TA results analyzed - fire • Границы • % >95% (в идеале, 100%) – зеленый • 85% <% < 95% – желтый • %<= 85 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
% of TA results analyzed - fire • Визуализация • % >95% – зеленый • 85% <% < 95% – желтый • %<= 85 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of product issues • % of automation issues • % of system issues
% of product issues - fire • Определение • Важно понимать как много дефектов находит Автоматизированное Тестирование, а так же процентное соотношения найденных дефектов к общему колличеству ложных срабатываний, что показывает стабильность Автоматизации 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = PB / (PB+AB+SI+TI)
% of product issues - fire • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
% of product issues - fire • Границы • 5% > % (в идеале, 0) – зеленый • 10% > % > 5% – желтый • % >= 10 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
% of product issues - fire • Визуализация • 5% > % – зеленый • 10% >% > 5% – желтый • % >= 10 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of TA results analyzed • % of automation issues • % of system issues
% of automation issues - fire • Определение • Важно понимать как много Автоматизированных тестов падает в силу ошибок самих тестов, а так же процентное соотношене ложный падений в силу ошибок в тесте к общему колличеству ложных срабатываний, что показывает корректность Автоматизации 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = AB / (PB+AB+SI+TI)
% of automation issues - fire • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
% of automation issues - fire • Границы • 5% > % (в идеале, 0) – зеленый • 10% > % > 5% – желтый • % >= 10 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
% of automation issues - fire • Визуализация • 5% > % – зеленый • 10% >% > 5% – желтый • % >= 10 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of TA results analyzed • % of product issues • % of system issues
% of system issues • Определение • Важно понимать как много Автоматизированных тестов падает в силу не стабильности окружения, а так же процентное соотношене ложный падений в силу проблем окружения к общему колличеству ложных срабатываний, что показывает корректность окружения 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = SI / (PB+AB+SI+TI)
% of system issues • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
% of system issues • Границы • 5% > % (в идеале, 0) – зеленый • 10% > % > 5% – желтый • % >= 10 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
% of system issues • Визуализация • 5% > % – зеленый • 10% >% > 5% – желтый • % >= 10 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of TA results analyzed • % of product issues • % of automation issues
«Окно» АТ - fire • Определение • «Окно» Автоматизированного тестирования (как пожарный извещатель) – как много физического времени занимает прогон Автоматизированных тестов (полное или подмножество) • «Окно» Автоматизированного тестирования – как много системного «лабороторного» времени занимает прогон Автоматизированных тестов (полное или подмножество)
«Окно» АТ - fire • «Физический смысл» • Время, требуемое для прогона автотестов необходимо учитывать при оценке экономической эффективности автоматизации, при анализе ROI и сравнении с ручным тестированием. Метрика необходима как при принятии решения о целесообразности внедрения автоматизации, так и при оценке текущего состояния уже реализованной автоматизации с целью выявления узких мест.
«Окно» АТ - fire • Границы • В зависимости от размера проекта может занимать от нескольких до многих часов. Как правило, Smoke после commit-а должен занимать не более часа, полная Регрессия не более двух дней (выходные) • Где взять информацию • Test Reports • Continuous Integration (CI)
«Окно» АТ - fire • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Контр пример – физическое время • Контр пример – машинное время (Claud) • Технические детали: Stateless и Statefull Автоматизация, параллельный запуск • Технические детали: Эффективные ожидания • Технические детали: Преждевременная оптимизация
«Окно» АТ - fire • Визуализация • Smoke <= 1 час, Full Regression <= 12 часов (ночь) - зеленый цвет • Smoke <= 2 часа, Full Regression <= 2 дня (выходные) - желтый цвет • Smoke > 2 часа, Full Regression > 2 дня (выходные) - красный цвет
«Окно» АТ - fire • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
«Окно» анализа АТ - fire • Определение • «Окно» анализа результатов Автоматизированного Тестирования (как пожарный извещатель) = Сколько времени требуется чтобы проанализировать полученные данные? • «Физический смысл» • Метрика показывает, насколько исчерпывающими и читабильными являются отчеты. При слишком большом окне анализа меньше времени будет уделяться фактическому написанию тестов, или анализ будет проводиться недостаточно тщательно, что обесценит value Автоматизации
«Окно» анализа АТ - fire • Границы • В зависимости от размера проекта может занимать от нескольких минут до многих часов. Как правило, анализ результатов Smoke тестов после commit - должен занимать считанные минуты, анализ результатов полной Регрессии – должен занимать считанные часы, в идеале, меньше часа. • Где взять информацию • Test Reports • Continuous Integration (CI) • Task Tracking Systems
«Окно» анализа АТ - fire • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • Mature Secure VPN (Russian), технологический стек; • Контрпримеры
«Окно» анализа АТ - fire • Визуализация • Smoke <= 10 минут, Full Regression <= 2 часа - зеленый цвет • Smoke <= 20 минут, Full Regression <= 4 часа - желтый цвет • Smoke > 20 минут, Full Regression > 4 часов - красный цвет
«Окно» анализа АТ - fire • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
М личной эффективности • Определение • Большинство метрик применимо к изучению личной эффективности, но не в контексте проекта, а в контексте индивидуального профессионального развития. • Пример • Экономическая целесообразность Автоматизации (ROI)
Как выбрать и исп. набор м? • Out of scope, but … 
Как выбрать и исп. набор м? • Сформулируйте цели проекта • Выберете метрики, которые смогут дать некоторую информацию по сформулированным целям • Путем экспертной оценки определите границы выбранных метрик для вашего проекта • Автоматизируйте подсчет метрик • Визуализируйте значения метрик на базе определенных границ • Не забывайте про эквалайзер и принцип светофора
Как выбрать и исп. набор м? • Заблаговременно разработайте план действий при выходе значений той или иной метрики из приемлемого диапазона • Регулярно пересматривайте цели проекта и набор метрик • Регулярно пересматривайте границы допустимых значений каждой метрики • Регулярно «балансируйте» эквалайзер под ваш проект в данной фазе
«Увлекательные» истории • Результаты голосования в РБ • Результаты голосования в РФ • Панельная дискуссия CodeFest 2016 Новосибирск • Уголок QA Secon 2016 в Пензе • Панельная дискуссия в EPAM Systems, Минск • Панельная дискуссия в EPAM Systems, Санкт- Петербург • Панельная дискуссия в EPAM Systems, Саратов
“Актуальность” информации • Результаты голосования в РБ • Результаты голосования в РФ • EPAM Systems best practices • DPI.Solutions best practices • EPAM IT Week и Open Days • Панельная дискуссия в EPAM Systems, Минск • Панельная дискуссия в EPAM Systems, Санкт- Петербург • Панельная дискуссия в EPAM Systems, Саратов • Панельная дискуссия CodeFest 2016 Новосибирск • Уголок QA Secon 2016 в Пензе
“Источники” информации • ISTQB certifications • “Implementing Automated Software Testing,” by Elfriede Dustin, Thom Garrett, Bernie Gauf • “Useful Automated Software Testing Metrics” by Thom Garrett • Результаты голосования в РБ от COMAQA • Результаты голосования в РФ от Software-Testing.ru • EPAM Systems best practices • DPI.Solutions best practices
“Take away” points • Уверен, презентация не бесполезна в нашей ежедневной работе. Коллеги, пожалуйста перечитывайте, при случае, презентацию, прежде всего слайды посвященные непосредственно метрикам. Спасибо! …
Что дальше? • Применяйте метрики  • Внимательно «всмотритесь» в ваш проект – скорее всего какие-то метрики, пусть и в неявном виде, но используются. Идентифицируйте неявно используемые метрики. • Классифицируйте выявленные метрики • Постарайтесь установить связь / корреляцию между метриками • Дополните метрики • Регулярно рассчитывайте значения метрик (Автоматически) • Используйте полученные данные • Постоянно адаптируйте процесс • Например, стоит ввести стандартные QA риски в качестве варанта классификации • Спасибо  …
IT overview • Фредерик Брукс «Мифический человеко-месяц или Как создаются программные системы» Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды. • Том де Марко «Peopleware: Productive Projects and Teams.» Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды.
IT overview • Том де Марко «The Deadline: A Novel About Project Management» Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды. • Кент Бек «Экстремальное программирование. Разработка через тестирование» Notes: IMHO Легкая для прочтения, концептуально целостная книга, с полезными примерами
Tech overview • Гради Буч «Объектно Ориентированный Анализ и проектирование с примерами приложений на С++» Notes: Не стоит пугаться примеров на С++, 95% материала концептуального, не зависящего от конретного языка программирования. На мой взгляд это одна из лучших книг для настоящего, а не шапочного, знакомство с ООП. • Стив Макконнелл «Совершенный код» Notes: Не стоит бояться размера книги ... ее стоит или читать перед сном с любого места ... или выборочные главы, что бы освежить свои знания в конкретной проблемной области.
Tech overview • Мартин Фаулер «Рефакторинг» Notes: IMHO категорически рекомендую прочитать от корки до корки, 2 раза подряд, что бы содержание книги стало вашим активным профессиональным багажом. • Gang of four “Design patterns” Notes: IMHO категорически рекомендую прочитать от корки до корки, как минимум, 2 раза подряд, что бы содержание книги стало вашим активным профессиональным багажом. • Д. Томас, Эндрю Хант «Программист-прагматик. Путь от подмастерья к мастеру» Notes: Замечательная книга, состоящая из множества атомарных советов. IMHO стоит прочитать от корки до корки 2 раза, а затем пролистывать выборочные главы при подготовке к обсуждению с заказчиком или интервью.
CONTACT ME semenchenko@dpi.solutions dpi.semenchenko https://www.linkedin.com/in/anton- semenchenko-612a926b https://www.facebook.com/semenche nko.anton.v https://twitter.com/comaqa
www.COMAQA.BY Аудитория сообщества Специалисты по тестированию (как ручному, так и автоматизированному) Разработчики средств автоматизации Менеджеры и специалисты по продажам в IT IT-специалисты, думающие о переходе в автоматизацию Студенты в поиске перспективной профессии Цель сообщества Создать единую площадку для эффективного общения всех IT- специалистов в контексте автоматизированного тестирования Ваша выгода Возможность услышать доклады ведущих IT-профессионалов и поделиться своим опытом Бесплатно участвовать в “промо” - версиях топовых IT- конференций стран СНГ Регулярно встречаться лично, на тематическом форуме, в “филиалах” сообщества в социальных сетях и мессенджерах
www.COMAQA.BY info@comaqa.by https://www.facebook.com/comaqa.by/ http://vk.com/comaqaby +375 33 33 46 120 +375 44 74 00 385
www.CoreHard.by Аудитория сообщества «Суровые» разработчики на С++ & co, IoT, BigData, High Load, Parallel Computing Разработчики средств автоматизации Менеджеры и специалисты по продажам в IT Студенты в поиске перспективной профессии Цель сообщества Создать единую площадку для эффективного общения всех IT- специалистов в контексте “суровой” разработки Ваша выгода Возможность услышать доклады ведущих IT-профессионалов и поделиться своим опытом Бесплатно участвовать в “промо” - версиях топовых IT- конференций стран СНГ Регулярно встречаться лично, на тематическом форуме, в “филиалах” сообщества в социальных сетях и мессенджерах
www.CoreHard.by info@corehard.by https://www.facebook.com/corehard.by/ +375 33 33 46 120 +375 44 74 00 385

Empfohlen

How to implement an effective fmea process
How to implement an effective fmea processHow to implement an effective fmea process
How to implement an effective fmea process
ASQ Reliability Division
 
MSA_Reference_Manual_4th_Edition.pdf
MSA_Reference_Manual_4th_Edition.pdfMSA_Reference_Manual_4th_Edition.pdf
MSA_Reference_Manual_4th_Edition.pdf
NiniaDidulo1
 
Internal Audit Check List
Internal Audit Check List Internal Audit Check List
Internal Audit Check List
Hands On Quality
 
FMEA 4th Edition for Beginer
FMEA 4th Edition for BeginerFMEA 4th Edition for Beginer
FMEA 4th Edition for Beginer
Nukool Thanuanram
 
Revenue assurance 101
Revenue assurance 101Revenue assurance 101
Revenue assurance 101
ntel
 
Pareto Analysis
Pareto AnalysisPareto Analysis
Pareto Analysis
Mohammed Hamed Ahmed Soliman
 
Fmea
FmeaFmea
Fmea
Sunil Yadav
 
APQP
APQP APQP
APQP
Age of Quality
 

Empfohlen

How to implement an effective fmea process
How to implement an effective fmea processHow to implement an effective fmea process
How to implement an effective fmea process
ASQ Reliability Division
 
MSA_Reference_Manual_4th_Edition.pdf
MSA_Reference_Manual_4th_Edition.pdfMSA_Reference_Manual_4th_Edition.pdf
MSA_Reference_Manual_4th_Edition.pdf
NiniaDidulo1
 
Internal Audit Check List
Internal Audit Check List Internal Audit Check List
Internal Audit Check List
Hands On Quality
 
FMEA 4th Edition for Beginer
FMEA 4th Edition for BeginerFMEA 4th Edition for Beginer
FMEA 4th Edition for Beginer
Nukool Thanuanram
 
Revenue assurance 101
Revenue assurance 101Revenue assurance 101
Revenue assurance 101
ntel
 
Pareto Analysis
Pareto AnalysisPareto Analysis
Pareto Analysis
Mohammed Hamed Ahmed Soliman
 
Fmea
FmeaFmea
Fmea
Sunil Yadav
 
APQP
APQP APQP
APQP
Age of Quality
 
Innovative Approach to FMEA Facilitation
Innovative Approach to FMEA FacilitationInnovative Approach to FMEA Facilitation
Innovative Approach to FMEA Facilitation
Govind Ramu
 
The EISA Audit Presentation
The EISA Audit PresentationThe EISA Audit Presentation
The EISA Audit Presentation
Senthil Kumar Manian (Amirtham)
 
Six sigma project_-_Call Centre Quality improvement
Six sigma project_-_Call Centre Quality improvement Six sigma project_-_Call Centre Quality improvement
Six sigma project_-_Call Centre Quality improvement
Vijay Baunthiyal
 
Awareness session on iatf 16949 2016 standard
Awareness session on iatf 16949 2016 standardAwareness session on iatf 16949 2016 standard
Awareness session on iatf 16949 2016 standard
Amit Mishra
 
4.fmea
4.fmea4.fmea
4.fmea
Krit Inkeaw
 
Process Certification Implementation Presentation
Process Certification Implementation PresentationProcess Certification Implementation Presentation
Process Certification Implementation Presentation
mdmilward
 
PPAP 101: What You Should Know About PPAP
PPAP 101: What You Should Know About PPAPPPAP 101: What You Should Know About PPAP
PPAP 101: What You Should Know About PPAP
Rapid Global Business Solutions, Inc.
 
Managing project with the Fsoft Insight
Managing project with the Fsoft InsightManaging project with the Fsoft Insight
Managing project with the Fsoft Insight
Mobi Marketing
 
ISO 9001:2015 Requirements.pptx
ISO 9001:2015 Requirements.pptxISO 9001:2015 Requirements.pptx
ISO 9001:2015 Requirements.pptx
GelmelinaLeaLepitenH
 
Summarized presentation vda 6.3 2016 (serial production)
Summarized presentation vda 6.3 2016 (serial production)Summarized presentation vda 6.3 2016 (serial production)
Summarized presentation vda 6.3 2016 (serial production)
Kiran Walimbe
 
Пополняем арсенал тестировщика. Учимся применять новые техники
Пополняем арсенал тестировщика. Учимся применять новые техникиПополняем арсенал тестировщика. Учимся применять новые техники
Пополняем арсенал тестировщика. Учимся применять новые техники
SQALab
 
Вредные привычки в тестировании
Вредные привычки в тестированииВредные привычки в тестировании
Вредные привычки в тестировании
SQALab
 
Оценки тестирования - полезные и условные метрики
Оценки тестирования - полезные и условные метрикиОценки тестирования - полезные и условные метрики
Оценки тестирования - полезные и условные метрики
SQALab
 
Введение в performance management
Введение в performance managementВведение в performance management
Введение в performance management
SQALab
 
Internet of Tested Things
Internet of Tested ThingsInternet of Tested Things
Internet of Tested Things
SQALab
 
UI Automation Patterns: "Sleep" Pattern
UI Automation Patterns: "Sleep" PatternUI Automation Patterns: "Sleep" Pattern
UI Automation Patterns: "Sleep" Pattern
Þorgeir Ingvarsson
 
Тестируем развитие тестировщика
Тестируем развитие тестировщикаТестируем развитие тестировщика
Тестируем развитие тестировщика
SQALab
 
Метрики покрытия. Прагматичный подход
Метрики покрытия. Прагматичный подходМетрики покрытия. Прагматичный подход
Метрики покрытия. Прагматичный подход
SQALab
 
Как же научиться программировать, в конце концов?
Как же научиться программировать, в конце концов?Как же научиться программировать, в конце концов?
Как же научиться программировать, в конце концов?
SQALab
 
QA как драйвер трансформации
QA как драйвер трансформацииQA как драйвер трансформации
QA как драйвер трансформации
SQALab
 
Как Cluster Membership Software может помочь QA
Как Cluster Membership Software может помочь QAКак Cluster Membership Software может помочь QA
Как Cluster Membership Software может помочь QA
SQALab
 
Полезные метрики покрытия. Практический опыт и немного теории
Полезные метрики покрытия. Практический опыт и немного теорииПолезные метрики покрытия. Практический опыт и немного теории
Полезные метрики покрытия. Практический опыт и немного теории
SQALab
 

Weitere ähnliche Inhalte

Was ist angesagt?

Process Certification Implementation Presentation
Process Certification Implementation PresentationProcess Certification Implementation Presentation
Process Certification Implementation Presentation
mdmilward
 

Was ist angesagt? (10)

Innovative Approach to FMEA Facilitation
Innovative Approach to FMEA FacilitationInnovative Approach to FMEA Facilitation
Innovative Approach to FMEA Facilitation
 
The EISA Audit Presentation
The EISA Audit PresentationThe EISA Audit Presentation
The EISA Audit Presentation
 
Six sigma project_-_Call Centre Quality improvement
Six sigma project_-_Call Centre Quality improvement Six sigma project_-_Call Centre Quality improvement
Six sigma project_-_Call Centre Quality improvement
 
Awareness session on iatf 16949 2016 standard
Awareness session on iatf 16949 2016 standardAwareness session on iatf 16949 2016 standard
Awareness session on iatf 16949 2016 standard
 
4.fmea
4.fmea4.fmea
4.fmea
 
Process Certification Implementation Presentation
Process Certification Implementation PresentationProcess Certification Implementation Presentation
Process Certification Implementation Presentation
 
PPAP 101: What You Should Know About PPAP
PPAP 101: What You Should Know About PPAPPPAP 101: What You Should Know About PPAP
PPAP 101: What You Should Know About PPAP
 
Managing project with the Fsoft Insight
Managing project with the Fsoft InsightManaging project with the Fsoft Insight
Managing project with the Fsoft Insight
 
ISO 9001:2015 Requirements.pptx
ISO 9001:2015 Requirements.pptxISO 9001:2015 Requirements.pptx
ISO 9001:2015 Requirements.pptx
 
Summarized presentation vda 6.3 2016 (serial production)
Summarized presentation vda 6.3 2016 (serial production)Summarized presentation vda 6.3 2016 (serial production)
Summarized presentation vda 6.3 2016 (serial production)
 

Andere mochten auch

UI Automation Patterns: "Sleep" Pattern
UI Automation Patterns: "Sleep" PatternUI Automation Patterns: "Sleep" Pattern
UI Automation Patterns: "Sleep" Pattern
Þorgeir Ingvarsson
 
Appium + selenide comaqa.by. Антон Семенченко
Appium + selenide comaqa.by. Антон СеменченкоAppium + selenide comaqa.by. Антон Семенченко
Appium + selenide comaqa.by. Антон Семенченко
Alina Dolgikh
 

Andere mochten auch (20)

Пополняем арсенал тестировщика. Учимся применять новые техники
Пополняем арсенал тестировщика. Учимся применять новые техникиПополняем арсенал тестировщика. Учимся применять новые техники
Пополняем арсенал тестировщика. Учимся применять новые техники
 
Вредные привычки в тестировании
Вредные привычки в тестированииВредные привычки в тестировании
Вредные привычки в тестировании
 
Оценки тестирования - полезные и условные метрики
Оценки тестирования - полезные и условные метрикиОценки тестирования - полезные и условные метрики
Оценки тестирования - полезные и условные метрики
 
Введение в performance management
Введение в performance managementВведение в performance management
Введение в performance management
 
Internet of Tested Things
Internet of Tested ThingsInternet of Tested Things
Internet of Tested Things
 
UI Automation Patterns: "Sleep" Pattern
UI Automation Patterns: "Sleep" PatternUI Automation Patterns: "Sleep" Pattern
UI Automation Patterns: "Sleep" Pattern
 
Тестируем развитие тестировщика
Тестируем развитие тестировщикаТестируем развитие тестировщика
Тестируем развитие тестировщика
 
Метрики покрытия. Прагматичный подход
Метрики покрытия. Прагматичный подходМетрики покрытия. Прагматичный подход
Метрики покрытия. Прагматичный подход
 
Как же научиться программировать, в конце концов?
Как же научиться программировать, в конце концов?Как же научиться программировать, в конце концов?
Как же научиться программировать, в конце концов?
 
QA как драйвер трансформации
QA как драйвер трансформацииQA как драйвер трансформации
QA как драйвер трансформации
 
Как Cluster Membership Software может помочь QA
Как Cluster Membership Software может помочь QAКак Cluster Membership Software может помочь QA
Как Cluster Membership Software может помочь QA
 
Полезные метрики покрытия. Практический опыт и немного теории
Полезные метрики покрытия. Практический опыт и немного теорииПолезные метрики покрытия. Практический опыт и немного теории
Полезные метрики покрытия. Практический опыт и немного теории
 
Waterfall revisited: практические метрики тестирования
Waterfall revisited: практические метрики тестированияWaterfall revisited: практические метрики тестирования
Waterfall revisited: практические метрики тестирования
 
CodeFest
CodeFest CodeFest
CodeFest
 
Автоматизация визуального тестирования
Автоматизация визуального тестированияАвтоматизация визуального тестирования
Автоматизация визуального тестирования
 
Example of TAF with batch execution of test cases
Example of TAF with batch execution of test cases Example of TAF with batch execution of test cases
Example of TAF with batch execution of test cases
 
ReportPortal.io - Open Source experience. Showcase, benefits
ReportPortal.io - Open Source experience. Showcase, benefits ReportPortal.io - Open Source experience. Showcase, benefits
ReportPortal.io - Open Source experience. Showcase, benefits
 
Работа в компании Изи-Штандарт
Работа в компании Изи-ШтандартРабота в компании Изи-Штандарт
Работа в компании Изи-Штандарт
 
Parallel run selenium tests in a good way
Parallel run selenium tests in a good wayParallel run selenium tests in a good way
Parallel run selenium tests in a good way
 
Appium + selenide comaqa.by. Антон Семенченко
Appium + selenide comaqa.by. Антон СеменченкоAppium + selenide comaqa.by. Антон Семенченко
Appium + selenide comaqa.by. Антон Семенченко
 

Ähnlich wie Метрики автоматизированного тестирования на пальцах

доклад на SQADays 2011 в Казани
доклад на SQADays 2011 в Казанидоклад на SQADays 2011 в Казани
доклад на SQADays 2011 в Казани
margo-qa
 
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной командыМаргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
SQALab
 
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. UkraineProcess Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Sergiy Povolyashko, PMP
 
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...
Ontico
 
Как автоматизировать тестирование метрик на сайте
Как автоматизировать тестирование метрик на сайтеКак автоматизировать тестирование метрик на сайте
Как автоматизировать тестирование метрик на сайте
Маркетинг-аналитика с OWOX BI
 
Доклад "Мониторинг серверных приложений"
Доклад "Мониторинг серверных приложений"Доклад "Мониторинг серверных приложений"
Доклад "Мониторинг серверных приложений"
Grigoriy Orlov
 
Tq Metric Compared Sep2009
Tq Metric Compared Sep2009Tq Metric Compared Sep2009
Tq Metric Compared Sep2009
Denis Khamin
 
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизацияQA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QAFest
 
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Andrey Ladutko
 

Ähnlich wie Метрики автоматизированного тестирования на пальцах (20)

доклад на SQADays 2011 в Казани
доклад на SQADays 2011 в Казанидоклад на SQADays 2011 в Казани
доклад на SQADays 2011 в Казани
 
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной командыМаргарита Сафарова - Аудит процессов тестирования при смене проектной команды
Маргарита Сафарова - Аудит процессов тестирования при смене проектной команды
 
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. UkraineProcess Quality, QA and QC. QA Club. Kharkov. Ukraine
Process Quality, QA and QC. QA Club. Kharkov. Ukraine
 
Организация тестирования производительности по SWEAT
Организация тестирования производительности по SWEATОрганизация тестирования производительности по SWEAT
Организация тестирования производительности по SWEAT
 
Организация тестирования производительности по SWEAT
Организация тестирования производительности по SWEATОрганизация тестирования производительности по SWEAT
Организация тестирования производительности по SWEAT
 
Человеко-дни на тестирование или как не ошибиться с оценкой
Человеко-дни на тестирование или как не ошибиться с оценкойЧеловеко-дни на тестирование или как не ошибиться с оценкой
Человеко-дни на тестирование или как не ошибиться с оценкой
 
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...
 
First class Testing
First class TestingFirst class Testing
First class Testing
 
Как автоматизировать тестирование метрик на сайте
Как автоматизировать тестирование метрик на сайтеКак автоматизировать тестирование метрик на сайте
Как автоматизировать тестирование метрик на сайте
 
01ka-nov
01ka-nov01ka-nov
01ka-nov
 
Test management print
Test management printTest management print
Test management print
 
Testing
TestingTesting
Testing
 
Доклад "Мониторинг серверных приложений"
Доклад "Мониторинг серверных приложений"Доклад "Мониторинг серверных приложений"
Доклад "Мониторинг серверных приложений"
 
A/B - тесты или раздолье для ошибок
A/B - тесты или раздолье для ошибокA/B - тесты или раздолье для ошибок
A/B - тесты или раздолье для ошибок
 
Analyst Days 2014
Analyst Days 2014Analyst Days 2014
Analyst Days 2014
 
Оценка эффективности работы аналитика
Оценка эффективности работы аналитикаОценка эффективности работы аналитика
Оценка эффективности работы аналитика
 
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUAREТехники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
Техники аналитика - CATWOE, H-METHOD, MOSCOW, SQUARE
 
Tq Metric Compared Sep2009
Tq Metric Compared Sep2009Tq Metric Compared Sep2009
Tq Metric Compared Sep2009
 
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизацияQA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
QA Fest 2017. Андрей Ладутько.Тестовая стратегия: создание и оптимизация
 
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
Test Strategy: creation and optimization - QA Fest-2017 (Тестовая стратегия: ...
 

Mehr von SQALab

Mehr von SQALab (20)

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировку
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщика
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержки
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
 

Метрики автоматизированного тестирования на пальцах

  • 2. About  Организатор сообществ www.COMAQA.BY и www.CoreHard.by, учередитель компании www.DPI.Solutions, «хитрый» менеджер в EPAM Systems. Почти 15 лет опыта в IT, основная специализация: Автоматизированное тестирование, разработка на С++ и ниже, менеджмент, продажи.
  • 3. Agenda, part 1 (введение) • QA и QC • Определение понятия метрика • Потенциальные сложности • Где взять данные для рассчета метрик? • Алгоритм трансформации данных в информацию • Источники данных для рассчета метрик • Взаимосвязь метрик • Светофор – метрик • Эквалайзер - метрик • «Пожарные» метрики
  • 4. Agenda, part 2 (основная) • 3 вида классификации метрик • Классификация с точки зрения тех специалистов • Классификация с точки зрения бизнеса • Классификация с точки зрения менеджмента на стороне исполнителя • Важность классификации • Стандартные QA Риски как вариант классификации метрик • 2 вида проектов • Ниболее популярные метрики АТ • Метрики – пожарные извещатели • Ниболее популярные метрики общие как для Ручного, так и для Автоматизированного тестирования • Метрики личной эффективности
  • 5. Agenda, part 3 (заключение) • «Увлекательные» истории • “Актуальность” информации • “Источники” информации • “Take away” points • Что дальше? • «Внеклассное чтение»
  • 6. QA и QC • Контроль качества (QC) — это измерение параметров качества продукта • Обеспечение качества (QA) – это измерение и управление качеством процесса (включая метрики), который используется для создания качества продукта (или качественного продукта).
  • 7. Метрика • Метрика программного обеспечения — мера, позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций. • Метрика – как механизм обратной связи • Том ДеМарко, «вы не можете контролировать то, что не можете измерить».
  • 8. Потенциальные сложности • Что такое качество тестирования? • Не тривиальный вопрос, очень комплексное понятие. • Успеваем ли мы уложиться в проектные ограничения? • Дата Релиза • Бюджет
  • 9. Потенциальные сложности • Как можно улучшить процесс тестирования и разработки ПО в целом? • Успешна ли АТ, текущий статус АТ, не отклонились ли мы от намеченной траектории • И многие другие
  • 10. Где взять данные? • Этот вопрос регулярно задают не только молодые, но и опытные специалисты. Пример: фактически, значимая часть панельной дискусии на конференции CodeFest 2016, посвященная метрикам тестирования, была сфокусирована на вопросе «Где взять данные?»
  • 11. Трансформация • Трансформация: • Данные • => • Информация (фильтрация данных) • => • Визуализация информации (сложение, вычитание, деление) • => • Работа с «Трендом» • Примеры: • Биржа • Любой BigData проект
  • 12. Где взять данные? • Test Plan • Test Reports • Continues Integration (CI) • Bug Tracking Systems • Task Tracking Systems • Test Management Systems (TMS) • Test Strategy • Другие источники
  • 14. Светофор - метрик • Светофор – как способ максимально быстро получить актуальную высокоуровневую информацию о проекте. Многие метрики можно и нужно использовать в стиле «светофор». • Красный – надо срочно обратить детальное внимание • Желтый – в зависимости от загруженности, либо обратить поверхностное внимание лично, либо дерелировать эту активность • Зеленый – не требует вмешательствавнимания
  • 15. Эквалайзер - метрик • The power of music (Metrics )
  • 17. «Пожарные» метрики • Если процесс разработки и тестирования ПО налажен – вероятность того, что проект будет успешно реализован приемлемо высока. • Если же процесс разработки и тестирования ПО не эффективен – что бы мы ни делали, какими бы замечательными отдельные показатели не были, проект прочти наверняка «провалится». • «Пожарные» метрики + принцип светофора + принцип эквалайзера – дают гарантию того, что процесс разработки приемлемо высокого качества.
  • 18. Классификация (IT stuff) • Классификация по «областям» • Качество Продукта (Quality) • Прогресс той или иной активности в тестировании (Progress) • Покрытие (Coverage) • Цена / время (Cost / time) • Процесс обеспечения качества и разработки в целом (Process)
  • 19. Классификация (Business) • Классификация «Что должно быть исправлено в первую очередь» • Качество Продукта (Quality) • Время тестирования продукта / впуска продукта (Time) • Стоимость тестирования продукта (Costs/efforts) • Прозрачность тестирования продукта (Testing visibility) • Автоматизация тестирования (Test automation approach)
  • 20. К-я менеджмента • Классификация менеджмента • Метрики – пожарные извещатели • Все остальные метрики
  • 21. 3 варианта классификации? • Классификация с точки зрения технического специалиста / исполнителя • Классификация с точки зрения заказчика • Классификация с точки зрения менеджмента • Любая классификация не идеальна и рассматривает «поблемную» область под определенным углом зрения • Метрика – инструмент • А классификация – инструмент для эффективной работы с инструментом-метрикой
  • 23. 2 вида проектов? • Outsourcing • Own product development
  • 24. Метрики АТ • Процент тестов, поддающихся автоматизации (ППА) • Прогресс автоматизации (ПА) • Процент покрытия автоматизированными тестами (ПП АТ) • Частота проведения регрессии (ЧР) • Стабильность Автоматизированных Тестов (САТ) • Колличество дефектов, на Автоматизированный Тест (ДАТ)
  • 25. Метрики АТ • Окно автоматизации тестирования • Окно анализа результатов тестирования • Время на создание автоматизированного теста • Время на поддержку автоматизированного теста • Экономическая целесообразность АТ (ROI)
  • 26. % т, поддающихся А (ППА) • Определение • Процент тестов, поддающихся автоматизации = # тест кейсов которые можно автоматизировать (ПА) / # общее количество тест кейсов (ОТК) • «Физический смысл» • Отражает адаптированность приложения к автоматизированному тестированию с точки зрения технологий и архитектуры
  • 27. % т, поддающихся А (ППА) • Границы • Для большинства относительно новых приложений этот параметр, как правило, превышает 90% • Где взять информацию • Информация получается на базе тест-плана и экспертной оценки
  • 28. % т, поддающихся А (ППА) • Примеры • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • Mature Secure VPN (Russian), технологический стек; • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • MS и Google;
  • 29. % т, поддающихся А (ППА) • Визуализация • Более 90% - зеленый цвет • От 70% до 90% - желтый цвет • Менее 70% - красный цвет • Связь с другими метриками • Прогресс автоматизации (ПА) • Процент покрытия автоматизированными тестами (ПП АТ) • Категория: • Качество • Автоматизация тестирования
  • 30. Прогресс А (ПА) • Определение • Прогресс автоматизации (ПА) = # количество автоматизированных на данный момент тест кейсов (АТК) / # общее количество тест кейсов автоматизации (ОАТК) • «Физический смысл» • Отражение статуса во времени для понимания достижимости или недостижимости поставленных целей • Как много тест кейсов команда покрыла Автоматизацией в течении последней итерации (Sprint, Release)? Способ убедиться в том, что текущий прогресс позволяет достичь намеченных целей до Deadline-а
  • 31. Прогресс А (ПА) • Границы • Границы: 0 – 100% • Где взять информацию • Test Plan • Test Reports • Continues Integration (CI) • Test Management Systems (TMS)
  • 32. Прогресс А (ПА) • Примеры • Mature Secure VPN (Russian), технологический стек;
  • 33. Прогресс А (ПА) • Визуализация • Круговая диаграмма (2 типа): • Общее колличество запланированных для Автоматизации тестов к уже реализованным • Общее колличество запланированных часов к уже использованному
  • 34. Прогресс А (ПА) • Связь с другими метриками • Процент покрытия автоматизированными тестами (ПП АТ); • Колличество найденных дефектов на Автоматизированный тест; • Окно Автоматизации Тестирования; • Окно Анализа результатов; • Экономическая целесообразность АТ (ROI); • Категория: • Прогресс • Автоматизация тестирования
  • 35. % покрытия АТ (coverage) • Определение • Процент покрытия автоматизированными тестами (ПП АТ) = Покрытие автоматизированными тестами (ПАТ) / Общее покрытие (ОП) (KLOC, FP, etc.) • Метрику можно «интерпретировать» очень по- разному
  • 36. % покрытия АТ (ПП АТ) • «Физический смысл» • Данная метрика помогает выявить, насколько «эффективна» / «разумна» автоматизация. • Выявить, какие тесты стоит Автоматизировать в первую очередь (например, начать со Smoke и Regression, если эти тест кейсы достаточно формализованы) и сравнить с текущим покрытием (подразумевается что АТ запускаются регулярно и выявляют дефекты). • Удостовериться, в том, что Автоматизированные тесты проверяют именно то, что должны проверять.
  • 37. % покрытия АТ (ПП АТ) • Границы • Границы: 0 – 100% • Где взять информацию • Test Reports • Continues Integration (CI) • Test Management Systems (TMS)
  • 38. % покрытия АТ (ПП АТ) • Примеры • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • MS and Windows Millennium • Data Protection Giant and Automation
  • 39. % покрытия АТ (ПП АТ) • Визуализация • Термин test coverage matrix и traceability matrix взаимозаменяемы в большинстве случаев • Karen Johnson's использовать trace matrix как индикатор test coverage. • Связь с другими метриками • Процент покрытия автоматизированными тестами (ПП АТ); • Прогресс Автоматизации • Категория: • Покрытие • Автоматизация тестирования
  • 40. Частота регрессии (ЧР) • Определение • Частота проведения регрессии (ЧР) = Как часто проводится автоматизированная регрессия? • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
  • 41. Частота регрессии (ЧР) • Границы • Широкораспространенные границы / рекомендации: o smoke - каждую ночь o full-regression - каждые выходные • Где взять информацию • Automation reports • Continuous Integration (CI)
  • 42. Частота регрессии (ЧР) • Примеры • ЧР и Экономическая целесообразность АТ (ROI); • Facebook и Bamboo • Kanban, ЧР, опыт WG • Доведенные до «абсолюта» «рекоммендации» • «Окно commit-а»
  • 43. Частота регрессии (ЧР) • Визуализация • Не реже чем 1 раз в неделю - зеленый цвет • Не реже чем 1 раз в 2 недели - желтый цвет • Реже чем 1 раз в месяц - красный цвет • Чаще чем раз в день - красный цвет • Связь с другими метриками • Экономическая целесообразность АТ (ROI); • Окно автоматизации тестирования; • Окно анализа результатов тестирования; • “Окно commit-а“ • Категория: • Качество • Автоматизация тестирования
  • 44. Стабильность АТ • Определение • Стабильность Автоматизированных тестов = процент тестов, которые либо успешно проходят либо падают, по причине нахождения дефекта • «Физический смысл» • Отражает качество автотестов и соответствие их текущему состоянию тестируемой системы
  • 45. Стабильность АТ • Границы • Цель – процент «случайных» падений не превышает 5% • Где взять информацию • Test Reports
  • 46. Стабильность АТ • Примеры • Множество проектов; • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
  • 47. Стабильность АТ • Визуализация • Более 95% - зеленый цвет • Более 90%, менее 95% - желтый цвет • Менее 90% - красный цвет • Связь с другими метриками • Колличество дефектов на Автоматизированный тест • Категория: • Качество / Процесс • Автоматизация тестирования
  • 48. # дефектов на АТ • Определение • Колличество дефектов на Автоматизированный Тест = ведется подсчет дефектов, как Автоматизированных, так и Ручных; • Если Автоматизированное тестирование не находит дефектов или лишь незначительное колличество дефектов, то: • Выделить области Автоматизации для улучшения; • Репреоретизировать усилия в Автоматизации; • Отказаться от Автоматизации;
  • 49. # дефектов на АТ • «Физический смысл» • Отражает эффективность автотестов с точки зрения нахождения дефектов • Границы • Отсутствие найденных дефектов может являться индикатором неудачного фокуса автотестов • Где взять информацию • Test Reports
  • 50. # дефектов на АТ • Примеры • Множество проектов; • Стандартная «проблема» Автоматизации ради Автоматизации • Стандартная «проблема» получения прибыли исполнителем в ущерб заказчику
  • 51. # дефектов на АТ • Визуализация • Более 5% (минимальный процент зависит от фазы и деталей проекта) - зеленый цвет • От 1 до 5% - желтый цвет • Менее 1% - красный цвет • Связь с другими метриками • Стабильность Автоматизированных тестов • Категория: • Качество / Процесс • Автоматизация тестирования
  • 52. «Окно» АТ • Определение • «Окно» Автоматизированного тестирования – как много физического времени занимает прогон Автоматизированных тестов (полное или подмножество) • «Окно» Автоматизированного тестирования – как много системного «лабороторного» времени занимает прогон Автоматизированных тестов (полное или подмножество)
  • 53. «Окно» АТ • «Физический смысл» • Время, требуемое для прогона автотестов необходимо учитывать при оценке экономической эффективности автоматизации, при анализе ROI и сравнении с ручным тестированием. Метрика необходима как при принятии решения о целесообразности внедрения автоматизации, так и при оценке текущего состояния уже реализованной автоматизации с целью выявления узких мест.
  • 54. «Окно» АТ • Границы • В зависимости от размера проекта может занимать от нескольких до многих часов. Как правило, Smoke после commit-а должен занимать не более часа, полная Регрессия не более двух дней (выходные) • Где взять информацию • Test Reports • Continuous Integration (CI)
  • 55. «Окно» АТ • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Контр пример – физическое время • Контр пример – машинное время (Claud) • Технические детали: Stateless и Statefull Автоматизация, параллельный запуск • Технические детали: Эффективные ожидания • Технические детали: Преждевременная оптимизация
  • 56. «Окно» АТ • Визуализация • Smoke <= 1 час, Full Regression <= 12 часов (ночь) - зеленый цвет • Smoke <= 2 часа, Full Regression <= 2 дня (выходные) - желтый цвет • Smoke > 2 часа, Full Regression > 2 дня (выходные) - красный цвет
  • 57. «Окно» АТ • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
  • 58. «Окно» анализа р-тов АТ • Определение • «Окно» анализа результатов Автоматизированного Тестирования = Сколько времени требуется чтобы проанализировать полученные данные? • «Физический смысл» • Метрика показывает, насколько исчерпывающими и читабильными являются отчеты. При слишком большом окне анализа меньше времени будет уделяться фактическому написанию тестов, или анализ будет проводиться недостаточно тщательно, что обесценит value Автоматизации
  • 59. «Окно» анализа р-тов АТ • Границы • В зависимости от размера проекта может занимать от нескольких минут до многих часов. Как правило, анализ результатов Smoke тестов после commit - должен занимать считанные минуты, анализ результатов полной Регрессии – должен занимать считанные часы, в идеале, меньше часа. • Где взять информацию • Test Reports • Continuous Integration (CI) • Task Tracking Systems
  • 60. «Окно» анализа р-тов АТ • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • Mature Secure VPN (Russian), технологический стек; • Контрпримеры
  • 61. «Окно» анализа р-тов АТ • Визуализация • Smoke <= 10 минут, Full Regression <= 2 часа - зеленый цвет • Smoke <= 20 минут, Full Regression <= 4 часа - желтый цвет • Smoke > 20 минут, Full Regression > 4 часов - красный цвет
  • 62. «Окно» анализа р-тов АТ • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
  • 63. t разработки АТ-а • Определение • Среднее время разработки Автоматизированного Теста = # всех автоматизированных тестов / время на создание • «Физический смысл» • Информация о времени на разработку одного теста помогает при расчете ROI, является одним из важнейших стоимостных показателей при внедрении автоматизации. Позволяет оценить издержки и потенциальную прибыль от введения автоматизации на проекте
  • 64. t разработки АТ-а • Границы • Границы: 1-16 часов на тест, в зависимости от сложности сценария, применяемых технологий (как в разработке приложения, так и в автоматизации), среднее время «по-больнице» 4 часа. • Где взять информацию • Task Tracking System
  • 65. t разработки АТ-а • Примеры • Множество проектов • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
  • 66. t разработки АТ-а • Визуализация • Менее 4 часов- зеленый цвет • Менее 8 часов, но более 4 часов - желтый цвет • Более 8 часов - красный цвет • Связь с другими метриками • Время на поддержку автоматизированного теста • Экономическая целесообразность АТ (ROI) • Категория: • Цена / время • Автоматизация тестирования
  • 67. t поддержки АТ-а • Определение • Среднее время уделяемое поддержке Автоматизированного Теста в течении указанного периуда времени = # всех автоматизированных тестов / время на поддержку.
  • 68. t поддержки АТ-а • «Физический смысл» • Любой программный продукт при работе по agile-методологиям особенно осклонен к изменчивости, соответственно адаптироваться под эту изменчивость должны и автотесты. Время, необходимое на доработку и адаптацию тестов, выделяется за счет времени на разработку новых тестов, а значит, чем выше этот показатель, тем хуже, тем меньше времени астается на другие активности. Высокий показатель данной метрики может быть индикатором того, что в автоматизации не были применены оптимальные архитектурные паттерны или вспомогательные программные инструменты.
  • 69. t разработки АТ-а • Границы • Границы: от 0.5 часа на тест в год, до ... чуть ли не бесконечности (заниматься тонкой балансировкой Sleep-ов можно сколько угодно – стабилизация так и не наступит) ... Безусловно конкретные показатели зависят от множества факторов – стабильности требований, стабильности приложения, технологического стека – как приложения, так и автоматизации, но время не должно превышать 4 часов в большиснтве случаев. • Где взять информацию • Task Tracking System
  • 70. t разработки АТ-а • Примеры • Множество проектов • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
  • 71. t разработки АТ-а • Визуализация • Менее 0,5 часа на тест в год - зеленый цвет • Не более 1 часа на тест в год - желтый цвет • Более 2 часов на тест в год - красный цвет • Связь с другими метриками • Время на поддержку автоматизированного теста • Экономическая целесообразность АТ (ROI) • Категория: • Цена / время • Автоматизация тестирования
  • 72. ROI (out of scope, but ) • Определение • Экономическая целесообразность Автоматизированного Тестирования (ROI) = Manual efforts – (Automation efforts + Automation investment) / QA investment * 100% • «Физический смысл» • Указывает на то, имеет ли смысл внедрять автоматизацию тестирования на данном проекте в данный момент. Может оказаться, что при определенных условиях автоматизация тестирования окажется экономически нецелесообразной, поскольку ручное тестирование даже в долгосрочной перспективе может оказаться дешевле.
  • 73. ROI • Границы • Out of scope • Где взять информацию • Test Strategy • Test Plan • Test Management Systems (TMS)
  • 74. ROI • Примеры • Множество проектов • Стандартная «проблема» при работе с middle+ специалистами по Автоматизированному тестированию «старой формации»
  • 75. ROI (+ доп выгоды) • Визуализация • Сравнение трендов • Ручное тестирование • Целый вариант опций введения / развития Автоматизированного тестирования • Выбор оптимальной команды-тренда здесь и сейчас
  • 76. ROI • Связь с другими метриками • Процент тестов, поддающихся автоматизации (ППА) • Частота проведения регрессии (ЧР) • Стабильность Автоматизированных Тестов (САТ) • Окно автоматизации тестирования • Окно анализа результатов тестирования • Время на создание автоматизированного теста • Время на поддержку автоматизированного теста • Категория: • Цена / время • Автоматизация тестирования
  • 77. Пожарные извещатели • Частота проведения регрессии (ЧР) - fire • % проанализированных тестов в Test Report-е • % ошибок / дефектов приложения • % ошибок Автоматизации Тестирования • % системных ошибок • «Окно» Автоматизированного тестирования (Время выполнения) - fire • Окно анализа результатов тестирования - fire
  • 78. Частота регрессии (ЧР) - fire • Определение • Частота проведения регрессии как пожарный извещатель (ЧР) = Как часто проводится автоматизированная регрессия? • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
  • 79. Частота регрессии (ЧР) - fire • Границы • Широкораспространенные границы / рекомендации: o smoke - каждую ночь o full-regression - каждые выходные • Где взять информацию • Automation reports • Continuous Integration (CI)
  • 80. Частота регрессии (ЧР) - fire • Примеры • ЧР и Экономическая целесообразность АТ (ROI); • Facebook и Bamboo • Kanban, ЧР, опыт WG • Доведенные до «абсолюта» «рекоммендации» • «Окно commit-а»
  • 81. Частота регрессии (ЧР) - fire • Визуализация • Не реже чем 1 раз в неделю - зеленый цвет • Не реже чем 1 раз в 2 недели - желтый цвет • Реже чем 1 раз в месяц - красный цвет • Чаще чем раз в день - красный цвет • Связь с другими метриками • Экономическая целесообразность АТ (ROI); • Окно автоматизации тестирования; • Окно анализа результатов тестирования; • “Окно commit-а“ • Категория: • Качество • Автоматизация тестирования
  • 82. % of TA results analyzed - fire • Определение • Процент проанализированных негативных результатов запуска Автоматизированных тестов. Если негативные результаты не проанализированны, Автоматизация не принесла никакой пользы 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = TI / (PB+AB+SI+TI)
  • 83. % of TA results analyzed - fire • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
  • 84. % of TA results analyzed - fire • Границы • % >95% (в идеале, 100%) – зеленый • 85% <% < 95% – желтый • %<= 85 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
  • 85. % of TA results analyzed - fire • Визуализация • % >95% – зеленый • 85% <% < 95% – желтый • %<= 85 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of product issues • % of automation issues • % of system issues
  • 86. % of product issues - fire • Определение • Важно понимать как много дефектов находит Автоматизированное Тестирование, а так же процентное соотношения найденных дефектов к общему колличеству ложных срабатываний, что показывает стабильность Автоматизации 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = PB / (PB+AB+SI+TI)
  • 87. % of product issues - fire • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
  • 88. % of product issues - fire • Границы • 5% > % (в идеале, 0) – зеленый • 10% > % > 5% – желтый • % >= 10 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
  • 89. % of product issues - fire • Визуализация • 5% > % – зеленый • 10% >% > 5% – желтый • % >= 10 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of TA results analyzed • % of automation issues • % of system issues
  • 90. % of automation issues - fire • Определение • Важно понимать как много Автоматизированных тестов падает в силу ошибок самих тестов, а так же процентное соотношене ложный падений в силу ошибок в тесте к общему колличеству ложных срабатываний, что показывает корректность Автоматизации 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = AB / (PB+AB+SI+TI)
  • 91. % of automation issues - fire • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
  • 92. % of automation issues - fire • Границы • 5% > % (в идеале, 0) – зеленый • 10% > % > 5% – желтый • % >= 10 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
  • 93. % of automation issues - fire • Визуализация • 5% > % – зеленый • 10% >% > 5% – желтый • % >= 10 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of TA results analyzed • % of product issues • % of system issues
  • 94. % of system issues • Определение • Важно понимать как много Автоматизированных тестов падает в силу не стабильности окружения, а так же процентное соотношене ложный падений в силу проблем окружения к общему колличеству ложных срабатываний, что показывает корректность окружения 1. # of not analyzed failed test cases (TI) 2. # of failed due to product bug (PB) 3. # of failed due to automation issues (AB) 4. # of failed due to system issue (SI) 5. Formula = SI / (PB+AB+SI+TI)
  • 95. % of system issues • «Физический смысл» • Чем выше частота использования продукта, тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.
  • 96. % of system issues • Границы • 5% > % (в идеале, 0) – зеленый • 10% > % > 5% – желтый • % >= 10 – красный • Где взять информацию • Automation reports • Continuous Integration (CI) • Примеры • Множество негативных примеров • Категория: • Процесс (fire-эквалайзер) • Автоматизация тестирования
  • 97. % of system issues • Визуализация • 5% > % – зеленый • 10% >% > 5% – желтый • % >= 10 – красный • Связь с другими метриками • Прогресс автоматизации (ПА) • Колличество дефектов, на Автоматизированный Тест (ДАТ) • Окно анализа результатов тестирования • Экономическая целесообразность АТ (ROI) • % of TA results analyzed • % of product issues • % of automation issues
  • 98. «Окно» АТ - fire • Определение • «Окно» Автоматизированного тестирования (как пожарный извещатель) – как много физического времени занимает прогон Автоматизированных тестов (полное или подмножество) • «Окно» Автоматизированного тестирования – как много системного «лабороторного» времени занимает прогон Автоматизированных тестов (полное или подмножество)
  • 99. «Окно» АТ - fire • «Физический смысл» • Время, требуемое для прогона автотестов необходимо учитывать при оценке экономической эффективности автоматизации, при анализе ROI и сравнении с ручным тестированием. Метрика необходима как при принятии решения о целесообразности внедрения автоматизации, так и при оценке текущего состояния уже реализованной автоматизации с целью выявления узких мест.
  • 100. «Окно» АТ - fire • Границы • В зависимости от размера проекта может занимать от нескольких до многих часов. Как правило, Smoke после commit-а должен занимать не более часа, полная Регрессия не более двух дней (выходные) • Где взять информацию • Test Reports • Continuous Integration (CI)
  • 101. «Окно» АТ - fire • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Контр пример – физическое время • Контр пример – машинное время (Claud) • Технические детали: Stateless и Statefull Автоматизация, параллельный запуск • Технические детали: Эффективные ожидания • Технические детали: Преждевременная оптимизация
  • 102. «Окно» АТ - fire • Визуализация • Smoke <= 1 час, Full Regression <= 12 часов (ночь) - зеленый цвет • Smoke <= 2 часа, Full Regression <= 2 дня (выходные) - желтый цвет • Smoke > 2 часа, Full Regression > 2 дня (выходные) - красный цвет
  • 103. «Окно» АТ - fire • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
  • 104. «Окно» анализа АТ - fire • Определение • «Окно» анализа результатов Автоматизированного Тестирования (как пожарный извещатель) = Сколько времени требуется чтобы проанализировать полученные данные? • «Физический смысл» • Метрика показывает, насколько исчерпывающими и читабильными являются отчеты. При слишком большом окне анализа меньше времени будет уделяться фактическому написанию тестов, или анализ будет проводиться недостаточно тщательно, что обесценит value Автоматизации
  • 105. «Окно» анализа АТ - fire • Границы • В зависимости от размера проекта может занимать от нескольких минут до многих часов. Как правило, анализ результатов Smoke тестов после commit - должен занимать считанные минуты, анализ результатов полной Регрессии – должен занимать считанные часы, в идеале, меньше часа. • Где взять информацию • Test Reports • Continuous Integration (CI) • Task Tracking Systems
  • 106. «Окно» анализа АТ - fire • Примеры • Социальные сети (Facebook, Bamboo), CMS, шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок; • Mature Data Protection Solution, new SQL Denali plug-in, close to 100%; • Mature Secure VPN (Russian), технологический стек; • Контрпримеры
  • 107. «Окно» анализа АТ - fire • Визуализация • Smoke <= 10 минут, Full Regression <= 2 часа - зеленый цвет • Smoke <= 20 минут, Full Regression <= 4 часа - желтый цвет • Smoke > 20 минут, Full Regression > 4 часов - красный цвет
  • 108. «Окно» анализа АТ - fire • Связь с другими метриками • Прогресс автоматизации • Процент покрытия автоматизированными тестами • Частота проведения регрессии • Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования • Категория: • Цена / Время • Автоматизация тестирования
  • 109. М личной эффективности • Определение • Большинство метрик применимо к изучению личной эффективности, но не в контексте проекта, а в контексте индивидуального профессионального развития. • Пример • Экономическая целесообразность Автоматизации (ROI)
  • 110. Как выбрать и исп. набор м? • Out of scope, but … 
  • 111. Как выбрать и исп. набор м? • Сформулируйте цели проекта • Выберете метрики, которые смогут дать некоторую информацию по сформулированным целям • Путем экспертной оценки определите границы выбранных метрик для вашего проекта • Автоматизируйте подсчет метрик • Визуализируйте значения метрик на базе определенных границ • Не забывайте про эквалайзер и принцип светофора
  • 112. Как выбрать и исп. набор м? • Заблаговременно разработайте план действий при выходе значений той или иной метрики из приемлемого диапазона • Регулярно пересматривайте цели проекта и набор метрик • Регулярно пересматривайте границы допустимых значений каждой метрики • Регулярно «балансируйте» эквалайзер под ваш проект в данной фазе
  • 113. «Увлекательные» истории • Результаты голосования в РБ • Результаты голосования в РФ • Панельная дискуссия CodeFest 2016 Новосибирск • Уголок QA Secon 2016 в Пензе • Панельная дискуссия в EPAM Systems, Минск • Панельная дискуссия в EPAM Systems, Санкт- Петербург • Панельная дискуссия в EPAM Systems, Саратов
  • 114. “Актуальность” информации • Результаты голосования в РБ • Результаты голосования в РФ • EPAM Systems best practices • DPI.Solutions best practices • EPAM IT Week и Open Days • Панельная дискуссия в EPAM Systems, Минск • Панельная дискуссия в EPAM Systems, Санкт- Петербург • Панельная дискуссия в EPAM Systems, Саратов • Панельная дискуссия CodeFest 2016 Новосибирск • Уголок QA Secon 2016 в Пензе
  • 115. “Источники” информации • ISTQB certifications • “Implementing Automated Software Testing,” by Elfriede Dustin, Thom Garrett, Bernie Gauf • “Useful Automated Software Testing Metrics” by Thom Garrett • Результаты голосования в РБ от COMAQA • Результаты голосования в РФ от Software-Testing.ru • EPAM Systems best practices • DPI.Solutions best practices
  • 116. “Take away” points • Уверен, презентация не бесполезна в нашей ежедневной работе. Коллеги, пожалуйста перечитывайте, при случае, презентацию, прежде всего слайды посвященные непосредственно метрикам. Спасибо! …
  • 117. Что дальше? • Применяйте метрики  • Внимательно «всмотритесь» в ваш проект – скорее всего какие-то метрики, пусть и в неявном виде, но используются. Идентифицируйте неявно используемые метрики. • Классифицируйте выявленные метрики • Постарайтесь установить связь / корреляцию между метриками • Дополните метрики • Регулярно рассчитывайте значения метрик (Автоматически) • Используйте полученные данные • Постоянно адаптируйте процесс • Например, стоит ввести стандартные QA риски в качестве варанта классификации • Спасибо  …
  • 118. IT overview • Фредерик Брукс «Мифический человеко-месяц или Как создаются программные системы» Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды. • Том де Марко «Peopleware: Productive Projects and Teams.» Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды.
  • 119. IT overview • Том де Марко «The Deadline: A Novel About Project Management» Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды. • Кент Бек «Экстремальное программирование. Разработка через тестирование» Notes: IMHO Легкая для прочтения, концептуально целостная книга, с полезными примерами
  • 120. Tech overview • Гради Буч «Объектно Ориентированный Анализ и проектирование с примерами приложений на С++» Notes: Не стоит пугаться примеров на С++, 95% материала концептуального, не зависящего от конретного языка программирования. На мой взгляд это одна из лучших книг для настоящего, а не шапочного, знакомство с ООП. • Стив Макконнелл «Совершенный код» Notes: Не стоит бояться размера книги ... ее стоит или читать перед сном с любого места ... или выборочные главы, что бы освежить свои знания в конкретной проблемной области.
  • 121. Tech overview • Мартин Фаулер «Рефакторинг» Notes: IMHO категорически рекомендую прочитать от корки до корки, 2 раза подряд, что бы содержание книги стало вашим активным профессиональным багажом. • Gang of four “Design patterns” Notes: IMHO категорически рекомендую прочитать от корки до корки, как минимум, 2 раза подряд, что бы содержание книги стало вашим активным профессиональным багажом. • Д. Томас, Эндрю Хант «Программист-прагматик. Путь от подмастерья к мастеру» Notes: Замечательная книга, состоящая из множества атомарных советов. IMHO стоит прочитать от корки до корки 2 раза, а затем пролистывать выборочные главы при подготовке к обсуждению с заказчиком или интервью.
  • 123. www.COMAQA.BY Аудитория сообщества Специалисты по тестированию (как ручному, так и автоматизированному) Разработчики средств автоматизации Менеджеры и специалисты по продажам в IT IT-специалисты, думающие о переходе в автоматизацию Студенты в поиске перспективной профессии Цель сообщества Создать единую площадку для эффективного общения всех IT- специалистов в контексте автоматизированного тестирования Ваша выгода Возможность услышать доклады ведущих IT-профессионалов и поделиться своим опытом Бесплатно участвовать в “промо” - версиях топовых IT- конференций стран СНГ Регулярно встречаться лично, на тематическом форуме, в “филиалах” сообщества в социальных сетях и мессенджерах
  • 125. www.CoreHard.by Аудитория сообщества «Суровые» разработчики на С++ & co, IoT, BigData, High Load, Parallel Computing Разработчики средств автоматизации Менеджеры и специалисты по продажам в IT Студенты в поиске перспективной профессии Цель сообщества Создать единую площадку для эффективного общения всех IT- специалистов в контексте “суровой” разработки Ваша выгода Возможность услышать доклады ведущих IT-профессионалов и поделиться своим опытом Бесплатно участвовать в “промо” - версиях топовых IT- конференций стран СНГ Регулярно встречаться лично, на тематическом форуме, в “филиалах” сообщества в социальных сетях и мессенджерах