От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
Шаги мануальщика к автоматизации на крупном проекте
1. Шаги мануальщика к автоматизации
на крупном проекте.
Когут Андрей, Softengi
2. О компании
•
•
•
•
Компания Softengi – поставщик услуг в области разработки ПО
Мы работаем преимущественно на рынках Европы и США
16+ лет опыта в области разработки программного обеспечения
Компания входит в Intecracy Group, международный ИТ консорциум
О проекте
•
•
•
Приложение – ERP система по анализу выбросов в окружающую среду
Отдел тестирования – 20 человек
Проект – мамонт (12 лет разработки, 21 модуль + дополнения)
Больше о нас:
www.softengi.com
www.facebook.com/softengi_ua
11. Состав рабочей группы
Основной состав:
•
Технарь (тестировщик)
•
Исполнитель (тестировщик)
•
“Пинатель”
•
Идейные вдохновители
•
Менеджер проекта
Дополнительная помощь:
•
Архитектор
•
Системный администратор
12. Предварительный
план действий
1. Определиться с проектом/версией для автоматизации
2. Выбрать модуль и определиться с глубиной тестирования
3. Выбрать инструмент автоматизации
4. Составить верхнеуровневый план действий/работ и оценить
ориентировочное время
5. Внедрение
13. Правила подачи менеджеру
•
Кто ваш менеджер?...
•
Экономический эффект!
•
Ожидаемое место применения
•
Разбить проект на спринты, по 1-2 недели каждый
Правила хорошего тона:
- Не удлинять спринт
- Не грузить техническими деталями
(предоставлять по необходимости)
14. Анализ эффективности
• Размер проекта
• Глубина/масштабность изменений
• Оценка затрат времени на ручное и автотестирование
T(manual_total) = T(manual_smoke) * N(modules) * N(smokes) = 2 * 13 * 24 = 624 h
T(automation_total) = T(dev_smoke) * N(modules) + T(logs_analysis) + T(maintenance) =
= 20 * 13 + 65 + 104 = 429 h
16. Внедрение
Доступно с первого кейса!
•
Организация хранения кода
•
“Continuous integration”
•
Анализ логов
•
Анализ проблем на конкретном
окружении - устранение
18. Главное – не
останавливаться
•
Мониторинг результатов спринта
•
Регулярные митинги! Сообщаем результаты
•
Формат логов (экономим время)
•
Review инструмента – проблемы,
меняем ли инструмент
•
Пересматриваем глобальные цели
19. Выбор инструмента
Telerik
Selenium
IBM RFT
TestComplete
http://www.telerik.com/
http://docs.seleniumhq.org/about/
http://www03.ibm.com/software/prod
ucts/us/en/functional/
http://smartbear.com/products/qatools/automated-testing-tools
C# supported
C# supported
Java, Visual basic .NET
C#Script (and similar, based on
JScript)
Good
Believed to be good
(no huge problems were observed by
web search)
Believed to be normal
(no huge problems were observed by
web search)
Good
Good
Medium
(has own visual editor)
Normal
(properties in source files)
link
Test script
language(s),
especially C# support
Interaction with UI (IE)
UI elements
recognition properties
management
Normal
(xpath in source files)
UI elements capture
Test studio – DOM explorer + capgure from
page;
Testing framework – Xpath in source code
Xpath in source code
Capture from page
DOM explorer
License
Test studio - License ;
Testing framework – free;
Regular updates
Free;
Open source
There are updates
License
License
Supported by IBM, but
there is no active
development
There are updates
Community, popularity
IDE
Special IE launching
requirements
Probably medium
MSVS
Needs to start new IE window;
Then can attach to new IE windows derived
from parent window; supports pop-ups
poor
Eclipse
Can use existing IE
window(s)
big
Own IDE
Can use existing IE window(s)
Comment
Telerik specify on Microsoft technologines;
C# is a major language for telerik;
big
MSVS (for C#)
Needs to start new IE window;
Then can attach to new IE windows
derived from parent window; supports
pop-ups
Open source – some important bugs
can be postponed;
IE is not a major browser for selenium;
C# is not a major language for
selenium;
Support, development
Used by Enviance
Компания без проектов по автоматизацииТестировщики-мануальщикиБольшой версионный проектСомневающийся менеджментНету запроса/финансирования от заказчикаХочу привести основные характеристики компании, которая вроде хотела бы автоматизировать тестирование, но не уверена, стоит ли начинать. Для примера возьму компанию, в которой работаю, это:Компания с большим версионным проектом.Компания без проектов по автоматизацииОтдел тестирования состоит из тестировщиков-мануальщиковСомневающийся менеджментНету запроса/финансирования от заказчика???Автоматизированное тестирование ПО— процесс тестирования программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, производятся автоматически с помощью инструментов для автоматизированного тестирования.
Что же делать и с чего начать?
В первую очередь нужно желание!Обычно возникает желание, у инициативного тестировщика, когда он выполняет тест-кейс «100-500-ый» раз.
У менеджмента и заказчика это желание обычно связано с тем, чтобы всегда быть в курсе, стабильно ли приложение.Специфика нашего проекта предполагает большое количество смоук-тестов, поэтому мы начали покрытие автотестами high-level тест кейсов.????Установочное тестированиеКонфигурационное тестированиеТестирование производительности.
В некоторых случаях автоматизация обусловлена необходимостью и тут уже нету смысла размышлять, стоит ли начинать. К этим случаям можна отнести программы для космической, военной, здравоохранительной промышленности.
Автоматизируем в первую очередь:- то, что руками практически невозможно протестировать;- те проекты, где применяются точные и сложные математические расчёты;- большие объемы данных- «Скучные» тест кейсы, которые «замыливают» глаз тестировщика.
Исключен «человеческий фактор». Сильное достоинство. Все мы люди и никто из нас не застрахован от ошибок. Выполняемый же тест-скрипт не пропустит тест по неосторожности и ничего не напутает в результатах.Быстрое выполнение – автоматизированному скрипту не нужно сверяться с инструкциями и документациями.Меньшие затраты на поддержку – когда скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.Отчеты – автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.Выполнение без вмешательства – во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время.
Повторяемость – все написанные тесты всегда будут выполняться однообразно. Это одновременно является и недостатком и преимуществом, так как тестировщик, выполняя тест вручную, может обратить внимание на некоторые детали и найти возникший дефект. Скрипт этого, увы, сделать не может.Затраты на поддержку – чем чаще изменяется приложение, тем они выше.Большие затраты на разработку – разработка автоматизированных тестов это сложный процесс, так как фактически идет разработка приложения, которое тестирует другое приложение. Стоимость инструмента для автоматизации – в случае, если используется лицензионное ПО, его стоимость может быть достаточно высока. Свободно распространяемые инструменты, как правило, отличаются более скромным функционалом и меньшим удобством работы.Пропуск мелких ошибок — автоматический скрипт может пропускать мелкие ошибки, на проверку которых он не запрограммирован.
? Кто будет писать CL/специф. на автотесты? Технарь – разработчик тестов + человек, который будет анализировать результаты тестовПинатель – менеджер, который будет двигать проект SCRUM MASTERИдейные вдохновителиStakeholderМенеджер проекта Product OwnerАрхитектор – помощь в архитектуре тестовСистемный администратор – настройка запуска тестовИдейные вдохновители (бизнес-применение, представители проекта)