All about QA - Все про тестування ПЗ
Все про тестування ПЗ
YouTube канал для тестувальників
https://www.youtube.com/c/AllaboutQA
Manual testing, Performance testing, Automated testing, Security testing, Mobile testing
Курси, навчання, івенти, вакансії. Для питань —> @d_bezt
YouTube канал для тестувальників
https://www.youtube.com/c/AllaboutQA
Manual testing, Performance testing, Automated testing, Security testing, Mobile testing
Курси, навчання, івенти, вакансії. Для питань —> @d_bezt
Рейтинг TGlist
0
0
ТипПубличный
Верификация
Не верифицированныйДоверенность
Не провернныйРасположениеРосія
ЯзыкДругой
Дата создания каналаFeb 18, 2022
Добавлено на TGlist
Jun 01, 2024Прикрепленная группа
All about QA Chat
4
Последние публикации в группе "All about QA - Все про тестування ПЗ"
28.04.202516:01
Підготовка до регресії перед релізом: що врахувати?
Регресійне тестування — це один із ключових етапів перед релізом, який дозволяє впевнитися, що нові зміни не зламали вже працюючий функціонал. Щоб регресія була ефективною та не перетворилася на безкінечний марафон, важливо правильно до неї підготуватися.
Що включає підготовка до регресії?
1. Актуалізація тест-кейсів
• Перевірка й оновлення тестової документації.
• Видалення застарілих тестів, додавання нових згідно останніх змін.
2. Визначення зони покриття
• Повна регресія чи вибіркова?
• Визначення критичного функціоналу, який обов’язково тестувати.
3. Підготовка тестових даних та оточення
• Наявність стабільного стенду.
• Підготовка або відновлення тестових даних.
4. Автоматизація
• Використання автотестів для пришвидшення процесу.
• Перевірка актуальності та стабільності автотестів.
5. Розподіл ресурсів
• Планування участі команди (мануальне тестування, автотести, рев’ю).
• Врахування залучення бізнес-аналітиків або девелоперів для швидкого уточнення питань.
6. Ризик-менеджмент
• Визначення найбільш ризикових зон.
• Пріоритезація тестування.
Оптимальні терміни проведення регресії
Все залежить від:
• Обсягу змін (feature, багфікси, рефакторинг).
• Розміру та складності проєкту.
• Наявності автоматизації.
• Кількості учасників тестування.
Як вирахувати термін регресії?
1. Оцінка кількості тест-кейсів
Порахувати загальну кількість тестів, які потрібно виконати.
2. Оцінка часу на виконання одного тесту
В середньому це 3-10 хвилин на мануальний тест (залежить від складності).
3. Формула для мануальної регресії:
(Кількість тестів х Середній час на тест) / Кількість тестувальників = Орієнтовний час
4. Врахувати буфери:
• На багфікси.
• На непередбачувані затримки.
5. Автотести:
Якщо автотести покривають більшу частину функціоналу, їх запуск планується паралельно або до старту мануальної частини.
Приклад:
• 200 тест-кейсів
• Середній час: 5 хв
• 3 тестувальники
(200 х 5) / 3 = ~333 хв (~5,5 годин)
З буфером — 1 робочий день.
Рекомендації:
• Плануйте регресію мінімум за 1-2 дні до релізу, щоб був час на виправлення критичних багів.
• Використовуйте ризик-орієнтований підхід, якщо часу мало.
• Регулярно оновлюйте автотести — це інвестиція в швидкість майбутніх регресій.
P.S.
Грамотна підготовка до регресії — запорука спокійного релізу без нічних гарячок!
Регресійне тестування — це один із ключових етапів перед релізом, який дозволяє впевнитися, що нові зміни не зламали вже працюючий функціонал. Щоб регресія була ефективною та не перетворилася на безкінечний марафон, важливо правильно до неї підготуватися.
Що включає підготовка до регресії?
1. Актуалізація тест-кейсів
• Перевірка й оновлення тестової документації.
• Видалення застарілих тестів, додавання нових згідно останніх змін.
2. Визначення зони покриття
• Повна регресія чи вибіркова?
• Визначення критичного функціоналу, який обов’язково тестувати.
3. Підготовка тестових даних та оточення
• Наявність стабільного стенду.
• Підготовка або відновлення тестових даних.
4. Автоматизація
• Використання автотестів для пришвидшення процесу.
• Перевірка актуальності та стабільності автотестів.
5. Розподіл ресурсів
• Планування участі команди (мануальне тестування, автотести, рев’ю).
• Врахування залучення бізнес-аналітиків або девелоперів для швидкого уточнення питань.
6. Ризик-менеджмент
• Визначення найбільш ризикових зон.
• Пріоритезація тестування.
Оптимальні терміни проведення регресії
Все залежить від:
• Обсягу змін (feature, багфікси, рефакторинг).
• Розміру та складності проєкту.
• Наявності автоматизації.
• Кількості учасників тестування.
Як вирахувати термін регресії?
1. Оцінка кількості тест-кейсів
Порахувати загальну кількість тестів, які потрібно виконати.
2. Оцінка часу на виконання одного тесту
В середньому це 3-10 хвилин на мануальний тест (залежить від складності).
3. Формула для мануальної регресії:
(Кількість тестів х Середній час на тест) / Кількість тестувальників = Орієнтовний час
4. Врахувати буфери:
• На багфікси.
• На непередбачувані затримки.
5. Автотести:
Якщо автотести покривають більшу частину функціоналу, їх запуск планується паралельно або до старту мануальної частини.
Приклад:
• 200 тест-кейсів
• Середній час: 5 хв
• 3 тестувальники
(200 х 5) / 3 = ~333 хв (~5,5 годин)
З буфером — 1 робочий день.
Рекомендації:
• Плануйте регресію мінімум за 1-2 дні до релізу, щоб був час на виправлення критичних багів.
• Використовуйте ризик-орієнтований підхід, якщо часу мало.
• Регулярно оновлюйте автотести — це інвестиція в швидкість майбутніх регресій.
P.S.
Грамотна підготовка до регресії — запорука спокійного релізу без нічних гарячок!
post.reposted:
🇺🇦 Security QA
25.04.202509:09
Я думаю багато хто зтикався з проблемою коли треба попрацювати з PDF-документами, але не знали яким існтрументом можна таке зробити
- обрізати,
- об'єднати,
- розділити,
- конвертувати,
- прочитати метадані
- тощо,
але саме головне, вони ще можуть містити в собі чутливу інформацію і ви не хочете завантажувати їх на сторонні онлайн-сервіси, то ось рішення. Я просто стикнувся з цією проблемою коли починав тестувати флоу, тестування вимог через чат гпт, то ось що я надибав для зручності:
1. Інструменти командного рядка, наприклад, команди у linux для роботи з PDF-файлами:
ocrmypdf - розпізнавання тексту
pdftotext - витягти текст
pdfimages - витягти зображення
exiftool - витягти метадані
pdfgrep - пошук збігів за ключовими словами
pdfunite - об'єднати PDF-файли в один файл (для швидшого та зручнішого перегляду)
2. Самостійно розміщеними на компі PDF-сервісами, такими як Stirling PDF
https://github.com/Stirling-Tools/Stirling-PDF
- обрізати,
- об'єднати,
- розділити,
- конвертувати,
- прочитати метадані
- тощо,
але саме головне, вони ще можуть містити в собі чутливу інформацію і ви не хочете завантажувати їх на сторонні онлайн-сервіси, то ось рішення. Я просто стикнувся з цією проблемою коли починав тестувати флоу, тестування вимог через чат гпт, то ось що я надибав для зручності:
1. Інструменти командного рядка, наприклад, команди у linux для роботи з PDF-файлами:
ocrmypdf - розпізнавання тексту
pdftotext - витягти текст
pdfimages - витягти зображення
exiftool - витягти метадані
pdfgrep - пошук збігів за ключовими словами
pdfunite - об'єднати PDF-файли в один файл (для швидшого та зручнішого перегляду)
2. Самостійно розміщеними на компі PDF-сервісами, такими як Stirling PDF
https://github.com/Stirling-Tools/Stirling-PDF
24.04.202512:04
Quality Gatekeeper wanted!
У Solidgate ми оркеструємо 18+ млн платежів щомісяця для сотень компаній від Європи до ЛАТАМу 🌎
Інженерів та коду стає більше, тому підсилюємо команду AQA в напрямку Core.
Для нас автоматизація є ключовим інструментом в забезпеченні якості продукту. А тести - це обовʼязковий Quality Gate в CI/CD процесі - без якого неможливо доставити зміни в продакшн.
Трохи фактів:
🧱 200+ тестових наборів
📈 ~150 000 результатів щодня
✅ Flaky tests — лише 0.05%
З чим працюємо: Java, TestNG, Selenide, Retrofit, Testomatio.
Що потрібно: від 3+ років досвіду з автоматизацією на Java та досвід з TestNG та тестування API.
Якщо цікаво — пиши в Telegram (@orozhanska) або на пошту (olesia.rozhanska@solidgate.com), розкажу всі деталі!
У Solidgate ми оркеструємо 18+ млн платежів щомісяця для сотень компаній від Європи до ЛАТАМу 🌎
Інженерів та коду стає більше, тому підсилюємо команду AQA в напрямку Core.
Для нас автоматизація є ключовим інструментом в забезпеченні якості продукту. А тести - це обовʼязковий Quality Gate в CI/CD процесі - без якого неможливо доставити зміни в продакшн.
Трохи фактів:
🧱 200+ тестових наборів
📈 ~150 000 результатів щодня
✅ Flaky tests — лише 0.05%
З чим працюємо: Java, TestNG, Selenide, Retrofit, Testomatio.
Що потрібно: від 3+ років досвіду з автоматизацією на Java та досвід з TestNG та тестування API.
Якщо цікаво — пиши в Telegram (@orozhanska) або на пошту (olesia.rozhanska@solidgate.com), розкажу всі деталі!
23.04.202514:42
Рефайнмент Беклогу: Не нудна зустріч, а ключ до ефективності! 🧐✨
Часто чуєте про "рефайнмент" або "грумінг" беклогу, але не до кінця розумієте, що це і навіщо? 🤔 Давайте розбиратися!
Рефайнмент (Product Backlog Refinement) – це регулярна активність (не обов'язково формальна зустріч!), мета якої – підтримувати беклог продукту в актуальному, зрозумілому та готовому до роботи стані. Це не планування спринта, а підготовка до нього!
🎯 Головна ціль рефайнменту:
Перетворити ідеї та вимоги з беклогу на чіткі, оцінені та готові до реалізації елементи (User Stories, Tasks), щоб команда могла взяти їх у наступний спринт без зайвих запитань та затримок.
Що відбувається під час рефайнменту:
Обговорення: Команда детально розбирає елементи беклогу (зазвичай ті, що плануються на найближчі спринти).
Уточнення: Виявляються незрозумілі моменти, ставляться запитання Product Owner'у/аналітику.
Декомпозиція: Великі User Stories розбиваються на менші, більш керовані завдання.
Додавання деталей: Прописуються критерії приймання (Acceptance Criteria), технічні деталі, можливі залежності.
Оцінка: Команда дає попередню оцінку складності/обсягу роботи (напр., у Story Points).
Пріоритезація (опціонально): Product Owner може уточнити пріоритети на основі обговорення.
👥 Хто бере участь? Це командна робота!
Product Owner (PO) / Власник Продукту: Головний ініціатор. Пояснює бізнес-цінність, відповідає на питання "Що?" і "Навіщо?", встановлює пріоритети.
Команда Розробки (Development Team): Інженери, QA, дизайнери (всі, хто реалізує). Відповідають на питання "Як?", виявляють технічні складності, залежності, оцінюють роботу.
Scrum Master / Фасилітатор (часто): Допомагає провести зустріч ефективно, слідкує за часом, усуває перешкоди в обговоренні.
Бізнес-аналітик (BA) / Системний аналітик (SA) (за потреби): Допомагає PO у формулюванні вимог, уточнює деталі, готує документацію.
Представники інших команд/стейкхолдери (рідко, за потреби): Якщо є сильні залежності або потрібна експертиза ззовні.
📈 Навіщо це потрібно?
Зменшення невизначеності: Команда краще розуміє, що потрібно зробити до початку спрінта.
Покращення планування: Більш точні оцінки та реалістичні плани на спринт.
Швидший старт спрінта: Команда витрачає менше часу на уточнення вимог під час планування.
Підвищення якості: Заздалегідь виявлені проблеми та залежності дозволяють уникнути помилок.
Краща комунікація: Сприяє спільному розумінню цілей та завдань між PO та командою.
❗️ Рефайнмент – це не разова акція, а постійний процес! Регулярно приділяйте час (зазвичай кілька годин на спринт) на цю активність, і ваш беклог завжди буде у бойовій готовності! 💪
Часто чуєте про "рефайнмент" або "грумінг" беклогу, але не до кінця розумієте, що це і навіщо? 🤔 Давайте розбиратися!
Рефайнмент (Product Backlog Refinement) – це регулярна активність (не обов'язково формальна зустріч!), мета якої – підтримувати беклог продукту в актуальному, зрозумілому та готовому до роботи стані. Це не планування спринта, а підготовка до нього!
🎯 Головна ціль рефайнменту:
Перетворити ідеї та вимоги з беклогу на чіткі, оцінені та готові до реалізації елементи (User Stories, Tasks), щоб команда могла взяти їх у наступний спринт без зайвих запитань та затримок.
Що відбувається під час рефайнменту:
Обговорення: Команда детально розбирає елементи беклогу (зазвичай ті, що плануються на найближчі спринти).
Уточнення: Виявляються незрозумілі моменти, ставляться запитання Product Owner'у/аналітику.
Декомпозиція: Великі User Stories розбиваються на менші, більш керовані завдання.
Додавання деталей: Прописуються критерії приймання (Acceptance Criteria), технічні деталі, можливі залежності.
Оцінка: Команда дає попередню оцінку складності/обсягу роботи (напр., у Story Points).
Пріоритезація (опціонально): Product Owner може уточнити пріоритети на основі обговорення.
👥 Хто бере участь? Це командна робота!
Product Owner (PO) / Власник Продукту: Головний ініціатор. Пояснює бізнес-цінність, відповідає на питання "Що?" і "Навіщо?", встановлює пріоритети.
Команда Розробки (Development Team): Інженери, QA, дизайнери (всі, хто реалізує). Відповідають на питання "Як?", виявляють технічні складності, залежності, оцінюють роботу.
Scrum Master / Фасилітатор (часто): Допомагає провести зустріч ефективно, слідкує за часом, усуває перешкоди в обговоренні.
Бізнес-аналітик (BA) / Системний аналітик (SA) (за потреби): Допомагає PO у формулюванні вимог, уточнює деталі, готує документацію.
Представники інших команд/стейкхолдери (рідко, за потреби): Якщо є сильні залежності або потрібна експертиза ззовні.
📈 Навіщо це потрібно?
Зменшення невизначеності: Команда краще розуміє, що потрібно зробити до початку спрінта.
Покращення планування: Більш точні оцінки та реалістичні плани на спринт.
Швидший старт спрінта: Команда витрачає менше часу на уточнення вимог під час планування.
Підвищення якості: Заздалегідь виявлені проблеми та залежності дозволяють уникнути помилок.
Краща комунікація: Сприяє спільному розумінню цілей та завдань між PO та командою.
❗️ Рефайнмент – це не разова акція, а постійний процес! Регулярно приділяйте час (зазвичай кілька годин на спринт) на цю активність, і ваш беклог завжди буде у бойовій готовності! 💪
21.04.202513:40
Тестування міграції даних: Як не втратити голову (і дані!) 🤯
Переїзд даних зі старої системи (джерела) в нову (ціль)? Це завжди відповідальний етап проєкту! Щоб переконатися, що вся цінна інформація переїхала коректно, без втрат та спотворень, потрібне ретельне тестування міграції. 🚀
🛠️ Як готуватись? Ключ до успіху – у підготовці!
Аналіз: Глибоко зрозумійте структури даних (схеми) і в джерелі, і в цілі. Які типи даних, обмеження, зв'язки?
Мапінг: Майте чіткий документ, який описує, як поля зі старої системи відповідають полям у новій (data mapping).
Обсяг (Scope): Визначте, які саме дані мігрують, чи є часові рамки, чи є винятки.
Тестові дані: Підготуйте репрезентативний набір даних для тестування. В ідеалі – анонімізована копія продакшену або його значна частина.
Середовище: Налаштуйте ізольоване тестове середовище, що максимально наближене до продакшену.
Інструменти та скрипти: Підготуйте SQL-запити, скрипти порівняння, можливо, спеціалізовані інструменти для валідації даних.
Критерії успіху: Чітко визначте, за яких умов міграція вважається успішною (напр., % розбіжностей, час виконання).
✅ Що саме перевіряти?
Повнота (Completeness): Чи всі очікувані записи перенесено? Порівняйте кількість записів у таблицях джерела та цілі.
Точність (Accuracy): Чи значення даних у цільовій системі відповідають значенням у джерелі? Робіть вибіркову перевірку ключових полів.
Відповідність формату (Data Format): Чи відповідають типи даних, довжина полів, формат дати/часу тощо вимогам цільової системи?
Цілісність даних (Integrity): Чи збереглися зв'язки між таблицями (foreign keys)? Чи немає "осиротілих" записів?
Трансформації (Transformations): Якщо дані під час міграції якось змінювалися (напр., об'єднання полів, зміна формату), чи коректно спрацювали правила трансформації?
Дублікати (Duplicates): Чи не з'явилися дублікати записів у цільовій системі?
Нульові значення (Null Values): Чи коректно оброблені/перенесені
Граничні значення (Boundary Values): Перевірте коректність міграції мінімальних/максимальних значень, спеціальних символів, порожніх рядків.
Продуктивність (Performance): Скільки часу зайняв процес міграції? Чи відповідає це очікуванням?
Відкат (Rollback): Чи існує (і чи працює) процедура відкату міграції у разі критичних помилок?
📊 Етапи тестування:
Pre-Migration Testing: Перевірка готовності середовищ, валідація даних у джерелі до початку міграції.
Migration Execution & Monitoring: Запуск скриптів міграції, моніторинг процесу, аналіз логів на помилки.
Post-Migration Testing: Основний етап! Перевірка повноти, точності, цілісності, форматів даних у цільовій системі. Звірка даних між джерелом і ціллю.
Application Testing: Після підтвердження коректності даних – проведення smoke-тестів або повного регресійного тестування на цільовій системі, щоб переконатися, що вона працює з мігрованими даними.
💡 Головна порада: Не довіряйте процесу міграції "на слово"! Ретельно плануйте, готуйтеся, автоматизуйте перевірки (особливо звірку великих обсягів даних) і валідуйте результати на кожному кроці.
Успішних вам міграцій! ✨
#Тестування #МіграціяДаних #DataMigration #QA #ТестуванняПЗ #DataValidation #БазиДаних #AllAboutQA
Переїзд даних зі старої системи (джерела) в нову (ціль)? Це завжди відповідальний етап проєкту! Щоб переконатися, що вся цінна інформація переїхала коректно, без втрат та спотворень, потрібне ретельне тестування міграції. 🚀
🛠️ Як готуватись? Ключ до успіху – у підготовці!
Аналіз: Глибоко зрозумійте структури даних (схеми) і в джерелі, і в цілі. Які типи даних, обмеження, зв'язки?
Мапінг: Майте чіткий документ, який описує, як поля зі старої системи відповідають полям у новій (data mapping).
Обсяг (Scope): Визначте, які саме дані мігрують, чи є часові рамки, чи є винятки.
Тестові дані: Підготуйте репрезентативний набір даних для тестування. В ідеалі – анонімізована копія продакшену або його значна частина.
Середовище: Налаштуйте ізольоване тестове середовище, що максимально наближене до продакшену.
Інструменти та скрипти: Підготуйте SQL-запити, скрипти порівняння, можливо, спеціалізовані інструменти для валідації даних.
Критерії успіху: Чітко визначте, за яких умов міграція вважається успішною (напр., % розбіжностей, час виконання).
✅ Що саме перевіряти?
Повнота (Completeness): Чи всі очікувані записи перенесено? Порівняйте кількість записів у таблицях джерела та цілі.
Точність (Accuracy): Чи значення даних у цільовій системі відповідають значенням у джерелі? Робіть вибіркову перевірку ключових полів.
Відповідність формату (Data Format): Чи відповідають типи даних, довжина полів, формат дати/часу тощо вимогам цільової системи?
Цілісність даних (Integrity): Чи збереглися зв'язки між таблицями (foreign keys)? Чи немає "осиротілих" записів?
Трансформації (Transformations): Якщо дані під час міграції якось змінювалися (напр., об'єднання полів, зміна формату), чи коректно спрацювали правила трансформації?
Дублікати (Duplicates): Чи не з'явилися дублікати записів у цільовій системі?
Нульові значення (Null Values): Чи коректно оброблені/перенесені
NULL значення? Чи не з'явилися вони там, де не мали?Граничні значення (Boundary Values): Перевірте коректність міграції мінімальних/максимальних значень, спеціальних символів, порожніх рядків.
Продуктивність (Performance): Скільки часу зайняв процес міграції? Чи відповідає це очікуванням?
Відкат (Rollback): Чи існує (і чи працює) процедура відкату міграції у разі критичних помилок?
📊 Етапи тестування:
Pre-Migration Testing: Перевірка готовності середовищ, валідація даних у джерелі до початку міграції.
Migration Execution & Monitoring: Запуск скриптів міграції, моніторинг процесу, аналіз логів на помилки.
Post-Migration Testing: Основний етап! Перевірка повноти, точності, цілісності, форматів даних у цільовій системі. Звірка даних між джерелом і ціллю.
Application Testing: Після підтвердження коректності даних – проведення smoke-тестів або повного регресійного тестування на цільовій системі, щоб переконатися, що вона працює з мігрованими даними.
💡 Головна порада: Не довіряйте процесу міграції "на слово"! Ретельно плануйте, готуйтеся, автоматизуйте перевірки (особливо звірку великих обсягів даних) і валідуйте результати на кожному кроці.
Успішних вам міграцій! ✨
#Тестування #МіграціяДаних #DataMigration #QA #ТестуванняПЗ #DataValidation #БазиДаних #AllAboutQA
19.04.202512:56
Зберігаємо новий гайд з використання Claude Code від Anthropic. Там усе — як правильно формулювати запити, на чому робити акцент і які слова використовувати для очікуваного ефекту.
Повний гайд вивчаємо тут.
Повний гайд вивчаємо тут.
18.04.202511:14
Вийшла нова версія Playwright 1.52 і Артур Шевченко підготував короткий огляд оновлень: зручніший
expect(locator).toContainClass(), нові можливості для Aria Snapshots, гнучкіші налаштування Test Runner і кілька важливих змін, про які варто знати. Детальніше читайте в його дописі.17.04.202511:35
🇺🇦 Middle Manual QA | Державний оборонний проєкт.
Шукаємо QA на проєкт у сфері національної безпеки. Це високотехнологічна система ситуаційної обізнаності, що допомагає координувати дії сил оборони. Ваша робота матиме реальний вплив на безпеку України.
🔧 Вимоги:
•3+ роки досвіду на позиції manual/general QA
•практичний досвід тестування web застосунків
•практичний досвід тестування REST API (Postman, Swagger);
•вміння працювати з логами (ELK);
•вміння аналізувати запити через DevTools;
•базові навички SQL;
•базове розуміння git;
• Робота з базами даних (SQL)
💼 Умови:
• Конкурентна ЗП з прив’язкою до валютного курсу
• Гібридний формат: віддалено + офіс у Києві
• Оплачувані відпустки та лікарняні
• Сильна команда та підтримуюча атмосфера
• Професійне та кар’єрне зростання
• Робота, що напряму підсилює обороноздатність країни
📩 За деталями — пиши @alisha_st
P.S. Вакансія для цивільних, не контракт, не мобілізація. Вакансія реальна, перевірена.
#QA #middleQA #remote #вакансія #defense #Ukraine
Шукаємо QA на проєкт у сфері національної безпеки. Це високотехнологічна система ситуаційної обізнаності, що допомагає координувати дії сил оборони. Ваша робота матиме реальний вплив на безпеку України.
🔧 Вимоги:
•3+ роки досвіду на позиції manual/general QA
•практичний досвід тестування web застосунків
•практичний досвід тестування REST API (Postman, Swagger);
•вміння працювати з логами (ELK);
•вміння аналізувати запити через DevTools;
•базові навички SQL;
•базове розуміння git;
• Робота з базами даних (SQL)
💼 Умови:
• Конкурентна ЗП з прив’язкою до валютного курсу
• Гібридний формат: віддалено + офіс у Києві
• Оплачувані відпустки та лікарняні
• Сильна команда та підтримуюча атмосфера
• Професійне та кар’єрне зростання
• Робота, що напряму підсилює обороноздатність країни
📩 За деталями — пиши @alisha_st
P.S. Вакансія для цивільних, не контракт, не мобілізація. Вакансія реальна, перевірена.
#QA #middleQA #remote #вакансія #defense #Ukraine
02.04.202513:23
Навчальний посібник "Безпека вебдодатків" – доступний українською мовою!
Посібник "Безпека вебдодатків".
📖 Що всередині посібника?
🔹 Основи веббезпеки: типи вебсистем, клієнт-серверна архітектура, модель 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
25.03.202505:35
🎧 Скрипт для розпізнавання аудіо українською мовою
Що робить:
- Обробляє всі файли у папці 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("=== Скрипт завершено ===")
08.02.202512:09
Що допоможе в тестуванні iOS-застосунків?
Тестування iOS-додатків має свої особливості, і для ефективної роботи важливо використовувати правильні інструменти та підходи. Ось що може допомогти:
🔹 Xcode + XCTest – основний інструмент для написання юніт- та UI-тестів.
🔹 Xcode Instruments – аналіз продуктивності, витоку пам’яті, роботи CPU/GPU.
🔹 Charles/Fiddler – перехоплення мережевого трафіку для тестування API.
🔹 TestFlight – зручний сервіс для тестування збірок перед релізом.
🔹 Appium – кросплатформний інструмент для автоматизації мобільного тестування.
🔹 Firebase Test Lab – хмарне тестування на реальних пристроях.
🔹 Simulator & Real Devices – тестування як на симуляторі, так і на реальних пристроях (важливо перевіряти на різних моделях iPhone/iPad).
🔹 Accessibility Inspector – перевірка доступності для користувачів з обмеженими можливостями.
⚡️ #AllAboutQA
Тестування iOS-додатків має свої особливості, і для ефективної роботи важливо використовувати правильні інструменти та підходи. Ось що може допомогти:
🔹 Xcode + XCTest – основний інструмент для написання юніт- та UI-тестів.
🔹 Xcode Instruments – аналіз продуктивності, витоку пам’яті, роботи CPU/GPU.
🔹 Charles/Fiddler – перехоплення мережевого трафіку для тестування API.
🔹 TestFlight – зручний сервіс для тестування збірок перед релізом.
🔹 Appium – кросплатформний інструмент для автоматизації мобільного тестування.
🔹 Firebase Test Lab – хмарне тестування на реальних пристроях.
🔹 Simulator & Real Devices – тестування як на симуляторі, так і на реальних пристроях (важливо перевіряти на різних моделях iPhone/iPad).
🔹 Accessibility Inspector – перевірка доступності для користувачів з обмеженими можливостями.
⚡️ #AllAboutQA
post.reposted:
QALight Info
05.09.202412:20
БЕЗКОШТОВНО!🔥🔥🔥
▶️Про те, як потрапити в ІТ, почати реально ПРАЦЮВАТИ і ЗАРОБЛЯТИ.
🟢Вебінар від QALight «Як стати тестувальником і знайти першу роботу в ІТ».🟢
На вебінарі ми:
✔️Розглянемо портрет тестувальника – для кого ця професія, що треба знати, вміти, до чого бути готовим.
✔️Проаналізуємо ринок праці та сучасну ситуацію – де і за скільки можна почати працювати.
✔️Створимо «дорожню карту» – як з нуля дійти до першої роботи в ІТ.
🗓Дата: 6 вересня 2024 року
⏰Час: 19:00
🌍Де: ZOOM, онлайн
🔝Проведе вебінар Микола Бобошко, CEO&Founder QALight, наставник тисяч успішних QA, що працюють по всьому світу.
🔗Реєстрація: https://forms.gle/vjgKHJJYN1M5NEno6
🌟😍Ринок ІТ стабілізується, вакансій стало більше. Не прогав шанс отримати перспективну професію!🚀
▶️Про те, як потрапити в ІТ, почати реально ПРАЦЮВАТИ і ЗАРОБЛЯТИ.
🟢Вебінар від QALight «Як стати тестувальником і знайти першу роботу в ІТ».🟢
На вебінарі ми:
✔️Розглянемо портрет тестувальника – для кого ця професія, що треба знати, вміти, до чого бути готовим.
✔️Проаналізуємо ринок праці та сучасну ситуацію – де і за скільки можна почати працювати.
✔️Створимо «дорожню карту» – як з нуля дійти до першої роботи в ІТ.
🗓Дата: 6 вересня 2024 року
⏰Час: 19:00
🌍Де: ZOOM, онлайн
🔝Проведе вебінар Микола Бобошко, CEO&Founder QALight, наставник тисяч успішних QA, що працюють по всьому світу.
🔗Реєстрація: https://forms.gle/vjgKHJJYN1M5NEno6
🌟😍Ринок ІТ стабілізується, вакансій стало більше. Не прогав шанс отримати перспективну професію!🚀
04.09.202415:56
04.09.202413:34
🇺🇦 IT вакансії до Сил Оборони України 🇺🇦
👤 DevOps/DevSecOps/SysAdmin
мобілізація до кінця воєнного стану або служба за контрактом, м. Київ
👤 Middle Firmware Engineer (напрям пілотування/навігації)
мобілізація до кінця воєнного стану або служба за контрактом, 12-й окремий загін спеціального призначення
👤 Розробник програмного забезпечення
НГУ, служба за контрактом до кінця воєнного стану, м. Київ
👤 Senior/Expert Machine Learning Engineer
служба за контрактом до кінця воєнного стану, м. Київ
👤 Automative QA (hardware)
служба за контрактом, переведення, м. Київ
👤 Embedded розробник
служба за контрактом, переведення, м. Київ
👤 Senior Frontend розробник
переведення, м. Київ
👤 Спеціаліст з технічної підтримки
служба за контрактом до кінця воєнного стану, м. Київ
👤 CSOC Engineer
мобілізація до кінця воєнного стану, переведення
🇺🇦🇺🇦 Приєднуйся до Сил Оборони! 🇺🇦🇺🇦
👤 DevOps/DevSecOps/SysAdmin
мобілізація до кінця воєнного стану або служба за контрактом, м. Київ
👤 Middle Firmware Engineer (напрям пілотування/навігації)
мобілізація до кінця воєнного стану або служба за контрактом, 12-й окремий загін спеціального призначення
👤 Розробник програмного забезпечення
НГУ, служба за контрактом до кінця воєнного стану, м. Київ
👤 Senior/Expert Machine Learning Engineer
служба за контрактом до кінця воєнного стану, м. Київ
👤 Automative QA (hardware)
служба за контрактом, переведення, м. Київ
👤 Embedded розробник
служба за контрактом, переведення, м. Київ
👤 Senior Frontend розробник
переведення, м. Київ
👤 Спеціаліст з технічної підтримки
служба за контрактом до кінця воєнного стану, м. Київ
👤 CSOC Engineer
мобілізація до кінця воєнного стану, переведення
🇺🇦🇺🇦 Приєднуйся до Сил Оборони! 🇺🇦🇺🇦
post.reposted:
DOU | QA
04.09.202413:03
Вереснева добірка подій для тестувальників! 🍁
5.09, онлайн Онлайн-співбесіда: Junior Manual QA #17
6.09, онлайн Вебінар «Як стати тестувальником і знайти першу роботу в ІТ»
11.09, онлайн Вебінар «Можливості АІ: чи може QA+BA створити проект «з нуля?»
21.09, онлайн Вебінар «Міфи та реальність у навчанні Automation QA та Manual QA» від Анни Єщенко
#DOU_Календар
5.09, онлайн Онлайн-співбесіда: Junior Manual QA #17
6.09, онлайн Вебінар «Як стати тестувальником і знайти першу роботу в ІТ»
11.09, онлайн Вебінар «Можливості АІ: чи може QA+BA створити проект «з нуля?»
21.09, онлайн Вебінар «Міфи та реальність у навчанні Automation QA та Manual QA» від Анни Єщенко
#DOU_Календар
Рекорды
28.04.202523:59
2.4KПодписчиков17.04.202523:59
200Индекс цитирования30.06.202423:59
1.7KОхват одного поста05.09.202423:59
941Охват рекламного поста03.04.202514:44
11.66%ER11.04.202520:21
35.33%ERRpost.reposted:🇺🇦 Security QA
25.04.202509:09
Я думаю багато хто зтикався з проблемою коли треба попрацювати з PDF-документами, але не знали яким існтрументом можна таке зробити
- обрізати,
- об'єднати,
- розділити,
- конвертувати,
- прочитати метадані
- тощо,
але саме головне, вони ще можуть містити в собі чутливу інформацію і ви не хочете завантажувати їх на сторонні онлайн-сервіси, то ось рішення. Я просто стикнувся з цією проблемою коли починав тестувати флоу, тестування вимог через чат гпт, то ось що я надибав для зручності:
1. Інструменти командного рядка, наприклад, команди у linux для роботи з PDF-файлами:
ocrmypdf - розпізнавання тексту
pdftotext - витягти текст
pdfimages - витягти зображення
exiftool - витягти метадані
pdfgrep - пошук збігів за ключовими словами
pdfunite - об'єднати PDF-файли в один файл (для швидшого та зручнішого перегляду)
2. Самостійно розміщеними на компі PDF-сервісами, такими як Stirling PDF
https://github.com/Stirling-Tools/Stirling-PDF
- обрізати,
- об'єднати,
- розділити,
- конвертувати,
- прочитати метадані
- тощо,
але саме головне, вони ще можуть містити в собі чутливу інформацію і ви не хочете завантажувати їх на сторонні онлайн-сервіси, то ось рішення. Я просто стикнувся з цією проблемою коли починав тестувати флоу, тестування вимог через чат гпт, то ось що я надибав для зручності:
1. Інструменти командного рядка, наприклад, команди у linux для роботи з PDF-файлами:
ocrmypdf - розпізнавання тексту
pdftotext - витягти текст
pdfimages - витягти зображення
exiftool - витягти метадані
pdfgrep - пошук збігів за ключовими словами
pdfunite - об'єднати PDF-файли в один файл (для швидшого та зручнішого перегляду)
2. Самостійно розміщеними на компі PDF-сервісами, такими як Stirling PDF
https://github.com/Stirling-Tools/Stirling-PDF
История изменений канала
Войдите, чтобы разблокировать больше функциональности.
