Статистика telegram каналу - @qamania
2024-07-14
QAMania
Кількість підписників:
4177
Фото:
191
Відео:
9
Посилання:
610
Категорія:
Технології
Опис:
Ламповий блог про тестування, пишемо про те, що нам цікаво та власний досвід. А ще в нас є 🌐 https://qamania.org 📺 https://youtube.com/@QAMania
Кількість підписників
Середній перегляд на повідомлення
Історія змін лого
Поки що змін не зафіксовано
Історія змін назви
Поки що змін не зафіксовано
Історія зміни типу аккаунта
Поки що змін не зафіксовано
Історія зміни статуса
Офіційно не підтверджена
2024-07-14
Стіна канала QAMania - @qamania
Привіт друзі! Трохи заклопотаний через роботу, мітапи та підготовку до дев челенджу, але я про всіх вас не забув.
Я вирішив підтримати ініціативу нашого незламного президента і потужно допомогти нашій QA спільноті. Щоб запобігти скороченням в ІТ і дати тестувальникам більше роботи, я дав розпорядження міністерству потужної незламності видати кожному QA в Україні по 1000 багів! 🐞 По нашим розрахункам - вони вже мають надходити в ПЗ, яке ви тестуєте. Просто проведіть регрешн чи хоча б smoke - і знайте, всі знайдені вами баги - то від мене.
Оскільки багів у всіх стало більше - сміливо йдіть до керівництва і просіть більше грошів, щоб потужно знайти всі баги
Не забудьте розказати про “Льошину тисячу” колегам - най перевірять застосунки, що тестують!
1300
24-10-28 14:52
#Збір на Мавік
Привіт друзі! Мій знайомий колега і волонтер відкрив збір на мавік, нижче його пост. Будемо вдячні за допомогу і поширення (посилання на збір)
➿ ➿ ➿ ➿ ➿ ➿
⚡️ Дрон для ППО ⚡️
Друзі, вітаю!
Наш близький друг служить у ППО (643 окремий зенітний батальйон 831 бригади тактичної авіації)
Раніше ми допомагали цьому підрозділу зі старлінком та колесами, але зараз виникла нова потреба - хлопцям потрібен дрон.
Після збиття ворожих БПЛА, їм доводиться шукати ці БПЛА пішки, витрачаючи купу часу.
Щоб пришвидшити і полегшити пошуки, необхідний DJI Mavic 3 (звичайний, без тепловізора).
Це значно підвищить ефективність роботи і зекономить їм сили.
Мета збору: 80,000 грн.
Схема проста як завжди: збір —> закупка —> передача —> звіт.
Реквізити:
💳 Монобанка: https://send.monobank.ua/jar/8fo5KJb1vy
💳 Номер банки: 5375411223863395
💳 Приват: 4731219659848570
Всі реквізити на імʼя: Валелерій Синенко
Давайте допоможемо їм, захистити нас!
Привіт друзі! Мій знайомий колега і волонтер відкрив збір на мавік, нижче його пост. Будемо вдячні за допомогу і поширення (посилання на збір)
⚡️ Дрон для ППО ⚡️
Друзі, вітаю!
Наш близький друг служить у ППО (643 окремий зенітний батальйон 831 бригади тактичної авіації)
Раніше ми допомагали цьому підрозділу зі старлінком та колесами, але зараз виникла нова потреба - хлопцям потрібен дрон.
Після збиття ворожих БПЛА, їм доводиться шукати ці БПЛА пішки, витрачаючи купу часу.
Щоб пришвидшити і полегшити пошуки, необхідний DJI Mavic 3 (звичайний, без тепловізора).
Це значно підвищить ефективність роботи і зекономить їм сили.
Мета збору: 80,000 грн.
Схема проста як завжди: збір —> закупка —> передача —> звіт.
Реквізити:
💳 Монобанка: https://send.monobank.ua/jar/8fo5KJb1vy
💳 Номер банки: 5375411223863395
💳 Приват: 4731219659848570
Всі реквізити на імʼя: Валелерій Синенко
Давайте допоможемо їм, захистити нас!
1200
24-10-26 06:49
#devchallenge
⭐️ Завдання №4 - тестова стратегія
За легендою, є старий проєкт для освітніх закладів, який хочуть переписати на новий стек, з мікросервісами, мобільними апками, блек джеком та курвами. Потрібно взяти готовий шаблон і написати стратегію тестування, враховуючи вказаний набір технологій та сроки.
✅ Expected results
Стратегія має мати
🟢 Користь для бізнесу
🟢 Цілі тестування
🟢 Підхід (Approach)
🟢 Метрики
🟢 Умови початку і закінчення тестування (Entry/Exit Criteria)
🟢 Об’єм робіт (Scope)
🟢 Ризики і питання (оскільки опис дуже короткий)
В цій задачі нема правильних та не правильних рішень - все в рамках адекватності
⚠️ Actual results
🟠 Таке враження, що більшість знову використала ШІ і навіть не почитала, що вписує в стратегію
🟠 Я бачив багато робіт з майже ідентичним змістом. Більш того - це generic відповідь chat-GPT про тестову стратегію - він просто перелічує всі відомі йому підходи, незалежно від того, чи вони тут можуть бути використані.
🟠 Багато проблем з визначенням користі для бізнесу - здається, QA інженери не розуміють, навіщо взагалі компанії платять за тестування
🟠 Якщо у вас є пів року, у вас фізично не буде часу на автоматизацію, враховуючи, що треба покрити Android, iOS, браузерну версію і стару версію на Delphi (навіщо?)
🟠 Багато хто запропонував зробити фокус на Performance та Security тестуванні - я фанат, але ви впевнені, що ви це зробите? І чи треба саме на цьому фокусуватись? Може спочатку функції перевірити?
🟠 Метрики - мало виписати список всього, що ви прочитали в інтернеті - метрики служать цілі. Якщо ваша ціль тестування - скорочення часу розробки, то й метрики мають бути спрямовані на визначення, чи ви виконуєте цю ціль, а не просто кількість тестів та багів
🟠 Ризики - це складна тема. Саме тому для вас Рома попросив додати слона в кімнату - застосунок на Delphi, який треба підтримувати, і витрачати на нього увагу. Очевидний ризик! Але не всі побачили
💡 Загальне враження -Хоча я й написав багато ай-ай-ай, але в цілому, мені сподобались стратегії. Я спродіваюсь, з ШІ чи без, учасники отримали цінний досвід і зможуть стратегічно поглянути на тестування і зробити світ якіснішим!
Дякую, що дочитали! Чекайте звіт по фіналу❣️
⭐️ Завдання №4 - тестова стратегія
За легендою, є старий проєкт для освітніх закладів, який хочуть переписати на новий стек, з мікросервісами, мобільними апками, блек джеком та курвами. Потрібно взяти готовий шаблон і написати стратегію тестування, враховуючи вказаний набір технологій та сроки.
✅ Expected results
Стратегія має мати
В цій задачі нема правильних та не правильних рішень - все в рамках адекватності
⚠️ Actual results
Дякую, що дочитали! Чекайте звіт по фіналу
1700
24-10-18 07:01
#devchallenge
⭐️ Завдання №3 - автоматизація
Завдання - соціальний експеримент. Ніяких легенд - потібно будь-яким безкоштовним інструментом, будь-якою мовою автоматизувати 3 простих тест кейса на сторінці https://devchallenge.it В самому завданні сказано, що можна користуватись ШІ і всім, що допоможе вирішити задачу.
По-перше, я та інші судді важаємо, що в 2024 році всі тестери мають хоч трішки розбиратись в автоматизації
По-друге, чергова лякалка, що от тепер, зі штучним інтелектом, розробники автотестери не потрібні. Цікаво подивитись, чи дійсно некодери зможуть успішно вирішити досить тривіальну задачу.
✅ Expected results
🟢 Судді мають отримати файли тестів та інструкцію, як їх запустити
🟢 Якщо всі кроки інструкції виконані і ми бачимо браузер, що виконує сценарії - це успіх. Ніяких хитрощів і підводних каменів
🟢 Особисто я очікував, що більшість піде найпростішим шляхом, і візьме Playwright + TS, і запише тести рекордером
⚠️ Actual results
🟠 Люди розучились писати інструкції. Для QA інженера це неприпустимо! 50% інструкцій не містять важливих кроків. Я б мав ставити 0 за такі роботи, але маю навички і досвід, тож запустив майже весь отриманий код. Але серед нас є і судді не автоматизатори. Якщо ваші тести на джаві/JS/Python, а ви не вказали, що цю мову потрібно встановити - тести вже не пройдуть. Якщо ви написали їх на Mac, вони можуть не запуститись на Linux чи Windows. І як мінімум, читайте 1 раз самі, що ви написали 😡
🟠 Було декілька грунтовних робіт - не просто файл тесту, а проєкт, з фабрикою браузерів, окремими класами на кроки, а зверху ще й тести написані на Cucumber. На написання такого треба витратити не години, а дні роботи. Як на мене це зайве ускладнення. А ще, не зважаючи на всю помпезність, використані дуже погані локатори типу
🟠 Були роботи, автори яких пропонували встановити IDE для запуску тестів. Народ, так ніхто не робить - це має бути 1 команда для CLI чи навіть скрипт - запустив - і все працює
🟠 Були роботи, які імітували виконання тестів, але по факту, код нічого не робив. Але ми вміємо читати 😀
🟠 1 людина написала в інструкції, що тести їй написав ШІ, а надиво - тести гарно працювали!
🟠 Загальна статистика:
➡️ Я зміг запустити 50% всіх тестових проєктів
➡️ Топ мов програмування: Python, TS, Java, Kotlin, JS. Я приємно здивований, що Python обрало найбільше
➡️ Топ фреймворків: Playwright, Selenium, Selenide, Cucumber, Cypress, Selenium IDE. Я дуже радів побачити тести на Selenium IDE - щось тепле і лампове з далекого минулого. А головне - це працює і вирішує задачу!
💡 Загальне враження - Автоматизатори - видихайте, ШІ нас не замінить. Не автоматизатори - починайте цікавитись автоматизацією, щоб випадкова задача не поставила вас в незручне становище. А ще мене турбує загальна якість більшості побаченого коду. Я розумію, що це Challenge, і можна не так старатись, але якщо вам за це гроші платять - вчіться робити якісніше!
⭐️ Завдання №3 - автоматизація
Завдання - соціальний експеримент. Ніяких легенд - потібно будь-яким безкоштовним інструментом, будь-якою мовою автоматизувати 3 простих тест кейса на сторінці https://devchallenge.it В самому завданні сказано, що можна користуватись ШІ і всім, що допоможе вирішити задачу.
По-перше, я та інші судді важаємо, що в 2024 році всі тестери мають хоч трішки розбиратись в автоматизації
По-друге, чергова лякалка, що от тепер, зі штучним інтелектом, розробники автотестери не потрібні. Цікаво подивитись, чи дійсно некодери зможуть успішно вирішити досить тривіальну задачу.
✅ Expected results
⚠️ Actual results
div/div/div/div/span/div/a
. Я б рекомендував витрачати час ефективніше
2000
24-10-17 07:01
#devchallenge
Привіт друзі! Завершився онлайн раунд DevChallange 21, вітаю всіх причетних і поспішаю поділитись своїми думками і спостереженнями цього року.
Матеріалу багато, тож буде декілька постів.
Загалом було придумано 4 задачі, які учасники мали виконати за 20 днів. Традиційно, номінація тестування містила 2 категорії: легше і важче, але цього року ми не стали пропонувати різні завдання учасникам (бо перевіряти їх потім важко), а запропонували тим, хто хоче легше виконати всього перші 3 завдання. До оцінювання робіт ми ретельно готуємось, тож у нас буквально написані expected results з кількістю балів за кожен пункт. Тож давайте, як справжні QA, подивимось на типові actual results і виміряємо якість відповідей учасників.
⭐️ Завдання №1 - вибір інструмента
За легендою учасник має обрати найкращий інструмент для тестування API складної системи, що містить цілий зоопарк інтерфейсів:
➡️ TCP sockets (data serialized as XML)
➡️ UDP sockets (byte stream)
↪️ SOAP (via HTTP and FTP)
➡️ REST API (JSON and byte stream via HTTP)
➡️ Web Sockets
↪️ GraphQL (via HTTP)
➡️ FTP and SFTP
➡️ + бази даних, різна автентифікація для HTTP та SHH tunneling
Учасникам було запропоновано пошукати інструменти, створити порівняльну таблицю і обрати найкращий інструмент для тестування. І написати короткий висновок, чому обрано саме цей інструмент.
Це досить типова задача для інженера - знайти щось, що за однакових обставин простіше, дешевше, корисніше. Незнання API не рахується як виправдання. Коли ви обираєте холодильники, телевізори чи телефони, теж не обов’язково розумієте всі фічі. Коли мав необхідність обрати і замовити РЕБ для підрозділу морпіхів - теж не дуже розумів список фіч, тож довелось швидко збирати інформацію 🤷♂️
✅ Expected results
- Ми очікували побачити порівняльну таблицю - в колонках інструменти, в рядках - фічі, які порівнюються.
- Ми очікували - що кожен протокол буде окремою фічою (рядком)
- Ми очікували, що учасники переглянуть документацію та проставлять реалістичні оцінки
- Ми не очікували, що учасники знайдуть один супер-інструмент, бо це майже неможливо (хоча цікаво було почитати про незнайомі), тож головна хитрість - зрозуміти, що ідеального інструмента немає і треба запропонувати наайкращу комбінацію, що задовільнить всі вимоги. І в висновку це і треба було написати
⚠️ Actual results
- більшість учасників чомусь вирішила, що дійсно може існувати лише 1 інструмент. Але біда навіть не в цьому, а в тому, що цей інструмент - Postman, який ні з TCP, ні з базами не працює. Типу - нема інструмента, значить ті АПІ хай хтось інший тестує
- Частина учасників, при цьому, в порівняльній таблиці без вагань ставила Postman`у 3 бали з 3 за повну підтримку протоколу TCP - таке враження, що скопіювали відповідь з ШІ не сильно вчитуючись, що саме він написав
- Багато, мінімум 50% учасників чомусь об’єднали всі протоколи в 1 рядок, який назвали “протоколи”. В інших були ціна, зручність користування та ін. Це однозначно поганий підхід, тому що важко порівнювати інструменти, якщо умовно Postman має оцінку протоколів 2/3, а JMeter - 3/3. Як зрозуміти з цього, який що вміє?
- Майже ніхто не згадав бази даних в можливостях інструментів - про них ніби забули, тому що вони описані не пунктом списку, а реченням нижче. Треба бути уважнішими!
- Деякі учасники зробили горизонтальні таблиці, які буквально треба скролити не вниз, а вправо. За що?
- Хочу відмітити декілька сильних робіт, які отримали майже максимальні бали і навіть запропонували цікаві рішення ❤️
💡 Загальне враження - суб’єктивно мені здається, що більшість учасників не шукала інструменти в Інтернеті, як в старі добрі часи, а попросила написати порівняння в Chat-GPT, і навіть не перевірили результати. Не треба так 🥲
Привіт друзі! Завершився онлайн раунд DevChallange 21, вітаю всіх причетних і поспішаю поділитись своїми думками і спостереженнями цього року.
Матеріалу багато, тож буде декілька постів.
Загалом було придумано 4 задачі, які учасники мали виконати за 20 днів. Традиційно, номінація тестування містила 2 категорії: легше і важче, але цього року ми не стали пропонувати різні завдання учасникам (бо перевіряти їх потім важко), а запропонували тим, хто хоче легше виконати всього перші 3 завдання. До оцінювання робіт ми ретельно готуємось, тож у нас буквально написані expected results з кількістю балів за кожен пункт. Тож давайте, як справжні QA, подивимось на типові actual results і виміряємо якість відповідей учасників.
⭐️ Завдання №1 - вибір інструмента
За легендою учасник має обрати найкращий інструмент для тестування API складної системи, що містить цілий зоопарк інтерфейсів:
Учасникам було запропоновано пошукати інструменти, створити порівняльну таблицю і обрати найкращий інструмент для тестування. І написати короткий висновок, чому обрано саме цей інструмент.
Це досить типова задача для інженера - знайти щось, що за однакових обставин простіше, дешевше, корисніше. Незнання API не рахується як виправдання. Коли ви обираєте холодильники, телевізори чи телефони, теж не обов’язково розумієте всі фічі. Коли мав необхідність обрати і замовити РЕБ для підрозділу морпіхів - теж не дуже розумів список фіч, тож довелось швидко збирати інформацію 🤷♂️
✅ Expected results
- Ми очікували побачити порівняльну таблицю - в колонках інструменти, в рядках - фічі, які порівнюються.
- Ми очікували - що кожен протокол буде окремою фічою (рядком)
- Ми очікували, що учасники переглянуть документацію та проставлять реалістичні оцінки
- Ми не очікували, що учасники знайдуть один супер-інструмент, бо це майже неможливо (хоча цікаво було почитати про незнайомі), тож головна хитрість - зрозуміти, що ідеального інструмента немає і треба запропонувати наайкращу комбінацію, що задовільнить всі вимоги. І в висновку це і треба було написати
⚠️ Actual results
- більшість учасників чомусь вирішила, що дійсно може існувати лише 1 інструмент. Але біда навіть не в цьому, а в тому, що цей інструмент - Postman, який ні з TCP, ні з базами не працює. Типу - нема інструмента, значить ті АПІ хай хтось інший тестує
- Частина учасників, при цьому, в порівняльній таблиці без вагань ставила Postman`у 3 бали з 3 за повну підтримку протоколу TCP - таке враження, що скопіювали відповідь з ШІ не сильно вчитуючись, що саме він написав
- Багато, мінімум 50% учасників чомусь об’єднали всі протоколи в 1 рядок, який назвали “протоколи”. В інших були ціна, зручність користування та ін. Це однозначно поганий підхід, тому що важко порівнювати інструменти, якщо умовно Postman має оцінку протоколів 2/3, а JMeter - 3/3. Як зрозуміти з цього, який що вміє?
- Майже ніхто не згадав бази даних в можливостях інструментів - про них ніби забули, тому що вони описані не пунктом списку, а реченням нижче. Треба бути уважнішими!
- Деякі учасники зробили горизонтальні таблиці, які буквально треба скролити не вниз, а вправо. За що?
- Хочу відмітити декілька сильних робіт, які отримали майже максимальні бали і навіть запропонували цікаві рішення ❤️
1900
24-10-15 07:01
⚡️Приєднуйтеся до події від SQUAD – Embedded QA skill set: Are you all set? 23 жовтня, онлайн + офлайн у Києві
У програмі:
📌 Актуальні скіли для Embedded QA
📌 Статистика по топ навичкам для Embedded QA в Україні та США
📌 Визначення пріоритетних скілів кандидатів при наймі в команду
📌 Обґрунтоване формування цілей та трекінг прогресу розвитку колег
📌 Оптимізація підбору ресурсів на проєкт
📌 Чому skill set матриця є одним з найзручніших інструментів візуалізації вмінь команди?
Участь безкоштовна, деталі та реєстрація — https://bit.ly/4eU7luY 🔥
У програмі:
📌 Актуальні скіли для Embedded QA
📌 Статистика по топ навичкам для Embedded QA в Україні та США
📌 Визначення пріоритетних скілів кандидатів при наймі в команду
📌 Обґрунтоване формування цілей та трекінг прогресу розвитку колег
📌 Оптимізація підбору ресурсів на проєкт
📌 Чому skill set матриця є одним з найзручніших інструментів візуалізації вмінь команди?
Участь безкоштовна, деталі та реєстрація — https://bit.ly/4eU7luY 🔥
1900
24-10-08 15:05
Фантомні поїзди у Швейцарії 🚂👻
#bugseverywhere
Продовжуємо подорож до цікавих прикладів overflow, на цей раз швейцарською залізницею.
Як виявляється, навіть швейцарськігодинники залізниці не застраховані від проблем, пов'язаних з переповненням змінних.
Поїздам у Швейцарії не дозволено мати рівно 256 осей. Це може здатися абсурдним обмеженням, але справа не в суворих європейських регуляціях чи дивній бюрократії. Причина набагато цікавіша — і це справжній баг!
Швейцарська залізнична мережа використовує детектори, розташовані вздовж рейок, для відстеження місцезнаходження поїздів. Ці детектори активуються, коли колесо проходить по рейці, і рахують кількість коліс, щоб надати основну інформацію про поїзд, що щойно проїхав. На жаль, кількість коліс відстежується за допомогою 8-розрядного двійкового числа. Коли це число досягає свого максимуму — 255 (або 11111111 в двійковій системі) — воно скидається до нуля. Тобто будь-який поїзд рівно із 256 осями стає "невидимим" для системи, ніби справжній фантомний потяг.
Цікавий також спосіб вирішення цієї проблеми: регламент швейцарських залізниць містить правило, яке забороняє поїздам мати 256 осей. Це правило знаходиться десь між положеннями про навантаження на поїзди та способи, за допомогою яких провідники можуть спілкуватися з водіями. Таке враження, що запитів від людей, які хотіли б додати 256-у вісь, було настільки багато, що залізничники вирішили просто пояснити це в керівництві. Очевидно, що таке бюрократичне рішення виявилося простішим, ніж змінити код системи або ж оновити всі датчики.
Отож, це один із тихрідкісних випадків, коли проблему в програмному забезпеченні вирішили адміністративним шляхом. Як вам такий підхід до багфіксу? 😂
Знаєте ще цікаві приклади "креативних" виправлень багів? Діліться в коментарях!
#bugseverywhere
Продовжуємо подорож до цікавих прикладів overflow, на цей раз швейцарською залізницею.
Як виявляється, навіть швейцарські
Поїздам у Швейцарії не дозволено мати рівно 256 осей. Це може здатися абсурдним обмеженням, але справа не в суворих європейських регуляціях чи дивній бюрократії. Причина набагато цікавіша — і це справжній баг!
Швейцарська залізнична мережа використовує детектори, розташовані вздовж рейок, для відстеження місцезнаходження поїздів. Ці детектори активуються, коли колесо проходить по рейці, і рахують кількість коліс, щоб надати основну інформацію про поїзд, що щойно проїхав. На жаль, кількість коліс відстежується за допомогою 8-розрядного двійкового числа. Коли це число досягає свого максимуму — 255 (або 11111111 в двійковій системі) — воно скидається до нуля. Тобто будь-який поїзд рівно із 256 осями стає "невидимим" для системи, ніби справжній фантомний потяг.
Цікавий також спосіб вирішення цієї проблеми: регламент швейцарських залізниць містить правило, яке забороняє поїздам мати 256 осей. Це правило знаходиться десь між положеннями про навантаження на поїзди та способи, за допомогою яких провідники можуть спілкуватися з водіями. Таке враження, що запитів від людей, які хотіли б додати 256-у вісь, було настільки багато, що залізничники вирішили просто пояснити це в керівництві. Очевидно, що таке бюрократичне рішення виявилося простішим, ніж змінити код системи або ж оновити всі датчики.
Отож, це один із тих
Знаєте ще цікаві приклади "креативних" виправлень багів? Діліться в коментарях!
2200
24-10-04 11:14
🤓Ті, хто цікавиться оновленнями у світі тестування, точно помітили, що цьогоріч світ ISTQB був щедрий на оновлення.
Про одне із найпомітніших — вперше за 12 років оновлена версія силабусу до сертифікації ISTQB Advanced Test Manager — вже все знає Олександра Ковальова, ISTQB-тренерка з 8+ річним досвідом.
8 жовтня відбудеться безкоштовний вебінар Олександри “ISTQB Test Manager 3.0: управління тестуванням в умовах невизначеності”, на якому вона розповість:
👉 що покриває нова версія Advanced Test Manager 3.0 і де вона стане у нагоді, а де ні;
👉 чи став іспит легшим в новій версії;
👉 скільки в новій версії agile і до чого тут Foundation Level 4.0;
👉 як впливає модель розробки на проєкті на планування тестування, і де тут невизначеність;
👉 навіщо тестувальникам рівня Middle та Senior розуміти роботу Test Lead;
👉 чи вплинули ці зміни на тестувальників, які складали попередні версії іспиту;
👉 яка різниця в ролях Тест Лід та Тест Менеджер в компаніях, і що про це каже ISTQB.
Долучайтеся, щоб дізнатися усі важливі нюанси оновлення та поставити тренерці будь-які запитання щодо ISTQB і його практичного застосування на проєктах.
⏰ Початок о 19:00, 8 жовтня
📋 Обов'язкова реєстрація для участі у трансляції та отримання запису.
🎯 Деталі та реєстрація: https://bit.ly/3BBWOWI
Про одне із найпомітніших — вперше за 12 років оновлена версія силабусу до сертифікації ISTQB Advanced Test Manager — вже все знає Олександра Ковальова, ISTQB-тренерка з 8+ річним досвідом.
8 жовтня відбудеться безкоштовний вебінар Олександри “ISTQB Test Manager 3.0: управління тестуванням в умовах невизначеності”, на якому вона розповість:
👉 що покриває нова версія Advanced Test Manager 3.0 і де вона стане у нагоді, а де ні;
👉 чи став іспит легшим в новій версії;
👉 скільки в новій версії agile і до чого тут Foundation Level 4.0;
👉 як впливає модель розробки на проєкті на планування тестування, і де тут невизначеність;
👉 навіщо тестувальникам рівня Middle та Senior розуміти роботу Test Lead;
👉 чи вплинули ці зміни на тестувальників, які складали попередні версії іспиту;
👉 яка різниця в ролях Тест Лід та Тест Менеджер в компаніях, і що про це каже ISTQB.
Долучайтеся, щоб дізнатися усі важливі нюанси оновлення та поставити тренерці будь-які запитання щодо ISTQB і його практичного застосування на проєктах.
⏰ Початок о 19:00, 8 жовтня
📋 Обов'язкова реєстрація для участі у трансляції та отримання запису.
🎯 Деталі та реєстрація: https://bit.ly/3BBWOWI
1900
24-10-02 18:37
Привіт друзі! Цього літа я вперше за довгий час шукав собі нову роботу. До цього я дуже пишався своїм резюме:
✅ в ньому описані мої навички та багатий досвід
✅ воно було концентроване - лише 3 сторінки
✅ воно мало непоганий дизайн
Але я вирішив, що хочу мати щось набагато крутіше. Тож почав з оптимізації контенту. На щастя, зараз є десятки сервісів-аналізаторів, куди можна завантажити резюме і отримати його оцінку. Я був впевнений, що зараз ШІ тільки гляне на моє CV, пустить скупу цифрову сльозу радості і видасть мені оцінку 99/100. Але я отримав
Причина дуже проста - моє резюме не містило конкретних досягнень. Тобто, працював я в різних проєктах. Брав участь в низці успішних релізів. Але чи це моя заслуга? Може я просто поруч стояв, поки інші вкалували? Як це виміряти?
Всі аналізатори зараз дають поради та приклади на кшталт:
- "завдяки моєму менеджменту, зменшив час регресійного тестування в 3 рази"
- "мій тест дизайн допоміг досягти 90% покриття продукту тестами і збільшити якість на 27%"
- "моя стратегія тестування призвела до зменшення кількості критичних багів на 95%"
Всі приклади вимагають від власника резюме посилань на конкретні метрики - що конкретно ви зробили і як це вплинуло на продукт? Це те, що давно вже є нормою в розвинених країнах і те, чого в Україні я майже ні в кого не зустрічав. Ба більше, не всі (і навіть я) навіть рахують такі метрики, якими можна потім пишатись.
А значить, ми маємо просту та очевидну думку - настав час кожному інженеру усвідомити необхідність збирати такі метрики і почати щось робити в цьому напрямку. В своїй ролі хеда практики тестування, я починав це впроваджувати, тож маю ідеї і практичні поради, якими і хочу поділитись з вами у найближчому майбутньому. Найбільш імовірно, зможу це зробити на Magic Meetup 6 вже скоро, а трохи пізніше і розлогий пост напишу.
А поки бережіть себе
допомагайте ЗСУ
Слава Україні!
1700
24-09-30 17:19
До речі, сьогодні в мене був останній робочий день в Інфопульс. Я працював з цією компанією довгих 16 років! Почав, ще будучи студентом 3-го курсу, а йду головою практики автоматизації. Це був довгий, але цікавий шлях. Я завжди мав можливість отримувати цікавий і різноманітний досвід і познайомився з чудовими людьми! Саме завдяки Інфопульсу я став тим, ким я є.
Але я не сумую, бо попереду мене чекають нові досягнення і новий досвід, яким я обов'язково поділюсь із вами!
Гарних всім вихідних і бережіть себе!
2400
24-08-09 15:47