Якщо ви займаєтесь тестуванням, то точно знаєте, скільки часу йде на рутину: запис кроків, опис дій, підготовка тест-кейсів.
QA Engineer Сергій Ткаченко створив розширення для Chrome — QA Test Case Helper, яке допомагає швидше збирати тестові кроки та генерувати тест-кейси.
👉 https://dou.ua/goto/ZhMG
QA Engineer Сергій Ткаченко створив розширення для Chrome — QA Test Case Helper, яке допомагає швидше збирати тестові кроки та генерувати тест-кейси.
👉 https://dou.ua/goto/ZhMG
DOU
Розширення для Chrome, яке спрощує життя тестувальникам — QA Test Case Helper
Привіт, колеги! Я створив розширення для Chrome – QA Test Case Helper, яке допомагає швидше збирати тестові кроки та генерувати тест-кейси.
Якщо ви займаєтесь тестуванням, то точно знаєте, скільки часу йде на рутину: запис кроків, опис дій, підготовка
Якщо ви займаєтесь тестуванням, то точно знаєте, скільки часу йде на рутину: запис кроків, опис дій, підготовка
✅ Чек-лист для usability-тестування.
Usability-тестування допомагає виявити проблеми зручності використання продукту, покращити UX та підвищити конверсію. Ось основні пункти, які варто перевірити:
1️⃣ Навігація та структура
☑ Чи зрозуміла структура сайту/додатку?
☑ Чи легко знайти потрібну інформацію?
☑ Чи логічно працює меню?
☑ Чи є «хлібні крихти» та зрозумілі заголовки?
2️⃣ Юзабельність інтерфейсу
☑ Чи всі кнопки та посилання працюють?
☑ Чи достатній розмір шрифтів та інтервалів?
☑ Чи немає перевантаження екрана елементами?
☑ Чи доступні основні функції за мінімум кліків?
3️⃣ Взаємодія з контентом
☑ Чи легко сприймається текст (структура, списки, підзаголовки)?
☑ Чи добре читається текст на різних пристроях?
☑ Чи немає зайвої термінології або незрозумілих слів?
☑ Чи зрозумілі користувачам CTA-кнопки (заклики до дії)?
4️⃣ Форма зворотного зв’язку та введення даних
☑ Чи коректно працюють форми (реєстрація, пошук, оплата)?
☑ Чи є підказки для полів введення?
☑ Чи правильно відображаються повідомлення про помилки?
☑ Чи можна легко виправити помилку в полі?
5️⃣ Адаптивність та продуктивність
☑ Чи коректно працює сайт на мобільних пристроях?
☑ Чи швидко завантажуються сторінки?
☑ Чи немає багів при зміні розміру вікна браузера?
☑ Чи коректно працюють анімації та інтерактивні елементи?
6️⃣ Доступність (Accessibility)
☑ Чи можна користуватись сайтом без миші (гарячі клавіші, табуляція)?
☑ Чи є контрастність тексту та елементів UI?
☑ Чи працюють screen-reader-и для людей з вадами зору?
☑ Чи є альтернативний текст для зображень?
🔍 Порада: залучайте реальних користувачів до тестування, записуйте їхні дії та відгуки – це допоможе знайти несподівані проблеми!
Збережи собі, щоб не забути! 📌
#UX #Usability #ЧекЛист #Тестування #AllAboutQA
Usability-тестування допомагає виявити проблеми зручності використання продукту, покращити UX та підвищити конверсію. Ось основні пункти, які варто перевірити:
1️⃣ Навігація та структура
☑ Чи зрозуміла структура сайту/додатку?
☑ Чи легко знайти потрібну інформацію?
☑ Чи логічно працює меню?
☑ Чи є «хлібні крихти» та зрозумілі заголовки?
2️⃣ Юзабельність інтерфейсу
☑ Чи всі кнопки та посилання працюють?
☑ Чи достатній розмір шрифтів та інтервалів?
☑ Чи немає перевантаження екрана елементами?
☑ Чи доступні основні функції за мінімум кліків?
3️⃣ Взаємодія з контентом
☑ Чи легко сприймається текст (структура, списки, підзаголовки)?
☑ Чи добре читається текст на різних пристроях?
☑ Чи немає зайвої термінології або незрозумілих слів?
☑ Чи зрозумілі користувачам CTA-кнопки (заклики до дії)?
4️⃣ Форма зворотного зв’язку та введення даних
☑ Чи коректно працюють форми (реєстрація, пошук, оплата)?
☑ Чи є підказки для полів введення?
☑ Чи правильно відображаються повідомлення про помилки?
☑ Чи можна легко виправити помилку в полі?
5️⃣ Адаптивність та продуктивність
☑ Чи коректно працює сайт на мобільних пристроях?
☑ Чи швидко завантажуються сторінки?
☑ Чи немає багів при зміні розміру вікна браузера?
☑ Чи коректно працюють анімації та інтерактивні елементи?
6️⃣ Доступність (Accessibility)
☑ Чи можна користуватись сайтом без миші (гарячі клавіші, табуляція)?
☑ Чи є контрастність тексту та елементів UI?
☑ Чи працюють screen-reader-и для людей з вадами зору?
☑ Чи є альтернативний текст для зображень?
🔍 Порада: залучайте реальних користувачів до тестування, записуйте їхні дії та відгуки – це допоможе знайти несподівані проблеми!
Збережи собі, щоб не забути! 📌
#UX #Usability #ЧекЛист #Тестування #AllAboutQA
🔍 Нові вакансії для тестувальників
Інженер ручного тестування / Junior / Middle Manual QA Engineer в Onseo
Київ
👉 https://dou.ua/goto/MXhh
Automation QA Engineer (Mobile) — AI/ML в Дія
Київ
👉 https://dou.ua/goto/lqOk
Mid-level QA Engineer (General and Automation) в Radity, $2000–2800
віддалено
👉 https://dou.ua/goto/L9Y6
Middle QA Engineer в "ІНФОТЕХ"
Київ
👉 https://dou.ua/goto/T5iX
Art QA в Frogwares
Київ, за кордоном, віддалено
👉 https://dou.ua/goto/q2tn
Інженер ручного тестування / Junior / Middle Manual QA Engineer в Onseo
Київ
👉 https://dou.ua/goto/MXhh
Automation QA Engineer (Mobile) — AI/ML в Дія
Київ
👉 https://dou.ua/goto/lqOk
Mid-level QA Engineer (General and Automation) в Radity, $2000–2800
віддалено
👉 https://dou.ua/goto/L9Y6
Middle QA Engineer в "ІНФОТЕХ"
Київ
👉 https://dou.ua/goto/T5iX
Art QA в Frogwares
Київ, за кордоном, віддалено
👉 https://dou.ua/goto/q2tn
DOU
Інженер ручного тестування / Junior / Middle Manual QA Engineer
Ми шукаємо Інженера ручного тестування, який приєднається до нашої продуктової команди у Києві.
Добірка ключових шаблонів договорів в IT
✅ Договір на розробку та програмування – визначає обов’язки сторін у створенні ПЗ.
✅ Договір на інформаційні послуги – ідеальний для консалтингу та інших сервісів, пов’язаних з інформацією.
✅ Договір на маркетингові послуги – регулює співпрацю з маркетинговими агентствами та спеціалістами.
✅ Договір на копірайтинг – підходить для роботи з контентом: статтями, блогами, SEO-текстами тощо.
Ще більше шаблонів, юридичних порад та безкоштовної корисної інформації шукай у Telegram-каналі IT-юриста.
📌 В цьому каналі:
✅ Практичні юридичні поради
✅ Корисні юр лайфхаки
✅ Оновлення в законодавстві
✅ Як захистити себе та свою справу
✅ Важливі юридичні нюанси для IT-бізнесу
💡 IT-юрист Дмитро Кондратьєв ділиться своїм досвідом безкоштовно!
📲 Долучайтеся, щоб завжди бути в курсі змін та уникати юридичних ризиків!
✅ Договір на розробку та програмування – визначає обов’язки сторін у створенні ПЗ.
✅ Договір на інформаційні послуги – ідеальний для консалтингу та інших сервісів, пов’язаних з інформацією.
✅ Договір на маркетингові послуги – регулює співпрацю з маркетинговими агентствами та спеціалістами.
✅ Договір на копірайтинг – підходить для роботи з контентом: статтями, блогами, SEO-текстами тощо.
Ще більше шаблонів, юридичних порад та безкоштовної корисної інформації шукай у Telegram-каналі IT-юриста.
📌 В цьому каналі:
✅ Практичні юридичні поради
✅ Корисні юр лайфхаки
✅ Оновлення в законодавстві
✅ Як захистити себе та свою справу
✅ Важливі юридичні нюанси для IT-бізнесу
💡 IT-юрист Дмитро Кондратьєв ділиться своїм досвідом безкоштовно!
📲 Долучайтеся, щоб завжди бути в курсі змін та уникати юридичних ризиків!
Як розпочати шлях в автоматизації QA з нуля? Чи варто копіпастити та покладатися на AI-інструменти? Відверто, з гумором і на власному досвіді про це розповідає Костя (Dneprokos) — фахівець із понад 16-річним досвідом у розробці програмного забезпечення.
👉 https://dou.ua/goto/F0cW
👉 https://dou.ua/goto/F0cW
DOU
«Буде боляче». Мій шлях з мануального тестування до автоматизації
Як розпочати шлях в автоматизації QA з нуля? Чи варто копіпастити та покладатися на AI-інструменти? Відверто, з гумором і на власному досвіді про це розповідає Костя (Dneprokos) — фахівець із понад 16-річним досвідом у розробці програмного забезпечення.
✅ Чек-лист для перевірки авторизації та автентифікації.
Перевіряємо надійність та безпеку доступу до системи!
🔑 1. Автентифікація (перевірка особи користувача):
• Використовуються надійні паролі (мінімум 8 символів, великі та малі літери, цифри, спеціальні символи).
• Є можливість зміни пароля користувачем.
• Налаштована багатофакторна аутентифікація (2FA або MFA).
• Використовуються сучасні методи аутентифікації (OAuth, SSO, JWT).
• Дані облікового запису зберігаються в зашифрованому вигляді (наприклад, хешування паролів).
• Захист від брутфорсу (обмеження кількості спроб входу).
👥 2. Авторизація (керування правами доступу):
• Чітко визначені ролі та права доступу користувачів.
• Правила доступу регулярно переглядаються та оновлюються.
• Доступ до конфіденційних даних обмежений тільки авторизованими користувачами.
• Використовуються принципи мінімальних прав (least privilege).
• Логуються всі спроби доступу до чутливих даних.
🕵️ 3. Безпека сесій:
• Сесії автоматично завершуються після періоду неактивності.
• Токени доступу мають обмежений термін дії.
• Застосовується захист від крадіжки сесій (наприклад, прив’язка до IP або пристрою).
📝 4. Логування та моніторинг:
• Логуються всі успішні та невдалі спроби входу.
• Логуються спроби доступу до адміністративних панелей.
• Проводиться регулярний моніторинг логів на предмет підозрілої активності.
🚨 5. Реакція на інциденти:
• Впроваджено механізм блокування підозрілих користувачів.
• Є процедура повідомлення про злом або спробу несанкціонованого доступу.
• Створений план реагування на інциденти безпеки.
#AllAboutQA
Перевіряємо надійність та безпеку доступу до системи!
🔑 1. Автентифікація (перевірка особи користувача):
• Використовуються надійні паролі (мінімум 8 символів, великі та малі літери, цифри, спеціальні символи).
• Є можливість зміни пароля користувачем.
• Налаштована багатофакторна аутентифікація (2FA або MFA).
• Використовуються сучасні методи аутентифікації (OAuth, SSO, JWT).
• Дані облікового запису зберігаються в зашифрованому вигляді (наприклад, хешування паролів).
• Захист від брутфорсу (обмеження кількості спроб входу).
👥 2. Авторизація (керування правами доступу):
• Чітко визначені ролі та права доступу користувачів.
• Правила доступу регулярно переглядаються та оновлюються.
• Доступ до конфіденційних даних обмежений тільки авторизованими користувачами.
• Використовуються принципи мінімальних прав (least privilege).
• Логуються всі спроби доступу до чутливих даних.
🕵️ 3. Безпека сесій:
• Сесії автоматично завершуються після періоду неактивності.
• Токени доступу мають обмежений термін дії.
• Застосовується захист від крадіжки сесій (наприклад, прив’язка до IP або пристрою).
📝 4. Логування та моніторинг:
• Логуються всі успішні та невдалі спроби входу.
• Логуються спроби доступу до адміністративних панелей.
• Проводиться регулярний моніторинг логів на предмет підозрілої активності.
🚨 5. Реакція на інциденти:
• Впроваджено механізм блокування підозрілих користувачів.
• Є процедура повідомлення про злом або спробу несанкціонованого доступу.
• Створений план реагування на інциденти безпеки.
#AllAboutQA
🌟БАЗОВИЙ МОДУЛЬ ТЕСТУВАННЯ🌟
Все ще думаєте, чому випускники курсу досягають таких успіхів і залишають захоплені відгуки?
➡️Тоді ✏️ записуйтесь на перше БЕЗКОШТОВНЕ заняття.
❗️Старт вже 25.03.2025 ❗️
✅Деталі: https://qalight.ua/kursy/bmt/
📌Адміністратор у Телеграм: @QALight_admin
☎️Тел:
+38 (063) 78-010-78
+38 (097) 78-010-78
+38 (099) 78-010-78
Все ще думаєте, чому випускники курсу досягають таких успіхів і залишають захоплені відгуки?
➡️Тоді ✏️ записуйтесь на перше БЕЗКОШТОВНЕ заняття.
❗️Старт вже 25.03.2025 ❗️
✅Деталі: https://qalight.ua/kursy/bmt/
📌Адміністратор у Телеграм: @QALight_admin
☎️Тел:
+38 (063) 78-010-78
+38 (097) 78-010-78
+38 (099) 78-010-78
Як розпочати шлях в автоматизації QA з нуля? Чи варто копіпастити та покладатися на AI-інструменти? Відверто, з гумором і на власному досвіді про це розповідає Костя (Dneprokos) — фахівець із понад 16-річним досвідом у розробці програмного забезпечення.
👉 https://dou.ua/goto/ynir
👉 https://dou.ua/goto/ynir
DOU
«Буде боляче». Мій шлях з мануального тестування до автоматизації
Як розпочати шлях в автоматизації QA з нуля? Чи варто копіпастити та покладатися на AI-інструменти? Відверто, з гумором і на власному досвіді про це розповідає Костя (Dneprokos) — фахівець із понад 16-річним досвідом у розробці програмного забезпечення.
Ольга Дудка, яка перейшла в ІТ з іншої професії, ділиться своїм шляхом до позиції QA Manual Tester.
Вона розповідає про виклики, з якими стикалася, та стратегії, які допомогли їй отримати роботу в британській продуктовій компанії. Детальніше читайте в її дописі.
Вона розповідає про виклики, з якими стикалася, та стратегії, які допомогли їй отримати роботу в британській продуктовій компанії. Детальніше читайте в її дописі.
DOU
Як знайти свою першу роботу QA, якщо ти Switcher
Всім привіт! 😀
Мене звати Оля. Я — QA Manual тестувальниця, яка світчнулась з іншої професії 3+ роки тому. За цей час я тричі змінювала ІТ-компанії, тобто тричі переді мною стояв виклик знайти роботу! Конкуренція на ри
Мене звати Оля. Я — QA Manual тестувальниця, яка світчнулась з іншої професії 3+ роки тому. За цей час я тричі змінювала ІТ-компанії, тобто тричі переді мною стояв виклик знайти роботу! Конкуренція на ри
🎧 Скрипт для розпізнавання аудіо українською мовою
Що робить:
- Обробляє всі файли у папці audio/
- Розпізнає українську мову (Whisper Large)
- Зберігає текст у файл
- Відкриває результат у VS Code
Як запустити:
1. Встановити Python: https://www.python.org/downloads/
2. Встановити FFmpeg:
- Mac: brew install ffmpeg
- Windows: https://ffmpeg.org/download.html
3. Встановити бібліотеки:
pip install openai-whisper ffmpeg-python
4. Створити папку audio/ і додати туди файли (.mp3, .wav, .m4a, .flac)
5. Запустити скрипт:
python transcriber.py
Результат:
- Для кожного файлу з’явиться текстовий файл з розпізнаним текстом.
Сам код:
import whisper
import os
import subprocess
import time # ⬅️ Додаємо імпорт time
print("=== Скрипт стартував ===")
# Вимірюємо час старту
start_time = time.time()
# Завантаження моделі Whisper
print("Завантаження моделі...")
model = whisper.load_model("large") # ⬅️ Тут обираєш точну модель
print("Модель завантажено!")
# Шлях до аудіофайлів
audio_dir = "audio"
supported_formats = [".mp3", ".wav", ".m4a", ".flac"]
# Сканування аудіофайлів
audio_files = [f for f in os.listdir(audio_dir) if os.path.splitext(f)[1].lower() in supported_formats]
if not audio_files:
print("⚠️ Аудіофайли не знайдено в папці 'audio/'.")
else:
print(f"Знайдено файлів: {len(audio_files)}")
for file_name in audio_files:
audio_path = os.path.join(audio_dir, file_name)
print(f"\n▶️ Обробка: {audio_path}")
result = model.transcribe(audio_path, language="uk")
recognized_text = result["text"]
output_file = os.path.join(audio_dir, f"{os.path.splitext(file_name)[0]}_transcription.txt")
with open(output_file, "w", encoding="utf-8") as f:
f.write(recognized_text)
print(f"✅ Збережено у файл: {output_file}")
subprocess.run(["code", output_file]) # Автовідкриття VS Code
# Вимірюємо час завершення
end_time = time.time()
elapsed = end_time - start_time
print(f"\n⏱️ Обробка завершена за {elapsed:.2f} секунд")
print("=== Скрипт завершено ===")
Що робить:
- Обробляє всі файли у папці audio/
- Розпізнає українську мову (Whisper Large)
- Зберігає текст у файл
- Відкриває результат у VS Code
Як запустити:
1. Встановити Python: https://www.python.org/downloads/
2. Встановити FFmpeg:
- Mac: brew install ffmpeg
- Windows: https://ffmpeg.org/download.html
3. Встановити бібліотеки:
pip install openai-whisper ffmpeg-python
4. Створити папку audio/ і додати туди файли (.mp3, .wav, .m4a, .flac)
5. Запустити скрипт:
python transcriber.py
Результат:
- Для кожного файлу з’явиться текстовий файл з розпізнаним текстом.
Сам код:
import whisper
import os
import subprocess
import time # ⬅️ Додаємо імпорт time
print("=== Скрипт стартував ===")
# Вимірюємо час старту
start_time = time.time()
# Завантаження моделі Whisper
print("Завантаження моделі...")
model = whisper.load_model("large") # ⬅️ Тут обираєш точну модель
print("Модель завантажено!")
# Шлях до аудіофайлів
audio_dir = "audio"
supported_formats = [".mp3", ".wav", ".m4a", ".flac"]
# Сканування аудіофайлів
audio_files = [f for f in os.listdir(audio_dir) if os.path.splitext(f)[1].lower() in supported_formats]
if not audio_files:
print("⚠️ Аудіофайли не знайдено в папці 'audio/'.")
else:
print(f"Знайдено файлів: {len(audio_files)}")
for file_name in audio_files:
audio_path = os.path.join(audio_dir, file_name)
print(f"\n▶️ Обробка: {audio_path}")
result = model.transcribe(audio_path, language="uk")
recognized_text = result["text"]
output_file = os.path.join(audio_dir, f"{os.path.splitext(file_name)[0]}_transcription.txt")
with open(output_file, "w", encoding="utf-8") as f:
f.write(recognized_text)
print(f"✅ Збережено у файл: {output_file}")
subprocess.run(["code", output_file]) # Автовідкриття VS Code
# Вимірюємо час завершення
end_time = time.time()
elapsed = end_time - start_time
print(f"\n⏱️ Обробка завершена за {elapsed:.2f} секунд")
print("=== Скрипт завершено ===")
Forwarded from Hot testing Channel (Alex Hot 🔥)
Чому data-test-id — це біль?
• Бо їх треба прокидати в коді всюди, хоча реально вони потрібні тільки для автотестів.
• Таска “додати data-test-id” — це завжди лоу пріоріті. Її бере самий лінивий дев, якому нема шо на стендапі сказати. Або береш і робиш сам. 🙃
• В React’і це часто болюче — щоб прокинути айдішнік кудись глибоко, треба модифікувати купу вкладених компонентів.
• Це техборг:
• змінюється компонент — міняй data-test-id;
• редизайн або рефакторинг — компонент зник, що робити з тестами? Натягувати айдішнік на новий компонент чи переписувати півпейджобджекта?
• на проді треба вирізати ці атрибути для мінімізації — ще одна порція складності в коді.
І все це — тільки для автотестів, які парсять DOM і намагаються працювати з UI як юзер. Хвилинку… А ще ж є скрінрідери — вони теж так роблять 👀
🎯 Вихід: accessibility-based локатори
ARIA-атрибути, ролі, лейбли — це вже не просто “та знову ті куеї якусь херню хочать, потерплять”, це про юзерів на проді.
І тепер, якщо “тест не може знайти кнопку” — це не тільки проблема QA, це проблема, бо реальні юзери теж не можуть її знайти або натиснути! 🔥
От вам і союзник — accessibility. Впроваджуйте раз, і користь всім.
• Бо їх треба прокидати в коді всюди, хоча реально вони потрібні тільки для автотестів.
• Таска “додати data-test-id” — це завжди лоу пріоріті. Її бере самий лінивий дев, якому нема шо на стендапі сказати. Або береш і робиш сам. 🙃
• В React’і це часто болюче — щоб прокинути айдішнік кудись глибоко, треба модифікувати купу вкладених компонентів.
• Це техборг:
• змінюється компонент — міняй data-test-id;
• редизайн або рефакторинг — компонент зник, що робити з тестами? Натягувати айдішнік на новий компонент чи переписувати півпейджобджекта?
• на проді треба вирізати ці атрибути для мінімізації — ще одна порція складності в коді.
І все це — тільки для автотестів, які парсять DOM і намагаються працювати з UI як юзер. Хвилинку… А ще ж є скрінрідери — вони теж так роблять 👀
🎯 Вихід: accessibility-based локатори
ARIA-атрибути, ролі, лейбли — це вже не просто “та знову ті куеї якусь херню хочать, потерплять”, це про юзерів на проді.
І тепер, якщо “тест не може знайти кнопку” — це не тільки проблема QA, це проблема, бо реальні юзери теж не можуть її знайти або натиснути! 🔥
От вам і союзник — accessibility. Впроваджуйте раз, і користь всім.
🚀 Опануй SQL – ключову навичку для роботи з даними!
Хочеш легко знаходити потрібну інформацію в базах даних, аналізувати її та працювати з нею ще більш професійно?
💡 Наш курс "Практичний SQL" – це:
✅ Максимум практики – жодної "води", лише робочі SQL-запити.
✅ Зрозумілий підхід – навчишся працювати з базами даних навіть без попереднього досвіду.
✅ Реальні кейси – розбереш завдання, які використовують у реальній роботі аналітики, тестувальники та розробники.
📚 Програма курсу:
🔹 Основи SQL – що таке бази даних, як вони працюють, які є ключові команди.
🔹 Запити SELECT – вибірка, фільтрація та сортування даних.
🔹 Функції та агрегування – обробка та аналіз інформації.
🔹 Зв’язки між таблицями – об’єднання та підзапити.
🔹 Маніпулювання даними – вставка, оновлення та видалення записів.
Для кого цей курс?
✅ Для тих, хто хоче опанувати SQL з нуля.
✅ Для аналітиків, тестувальників та розробників, які хочуть підвищити кваліфікацію.
✅ Для тих, хто працює з великими масивами даних.
📅 Старт курсу: 2 квітня
🖥 Формат: онлайн-заняття в режимі реального часу.
👨🏫 Викладачі: експерти, які щодня працюють з SQL на реальних проєктах.
👉 Реєстрація тут: https://qalight.ua/kursy/tech-skills/sql/
Або адміністратор у Телеграм: @QALight_admin
☎️Тел:
+38 (063) 78-010-78
+38 (097) 78-010-78
+38 (099) 78-010-78
Хочеш легко знаходити потрібну інформацію в базах даних, аналізувати її та працювати з нею ще більш професійно?
💡 Наш курс "Практичний SQL" – це:
✅ Максимум практики – жодної "води", лише робочі SQL-запити.
✅ Зрозумілий підхід – навчишся працювати з базами даних навіть без попереднього досвіду.
✅ Реальні кейси – розбереш завдання, які використовують у реальній роботі аналітики, тестувальники та розробники.
📚 Програма курсу:
🔹 Основи SQL – що таке бази даних, як вони працюють, які є ключові команди.
🔹 Запити SELECT – вибірка, фільтрація та сортування даних.
🔹 Функції та агрегування – обробка та аналіз інформації.
🔹 Зв’язки між таблицями – об’єднання та підзапити.
🔹 Маніпулювання даними – вставка, оновлення та видалення записів.
Для кого цей курс?
✅ Для тих, хто хоче опанувати SQL з нуля.
✅ Для аналітиків, тестувальників та розробників, які хочуть підвищити кваліфікацію.
✅ Для тих, хто працює з великими масивами даних.
📅 Старт курсу: 2 квітня
🖥 Формат: онлайн-заняття в режимі реального часу.
👨🏫 Викладачі: експерти, які щодня працюють з SQL на реальних проєктах.
👉 Реєстрація тут: https://qalight.ua/kursy/tech-skills/sql/
Або адміністратор у Телеграм: @QALight_admin
☎️Тел:
+38 (063) 78-010-78
+38 (097) 78-010-78
+38 (099) 78-010-78
Senior QA Automation Вʼячеслав Потапкін підготував гайд із налаштування навантажувального тестування за допомогою Gatling.
Автор пояснює, чому продуктивність системи не можна сприймати як належне, і показує, як працювати з цим інструментом.
Автор пояснює, чому продуктивність системи не можна сприймати як належне, і показує, як працювати з цим інструментом.
DOU
Як налаштувати навантажувальне тестування на Gatling+Java. Гайд для початківців
Senior QA Automation Вʼячеслав Потапкін підготував гайд із налаштування навантажувального тестування за допомогою Gatling. Автор пояснює, чому продуктивність системи не можна сприймати як належне, і показує, як працювати з цим інструментом.
Forwarded from Test Engineering Notes
Why do we fail at interviews?
#testing #interview
Невелика стаття, де я розповідаю, чому нам зазвичай складно проходити співбесіди.
А як ви проходите інтервʼю? Чи вам легко відповідати на усі питання?
#testing #interview
Невелика стаття, де я розповідаю, чому нам зазвичай складно проходити співбесіди.
А як ви проходите інтервʼю? Чи вам легко відповідати на усі питання?
Test Engineering Notes
Why do we fail at interviews?
Why do we fail at interviews and what we can do about it
Forwarded from 🇺🇦 Security QA
🎤 QA — це не просто тестування задач… А що тоді?
Маю для вас дещо цікаве. 16-17 травня на DOU Day я виходжу на сцену, щоб поставити під сумнів те, як багато хто бачить роль QA.
Це буде не просто чергова доповідь — це буде виклик стандартному мисленню.
✅ Для тих, хто вже в темі — обіцяю нові ідеї, практичні кейси та трошки гумору.
❗Для тих, хто вважає, що QA — це лише “перевірити, чи працює” — приходьте, ризикуєте побачити все з іншого боку.
📲 Слідкуйте за анонсами, оновленнями та закуліссям конференції:
• Instagram
• LinkedIn
• Facebook
• YouTube
• Telegram
Буде цікаво. Приходьте — поговоримо не про баги 😉
https://dou.ua/goto/i1Mw
Маю для вас дещо цікаве. 16-17 травня на DOU Day я виходжу на сцену, щоб поставити під сумнів те, як багато хто бачить роль QA.
Це буде не просто чергова доповідь — це буде виклик стандартному мисленню.
✅ Для тих, хто вже в темі — обіцяю нові ідеї, практичні кейси та трошки гумору.
❗Для тих, хто вважає, що QA — це лише “перевірити, чи працює” — приходьте, ризикуєте побачити все з іншого боку.
📲 Слідкуйте за анонсами, оновленнями та закуліссям конференції:
• YouTube
• Telegram
Буде цікаво. Приходьте — поговоримо не про баги 😉
https://dou.ua/goto/i1Mw
Інцидент. Що таке інцидент? Коли трапляється? Як визначається? Що з цим робити?
Інцидент — це несподівана подія, яка порушує нормальну роботу системи або ставить під загрозу її стабільність, доступність чи безпеку. Наприклад:
— сайт раптово перестав відповідати
— зламався ключовий API
— користувачі масово скаржаться на помилки
Коли трапляється інцидент?
— Після релізу з багами
— Через збій інфраструктури (сервер, БД, CDN тощо)
— Внаслідок атаки або неправильних змін у конфігурації
Як визначити інцидент?
— Моніторинг сповіщає про помилку (наприклад, спайк 500-к)
— Алерт із систем логів
— Зворотній зв’язок від користувачів або сапорту
— Автоматичні тести не проходять після деплою
Що робить команда?
1. Ідентифікація — визначити суть і масштаби проблеми
2. Ескалація — залучити потрібних людей (DevOps, бекенд, підтримку)
3. Мітинг/канал — швидко зібратися для обговорення
4. Розв’язання — хотфікс, відкат, ізоляція багу
5. Постмортем *— аналіз причин, висновки, поліпшення процесів
Головне правило: швидка реакція + чітка комунікація.
Інцидент — це несподівана подія, яка порушує нормальну роботу системи або ставить під загрозу її стабільність, доступність чи безпеку. Наприклад:
— сайт раптово перестав відповідати
— зламався ключовий API
— користувачі масово скаржаться на помилки
Коли трапляється інцидент?
— Після релізу з багами
— Через збій інфраструктури (сервер, БД, CDN тощо)
— Внаслідок атаки або неправильних змін у конфігурації
Як визначити інцидент?
— Моніторинг сповіщає про помилку (наприклад, спайк 500-к)
— Алерт із систем логів
— Зворотній зв’язок від користувачів або сапорту
— Автоматичні тести не проходять після деплою
Що робить команда?
1. Ідентифікація — визначити суть і масштаби проблеми
2. Ескалація — залучити потрібних людей (DevOps, бекенд, підтримку)
3. Мітинг/канал — швидко зібратися для обговорення
4. Розв’язання — хотфікс, відкат, ізоляція багу
5. Постмортем *— аналіз причин, висновки, поліпшення процесів
Головне правило: швидка реакція + чітка комунікація.
* Постмортем (від лат. post mortem — “після смерті”) — це детальний розбір інциденту після його вирішення.
Мета — зрозуміти, що саме сталося, чому, як команда реагувала, і як уникнути повторення.
Зазвичай включає:
1. Опис інциденту — що і коли трапилось
2. Вплив — хто і як постраждав (користувачі, система, бізнес)
3. Причини — технічні та організаційні
4. Хронологію — як розвивались події
5. Дії команди — що робили для вирішення
6. Висновки — що спрацювало, а що ні
7. План дій — щоб запобігти подібному в майбутньому
Важливо, що це не повинно бути пошуком винних, а інструментом навчання й вдосконалення процесів.
Мета — зрозуміти, що саме сталося, чому, як команда реагувала, і як уникнути повторення.
Зазвичай включає:
1. Опис інциденту — що і коли трапилось
2. Вплив — хто і як постраждав (користувачі, система, бізнес)
3. Причини — технічні та організаційні
4. Хронологію — як розвивались події
5. Дії команди — що робили для вирішення
6. Висновки — що спрацювало, а що ні
7. План дій — щоб запобігти подібному в майбутньому
Важливо, що це не повинно бути пошуком винних, а інструментом навчання й вдосконалення процесів.
Навчальний посібник "Безпека вебдодатків" – доступний українською мовою!
Посібник "Безпека вебдодатків".
📖 Що всередині посібника?
🔹 Основи веббезпеки: типи вебсистем, клієнт-серверна архітектура, модель OSI, шифрування
🔹 Контроль доступу: ідентифікація, аутентифікація, авторизація, управління сесіями
🔹 Захист від атак: XSS, CSRF, SQL-ін'єкції, XXE, SSRF, brute-force, DoS
🔹 Практичні аспекти: тестування безпеки, пентестинг (Nmap, Burp Suite, Metasploit)
🔹 Безпечне програмування: SDLC, моделювання загроз (STRIDE, PASTA), запобігання помилкам
🔹 Економічні аспекти веббезпеки та інвестування у кіберзахист
Посібник розроблено для бакалаврів "Кібербезпека та захист інформації", але буде корисним і для інших IT-спеціальностей.
📥 Завантажити безкоштовно:
🔗 https://eztuir.ztu.edu.ua/bitstream/handle/123456789/8791/Пірог.pdf?sequence=1&isAllowed=y
Посібник "Безпека вебдодатків".
📖 Що всередині посібника?
🔹 Основи веббезпеки: типи вебсистем, клієнт-серверна архітектура, модель OSI, шифрування
🔹 Контроль доступу: ідентифікація, аутентифікація, авторизація, управління сесіями
🔹 Захист від атак: XSS, CSRF, SQL-ін'єкції, XXE, SSRF, brute-force, DoS
🔹 Практичні аспекти: тестування безпеки, пентестинг (Nmap, Burp Suite, Metasploit)
🔹 Безпечне програмування: SDLC, моделювання загроз (STRIDE, PASTA), запобігання помилкам
🔹 Економічні аспекти веббезпеки та інвестування у кіберзахист
Посібник розроблено для бакалаврів "Кібербезпека та захист інформації", але буде корисним і для інших IT-спеціальностей.
📥 Завантажити безкоштовно:
🔗 https://eztuir.ztu.edu.ua/bitstream/handle/123456789/8791/Пірог.pdf?sequence=1&isAllowed=y
Оновлена дорожня карта QA на 2025 рік
Хлопці чудово прокачали свої дорожні карти, у тому числі і QA. Там зібрані основні технології, які бажано вивчати тестувальнику
Шпаргалками можна скористатися як чек-листом і дізнаватися подробиці по кожному пункту прямо на сайті. А ще є прогрес-бар, який дозволяє відслідковувати процес освоєння: https://roadmap.sh/qa
Хлопці чудово прокачали свої дорожні карти, у тому числі і QA. Там зібрані основні технології, які бажано вивчати тестувальнику
Шпаргалками можна скористатися як чек-листом і дізнаватися подробиці по кожному пункту прямо на сайті. А ще є прогрес-бар, який дозволяє відслідковувати процес освоєння: https://roadmap.sh/qa
roadmap.sh
QA Roadmap: Learn to become a modern QA engineer
Community driven, articles, resources, guides, interview questions, quizzes for modern QA development. Learn to become a modern QA engineer by following the steps, skills, resources and guides listed in this roadmap.
🔍 Outline vs Confluence — що обрати для документації?
В сучасних командах розробки важливо мати зручне місце для документації, обміну знаннями та співпраці. Два популярних інструменти для цього — Outline і Confluence. Порівняю їх за ключовими параметрами 👇
🧠 Простота використання
Outline — мінімалістичний, швидкий, схожий на Notion. Ідеальний для команд, яким важливо просто й швидко документувати знання.
Confluence — потужніший, але складніший. Має більше можливостей, але UI іноді перевантажений.
🛠 Інтеграції
Confluence легко інтегрується з Atlassian Jira, Bitbucket та іншими інструментами Atlassian.
Outline підтримує GitHub, Slack, Zapier тощо, але інтеграцій менше.
📁 Організація знань
Outline — структура на базі колекцій та документів, дуже зрозуміла.
Confluence — сторінки, простори, дерева — гнучко, але з часом може стати хаотично.
🔐 Безпека та контроль доступу
Confluence — потужні ролі, права, SSO, корпоративний рівень безпеки.
Outline — простіший контроль доступу, але достатній для більшості невеликих і середніх команд.
⚡️ Швидкодія
Outline — працює дуже швидко, з мінімальними затримками.
Confluence — може бути повільнішим, особливо у великих інстанціях.
💰 Вартість
Outline
▪️ Безкоштовно з відкритим кодом (self-hosted)
▪️ SaaS-версія: від $10/користувача/міс.
▪️ Ідеально для команд, які хочуть заощадити
Confluence
▪️ Безкоштовно до 10 користувачів
▪️ Платні тарифи: від $5.75/користувача/міс (Cloud)
▪️ Дорожче в Enterprise-сегменті, але дає потужні корпоративні можливості
✅ Що обрати?
- Якщо стартап або шукаєш простіше — підійде Outline.
- Якщо середній/великий бізнес і потрібна повна інтеграція з Atlassian — обирайте Confluence.
В сучасних командах розробки важливо мати зручне місце для документації, обміну знаннями та співпраці. Два популярних інструменти для цього — Outline і Confluence. Порівняю їх за ключовими параметрами 👇
🧠 Простота використання
Outline — мінімалістичний, швидкий, схожий на Notion. Ідеальний для команд, яким важливо просто й швидко документувати знання.
Confluence — потужніший, але складніший. Має більше можливостей, але UI іноді перевантажений.
🛠 Інтеграції
Confluence легко інтегрується з Atlassian Jira, Bitbucket та іншими інструментами Atlassian.
Outline підтримує GitHub, Slack, Zapier тощо, але інтеграцій менше.
📁 Організація знань
Outline — структура на базі колекцій та документів, дуже зрозуміла.
Confluence — сторінки, простори, дерева — гнучко, але з часом може стати хаотично.
🔐 Безпека та контроль доступу
Confluence — потужні ролі, права, SSO, корпоративний рівень безпеки.
Outline — простіший контроль доступу, але достатній для більшості невеликих і середніх команд.
⚡️ Швидкодія
Outline — працює дуже швидко, з мінімальними затримками.
Confluence — може бути повільнішим, особливо у великих інстанціях.
💰 Вартість
Outline
▪️ Безкоштовно з відкритим кодом (self-hosted)
▪️ SaaS-версія: від $10/користувача/міс.
▪️ Ідеально для команд, які хочуть заощадити
Confluence
▪️ Безкоштовно до 10 користувачів
▪️ Платні тарифи: від $5.75/користувача/міс (Cloud)
▪️ Дорожче в Enterprise-сегменті, але дає потужні корпоративні можливості
✅ Що обрати?
- Якщо стартап або шукаєш простіше — підійде Outline.
- Якщо середній/великий бізнес і потрібна повна інтеграція з Atlassian — обирайте Confluence.
🧾 ADR для тестувальника — навіщо це тобі?
ADR (Architecture Decision Record) — це документ, у якому команда фіксує важливі архітектурні рішення про систему: що вирішили, чому, які були альтернативи.
На перший погляд здається, що це тільки для архітекторів і девелоперів. Але ні! Для тестувальника ADR — це дуже корисний документ 🗝
🔍 Навіщо тестувальнику читати ADR?
✅ Розуміння архітектури
– Знаєш, чому обрали певний підхід: наприклад, REST замість GraphQL або Redis для кешу.
– Це дає контекст для створення тест-кейсів, перевірки сценаріїв відмов, продуктивності тощо.
✅ Покриття ризиків
– ADR часто описують компроміси — наприклад, «не підтримує офлайн-режим».
– Це сигнал: треба протестити edge cases або попередити бізнес.
✅ Формування тест-стратегії
– Рішення впливають на рівень тестування (UI/API), середовище, мокові сервіси.
– Якщо впроваджується нова бібліотека або сервіс — ти вже знаєш, що і де може впасти.
✅ Підготовка до змін
– Коли архітектура змінюється, ADR допомагає зрозуміти, чому саме і що слід ретестити.
🧠 Як працювати з ADR
📖 Читайте нові ADR — або підписуйтесь на зміни у репозиторії.
✍️ Коментуйте — якщо бачите потенційні проблеми для QA (наприклад, недокументований API).
🧩 Використовуйте у тест-плані — додавайте витяги з ADR як аргументацію.
🔄 Піднімайте ADR самостійно — якщо тестувальник виявив проблему на архітектурному рівні — це не табу.
💡 ADR — не тільки для розробників. Це must-have інструмент і для QA, який хоче бачити всю картину й робити тестування усвідомлено, а не «на око».
ADR (Architecture Decision Record) — це документ, у якому команда фіксує важливі архітектурні рішення про систему: що вирішили, чому, які були альтернативи.
На перший погляд здається, що це тільки для архітекторів і девелоперів. Але ні! Для тестувальника ADR — це дуже корисний документ 🗝
🔍 Навіщо тестувальнику читати ADR?
✅ Розуміння архітектури
– Знаєш, чому обрали певний підхід: наприклад, REST замість GraphQL або Redis для кешу.
– Це дає контекст для створення тест-кейсів, перевірки сценаріїв відмов, продуктивності тощо.
✅ Покриття ризиків
– ADR часто описують компроміси — наприклад, «не підтримує офлайн-режим».
– Це сигнал: треба протестити edge cases або попередити бізнес.
✅ Формування тест-стратегії
– Рішення впливають на рівень тестування (UI/API), середовище, мокові сервіси.
– Якщо впроваджується нова бібліотека або сервіс — ти вже знаєш, що і де може впасти.
✅ Підготовка до змін
– Коли архітектура змінюється, ADR допомагає зрозуміти, чому саме і що слід ретестити.
🧠 Як працювати з ADR
📖 Читайте нові ADR — або підписуйтесь на зміни у репозиторії.
✍️ Коментуйте — якщо бачите потенційні проблеми для QA (наприклад, недокументований API).
🧩 Використовуйте у тест-плані — додавайте витяги з ADR як аргументацію.
🔄 Піднімайте ADR самостійно — якщо тестувальник виявив проблему на архітектурному рівні — це не табу.
💡 ADR — не тільки для розробників. Це must-have інструмент і для QA, який хоче бачити всю картину й робити тестування усвідомлено, а не «на око».