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

Тому, хто може, підтримайте будь ласка мого товариша

🔗Посилання на банку
https://send.monobank.ua/jar/6VfMZ4ADx1

💳Номер картки банки
5375 4112 0985 9557

Гайз привіт 😉

Було прийнято рішення перенести старт марафону з 6-ого, на 9-те число, оскільки по фітбеку від учнів я чую що краще буде зафіналити 12-тий день в пʼятницю а не у віторок, щоб було більше часу на вихідних дороблювати домашки.

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

Ми пройдемо:

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

Вартсіть:

📌 4300 грн

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

Деталі з приводу того як будуть проходити зустрічі шукайте на сайті https://test-marathon.ry-consulting.online/ або запитуйте під цим постом!

Друзі привіт 👋

У грудні планується четверта масштабна конференція - QA Magic MeetUP 4.0

Основна тематика конференції - "Тест менеджмент і Тестові процеси"

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

Зараз формуємо склад спікерів і хочу дізнатись у вас, кого б ви хотіли почути та побачити?

Пишіть побажання у коментарях під цим дописом😉

А поки ділюсь з вами виступом з QA Magic MeetUp 2.0!

Спікер - Михайло Чуб
Head of QA Practice Infopulse

Тема доповіді: Вартові автотестів в метавсесвіті тестування

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

Дивіться з кайфом та користю, доповідь вийшла дійсно цікавою 😉

Гайз привіт👋

5-тий вагон ломокомотиву під назвою "Практичний Марафон для Тестувальників" відправляється вже завтра

Хто планує доєднатися та прокачати свої навички тестувальника і отримати той самий практичний досвід про який питають на кожній співбесіді - Welcome

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

Наступний вагон буде вже з поміткою 2024, тож не втрачайте можливість 😉

Якщо у вас ще залишились питання то пишіть у особисті @yakymchuk_roma

Важливі аспекти Quality Assurance 🎥

Друзі всім привіт 🙋‍♂️

У цю неділю, проведу вам етер по темі «Налагодження процесу тестування, або чому хаос це не процес»

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

Хто планує бути ставте +
Неділя 12 листопада - 19:30
Zoom

До зустрічі 😉

Налагодження процесу тестування, або чому хаос це не процес

Друзі хто не зміг долучитися, ось запис, чекаю питання під постом 🙏

Ставте нагадування в календариках 🤓 Адже ми зберемось з суддями Dev Challenge та розкажемо про очікування\реальність від завдань вже в цю середу (15.11) о 19 30!

Хто буде:
Роман Марінський
Роман Якимчук
Олексій Остапов
Наталія Попелишко

Про що поговоримо:
Як створювали завдання?
На що був розрахунок?
Що очікували?
Основні помилки в виконанні та трошки детальніший фідбек :)

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

API: Про що нам не говорять програмісти?

Гайз! З вами на звʼязку Іра Вольних. Давайте сьогодні поговоримо про АPIшки, а саме про доволі незвичну тему - про які аспекти розробки іноді не згадують наші колеги програмісти, що можуть повпливати на процеси тестування.

Поїхали!

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

👉Версії та підтримка
Одного разу відтестувавши API всіма можливими способами існує хибне уявлення що вони працюватимуть до тих пір як хтось щось десь не зламає. Але! Ще існує така підлість як версійність програмного забезпечення яке приймає участь у використанні чи обслуговуванні нашого API. Дуже розповсюджений приклад: Google Maps API, де оновлення версій може призвести до змін у структурі даних. Якщо наш застосунок використовує конкретний формат відповіді, нова версія може вимагати адаптацій, щоб забезпечити неперервну роботу додатку. І це краще передбачити!

💸Витрати та обмеження використання
При роботі з обчислювальними хмарними середовищами, як Google Cloud, AWS чи Azure, важливо слідкувати за обмеженнями трафіку та витратами. Наприклад, несвоєчасне припинення використання служби або безконтрольний запуск тестів може призвести до несподіваних рахунків та використання ресурсів. Не раз чула на конференціях жахливі історії про рахунки за тестування тому застерігаю і вас🤞Подумайте про цей нюанс адже часто в описі функціоналу API ви не знайдете цього пункту.

👉Безпека та конфіденційність
Неправильна обробка та збереження токенів доступу може призвести до порушення конфіденційності та втрати сенсетивних даних застосунку або ж користувачів. І тут мова не тільки про хардкод даних прямо в коді але і про неконтрольовані передачі колекцій, реквестів чи ключів тощо. Згадайте, що Quality Assurance це не тільки про тестування але і забезпечення якості в процесах.

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

Сподіваюсь ці поради стануть вам у нагоді🤝 а також діліться вашими історіями у коментарях!

До зустрічі🎃

Друзі, також нагадую що вже о 19:30 ми чекаємо вас на ефірі, де ми зберемось з суддями Dev Challenge та розкажемо, про очікування\реальність від завдань, які були у цей раз.

Про що поговоримо:
Як створювали завдання?
На що був розрахунок?
Що очікували?
Основні помилки в виконанні та трошки детальніший фідбек 🙂

Чекаємо на вас 😉