Але в покритті мене також цікавить якими саме тестами воно покрите. Можна наслідувати мій приклад і спробувати поєднати навчання з роботою. Так ви збережете зарплату, але на кілька місяців повністю забудете про існування вільного часу. Півроку тому ми вакансія Middle Manual QA з колегами організували в офісі власний навчальний центр з автотестування. Почали приймати на навчання студентів останніх курсів і людей, які вирішили змінити сферу діяльності. Одного разу ми з моїм менеджером обговорювали мій подальший розвиток.
Завів 5 дефектів по існуючих степах, сказав, що все працює класно, нових регресій — 5. Ви можете послухати войсчат у записі або прочитати текстові тези у цьому матеріалі. Таймкоди по темах розставлені у заголовках матеріалу. QA інженер може перетворитися в менеджера проектів.
Перший кейс — це коли сліпо приводили Gherkin-описи тестів у вигляді Gherkin сценаріїв. Коли це не було як процес, conduct driven improvement. Комунікація з інженірінгом не виконувалась у вигляді Gherkin. Якщо ви лише паралельно працюєте над автоматизацією — залежить від бюджету. Ми хочемо перевірити, що щось у нас працює так, як треба, або не так. Вона показала, що у другій половині 2021 року зарплати активно зростали у спеціалістів Automation QA.
Для мене лички — це і є обов’язки. У нас їх просто не юзають за призначенням, але то проблема нашого ринка. Навіщо придумали назви паттернам, якщо паттерн — це типове рішення типової проблеми?
І клиент тупо релізить такую команду бо з нею профіта нема. Задача автоматизації — найменшими зусяллями зробити найбільший кавередж. Тести повинні перш за все велью приносити а не буди мегагнучкими. Як на мене, це наступна ланка еволюції інженера з автоматизації тестування. Глобально, це та сама ціль — звільнити мануальщиків від рутини регресії та швидкий відгук девелоперам на їх зміни в коді. А ось як того досягти — то вже інша історія.
Хотіли подолати бар’єр, де мануальщики тільки мануалять, а автоматизатори тільки автоматизують. Ми вчили мануальщиків автоматизувати, а вони нас — тест-кейси писати. У нас був один словник термінів, а всі тести були синхронізовані. Часто люди перебільшують свій біль з BDD, або дійсно погана кодова база. Не подобаються системи, де мануальні QA автоматизують, або автоматизатори мануалять, бо в якийсь момент починають лажати й ті, й інші.
Вони теж колись були на вашому місці й припускалися таких же помилок. Обговорюючи будь-яку задачу з досвідченими автоматизаторами, ви розширюєте свій професійний кругозір. Припустимо, ви зрозуміли, що хочете розвиватися як тестувальник-автоматизатор і готові витратити час на навчання.
Сьогодні це можна зробити з допомогою Katalon Studio, який замінив Selenium IDE. Такі завдання підігрівають інтерес до вивчення автоматизації. Потім можна буде перейти до вивчення теорії та специфіки автоматизації, а також почати опановувати мову програмування в зв’язці з Selenium WebDriver. Я часто бачу тести, написані на функціональність, яка рідко змінюється, рідко відбувається дефекти. Перевіряють форму валідації, де валідатори ніхто ніколи не міняє.
І зробити рев’ю важче ніж поставити локатори. На девівський гімнокод є свій Dev лід чи менеджер, який за нього і відповідає, в т.ч. І хто замінює автора гімнокоду, і має його рефакторити, це не Ваші проблеми як QA Manager-a. Лого, лейбли і все інше маленьке треба виносити в юніт тести. Які є швидкі і надійні на відміну від UI рівня. В цьому взагалі головна суть статті.
По-перше мають бути правила, які не дозволяють пушити напряму в головну бранчу і не дозволяють мерджити без рев’ю. Для девелопера це, так, беклог, грумінг, планінг, спрінт, фікс. Ну і хто ж його зна, в залежності від бага і пріоритетів, коли та таска попаде в спринт. Я ж роблю в рамках своєї задачі тут і зараз. З фіча бранчою, динамічним енвом для теста, ПР-ом і всім, чим треба. Такий підхід має право на життя, але особисто мені не подобається.
Наступні шість місяців я працював та навчався — вечорами, у вихідні, у свята. Все ускладнювалося тим, що перші три місяці я був у відрядженні на новому проєкті. Після роботи я повертався у готель з думками про те, що якщо не здам вчасно домашнє завдання, то накопичу борги, за які мене можуть відрахувати. Для мене це був жахливий стрес, я навіть схуд на кілька кілограмів. У багатьох великих IТ-компаніях є внутрішні (як правило, безплатні) курси з тестування.
Але тільки тестувальник QA може гарантувати його життєздатність. Такий фахівець потрібен кожен команді. Давайте з’ясуємо, чим же він займається. Роблю висновок, що вам не цікаво читати, що я тут відповідаю. Ми одне і те саме обговорюємо під різними коментами.
Але вони корисні для проєкту, бо добре знають бізнес-логіку. І вони можуть добре домовитись, не все вирішується технічними скілами. Головна складність професії в її багатопрофільність. Адже QA інженер-автоматор – це одночасно і тестувальник ПЗ, і програміст. Стрімкий розвиток технологій не полегшує життя.
QA Testing передбачає вивчення продукту в різних умовах, пошук дефектів і шляхів їх виправлення. Якщо дуже погано зробити і тести і рефакторин, то може звичайно. Але, якщо ти правильно написав тест, то функціонал не перестане правильно працювати після рефакторингу. І не треба ото тянути гугловських сдетів до нашого ринку.
В моєму розумінні sdet драйвить тестабельність коду. А це означає і юніт тести і зміни в дев коді, якщо на то не можна написати юніт тести в оригінальному вигляді. Бо якщо мануальщики хочуть тест, який не лягає на UI рівень, то хто, як не sdet буде робити юніт тест. Наші описи позиції багато в чому пересікаються, але є й різниця. Сорі, але тут пахне якимось комплексом чужого коду і неосяжності коду, який пишуть деви.
Однозначно потрібно пробувати потрапити туди, особливо якщо хочете працювати в компанії-організаторі таких курсів. Мінус подібного навколокорпоративного навчання — воно часто буває вузькоспрямованим і не зовсім підходить за своїм змістом середнім вимогам ринку. Платні курси, яких безліч, частіше дають ширшу програму підготовки. Ми здебільшого займаємось контролем якості і робимо припущення. Здебільшого ми пишемо кодяру, беремо функціонал і верифікуємо його або валідуємо, чи він ок з вимогами чи очікуваннями користувачів. Ми можемо сповістити команду про те, що в продукті щось погано, знайти проблему, щоб її пофіксили.
Типу коли ти кажеш «сінглтон» всі розуміють про що ти. KISS не означає, що в тебе не буде складного коду взагалі. Якщо у тебе велике рішення і багато функціоналу, то, щоб воно масштабувалося і то було легко підтримувати — десь обов’язково буде складно.
Всі працюють на межі, бо не вистачає часу, щоб доавтоматизовувати, дорозробляти, написати новий модуль. І постійна гонитва за тим, чого від нас вимагають замовники чи менеджмент. Необхідно розуміти, що курси – це не панацея. А ще не варто забувати, що тестувальник – це ще й особливий склад розуму.
Бо може настати момент, коли підтримка цього всього стає настільки недоцільною, що займає весь час, який у нас є. І ні про яку in sprint автоматизацію вже мова не йде. Бо цей шалаш, який ми там збудували, треба ще й не розвалити, бо на ньому все тримається, вся якість. Якщо є така постійна ціль, то коли виникає щось червоне, ми все кидаємо і фіксимо. Інженери-розробники можуть писати власноруч тести для мобілки і скріна.
Usability-тестувальники перевіряють, наскільки продукт зручний у використанні та привабливий для користувача. Важливо починати писати тести на умовний фреймворк, не починайте писати його одразу гігантським, почніть з тестів. А вже потім можна буде робити оптимізацію по ходу. Чим людина стає синьйорнішою, тим більш розвинуті в неї мають бути софт скіли, бо могти пояснити замовнику чому щось так — дуже важливо. Дуже багато тім лідів і синьйорів не можуть зробити це. Дефіцит знань може бути, я теж зустрічав людей, які по 15 років у тестуванні і дуже слабенькі.