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

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

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

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

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

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

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

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

Плюси:

Мінуси:

Всі за одного і один за всіх, або 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 до продукту). Драйвер продукту виконує тести на певному білді.

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

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

Висновок

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

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

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

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

Рекомендуємо:

Дайджест цікавих вакансій № 2
12 листопада, Київ - Social Media Marketing Camp
2 - 23 грудня - Онлайн-тренінг з домашніми завданнями "Автоматизація тестів з використанням TestComplete"
Інтерв'ю - Володимир Карпєєв, автор блога vovka.su
Традиційний пост, правда з Хургади