Посидіти автоматизаторів

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

Мені сподобалася одна практика, яку хлопці застосували на посиденьках. Всі учасники склали питання і записали їх на папірцях. Потім ми по черзі задавали свої питання і колективно шукали рішення. Перед тим, як написати питання, яке я задав, розповім про нашу специфіку.

У наших продуктів суміжна предметна область. Наприклад, у кожному продукті є картка підприємства в тому чи іншому вигляді, у всіх продуктах є спільні елементи цієї картки + своя специфіка кожного продукту. Продукти різні за технологіями і ЯП .

Питання звучало так: чи можна писати тести до продуктів з можливістю їх перевикористання в цілій лінійці продуктів, написаних на абсолютно різних технологіях?

З питання розгорілася дискусія, і почалася вона з обговорення варіантів організації відділу автоматизації в структурі компанії в цілому. Ми виділили 2 варіанти.

Все на одного і один для всіх, або Зберемо «золоту» команду крос-мовних автоматизаторів

Відділ автоматизації без залучення розробників займається написанням всієї інфраструктури для автоматизації.

Плюси:

відділи розробки не витрачають час на створення інфраструктури для автоматичних тестів/фреймворків/api і т.д.

Мінуси:

«золота» команда. :) Відділ повинен володіти всіма технологіями компанії і повинен розбиратися у всіх продуктах. Таку команду зібрати дуже складно і дорого

Всі за одного і один за всіх, або Feature Development Team

Команда розробки кожного продукту планує час девелопера для участі в написанні інфраструктури автоматизації. Формується feature development team, тобто команда, яка укомплектована тими фахівцями, які необхідні для вирішення саме цього завдання. У нашому випадку це означає, що автоматизатора на допомогу приходить хтось із розробників.

Плюси:

обов'язкові знання відділу визначаються технологіями, за допомогою яких буде здійснюватися автоматизація тестування продуктів.
розробник, який бере участь в написанні інфраструктури для автоматизації, знає продукт, використовує свої знання про його внутрішній устрій. Полегшує роботу відділу автоматизації і прискорює досягнення результату.

Мінуси:

у відділі розробки доведеться виділяти час розробника для роботи над інфраструктурою автоматизації.

Яку схему вибрати? Мені більше подобається змішана схема.

Змішана схема

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

Володіє плюсами FDT-варіанту і частково нівелює його мінуси. :)

Після цього учасники дали відповідь на моє запитання.

Keyword driven testing!

Відповіддю став наступний варіант: відділ автоматизації бере на озброєння таку методику як keyword driven testing . Тобто тести пишуться в xml-нотації за наступним принципом:

сутність дію дані

Сутність - проектується в подальшому в клас драйвера. Сутності - так само, як і класи - можуть успадковувати один одного.
Дія - проектується в далі в метод класу.

Дані - параметри, які будуть передані в викликані метод класу в драйвері.

Приклад.

сутність дію дані

SitePage open http://test.test/index

TextField type test text

Form SearchForm submit

Існує сховище для цих тестів і парсер. Парсер розбирає їх і запускає на виконання відповідного драйверу продукту (свого роду API до продукту). Драйвер продукту виконує тести на певному білді.

Кожен драйвер розробляється до продукту на своїх технологіях і реалізує дії, визначені в тестах.

У результаті:

відділ QA пише тести за методикою KDT на xml, і тести можуть переіспользоваться для будь-яких продуктів незалежно від технологій. Поріг входження невеликий. Можемо задіяти усіх QA-спеціалістів;
відділ автоматизації власними силами або за підтримки розробників пише драйвера до продукції та актуалізує їх з розвитком продукту;
парсер і сховище тестів реалізуються один раз відділом автоматизації.

Висновок

Мені дуже сподобалося на посиденьках, пройшло і з користю і великим інтересом. Чекаю наступних посиденьок;)

Матеріал підготували Кульпін Віталій і компанія ДубльГІС

PS Ви ще не автоматизуєте? Тоді приходьте до нас! :)

Опубліковано: 13/10/11 @ 06:04
Розділ Різне

SEO Блог