Roman Yakymchuk Consulting

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

В цьому місяці маю всього часу на 15 zoom-зустрічей
Тому якщо ви бажаєте змінити щось у вашій кар'єрі - записуйтесь

Урок 5: Швидко знаходьте критичні помилки

Ймовірно, в ваші цілі входить пошук критичних багів і він має бути швидким. Якщо так, то що це означає в контексті тестування?

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

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

Уривок взято з книги Lessons Learned in Software Testing

Давав інтерв'ю про свій розвиток, можливо і вам буде корисно 🙏🏻

А навіщо ці Bug Triage мітинги?

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

І ось для того щоб правильно впорядкувати та відсортувати баги, нам потрібно проводити ці Bug Triage мітинги. На такому мітингу мають бути присутні, QA, це може бути або лід або хтось хто добре знає систему, Dev або Tech Lead, PO продукт овнер.

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

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

Bug Triage бажано проводити регулярно хоча б раз на тиждень. В результаті можна оформити табличку в Confluence з переглянутими багами та відсортувати їх за пріоритетами. Закриті баги та дублікати також вказуємо, щоб команді було зрозуміло, які вже неактуальні. Ну і щоб вони пам'ятали що ці баги були закриті і мати на увазі коли буде проводитись регресія, переглядати цей список, як ризикові.

Roman Yakymchuk Consulting pinned «Друзі привіт, скажіть чи цікаво буде вам 5 денний інтенсив, де ви зможете попрактикуватися у роботі з проектом, використовуючи Jira, систему менеджменту тестів Testomatio, створення плану і використання різних технік тест дизайну на практиці? Якщо цікаво…»

Друзі привіт, скажіть чи цікаво буде вам 5 денний інтенсив, де ви зможете попрактикуватися у роботі з проектом, використовуючи Jira, систему менеджменту тестів Testomatio, створення плану і використання різних технік тест дизайну на практиці?

Якщо цікаво, пишіть в приват, розповім деталі
@yakymchuk_roma

Участь буде за донат

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

Я пропоную консультацію за донат, на якій ми:
✅ Розберемо вашу поточну ситуацію в QA.
✅ Складемо покроковий план вашого розвитку.
✅ Визначимо, як досягти ваших кар’єрних цілей у найближчі 12 місяців.

Не втрачайте час на хаотичне навчання — почніть розвиватися усвідомлено!

Всього 30 місць, то ж не прогавте свій шанс: записуйтесь на консультацію

🔗 Рік змін починається з одного рішення. Давайте створимо ваш успіх разом! 💪

Після успішно найму кандидата, вам потрібно підготувати план адаптації Onboarding Plan

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

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

Перший день виходу на роботу
Ознайомлення з компанією, цінностями та правилами. HR може розповісти та познайомити з загальними положеннями компанії.
Тур по офісу, показати де які зони знаходяться: робоче місце, кімнати для мітингів, кімнати відпочинку, кухні, вбиральні та інші зручності.
Представлення нового співробітника усій команді та знайомство з персональним менеджером.
Далі вже менеджер може пройтись по чеклісту інструментів, різних акаунтів і представити програму онбордингу розписану в Confluence або іншій wiki системі.

Призначте Ментора (Buddy) людину з досвідом, яка зможе допомагати з розвитком та ознайомленням з проектом та відповідати на питання.

Більш детально розкажіть про проект, підготуйте гайди, або відео інструкції, для швидкого ознайомлення з проектом (я готую це все в Loom)
Розкажіть про роль, обов'язки та які очікування стоять.

Ознайомте людину з процесами, підготуйте діаграми та детальні інструкції щодо взаємодії на проекті. Розкажіть про інструменти, які використовуються на проекті та також надайте інструкції з прикладами застосування.

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

Робіть щотижневі 1 на 1 зустрічі з менеджером
Обговорюйте прогрес, питання чи виклики з якими стикається новенький.

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

На 3му тижні поступово впроваджуйте людину в проект і команду, давайте задачі з існуючих ітерацій та контролюйте їх виконання.

Оцінка та завершення онбордингу дуже важлива стадія. На якій вам, як менеджеру потрібно проаналізувати весь період (припустимо це 90 днів).
Переглянути прогрес та якість виконання обов'язків та завдань.
Чи були досягнуті поставлені цілі.
Зберіть зворотній зв'язок від команди, чи задоволені вони співпрацею з новою людиною.
Розплануйте подальші тренінги та активності.

І обов'язково візьміть фідбек у людини по процесу онбордингу, і якщо потрібно додайте ще якісь моменти в план, щоб покращувати цей процес.

Трішки статистики - цей курс пройшло близько 300 людей
Після курсу влаштувалось на роботу 30 новачків
Завдяки курсу близько 10 людей змінили свою позицію з ростом в доходах
5 людей відновилися і знайшли роботу після довгої перерви як от декретна відпустка (це доречі як виявилось проблема на ринку, вийти на роботу з перервою)

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

Програма складається з 12 уроків:
Урок 1: Декомпозиція продукту, аналіз параметрів та значень
Урок 2: Тестування станів та переходів
Урок 3: Попарне тестування та Таблиці рішень
Урок 4: Робота з Jira. Створення задач та організація проектної документації
Урок 5: Організація тестового процесу за допомогою системи менеджменту тестів
Урок 6: Створення баг репортів
Урок 7: SQL практика створення запитів на локальній базі даних
Урок 8: Тест план і Стратегія тестування
Урок 9: Дослідницьке тестування
Урок 10: API тестування з Postman та ChromeDev Tools
Урок 11: Налаштування тестових процесів, коли ви один тестувальник на новому проекті
Урок 12: Налаштування тестових процесів, коли ви тестувальник у великій команді.

Придбати можна на сайті https://test-marathon.ry-consulting.online/
Записи залишаться у вічному доступі

Привіт, сьогодні поговоримо про формування команди

Найм правильних людей в команду передбачає наступні кроки:
◽Чітко визначити посаду на яку ми наймаємо людину
◾Випишіть навички та вміння, яким має відповідати кандидат, щоб зайняти цю посаду
◽Сформуйте вакансію де опишіть: які завдання та обов'язки матиме успішний кандидат, який досвід має бути і скільки, якими конкретними навичками та інструментами має володіти кандидат, які додаткові навички було б добре щоб мав кандидат, якщо потрібна якась певна сертифікація, також вказуємо це у вакансії
◾Після розміщення вакансії, відфільтруйте кандидатів, які підходять вам за описом в резюме
◽Якщо потрібно, підготуйте тестове завдання, яке буде схоже на активності якими має займатися кандидат на вашому проекті
◾Після успішного виконання тестового запросіть кандидата на співбесіду
◽Бажано щоб кілька людей проводило співбесіду, щоб сформувати колективну думку по кандидату, якщо у вас маленька команда і ви один тестувальник на проекті і тільки набираєте собі команду, можете покликати з собою девелопера

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

Привіт колеги 👋
Продовжуємо тему тест-менеджменту і сьогодні поговоримо про види стратегій тестування

Аналітична Стратегія
◽️Узгодження тестування з чітко визначеними базисами тестування (Вимоги, дизайни, прототипи, діаграми і т. д.)
◾️Вимірювання тестування на основі тестових базисів (Матриця трасування вимог, матриця трасування багів по відношенню до тестів)
◽️Запобігання дефектам шляхом раннього аналізу тест базисів (Аналіз вимог, аналіз ризиків, дослідження за допомогою декомпозиції)

Стратегія на основі моделей
◾️Моделювання на основі реальних статистичних даних, наприклад навантаження на систему, як от аналіз кількості клієнтів у магазині на чорну п’ятницю
◽️Аналіз вхідних і вихідних даних, наприклад шифрування конфіденційних даних або паролів користувачів

Методична стратегія
◾️Використання чеклістів та тест кейсів
◽️Використання чітлістів

Реактивна Стратегія
◾️Використання тест чартерів та інших підходів дослідницького тестування
◽️Тест кейси розробляти згідно технікам основаним на попередньому досвіді або на попередніх дефектах

Консультативна Стратегія
◾️Зацікавлені сторони з бізнесової сторони надають інформацію по девайсам, платформам та іншим можливим конфігураціям, на яких потрібно провести тестування

Регресійна Стратегія
◽️Використання аналізу залежностей для відбору тестів
◾️Використання пріоритезації і кластеризації функціоналу

Стратегія Автоматизації
◽️API тестування
◾️UI тестування
◽️Інтеграційне тестування
◾️Мобільне тестування

Привіт 👋🏻
Цей рік розпочнемо з серії статей про тест-менеджмент 👇🏻

Що таке тест-менеджмент і чому це важливо?

Тест менеджмент - це процес управління всіма аспектами тестування, метою якого є забезпечення якості продукту, зберігаючи баланс між часом, ресурсами та очікуваннями бізнесу.

Що включає тест-менеджмент:
◽ Планування тестування та розробка стратегії
◾ Управління ресурсами
◽ Контроль і моніторинг процесу
◾ Управління ризиками
◽ Спілкування з зацікавленими сторонами
◾ Забезпечення якості
◽ Покращення процесів

Проблеми з якими стикаються тест менеджери:
◽ Обмеження часу та ресурсів
◾ Складність додатків
◽ Зміна технологічного різновиду
◾ Управління командами та мотивація
◽Балансування між якістю та потребами бізнесу

Відпускаючи 2024 хочу сказати дякую кожному тут🙏🏼
За те, що цікавитесь, читаєте, підтримуєте і мотивуєтесь.
Рік був важким, але всі наші зусилля завжди винагороджуються🙌🏼

Вітаю з прийдешнім 2025 Новим Роком 🥳🎄

Хочу побажати вам та вашим рідним здоров'я, добра, любові та гармонії. Щоб були класні проекти та чудові злагоджені команди, щоб ви досягали найкращих результатів та збирали плоди ваших зусиль🎁

До зустрічі у 2025 🩶

Всім привіт,
Анонси навчання на найближчий час

Наступна група по Тест Менеджменту планується з 20 січня
Тест Аналіз також десь в тих числах

Зараз також запустив менторську програму тривалістю 4 місяці, тому кому що цікаво, пишіть мені розповім всі деталі

Сьогодні після насиченого роботою дня, ми святкуємо 2 рочки Мімі 🥳

Всім гарного вечора 🙏

Багато від кого чую, що у нас немає ніяких процесів на проекті, повний хаос і постійні овертайми

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

Почніть організовувати процес хоча б з цього. Робіть майнд карти з декомпозицію - це теж документація, по ним теж можна тестувати.

Налаштуйте свою Jira. Використовуйте фільтри. Задачі заасайнені на вас, баги створені вами. Пріоритезуйте задачі, рухайтесь логічно і хаос поступово зникне.

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

Штучний інтелект - наш найкращий інструмент, але не заміна нашого мозку.

Тестування - це мистецтво, яке поєднує в собі різні підходи, ваш досвід та інтуіцію. ШІ, як потужний інструмент, допомагає нам автоматизувати рутинні завдання та аналізувати величезні обсяги даних, що значно прискорює процес тестування. Але саме людський інтелект дозволяє нам:

Мислити критично: знаходити нестандартні рішення та виявляти приховані помилки, які алгоритми можуть пропустити. Наприклад, тільки людина може помітити, що інтерфейс програми неінтуїтивний або що повідомлення про помилку важко зрозуміти

Бути креативним: розробляти нові тестові сценарії та підходи, які зможуть виявити непередбачувані проблеми. ШІ може генерувати тестові дані, але саме людина може визначити, які дані є найбільш релевантними для конкретного тесту

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

Як ми можемо застосовувати ШІ в тестуванні?

Автоматизація рутинних тестів: ШІ може виконувати повторювані дії, такі як заповнення форм, натискання кнопок, перевірка функціональності. Це дозволяє тестувальникам зосередитися на більш складних завданнях

Аналіз логів: ШІ може автоматично аналізувати великі обсяги лог-файлів, щоб виявити помилки та аномалії, які важко помітити вручну

Генерація тестових даних: ШІ може генерувати різноманітні тестові дані, що дозволяє більш ретельно перевірити програму на надійність

Візуальне тестування: ШІ може порівнювати скріншоти, щоб виявити візуальні відмінності та зміни в інтерфейсі

Прогнозування помилок: на основі історичних даних ШІ може прогнозувати, де можуть виникнути нові помилки

Чи використовуєте ви штучний інтелект на своїх проектах, поділіться в коментарях?

Записатися на безкоштовну консультацію з покроковим планом розвитку

Друзі, рекомендую долучитися до конференції 👆

Конференція тестувальників вже завтра, а нам лишилося тільки нагадати основні її деталі.

👉Доєднатися: https://betelgeuse.qaukraine.online/

Всім привіт, на наступному тижні буду мати кілька вільних годин, для проведення для вас безкоштовних розборів та оформлення покрокового плану розвитку

Тому, хто хоче визначитись, куди далі рости, записуйтесь
https://forms.gle/Ym9arAgwbBxqVpgx6

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

Якщо ви пам'ятаєте, що таке матриця трасування, то вона показує покриття одного об'єкта іншим. Наприклад User Story vs Tests, або Bug vs Tests. Здавалося б звичайна річ, але часто за допомогою цього інструменту можна виявити прогалини в покритті.

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

Але часто люди забувають про борги свої технічні і от як зараз є близько 100 ітемів, яких потрібно покрити тестами. Здавалося б що це не проблема, але це велика проблема. Недостатнє покриття призводить до багів, які накопичуються в тому функціоналі, який ви не перевіряєте, бо немає ж по чому перевіряти. Баги також мають покриватися тестами і теж валідуватися.

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

Слідкуйте за якістю 😉

Як покращити свої практичні навички тестування за 1 годину. Отримай свій покроковий план розвитку 🔥

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

Підходи до тестування великих даних (Big Data)

Тестування Big Data - це не лише виклик, а й справжнє мистецтво, адже обсяги, швидкість і різноманітність даних створюють нові вимоги до якості продукту. Як же перевірити, що все працює коректно?

1️⃣ Валідація даних (Data Validation)

Переконайтеся, що дані, які надходять у систему, відповідають очікуваним форматам, діапазонам значень і типам. Наприклад, числові поля не містять текстових значень, а дати дотримуються правильного формату.
Використовуйте інструменти для перевірки якості даних, такі як Apache Spark або Talend.

2️⃣ Тестування ETL-процесів

ETL (Extract, Transform, Load) — це основа роботи з великими даними. Перевірте, що дані коректно витягуються з джерел, трансформуються відповідно до правил і завантажуються без втрат.
Робіть перевірки цілісності даних до і після трансформації: чи не було загублено чи спотворено важливу інформацію.

3️⃣ Тестування продуктивності (Performance Testing)

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

4️⃣ Тестування обробки даних у реальному часі

Для систем, які обробляють дані в реальному часі (наприклад, потоки подій), важливо перевірити, чи затримки не перевищують допустимих меж.
Враховуйте обмеження пропускної здатності і час реакції на події.

5️⃣ Тестування збереження і відновлення даних

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

6️⃣ Тестування аналітичних запитів

Велику увагу приділяйте перевірці аналітичних запитів, які виконуються над даними. Чи видають вони правильні результати? Чи ефективно обробляють величезні обсяги інформації?
Для цього використовуйте техніки валідації результатів: порівнюйте з очікуваними даними, застосовуйте різні сценарії для перевірки коректності.

7️⃣ Аналіз даних і пошук аномалій

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

📝 На що звернути увагу?

Грамотно продумуйте свої тестові сценарії, адже в умовах великих даних часто неможливо протестувати абсолютно все.

Використовуйте техніки тест аналізу та комбінаторики, щоб оптимізувати процеси тестування.

🤔 Чи доводилось вам тестувати Big Data? Діліться вашим досвідом у коментарях

Останнім часом, багато дуже провожу особистих консультацій і основна проблема, яку я побачив у багатьох людей, це невпевненність, не розуміння куди далі рухатись і що робити. Я застряг на місці і не бачу розвитку на проекті.

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

Тому, хто хоче визначитись, куди далі рости, записуйтесь
https://forms.gle/Ym9arAgwbBxqVpgx6

Всім привіт 👋

від сьогодні і до 29 листопада будуть діяти знижки до Black Friday на всі курси 🔥
Тест Марафон -50% знижки
Тест Аналіз -15% знижки
Тест Менеджмент -30% знижки

Курси вже пройшло більше 500 людей та підвищили свою ефективність на проектах, а хтось навіть отримав свою першу роботу після них.

Деталі по старту курсів запитуйте в приват @yakymchuk_roma

Привіт, сьогодні хочу підняти важливу тему для початківців.

Коли ви перший раз приходите на роботу, НЕ БІЙТЕСЯ ЗАДАВАТИ ПИТАННЯ. І чим раніше ви навчитеся задавати питання, тим швидше ви почнете приносити результат.

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

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

Не тягніть, не сидіть над задачею, годинами чи днями. Не зрозуміло, ПИТАЙ.

Ну і ще на останок, вчіться правильно задавати питання, бо деколи, правильно сформульоване питання, може уже бути частиною вашої відповіді 🤫

Блін гайз! Ну хватить вже страждати роками з старими, повільними та заскурублими тестрейлами, ікс-реями та кютестами. Переходьте на новітню testomat.io!

Кодове слово FUCKOFFTESTRAIL звертайтесь в саппорт, і ми допоможемо вам переїхати. А тим хто готовий переїхати на протязі наступного тижня буде супер знижка 😎 Акція дійсна для українців! Не страждайте та переходьте на українську TMS.

Звертайтесь

Привіт 👋

Сьогодні хочу поділитися з вами коротеньким відео по використанню такого інструменту як AI Test Case Generator.

У відео я показую, як цей інструмент працює. Створивши вимоги, ми запускаємо генератор тест кейсів і він створює нам тести відразу лінкуючи їх до задач в Jira.

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

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

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

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

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

Дякую за підтримку, дискусії та ваші думки щодо мого рішення.
Але тепер повернемося до ведення цього каналу на професійні теми.
Я продовжую жити, донатити та давати вам користь 🙌

Всім привіт

Почнемо з головних новин, багато хто з вас вже знає, а хтось ще ні. Я виїхав з України.

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

Але паралельно на навчаннях, багато хлопців розповідали різні історії про те, що з цієї частини всіх відправляють відразу на 0, і ти не зможеш перевестися. Я також уточнював цю інформацію у своїх командирів, які прямо відповіли, “Ти можеш зробити відношення (документ про перевід між частинами), але відразу скажу що можеш засунути його в одне місце, бо у нас це не працює, куди скажуть туди й тебе відправимо”
Ця ситуація звісно ж не сильно мене влаштовувала. Також на навчаннях в польових умовах, я сильно захворів та ліг в госпіталь на лікування з високою температурою та постійним кашлем, що не зупинявся вже кілька тижнів. Певний час поки я лікувався, я все ще намагався якось перевестися в інший навчальний центр, щоб звідти попасти в ІТ підрозділ, але всі дії які я робив, не давали бажаного результату.
Хлопців з якими я навчався вже відправили на фронт і через тиждень, я дізнався що половини складу вже немає, що мене дуже засмутило. Тоді я вирішив залишити терени нашої країни.

Для себе я зробив вибір, жити і приносити користь там, де я можу.
Більшість людей мене підтримує, це дуже приємно, але є ті, хто засуджує цей вчинок. Але це моє життя, яке в мене одне, і мій вибір. Я хочу жити і продовжувати забезпечувати свою сімʼю, виконувати свою місію - навчати. Та донатити, як і робив це весь час.

І так, давайте почнемо з візуального штучного інтелекту

Visual AI - це грубо кажучи комп’ютеризоване око людини, яке дозволяє розпізнавати елементи на сторінці та порівнювати їх з очікуваними.

Зазвичай ми сконцентровуємо свою увагу на функціональне тестування і часто не переймаємось за кожну деталь UI елементів на сторінці чи навіть в різних браузерах. В свою чергу Visual AI тестування допомагає нам наконфігурувати області, які ми хочемо перевіряти, виставити браузери і так далі, щоб воно все це перевірило за лічені секунди.

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

Звісно що це все не 100% досконало працює, але зараз вже дає дуже високу якість. Я вам залишу ряд інструментів, які дозволяють працювати з Visual AI автоматизацією:

- Applitools
- Browserstack
- Katalon
- LambdaTest

І закину вам відосик, як приклад, щоб ви хоч розуміли, що то таке
https://www.youtube.com/watch?v=SfbkC2tBI2k

Привіт, поки я займаюся оформленням статті по Visual AI Testing

Хочу вам нагадати, що вже у суботу відбудеться QA Magic Meetup 6.0, наразі маємо 142 учасника 🔥

Будуть розналянуті такі теми:
🔹 Впровадження системного процесу QA в великій компанії для забезпечення якості IT-продуктів на кожному етапі
🔸 Персональна ефективність
🔹 Впровадження процесу адаптації на великому проєкті
🔸 Promises від А до Я: Асинхронність, колбеки та пастки масивів
🔹 Як побудувати процес тестування на проєкті з нуля?
🔸 QA метрики і як їх хакнути

Поки дописав нагадування вже 143 😉

Ну раз просили про AI в тестуванні, погнали

AI-Driven Test Automation - ця штука зробила революцію в автоматизації. Ще в далекому 2016 році, коли я вперше почув про те, що тести за допомогою штучного інтелекту можуть самі себе пофіксити. Тобто він аналізує зміни, які були внесені в вашому додатку і підправляє тест згідно тим змінам. Це неабияк зменшило час на підтримку тестів та підвищило ефективність автоматизації.

Regression Suite Optimization - це просто те, чого я давно чекав, штучний інтелект дозволяє проаналізувати зміни в коді та вибрати найбільш релевантні тести, що значно скорочує час на тестування та оптимізує покриття.

Intelligent Test Case Generation - штучний інтелект може допомогти з генерацією тестів, аналізуючи вимоги, це те що ви можете робити з GPT та іншими AI генераторами. Це допомагає нагенерувати ідей для тест кейсів. З досвіду використання одного з таких інструментів у нас на проекті, скажу що досить якісно створює тест кейси, але важливо робити рев'ю тестів та додавати степи або тестові дані, більш лаконічно.

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

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

Можна вас попросити накидати мені в коментарях, щоб ви хотіли дізнатися, про що почитати чи послухати. Я вам підготую пости по вашим запитам 😉

Заключний спікер на QA Magic - Євген Толчинський

Скільки разів ви чули:
“У нас багато багів”
“У нас високий тест кавередж”
“У нас багато тестів”

Я коли чую такі формулювання в мене починають випадати залишки волося 😁

Про шо ми поговоримо?
Про те що цифри мають нести інформацію і аналітику, а цифри в “вакумі” не потрібні

Ми подивимось на нестандартні метрики
- Швидкість виправлення багів
- Якість створення багрепортів
- Відсоток баг репортів, які не пройшли багрепорт ревью
- Bugness Index - а що це таке, я разповім :-)

Як змінити метрики? “У нас має бути мало багів” на “Кількість баг репортів зменьшилась на Х і якість не постраджала”

І звісно я відповім на ваші питання :-)
Тому готуйте їх

Я вже 5 років проводжу співбесіди різних QA engineer і розуміння метрик додає бонусів. А ще дуже часто PO, CTO не розуміють які метрики потрібні, до яких треба йти.

Тому, запрошую вас на мітап, уже 26 жовтня
https://conference.ry-consulting.online/

Ну що ж, 10 днів залишилось до QA Magic 6.0. Я завжди згадую ці емоції, які відчував на сцені, переживання перед кожним виступом, кожного разу наче вперше виходиш))

Мені дуже подобається та атмосфера і вайб, який відбувається на конфі. Люди спілкуються, задають багато питань, отримують дуже багато відповідей. Нові знайомства, нові знання, що може бути краще.

Отож чекаємо всіх офлайн та онлайн

​​На вихідних провів воркшоп по Дослідницькому тестуванню, і в мене є що вам сказати:

- 9 людей випробували 5 нових підходів, які раніше не використовували в тестуванні

- 9 щасливих людей, бо дізналися, що таке робота в парі і які бенефіти від цього можна отримати

- люди створили дуже круті описи своїх проектів використовуючи тестування на основі персон, та побачили, як за допомогою продумування потреб персон, можна розробити покращення та в деяких випадках навіть придумати нові фічі

- всі знають що таке тест тури, але як це застосувати саме на проекті, мало хто догадувався, а тепер вже навіть знають як назвуть свої тури

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

Ну що ж, я задоволений результатом, а хто хоче потрапити на такий двіж, то 19 жовтня вже знову набирається групка на воркшоп, вартісттю всього 2500 юашів

Став + в коментарях, якщо теж хочеш приєднатися та отримати купу інсайтів

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

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

Нагадую, що є також ОНЛАЙН квитики, тому ви можете дивитися конференцію з будь якої точки світу 😉

​​Наш наступний спікер - Антон Синявський

«Кожен раз, коли мова заходить про процеси, я чую різні відповіді.
Але, на жаль, дуже важко зрозуміти послідовність того, що на що впливає: документи, цикли, покриття? Дуже часто бачу, як створюють документацію, яка взагалі не використовується в процесі, але її все одно підтримують, витрачаючи час і ресурси всієї команди.
Коли питаю, навіщо це робити, всі хитають головами й кажуть: «Ну, так було зроблено до нас».

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

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

З чого почати?
На що звернути увагу?
Які інструменти використовувати?
Яку документацію створювати?
Яка послідовність?
Як відстежувати прогрес?

Чому це важливо?

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

26 жовтня ми заглибимося в тему систем і процесів. Я покажу на прикладі одного з моїх проєктів, як перетворити хаос на чіткий процес. Навіть через рік клієнт повернувся, щоб подякувати за процес, який продовжував працювати.

P.S. Якщо ви вже створювали процеси і щось не виходило, підготуйте свої питання  – ми їх також розберемо. З радістю поділюсь своїм досвідом»

Привіт! Настав час поділитися враженнями від курсу Test Analyst#17..
Курс надзвичайно інформативний та добре організований. Матеріал був поданий чітко та лаконічно: кожне наступне заняття логічно випливає з попереднього. Все систематизовано, що допомагає краще зрозуміти з якого моменту і як саме проводити аналіз та відповідно підібрати коректну стратегію тестування, що буде оптимізувати час на тестування без втрати якості.

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

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

🚀 Хочеш прокачати свої навички в тест аналізі і стати ТОП-фахівцем на ринку?

Це саме той шанс, якого ти чекав! 🔥 Всього 2 місяці, і ти перетворишся на експерта з тест аналізу, здатного вирішувати найскладніші завдання!

У практичному курсі "Тест Аналіз" я зібрав усе, що допоможе тобі:
✅ Опанувати комбінаторику і оптимізувати тестові сценарії
✅ Створювати ефективні стратегії тестування
✅ Використовувати таблиці залежностей для покращення результатів
✅ І багато іншого, щоб позбутися монотонності у роботі і стати лідером в своїй сфері!

👉 Реальний практичний досвід
Цей курс — не просто теорія, а реальні кейси і завдання, з якими ти зіткнешся на своїй роботі. Домашки перевіряються індивідуально, і ти отримуєш повноцінні фідбеки та розбори від мене особисто.

🎯 Для кого цей курс?

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

💥 Акційні умови: не пропусти!
На даний момент у тебе є можливість обрати зручний для себе варіант оплати:
💳 Розстрочка до 5 платежів
І обрати один з пакетів:
🔝 Пакет PRO: 16 повноцінних уроків, перевірка домашніх завдань, індивідуальні сесії — 22500 грн
🎯 Пакет LITE: 16 уроків без перевірки домашніх завдань — 15500 грн

🔥 Бонус для тих, хто зареєструється протягом тижня — персональна консультація абсолютно безкоштовно!

⏳ Не зволікай! Місця обмежені, і цей курс може стати тим самим ключем до твого кар'єрного прориву! Переходь за посиланням і дізнайся більше ➡️ https://test-analysis.ry-consulting.online/

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

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

Виявлення пробілів та ризиків
На іншому проекті, де було розроблено складну CRM-систему, ми використовували техніку "аналізу залежностей”. Ми звернули увагу на перехресні залежності між модулями, і в підсумку тестування виявило кілька помилок у синхронізації даних між модулями. А також завдяки цій техніці ми завжди відбирали тести для регресійного тестування.

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

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

Колеги привіт 👋

Хочу вам нагадати, що сьогодні останній день дії ранньої ціни на квитки QA Magic
Цього разу будуть дуже сильні доповіді від спікерів та чудовий нетворкінг.

А зараз можна поглянути як це було минулого разу 🙃

​​Наступний наш спікер - Артем Овчаренко

Мене вкрай дістали співбесіди під час яких JS автоматизатори від джуні до сіньйора (доречі, джуни показують кращі результати 😁) не можу відповісти на питання, що таке проміс! В кращому випадку люди можуть повторити визначення або пояснити власними словами. Проте коли діло доходить до глибшого розуміння та використання на практиці - це повна лажа.

Маленька ремарка - не всі автоматизатори, але напревеликий жаль багато.

Чому це важливо?

Якщо подивитись автотести написані на JavaScript 70-80% коду буде асинхронним і відповідно використовувати проміси. Для 80% автотестів, глибоке розуміння цієї матерії непотрібне, ставимо await і все працює. Проте, з збільшенням кодової бази вашого проекту, з ускладненням задач, які ставлять перед командою автоматизації, зростають вимоги до вас, як до інженера і відповідно просто поставити await вже не достатньо, оскільки це не вирішує проблеми.

В моєму досвіді було декілька випадків, коли незнання та нерозуміння концепції промісів призвело до неймовірної нестабільності тестів. Уявіть 200 end2end автотестів і кожен запуск, рандомно падає приблизно 50-70%. Менеджмент навіть зневірився в можливостях автоматизації, хоча проблема була в знаннях і вміннях автоматизаторів.

Отже, 26го жовтня, заглибимось в цю тему, розберемо, що ж таке ті проміси і асинхронність, а також розглянемо різноманітні тонкощі їх застосування.

Доречі, буде корисно й тим, хто пише більш складні (з використанням JS скриптів) автотести на Postman.

Всім привіт!

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

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

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

Було таке? 😁

Оце я розумію! У когось щастя - це просто приїхати на QA Magic 🤗

Тому нагадую що квиточки зі знижкою ще можна придбати до 10 жовтня 😉

Наступний наш спікер - Ріна Ужевко

Наприкінці 2019 р. стався мій особистий переломний момент у ставленні до того, що я роблю.

З 2017 року я була на дуже великому проєкті, і в нас був дуже активний найм людей і дуже швидкий.
За найпіковіший місяць в команду тестування долучилось понад 40 людей різних грейдів. В нас тоді був якийсь процес онбордингу і він якось працював, але він був зроблений менеджером до мене, і мав (як виявилось) багатенько гепів.

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

В результаті, вже після закінчення мого проєкту, процес перенесли спочатку для одного IT відділу, згодом — цю систему застосували на всіх рівнях компанії, що охоплює тисячі співробітників.
Зауважу, що я була аутстафером, а компанія, продуктова.

Що ж було такого, чого в них не було до мене?
- розуміння, що саме повинно бути в процесі онбордингу
- з яких саме етапів він складається
- не було зворотнього зв'язку
- не було досвіду онбордингу одночасно такої кількості людей різних грейдів
- не було розділення обов'язків
- певної документації та чек-листів індивідуальних для кожної людини

🔗 Про весь цей процес я розкажу на конференції QA Magic Meetup 26 жовтня, "Впровадження процесу адаптації на великому проєкті", де ми детально розберемо всі етапи та ключові стратегії.
Це ваш шанс поглибити знання і впровадити ці зміни у ваших проектах.

Часто чую від колег, що вони прям дуже переживають за те, що клієнт знайде баг.
Але основне питання яке їх лякає це "Як ти так тестував/ла, що пропустив/ла баг?"

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

Друзі привіт, до мене прийшов запит на воркшоп по Дослідницькому тестуванню, тому якщо хтось хоче відвідати воркшоп, заповнюйте гугл форму, там всередині опис що буде і ціна
https://forms.gle/4JJzrgnyadTbPt9T9

Накидаю трохи анонсів, що планується на цей місяць

Основна подія місяця це QA Magic Meetup, дуже хочеться, щоб по максимуму прийшло людей та відвідало онлайн
26 жовтня, дуже круті допопвіді від експертів галузі

28 жовтня дуже хочу запустити курс по Тест Аналізу, як показала практика останніх 17 груп, всі задоволені практичним досвідом, який отримують в результаті навчання. Особливо ті, хто працюють зі мною по своїм проектам

15 жовтня Тест Марафон, хоч і в записі, але пишаюся результатами студентів, хочеться, щоб кожен пройшов ці 12 уроків досвіду

Кому потрібна буде консультація, пишіть, знайдемо час для вирішення ваших задач і проблем

Друзі привіт

Всіх причетних вітаю зі святом і дякуємо всім хто захищає 🇺🇦
Всім полеглим велика вдячність і пошана 🙏🏻

Борітеся - поборете, Вам Бог помагає

📊 Персональна ефективність

Привіт друзі! Цього літа я вперше за довгий час шукав собі нову роботу. До цього я дуже пишався своїм резюме:
✅ в ньому описані мої навички та багатий досвід
✅ воно було концентроване - лише 3 сторінки
✅ воно мало непоганий дизайн

Але я вирішив, що хочу мати щось набагато крутіше. Тож почав з оптимізації контенту. На щастя, зараз є десятки сервісів-аналізаторів, куди можна завантажити резюме і отримати його оцінку. Я був впевнений, що зараз ШІ тільки гляне на моє CV, пустить скупу цифрову сльозу радості і видасть мені оцінку 99/100. Але я отримав лише ~25%. Але чому так?

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

Всі аналізатори зараз дають поради та приклади на кшталт:
- "завдяки моєму менеджменту, зменшив час регресійного тестування в 3 рази"
- "мій тест дизайн допоміг досягти 90% покриття продукту тестами і збільшити якість на 27%"
- "моя стратегія тестування призвела до зменшення кількості критичних багів на 95%"

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

А значить, ми маємо просту та очевидну думку - настав час кожному інженеру усвідомити необхідність збирати такі метрики і почати щось робити в цьому напрямку. В своїй ролі хеда практики тестування, я починав це впроваджувати, тож маю ідеї і практичні поради, якими і хочу поділитись з вами у найближчому майбутньому. Найбільш імовірно, зможу це зробити на Magic Meetup 6 вже скоро, а трохи пізніше і розлогий пост напишу.

А поки бережіть себе
допомагайте ЗСУ
Слава Україні! 🇺🇦

Всіх вітаю! Сьогодні в мене для вас є чудові новини!

Оголошую реестрацію на новий воркшоп "Перші кроки з Playwright (ONLINE)"!

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

Це будуть ваші перші кроки по опануванню інструментів автоматизації та роботизації своїх тестів. Ми підемо в зворотньому порядку - так як вчився я сам - будемо записувати дії і генерувати з них код.

1. **Початок роботи з Playwright без досвіду программування:** Покажу, як швидко і просто виконувати автоматизовані дії за допомогою сучасного інструменту автоматизації
2. **Пошук елементів на сторінках:** Пошук елементів на сторінці та робота з ними
3. Виконання тестів та CI: робота з репозиторіем, виконання тестів в системі continious integration

Після цього воркшопу ви можете продовжити опановувати playwright, здобувати знання мови программування JavaScript - і ви Automation QA! Або вже використовувати здобуті знання для автоматизації рутинних дій.

Знання мови программування не обовʼязкове!

З частини, 19:00 до 21:00 за київським часом.
7, 9, 11 жовтня 2024 року.

Вартість 2000 гривень. Всі зібрані кошти підуть на закупівлю засобів РЕБ для бригади НГУ "Рубіж" Щодо реестрації - пишіть мені @xotabu4 .

Заняття будуть проходити в онлайні. Буде відеозапис!

https://xotabu4.notion.site/Playwright-ONLINE-5122941bb8214367b9959687b2d6edf4?pvs=74