All about QA - Все про тестування ПЗ

Інцидент. Що таке інцидент? Коли трапляється? Як визначається? Що з цим робити?Інцидент — це несподівана подія, яка порушує нормальну роботу системи або ставить під загрозу її стабільність, доступність чи безпеку. Наприклад:— сайт раптово перестав відповідати— зламався ключовий API— користувачі масово скаржаться на помилкиКоли трапляється інцидент?— Після релізу з багами— Через збій інфраструктури (сервер, БД, CDN тощо)— Внаслідок атаки або неправильних змін у конфігураціїЯк визначити інцидент?— Моніторинг сповіщає про помилку (наприклад, спайк 500-к)— Алерт із систем логів— Зворотній зв’язок від користувачів або сапорту— Автоматичні тести не проходять після деплоюЩо робить команда? 1. Ідентифікація — визначити суть і масштаби проблеми 2. Ескалація — залучити потрібних людей (DevOps, бекенд, підтримку) 3. Мітинг/канал — швидко зібратися для обговорення 4. Розв’язання — хотфікс, відкат, ізоляція багу 5. Постмортем *— аналіз причин, висновки, поліпшення процесівГоловне правило: швидка реакція + чітка комунікація.

Чому data-test-id — це біль? • Бо їх треба прокидати в коді всюди, хоча реально вони потрібні тільки для автотестів. • Таска “додати data-test-id” — це завжди лоу пріоріті. Її бере самий лінивий дев, якому нема шо на стендапі сказати. Або береш і робиш сам. 🙃 • В React’і це часто болюче — щоб прокинути айдішнік кудись глибоко, треба модифікувати купу вкладених компонентів. • Це техборг: • змінюється компонент — міняй data-test-id; • редизайн або рефакторинг — компонент зник, що робити з тестами? Натягувати айдішнік на новий компонент чи переписувати півпейджобджекта? • на проді треба вирізати ці атрибути для мінімізації — ще одна порція складності в коді.І все це — тільки для автотестів, які парсять DOM і намагаються працювати з UI як юзер. Хвилинку… А ще ж є скрінрідери — вони теж так роблять 👀🎯 Вихід: accessibility-based локаториARIA-атрибути, ролі, лейбли — це вже не просто “та знову ті куеї якусь херню хочать, потерплять”, це про юзерів на проді.І тепер, якщо “тест не може знайти кнопку” — це не тільки проблема QA, це проблема, бо реальні юзери теж не можуть її знайти або натиснути! 🔥От вам і союзник — accessibility. Впроваджуйте раз, і користь всім.

🎧 Скрипт для розпізнавання аудіо українською мовоюЩо робить:- Обробляє всі файли у папці audio/- Розпізнає українську мову (Whisper Large)- Зберігає текст у файл- Відкриває результат у VS CodeЯк запустити:1. Встановити Python: https://www.python.org/downloads/2. Встановити FFmpeg: - Mac: brew install ffmpeg - Windows: https://ffmpeg.org/download.html3. Встановити бібліотеки:pip install openai-whisper ffmpeg-python4. Створити папку audio/ і додати туди файли (.mp3, .wav, .m4a, .flac)5. Запустити скрипт:python transcriber.pyРезультат:- Для кожного файлу з’явиться текстовий файл з розпізнаним текстом.Сам код:import whisperimport osimport subprocessimport time # ⬅️ Додаємо імпорт timeprint("=== Скрипт стартував ===")# Вимірюємо час стартуstart_time = time.time()# Завантаження моделі Whisperprint("Завантаження моделі...")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_timeprint(f"\n⏱️ Обробка завершена за {elapsed:.2f} секунд")print("=== Скрипт завершено ===")

✅ Чек-лист для перевірки авторизації та автентифікації.Перевіряємо надійність та безпеку доступу до системи!🔑 1. Автентифікація (перевірка особи користувача): • Використовуються надійні паролі (мінімум 8 символів, великі та малі літери, цифри, спеціальні символи). • Є можливість зміни пароля користувачем. • Налаштована багатофакторна аутентифікація (2FA або MFA). • Використовуються сучасні методи аутентифікації (OAuth, SSO, JWT). • Дані облікового запису зберігаються в зашифрованому вигляді (наприклад, хешування паролів). • Захист від брутфорсу (обмеження кількості спроб входу).👥 2. Авторизація (керування правами доступу): • Чітко визначені ролі та права доступу користувачів. • Правила доступу регулярно переглядаються та оновлюються. • Доступ до конфіденційних даних обмежений тільки авторизованими користувачами. • Використовуються принципи мінімальних прав (least privilege). • Логуються всі спроби доступу до чутливих даних.🕵️ 3. Безпека сесій: • Сесії автоматично завершуються після періоду неактивності. • Токени доступу мають обмежений термін дії. • Застосовується захист від крадіжки сесій (наприклад, прив’язка до IP або пристрою).📝 4. Логування та моніторинг: • Логуються всі успішні та невдалі спроби входу. • Логуються спроби доступу до адміністративних панелей. • Проводиться регулярний моніторинг логів на предмет підозрілої активності.🚨 5. Реакція на інциденти: • Впроваджено механізм блокування підозрілих користувачів. • Є процедура повідомлення про злом або спробу несанкціонованого доступу. • Створений план реагування на інциденти безпеки.#AllAboutQA

Отримай практичний досвід тестувальника!🔥👾📢 Ти вивчив тестування, але чуєш від працедавців: “Все добре, але не вистачає досвіду”?Курс EXPERIENCE.JOB – це шанс отримати реальну практику та додати до резюме досвід роботи на проєкті!😍🌟💡 Що на тебе чекає?✅ Робота у форматі справжньої команди тестувальників✅ Виконання тестових спринтів з тасками, дедлайнами, деплоями та фідбеком✅ Виявлення, заведення та ретестування багів у реальному робочому процесі✅ Досвід тестування критично важливих функцій: логін, реєстрація, smoke- та регресійне тестування✅ Знання та навички, які допоможуть впевнено проходити співбесіди та знайти першу роботу🔎 Як проходить навчання?Програма курсу максимально наближена до реальних умов роботи:📌 Спринт 1: Тестування логіну – перевірка чеклісту, заведення багів, ретести📌 Спринт 2: Smoke-тестування – виявлення критичних помилок перед релізом📌 Спринт 3: Тестування реєстрації та повна регресія всіх змін🗓 Старт курсу: 19 березня🔐 Реєстрація: https://qalight.ua/kursy/testirovanie/praktychnyj-kurs-manualnogo-testuvannya-experience-job/✏️Або адміністратор у Телеграм: @QALight_admin☎️Чи за телефоном:+38 (063) 78-010-78+38 (097) 78-010-78+38 (099) 78-010-78

Чек-лист для перевірки доступності сайту (Web Accessibility Checklist).1. Загальні принципи доступності • Сайт відповідає стандартам WCAG 2.1 (мінімальний рівень AA). • Всі функції доступні за допомогою клавіатури (без використання миші). • Контент доступний для всіх користувачів, включаючи людей із вадами зору, слуху, моторики та когнітивними порушеннями.2. Структура та семантика HTML • Використані правильні HTML-теги (заголовки <h1>-<h6>, списки <ul>/<ol>, абзаци <p>, таблиці <table>, кнопки <button> тощо). • Відсутні пусті заголовки, списки або таблиці без заголовків. • Всі інтерактивні елементи мають відповідні атрибути ARIA, якщо це необхідно. • Всі ідентифікатори на сторінці унікальні.3. Навігація та клавіатурний доступ • Всі інтерактивні елементи доступні через клавіатуру (Tab, Enter, Space, Arrow keys). • Є можливість пропустити навігаційні елементи (наприклад, кнопка “Skip to Content”). • Логічний порядок навігації (відповідає візуальному порядку). • Фокус видимий для всіх інтерактивних елементів. • Можна закрити будь-яке модальне вікно або випадаюче меню без миші.4. Альтернативний текст для медіа • Всі зображення мають відповідні alt-описи. • Декоративні зображення позначені alt="" або через role="presentation". • Відео мають субтитри або текстові транскрипти. • Аудіофайли мають текстову транскрипцію. • Є аудіоописи для відеоконтенту, якщо це необхідно.5. Контрастність та кольори • Мінімальний контраст тексту до фону — 4.5:1 (для звичайного тексту) або 3:1 (для великого тексту). • Колір не є єдиним засобом передачі інформації (наприклад, помилки підсвічуються не лише кольором, але й текстом або іконками). • Фон не зливається з текстом.6. Форматування тексту • Використовується читабельний шрифт, мінімальний розмір тексту — 16px. • Лінійна висота (line-height) тексту не менше 1.5. • Текст не втрачає читабельність при збільшенні масштабу браузера (до 200%). • Використовується вирівнювання за лівим краєм (уникається повне вирівнювання).7. Функціональність та інтерактивність • Всі інтерактивні елементи доступні за допомогою клавіатури. • Випадаючі списки, модальні вікна та інші інтерактивні елементи працюють коректно без миші. • Фокус автоматично не переноситься без відома користувача. • Форми мають підписані (label або aria-label) поля введення. • Всі кнопки мають зрозумілі текстові описи, а не лише іконки.8. Тести на різних пристроях • Перевірено доступність сайту на мобільних пристроях. • Сайт коректно відображається у різних браузерах. • Всі елементи мають достатній розмір для зручного натискання на сенсорних екранах.9. Додаткові перевірки • Використані автоматизовані інструменти перевірки доступності (Lighthouse, Axe, WAVE). • Проведено тестування користувачами з інвалідністю. • Випробувано сайт із екранними читалками (NVDA, JAWS, VoiceOver).

✅ Хочеш опанувати один із найзатребуваніших напрямків в ІТ?✅ Мрієш працювати у міжнародних компаніях та отримувати високу зарплату?✅ Готовий перейти на новий рівень та вивчити автоматизоване тестування за допомогою Selenium WebDriver (Python)?🔥🔥🔥Тоді цей курс саме для тебе!13 березня в QALight стартує курс "Автоматизація тестування за допомогою Selenium WebDriver (Python)".🔹 Що на тебе чекає?💡 24 заняття, повністю орієнтовані на практику💡 Навчання з нуля: від основ Python до побудови власного тестового фреймворку💡 Написання реальних автотестів, робота з API, базами даних, CI/CD💡 Підготовка до тестового інтерв’ю💼 Для кого цей курс?🔹 Початківців, які хочуть стати автоматизаторами🔹 Мануальних тестувальників, які прагнуть зменшити кількість операційки🔹 Розробників, які хочуть покращити якість свого коду 🔥 Запишись на безкоштовний перший урок прямо зараз! 👉 https://qalight.ua/kursy/automation/selenium-python/Адміністратор у Телеграм: @QALight_admin☎️Телефони:+38 (063) 78-010-78+38 (097) 78-010-78+38 (099) 78-010-78

Що в собі містить і для чого потрібно тест ревʼю?Тест рев’ю (Test Review) в контексті роботи QA-інженера — це процес перевірки тестової документації для виявлення помилок, покращення якості тест-кейсів і забезпечення відповідності вимогам. Це може бути як формальна, так і неформальна перевірка тестових артефактів.Що містить в собі тест рев’ю?1. Оцінка тестової документації: • Тест-план (Test Plan) — чи містить чіткий опис стратегії тестування, підходів, середовищ і критеріїв виходу. • Тест-кейси (Test Cases) / Чек-листи (Checklists) — чи покривають всі важливі сценарії, чи зрозуміло сформульовані, чи містять очікуваний результат. • Тестові сценарії (Test Scenarios) — чи враховані всі критичні бізнес-функції. • Тестові дані (Test Data) — чи правильно підібрані вхідні дані для різних сценаріїв. • Тестові звіти (Test Reports) — чи чітко зафіксовані результати тестування, дефекти, покриття тестами.2. Перевірка відповідності вимогам: • Чи тест-кейси покривають всі функціональні та нефункціональні вимоги. • Чи є зв’язок між тест-кейсами та вимогами (traceability matrix). • Чи немає пропущених або дубльованих тестів.3. Аналіз якості тестів: • Чи є чіткість і зрозумілість у тест-кейсах (унікальність, структура Given-When-Then, коректне формулювання очікуваного результату). • Чи не надто складні або непотрібні тест-кейси, які можуть ускладнити тестування. • Чи достатньо негативних сценаріїв та тестів на граничні значення.4. Аналіз ефективності покриття тестами: • Чи враховані основні користувацькі сценарії (happy path). • Чи є перехресне тестування (наприклад, API vs UI). • Чи враховано регресійне тестування.5. Автоматизовані тести (якщо є): • Чи правильно покриті ключові функції автоматизованими тестами. • Чи оптимізовані локатори, структура коду та логіка перевірок. • Чи є документація на автоматизовані тести.Формати тест рев’ю:🔹 Саморев’ю — коли QA перевіряє свої тести перед відправкою на командний рев’ю.🔹 Взаємне рев’ю (Peer Review) — коли інший тестувальник переглядає тест-кейси перед використанням.🔹 Формальне рев’ю (Formal Review) — коли вся команда (QA, розробники, аналітики) перевіряє тестову документацію, часто з фіксацією зауважень.🔹 Code Review для автотестів — якщо тести автоматизовані, їх код також переглядається за стандартами команди.Що дає тест рев’ю?✅ Підвищує якість тестування (менше помилок у тестах).✅ Виявляє пропущені сценарії ще до початку тестування.✅ Робить тестову документацію більш зрозумілою для команди.✅ Допомагає економити час за рахунок зменшення переробок тестів.Цей процес є ключовою частиною якісного QA-процесу, особливо в командах, що працюють за Agile або DevOps.

🔍 Аналітичні інструменти, які повинен знати тестувальник ПЗ.Сучасний тестувальник – це не просто виконавець тест-кейсів, а справжній аналітик, який допомагає команді покращувати якість продукту. Ось ключові інструменти аналітики, якими варто володіти:📊 Інструменти для аналізу логів: • Kibana, Splunk – пошук і візуалізація логів • Logstash, Graylog – збір та обробка логів🕵️ Моніторинг продуктивності та аплікейшен логів: • Grafana, Prometheus – моніторинг метрик додатків • New Relic, Datadog, AppDynamics – профілювання та аналіз продуктивності📢 Системи краш-репортів та аналітики поведінки користувачів: • Sentry, Firebase Crashlytics – відстеження помилок на проді • Google Analytics, Mixpanel, Hotjar – аналіз взаємодії користувачів з продуктом📌 Інструменти для роботи з базами даних: • SQL (MySQL, PostgreSQL, MS SQL, Oracle) – написання запитів для перевірки даних • NoSQL (MongoDB, Firebase, Redis) – робота з нереляційними БД📑 Інструменти BI (Business Intelligence): • Tableau, Power BI – створення інтерактивних звітів і дашбордів💡 Чому це важливо?Знання аналітичних інструментів допомагає тестувальнику не тільки знаходити баги, а й глибше розуміти причини їх появи, аналізувати тренди та вплив змін на продукт.

📌 Що містить стратегія тестування ПЗ і чим вона відрізняється від плану тестування?✅ Стратегія тестування – це високорівневий документ, що визначає загальні підходи, методи та принципи тестування в організації або конкретному проєкті. Вона відповідає на питання “як ми тестуємо?”Основні компоненти стратегії тестування:🔹 Об’єкт тестування – які компоненти або системи будуть тестуватися.🔹 Методологія –підходи до тестування (Waterfall, Agile, DevOps тощо).🔹 Типи тестування –функціональне, нефункціональне, регресійне, безпекове і т. д.🔹 Рівні тестування – юніт-тестування, інтеграційне, системне, приймальне.🔹 Автоматизація – які тести будуть автоматизовані, які інструменти використовуються.🔹 Критерії виходу та входу – коли тестування починається і коли вважається завершеним.🔹 Ризики та їх мінімізація – які загрози можуть вплинути на якість тестування.⚡ Чим стратегія відрізняється від плану тестування?🔹 Стратегія – це загальний підхід до тестування, вона є довгостроковою та може застосовуватися до кількох проєктів.🔹 План тестування – це конкретний документ для певного проєкту, який визначає що, коли і як буде тестуватися, хто відповідає за тестування, які ресурси необхідні тощо.📢 Висновок: стратегія тестування задає напрям, а тест-план – це детальна карта руху.#тестування#QA#allaboutqa