Як стати автоматизатором тестування?

Доброго дня!

Вчора, відповідаючи, здається, вшосте на це питання, твердо вирішив, що прийшов час для написання статті. Відразу зазначу - це виключно моє бачення, з яким, впевнений, добра половина світу автоматизаторів не погодиться, - мій рецепт дещо складніше, ніж «почитати про тулзу», «поставити тулзу», «використовувати тулзу», «написати в резюме, що вмієш користуватися тулзою».

Ця стаття корисна не тільки для мануальних тестувальників, які бажають автоматизувати свої рутинні перевірки, але і для бізнесу і HR-ів, які зважаючи на відсутність будь-яких загальноприйнятих критеріїв, як правило, поняття не мають хто є QA Automation Engineer і в більшості випадків приймають рішення на підставі «хороша людина».

Буває ще гірше - керівник/PM/etc... приходять до своїх мануальних тестувальників і кажуть: "слухай, а може ми автоматизуємо наше тестування - це заощадить нам купу часу і грошей. Скажи, які книги тобі потрібні і які курси ".

0. Почнемо з помилок, які не треба допускати:

• Дайте мені книгу розумну, яка все за мене зробить
• Дайте мені курси платні, які всьому мене навчать
• Дайте мені форуми спеціалізовані, які дадуть відповідь мені на всі запитання
• Дайте мені сертифікацію корисну, з якою мене скрізь приймуть

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

1. У першу чергу треба вибрати мову програмування

Не тулзу, не TestComplete, не тикалки по екрану макросоподібні. А об'єктно-орієнтована мова програмування. Я свого часу попрацював трохи з C #, потім вибрав Java - і досі не пошкодував про зроблений вибір. Але наполягати не стану. Скажу тільки, що ще не стикався з жодною невирішуваною на Java проблемою - навіть Delphi додаток через WinAPI тестується (але краще для таких завдань використовувати дейфійські DUnit та інше).

Отже, ми дізнаємося, що таке примітиви, класи, об'єкти, поліморфізм, інкапсуляція, інтерфейси, абстрактні класи, статичні поля, цикли, масиви, аркуші, мапи, потоки тощо... Це вивчення триватиме в цілому весь час, навіть коли ви вже автоматизуєте тестування. Але на базовому рівні - Junior Java Developer - ви повинні (якщо вибрали Java) бути знайомі з мовою і мати відповідні навички, тому що первинна локалізація проблеми лежить на ваших плечах. Забудьте про «а ось у мене сценарій, помилка награється незрозуміло як і незрозуміло чому» - ваше завдання, щоб розробник знав, що тут ось поруч людина може знайти баги навіть не запускаючи додаток. Не повірите, як раптом якість продукту зростає, коли є людина, яка не просто чує запах погано пахнучого коду, але і може запропонувати рішення щодо поліпшення.

Ми плавно перейшли до

2. Використання шаблонів проектування для розробки тестового фреймворку.

ТАК-ТАК. Ви відкрили, наприклад, Selenium, - всякі приклади, скопіювали бездумно, написали на отриманому «фреймворку» 1000 тестів. Приходить замовник до бізнесу, каже «мені тут потрібно дещо переробити», бізнес приходить до розробника - «нам тут потрібно трохи підлаштуватися під ринок», розробник все прекрасним чином запилює, - 90% тестів падають. Приходять до автоматизатора «ми тут трохи поміняли, треба привести тести в порядок», а автоматизатор у відповідь «тут роботи на місяць»... Упс...

Архітектура фреймворку, який ви пишете, повинна не просто бути гнучкою, а повинна постійно прагнути мінімізувати час рефакторингу наявних тестів і написання нових. В ідеалі, якщо розробник і автоматизатор одночасно сідають виправляти що-небудь, то автоматизатор повинен зробити все швидше і надати розробнику якусь форму TDD.

У створенні такої диво-архітектури нам допомагають патерни проектування та їх грамотне використання... Builder, Facade, Factory, Null Object, Singleton, Adapter і багато інших патернів активно допомагають у вирішенні подібних завдань. Грамотна архітектура тестового фреймворку - це щастя для вас, для розробників, для бізнесу... і в кінцевому рахунку для користувача. Пам'ятайте, що експоненційне зростання ресурсів підтримки тестів при лінійному зростанні/зміні функціоналу свідчить про те, що вам пора допрацьовувати архітектуру движку. З найбільш повним списком набоїв з прикладами на Java можете ознайомитися тут. Окремо зазначу Page Object Pattern, але краще, спочатку познайомитися з класичними.

3. Використання бібліотек

Те, що плавно вливається в будь-які завдання, - зовнішні API, бібліотеки, драйвери та інші принади. Selenium - тестуємо Web, Robotium/Espresso - тестуємо Android, Fest/Jemmy - тестуємо Java Swing, JemmyFX - тестуємо JavaFX, чудові Apache HttpComponents - робимо запити і тестуємо безліч API... Бібліотек прекрасних багато написано майже під будь-яке завдання - про деякі з них можна почитати тут. Не варто боятися того, що їх багато - ви вже достатньо знаєте, щоб вибрати те, що вам підходить/подобається/вписується в архітектуру. Наприклад, під тестування Java Swing додатків я використовую JUnit, Fest, Mockito і широкі можливості java.lang.reflect - цього набору мені більш ніж вистачає.

Будьте готові до частого відвідування stackoverflow і подібних ресурсів на ранніх етапах. Будьте готові до того, що іноді треба буде зазирнути у вихідники. І найголовніше - не бійтеся не розібратися.

4. Планування тестів/написання тестів

У рамках цієї статті я не розповідаю про те, що згубна для будь-якого проекту ідея про 100% покриття, про розклад сценаріїв тощо. Взагалі класичні підходи до тестування згубні в автоматизованому тестуванні -, наприклад, ізольовані вхідні дані для тестів. Загалом тут вже грають роль ваші навички, вміння аналітично мислити, вміння сумніватися в тому, в чому варто сумніватися і не шукати проблему там, де її не може бути. Хороші сценарії тестів - це як хороший інтерфейс... ідеальними бути не можуть. Мій досвід дає таку статистику: 5% всіх сценаріїв забезпечує 95% покриття функціоналу. На поточному проекті у нас 180 повноцінних функціональних тестів за майже 2 роки роботи, які забезпечують нам ці 95% - 99%, шість успішних впроваджень - на виході трохи low зауважень, які абсолютно не позначилися на основному функціоналі і на лояльності клієнтів, і були швидко поправлені. Але заради них городити ще 2000 тестів невигідно чисто по грошах - це я звертаюся в бік керівників і бізнесу, які мріють про 100% покриття. Повірте мені, воно вам не потрібно. Тут обмовлюся, якщо мова йде не про автоматичне тестування безпеки або білінгу - тут ризики повинні бути не мінімізовані, а, по можливості, зведені до нуля. Але це окрема історія...

5***. Написання інструмента та власних бібліотек

Тут зірочки... У вас вже все чудово на проекті, регрес покритий, тести ганяються, розробники спокійні і можуть спокійно рефакторити архітектуру, не боячись зламати наявний функціонал. Але, наприклад, для того, щоб щось семулювати руками, розробнику доводиться проробляти з місяця в місяць одну і ту ж дію руками. Напишіть для нього утиліту, що оптимізує ці процеси, включіть туди всякі невалидні сценарії, розрекламуйте на рівні компанії, - нехай всі почнуть користуватися... Це прискорить роботу і, як не дивно, зменшить кількість багів, так як у розробника з'явиться більше часу на те, щоб перевірити побільше сценаріїв, перш ніж розмітити змінення в гілку. Озираєтеся по сторонах і ви побачите так багато процесів, які можна автоматизувати, що не будете знати, за що взятися.

Пишіть досить абстрактні бібліотеки, які можуть бути використаними на різних проектах у вашій компанії, та й просто у вашій роботі в майбутньому.

Ув'язнення

Ви, звичайно, можете про себе подумати «жееесть», але...

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

P.S.

До бізнесу, керівників, фахівців з підбору персоналу:

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