В тестових спільнотах тільки й розмов, що про ШІ...
Менеджери "пушать" користуватись ШІ якнайшвидше. Рекрутери та інтервʼюєри очікують знання та вміння роботи з ШІ інструментами (й не тільки в резюме).
Крім того - на ринку безліч ШІ інструментів. Чи існує один інструмент, на якому варто зупинитись?
Можна гуглити самостійно. Можна проходити курси від вендорів.
А можна ... отримати сертифікат ISTQB CT-GenAI та отримати структуровані знання.
@certifiQAte запускають курс підготовки до сертифікації ISTQB Testing with Generative AI.
😱Хто? Тренери курсу - @VolodymyrKurenkov та @KaterynaAbzyatova допоможуть вам підготуватись.
🤔Що буде? LLM, RAG, промпти, ризики та ефективне впровадження ШІ на проєкт.
🎯 Плюшки: Знижка -20% від вартості іспиту у провайдера iSQI для студентів курса, а також - бокс з друкованим сілабусом, глосарієм, трекером, вайтбордом і всім, що потрібно для підготовки.
📅 Коли: старт 9 травня, щосуботи, обідній час, тривалість 2–2.5 місяці
👉 Реєстрація за посиланням (до 15го травня)
Менеджери "пушать" користуватись ШІ якнайшвидше. Рекрутери та інтервʼюєри очікують знання та вміння роботи з ШІ інструментами (й не тільки в резюме).
Крім того - на ринку безліч ШІ інструментів. Чи існує один інструмент, на якому варто зупинитись?
Можна гуглити самостійно. Можна проходити курси від вендорів.
А можна ... отримати сертифікат ISTQB CT-GenAI та отримати структуровані знання.
@certifiQAte запускають курс підготовки до сертифікації ISTQB Testing with Generative AI.
😱Хто? Тренери курсу - @VolodymyrKurenkov та @KaterynaAbzyatova допоможуть вам підготуватись.
🤔Що буде? LLM, RAG, промпти, ризики та ефективне впровадження ШІ на проєкт.
🎯 Плюшки: Знижка -20% від вартості іспиту у провайдера iSQI для студентів курса, а також - бокс з друкованим сілабусом, глосарієм, трекером, вайтбордом і всім, що потрібно для підготовки.
📅 Коли: старт 9 травня, щосуботи, обідній час, тривалість 2–2.5 місяці
👉 Реєстрація за посиланням (до 15го травня)
🔥11❤8😁4🥴1
20 законів розробки софта
#engineering
Приніс немаленьку статтю про 20 різних правил та законів, за якими працює розробка та ІТ в цілому.
💡 Gall's Law. Складна система, що працює завжди була побудована з більше простої систем, яка працювала
💡 KISS. Keep It Simple/ Спрощуйте там де можливо.
💡 Conway's Law. Організації створюю системи, що відображають їх організаційну структуру
💡 CAP Theorem. Розподілена система може гарантувати лише дві з трьох властивостей одночасно: узгодженість, доступність чи толерантність до розділення
💡 Hyrum's Law. Маючи достатню кількість користувачів, кожна поведінка вашого API стає чиєюсь залежністю.
💡 Zawlinski Law. Кожна програма розшируюється, поки не зможе читати пошту. Ті, хто не може читати - змінюються тими, хто може.
💡 Brook's Law. Додавання людей на піздньому етапі розробки ще більше віддаляє реліз.
💡 Ringelmann Effect. Індивідуальна продуктивність падає зі збільшенням розміру команди.
💡 Ефект Даннінга - Крюгера. Чим менше ви знаєте про щось, тим впевненіше ви з цієї теми.
💡 Hofstadter's Law. Це займе більше часу, ніж ви очікуєте.
💡 Price's Law. Половина роботи виконується квадратним коренем із кількості людей.
💡 Parkinson's Law. Робота розширюється, щоб заповнити весь відведений на неї час.
💡 Goodhart's Law. Коли метрика стає ціллю, вона перестає бути хорошою метрикою.
💡 Gilb's Law. Все, що потрібні виміряти кількісно, можна виміряти іншим чином, що буде краще, ніж кількісно.
💡 Knuth's Optimization Principle. Передчасна оптимізація - корінь усього зла.
💡 Amdahl's Law. Прискорення від паралелізму обмежене частиною, що працює послідовно.
💡 Murphy's Law. Все, що може піти не так, піде не так.
💡 Postel's Law. Будьте консервативними в тому, що надсилаєте, та ліберальними в тому, що приймаєте (наприклад для API).
💡 Sturgeon's Law. 90% усього - повна фігня.
💡 Cunningham's Law. Найшвидший спосіб отримати правильну відповідь онлайн - це опублікувати неправильну.
А ви які закони знаєте?
#engineering
Приніс немаленьку статтю про 20 різних правил та законів, за якими працює розробка та ІТ в цілому.
💡 Gall's Law. Складна система, що працює завжди була побудована з більше простої систем, яка працювала
💡 KISS. Keep It Simple/ Спрощуйте там де можливо.
💡 Conway's Law. Організації створюю системи, що відображають їх організаційну структуру
💡 CAP Theorem. Розподілена система може гарантувати лише дві з трьох властивостей одночасно: узгодженість, доступність чи толерантність до розділення
💡 Hyrum's Law. Маючи достатню кількість користувачів, кожна поведінка вашого API стає чиєюсь залежністю.
💡 Zawlinski Law. Кожна програма розшируюється, поки не зможе читати пошту. Ті, хто не може читати - змінюються тими, хто може.
💡 Brook's Law. Додавання людей на піздньому етапі розробки ще більше віддаляє реліз.
💡 Ringelmann Effect. Індивідуальна продуктивність падає зі збільшенням розміру команди.
💡 Ефект Даннінга - Крюгера. Чим менше ви знаєте про щось, тим впевненіше ви з цієї теми.
💡 Hofstadter's Law. Це займе більше часу, ніж ви очікуєте.
💡 Price's Law. Половина роботи виконується квадратним коренем із кількості людей.
💡 Parkinson's Law. Робота розширюється, щоб заповнити весь відведений на неї час.
💡 Goodhart's Law. Коли метрика стає ціллю, вона перестає бути хорошою метрикою.
💡 Gilb's Law. Все, що потрібні виміряти кількісно, можна виміряти іншим чином, що буде краще, ніж кількісно.
💡 Knuth's Optimization Principle. Передчасна оптимізація - корінь усього зла.
💡 Amdahl's Law. Прискорення від паралелізму обмежене частиною, що працює послідовно.
💡 Murphy's Law. Все, що може піти не так, піде не так.
💡 Postel's Law. Будьте консервативними в тому, що надсилаєте, та ліберальними в тому, що приймаєте (наприклад для API).
💡 Sturgeon's Law. 90% усього - повна фігня.
💡 Cunningham's Law. Найшвидший спосіб отримати правильну відповідь онлайн - це опублікувати неправильну.
А ви які закони знаєте?
Techworld-With-Milan
The 20 Software Engineering Laws
A field guide to why software projects fail, systems rot, and teams slow down.
👍19🔥6❤2🥱1
📚Огляд на книгу "Contract Testing in Action: With Pact, PactFlow and GitHub Actions"
#books
Починаю публікувати свої огляди на книжки з тестування, автоматизації та інженерії загалом.
Сьогодні - свіжа книжка про контрактне тестування з Pact, яку написали Marie Cruz та Lewis Prescott.
#books
Починаю публікувати свої огляди на книжки з тестування, автоматизації та інженерії загалом.
Сьогодні - свіжа книжка про контрактне тестування з Pact, яку написали Marie Cruz та Lewis Prescott.
Test Engineering Notes
Book Review: Contract Testing in Action — Test Engineering Notes
Review of "Contract Testing in Action: With Pact, PactFlow, and GitHub Actions" book written by Marie Cruz and Lewis Prescott
1🔥20
Forwarded from DOU
На війні загинув QA-спеціаліст, переможець Премії DOU Геннадій Міщевський
https://dou.ua/goto/qViK
Геннадій багато років працював у QA, писав про тестування й автоматизацію, був одним із переможців першої Премії DOU. Після початку повномасштабного вторгнення долучився до проєкту SocialDroneUA, а потім — до лав Сил оборони. Редакція DOU висловлює співчуття рідним і близьким Геннадія.
https://dou.ua/goto/qViK
Геннадій багато років працював у QA, писав про тестування й автоматизацію, був одним із переможців першої Премії DOU. Після початку повномасштабного вторгнення долучився до проєкту SocialDroneUA, а потім — до лав Сил оборони. Редакція DOU висловлює співчуття рідним і близьким Геннадія.
💔97😭32🫡6😢2
Усі пишуть про ШІ, усі пишуть з ШІ
#testing
На картинці можна побачити про що писали раніше й зараз.
З одного боку - ШІ з сьогодення, його вимагають на роботі та у вакансіях.
Але з іншого - таке відчуття, що в інженерії та тестуванні вже закінчилися теми, крім "Як я нагенерував тест кейсів за допомогою ШІ".
ШІ дав нам можливість виправляти орфографічні помилки Але дехто йде далі, та генерує пости повністю за домогою LLM-ок. В результаті ці статті відчуваються та читаються, наче однаковий ШІ слоп.
• "Зараз я розповім тобі про ... без води, тільки практика."
• "І проблема не тільки в ... Проблема в. ... Зараз поясню..."
Так, статті та дописи можна генерувати за секунди. Як результат - Linkedin та інші блогоплатформи завалені однаковими дописами.
Але, ці дописи можна було б і не писати. Можна просто задати цей промпт LLM-ці, отримати собі відповідь та йти далі.
Що більш цінне - це ваш особистий досвід роботи із чимось. Чи вивчення чогось.
Ваші особисті інсайти написані своїми словами.
#testing
На картинці можна побачити про що писали раніше й зараз.
З одного боку - ШІ з сьогодення, його вимагають на роботі та у вакансіях.
Але з іншого - таке відчуття, що в інженерії та тестуванні вже закінчилися теми, крім "Як я нагенерував тест кейсів за допомогою ШІ".
ШІ дав нам можливість виправляти орфографічні помилки Але дехто йде далі, та генерує пости повністю за домогою LLM-ок. В результаті ці статті відчуваються та читаються, наче однаковий ШІ слоп.
• "Зараз я розповім тобі про ... без води, тільки практика."
• "І проблема не тільки в ... Проблема в. ... Зараз поясню..."
Так, статті та дописи можна генерувати за секунди. Як результат - Linkedin та інші блогоплатформи завалені однаковими дописами.
Але, ці дописи можна було б і не писати. Можна просто задати цей промпт LLM-ці, отримати собі відповідь та йти далі.
Що більш цінне - це ваш особистий досвід роботи із чимось. Чи вивчення чогось.
Ваші особисті інсайти написані своїми словами.
🔥33💯14❤2👍1😁1
📚 Огляд на книгу: "Testing Web APIs"
#books
Чи знаєте ви як тестувати API? На перший погляд це дуже просто: відкрий Postman, створи колекцію та запускай!
Але як підходити до тестування API більш продумано? Чи варто планувати стратегію тестування?
Чи можна перевіряти API ще до того, як його написали? Чи потрібно додавати автоматизацію? А як щодо перфомансу чи безпеки?
Все це можна знайти у книзі "Testing Web APIs" від Mark Winteringham.
#books
Чи знаєте ви як тестувати API? На перший погляд це дуже просто: відкрий Postman, створи колекцію та запускай!
Але як підходити до тестування API більш продумано? Чи варто планувати стратегію тестування?
Чи можна перевіряти API ще до того, як його написали? Чи потрібно додавати автоматизацію? А як щодо перфомансу чи безпеки?
Все це можна знайти у книзі "Testing Web APIs" від Mark Winteringham.
Test Engineering Notes
Book Review: Testing Web APIs — Test Engineering Notes
Review of "Testing Web APIs " by Mark Winteringham
2❤25👍6
Forwarded from ISTQB Certified Unicorns
❤️🩹 Прощання з Геннадієм Міщевським відбудеться у середу, 20 травня у Києві. Для родини дуже важливо щоб ті, хто знав його особисто, провели його в останню путь. Тож якщо ви зможете прийти, будемо дуже вдячні.
12:00 — відспівування у Михайлівському Золотоверхому монастирі.
12:50-13:00 – піша хода з Михайлівського Золотоверхого монастиря до Майдану Незалежності
13:50-14:00 – виїзд з Майдану Незалежності до кладовища, с. Крюківщина, вул. Каштанова 1. Орієнтовно поховання відбудеться 14.40-15.00
Після поховання відбудеться поминальний обід — якщо ви знали Гену особисто, його родина була б рада, щоб ви долучилися і поділилися спогадами про Героя. Будь ласка, напишіть Олександрі Ковальовій (@molly4air) в особисті, якщо плануєте залишитися на прощальний обід у кафе.
12:00 — відспівування у Михайлівському Золотоверхому монастирі.
12:50-13:00 – піша хода з Михайлівського Золотоверхого монастиря до Майдану Незалежності
13:50-14:00 – виїзд з Майдану Незалежності до кладовища, с. Крюківщина, вул. Каштанова 1. Орієнтовно поховання відбудеться 14.40-15.00
Після поховання відбудеться поминальний обід — якщо ви знали Гену особисто, його родина була б рада, щоб ви долучилися і поділилися спогадами про Героя. Будь ласка, напишіть Олександрі Ковальовій (@molly4air) в особисті, якщо плануєте залишитися на прощальний обід у кафе.
💔27
🛠 Your K6 Tests Are Lying to You (And It’s Not K6’s Fault)
#testing #performance
Невеличка стаття про те, що недостатньо просто користуватись інструментом для навантаження. Треба ще й ... продумувати реалістичні сценарії.
😱 Реалістичні сценарії не просто ганяють ваш скрипт із реквестами в нескінченному циклі в багато потоків.
Щоб покращити такі тести треба додавати таку штуку, як think time.
🤯 Think time - це додавання затримок між діями користувача. Реальні юзери не клацають на кнопки як навіжені із максимально можливою швидкістю. Юзери думають, приймають рішення, неспішно заповнюють форми, роблять помилки та виправляють.
😏 Як зрозуміти, яку затримку додавати? Дослідити те, як користувачі взаємодіють із вашою системою на продакшені. (Якщо ще немає трейсингу - варто його додати).
🤔 Звичайно, часом на затримку в деяких випадках можна знехтувати. Наприклад, коли ви тестуєте систему, де користувач - інша підсистема, яка може запускати купу запитів із самого старту.
#testing #performance
Невеличка стаття про те, що недостатньо просто користуватись інструментом для навантаження. Треба ще й ... продумувати реалістичні сценарії.
😱 Реалістичні сценарії не просто ганяють ваш скрипт із реквестами в нескінченному циклі в багато потоків.
Щоб покращити такі тести треба додавати таку штуку, як think time.
🤯 Think time - це додавання затримок між діями користувача. Реальні юзери не клацають на кнопки як навіжені із максимально можливою швидкістю. Юзери думають, приймають рішення, неспішно заповнюють форми, роблять помилки та виправляють.
😏 Як зрозуміти, яку затримку додавати? Дослідити те, як користувачі взаємодіють із вашою системою на продакшені. (Якщо ще немає трейсингу - варто його додати).
🤔 Звичайно, часом на затримку в деяких випадках можна знехтувати. Наприклад, коли ви тестуєте систему, де користувач - інша підсистема, яка може запускати купу запитів із самого старту.
Medium
Your K6 Tests Are Lying to You (And It’s Not K6’s Fault)
A little over 3 years ago, I decided to give K6 a try. It was different from the load testing tools I’d used before. It’s lightweight…
🔥14❤1👍1
Огляд на книгу: Software Testing Strategies
#books #testing
🙄 Коли деякий час працюєш в тестуванні, може виникнути спокуса сказати: «Я все знаю» або «Книга про стратегії тестування не може дати мені нічого нового».
👏 Але я знайшов книгу, яка сповнена практичних прикладів технік і підходів, які ви можете використовувати як тестувальник в сучасному світі.
✍ Ця книга називається «Software Testing Strategies: A Testing Guide for the 2020s» Метта Хойссера та Майкла Ларсена. Вона охоплює багато тем: від методів розробки тестів до підходів до автоматизації, від тест планів до філософії й етики тестування.
👉 Мої 5 інсайтів з книги - у блозі.
#books #testing
🙄 Коли деякий час працюєш в тестуванні, може виникнути спокуса сказати: «Я все знаю» або «Книга про стратегії тестування не може дати мені нічого нового».
👏 Але я знайшов книгу, яка сповнена практичних прикладів технік і підходів, які ви можете використовувати як тестувальник в сучасному світі.
✍ Ця книга називається «Software Testing Strategies: A Testing Guide for the 2020s» Метта Хойссера та Майкла Ларсена. Вона охоплює багато тем: від методів розробки тестів до підходів до автоматизації, від тест планів до філософії й етики тестування.
👉 Мої 5 інсайтів з книги - у блозі.
Test Engineering Notes
Book Review: Software Testing Strategies — Test Engineering Notes
My insights from "Software Testing Strategies: A Testing Guide for the 2020s" book by Matthew Heusser and Michael Larsen
1❤31🔥7
💰 The Hidden Cost of AI Coding That's Destroying Engineering Teams
#ai #engineering
Знайшов непогане відео про реальність бездумного використання ШІ де тільки можна.
🤔 Найважливіші інсайти:
💡Ми можемо зрозуміти коли створюємо технічний борг. Знаємо як із ним боротись. Але ШІ додає борг розуміння - різницю між тим, скільки коду у програмі та тим, скільки з цього коду розробник реально розуміє. З ШІ борг розуміння зростає непомітно. (Одна команда 3 місяці вайбкодила, а потім витратила ще 6 місяців, щоб розібратись в тому, як це згенероване працює)
💡Парадокс продуктивності. Джуніори з ШІ швидше генерують новий код. Сіньйори зменшують продуктивність на 19% через те, що їм доводиться ревьювати набагато більше коду. Сіньйори стають такими собі "збирачами сміття" замість того, щоб розвʼязувати важливіші проблеми.
💡Джуніори з ШІ не створюють ментальних моделей. Вони їх "позичають" у ШІ. Без цих моделей в голові, таким інженерам тяжко швидко реагувати на продакшн інциденти.
💡Код - не головний артефкт роботи. Головний артефакт роботи - це грамотно сформулювана специфікація. На її основі ШІ зможе щось створити.
💡Зараз створюється ринок праці де вартість експертизи у верифікації зростає. А вартість написання коду - знижується.
#ai #engineering
Знайшов непогане відео про реальність бездумного використання ШІ де тільки можна.
🤔 Найважливіші інсайти:
💡Ми можемо зрозуміти коли створюємо технічний борг. Знаємо як із ним боротись. Але ШІ додає борг розуміння - різницю між тим, скільки коду у програмі та тим, скільки з цього коду розробник реально розуміє. З ШІ борг розуміння зростає непомітно. (Одна команда 3 місяці вайбкодила, а потім витратила ще 6 місяців, щоб розібратись в тому, як це згенероване працює)
💡Парадокс продуктивності. Джуніори з ШІ швидше генерують новий код. Сіньйори зменшують продуктивність на 19% через те, що їм доводиться ревьювати набагато більше коду. Сіньйори стають такими собі "збирачами сміття" замість того, щоб розвʼязувати важливіші проблеми.
💡Джуніори з ШІ не створюють ментальних моделей. Вони їх "позичають" у ШІ. Без цих моделей в голові, таким інженерам тяжко швидко реагувати на продакшн інциденти.
💡Код - не головний артефкт роботи. Головний артефакт роботи - це грамотно сформулювана специфікація. На її основі ШІ зможе щось створити.
💡Зараз створюється ринок праці де вартість експертизи у верифікації зростає. А вартість написання коду - знижується.
YouTube
The Hidden Cost of AI Coding That's Destroying Engineering Teams
AI is making your team ship faster. It's also filling your codebase with code nobody understands, security flaws nobody caught, and architecture debt that will cost you six months to untangle.
This video breaks down exactly what's happening inside AI-assisted…
This video breaks down exactly what's happening inside AI-assisted…
👍19❤7
Огляд книги: "Mastering Blockchain"
#books #blockchain #engineering
🙄 На полицях сотні книжок про блокчейн. Десятки з них технічні. Але з якої почати? Треба вчити одразу Bitcoin, Ethereum, Solana, Midnight, чи щось інше?
🕶️ Моя порада для будь-якого інженера, що стартує (чи думає працювати) в блокчейні - це розібратись з фундаментальними знаннями.
📚 Я можу порекомендувати 1 (одну!) книгу, яка покриває майже усі базові знання в блокчейні на досить хорошому технічному рівні. Тут і про хешування, і про консенсуси, і про Біток з Ефіром (а саме про їх архітектуру!), і про смарт контракти.
👉 Ця книга - це "Mastering Blockchain" за авторством Imran Bashir.
✍ Інсайти, плюси й мінуси книжки - у пості.
#books #blockchain #engineering
🙄 На полицях сотні книжок про блокчейн. Десятки з них технічні. Але з якої почати? Треба вчити одразу Bitcoin, Ethereum, Solana, Midnight, чи щось інше?
🕶️ Моя порада для будь-якого інженера, що стартує (чи думає працювати) в блокчейні - це розібратись з фундаментальними знаннями.
📚 Я можу порекомендувати 1 (одну!) книгу, яка покриває майже усі базові знання в блокчейні на досить хорошому технічному рівні. Тут і про хешування, і про консенсуси, і про Біток з Ефіром (а саме про їх архітектуру!), і про смарт контракти.
👉 Ця книга - це "Mastering Blockchain" за авторством Imran Bashir.
✍ Інсайти, плюси й мінуси книжки - у пості.
Test Engineering Notes
Book Review: Mastering Blockchain — Test Engineering Notes
My insights from "Mastering Blockchain: Inner workings of blockchain, from cryptography and decentralized identities, to DeFi, NFTs and Web3, 4th Edition" book by Imran Bashir
1👍19❤4
Огляд книги: "Full Stack Testing"
#books #testing
Приніс хорошу книжку по сучасне тестування.
Дуже багато корисних діаграм, схем процесів (коли які тести запускати).
Книжка звичайно не без недоліків - "своя" термінологія, майже немає ШІ (але обіцяють, що буде в другій редакції цього липня).
Але загалом - непоганий огляд на сучасні підходи до різних видів тестування (+ тулзи). Тільки не треба очікувати аж надто великої "глибини".
#books #testing
Приніс хорошу книжку по сучасне тестування.
Дуже багато корисних діаграм, схем процесів (коли які тести запускати).
Книжка звичайно не без недоліків - "своя" термінологія, майже немає ШІ (але обіцяють, що буде в другій редакції цього липня).
Але загалом - непоганий огляд на сучасні підходи до різних видів тестування (+ тулзи). Тільки не треба очікувати аж надто великої "глибини".
Test Engineering Notes
Book Review: Full Stack Testing — Test Engineering Notes
My insights from "Full Stack Testing: A Practical Guide for Delivering High Quality Software" by Gayathri Mohan
1👍20❤2
Консультації, менторинг та підготовка до співбесід
#services
В ІТ я вже понад 14 років. Автоматизував різні проєкти - від вебу до мобільних застосунків, від ігор до блокчейну.
Зараз мій стек - Python / Rust. Також мав справу з Java, Scala та C#.
Крім того, час від часу я залучений як технічний інтервʼюер у різних компаніях.
Давайте розповім, із чим саме я можу вам допомогти.
Підготовка до співбесіди
Коли це може бути потрібно:
* ви не впевнені, які теми вчити перед співбесідою
* маєте страх технічних запитань чи live-coding задач
* вам складно презентувати свій досвід
* ви думаєте, що нічого не знаєте - спойлер: це зовсім не так!
* у вас були невдалі співбесіди, але незрозуміло, чому ви отримали відмову
З чим я можу допомогти: проведемо розбір вашого резюме, потренуємося на мок-інтервʼю, розберемо типові запитання для різних компаній.
Індивідуальний план розвитку карʼєри
Коли це може бути потрібно:
* незрозуміло, який у вас зараз рівень і що потрібно знати на позиціях Middle / Senior / Lead
* хочеться вивчити багато тем, але немає часу та системи
* складно пріоритезувати теми для навчання й тримати фокус
* незрозуміло, як практикувати отримані навички
З чим я можу допомогти: зробимо аналіз ваших поточних навичок, а також пробілів у знаннях і вміннях; створимо індивідуальний план розвитку вас як спеціаліста під вашу конкретну ціль, як-от отримати нову цікавішу роботу або підвищення всередині компанії.
Подальший шлях ви обираєте самі: самостійний розвиток або індивідуальний менторинг зі мною.
Консультації з автоматизації тестування та інших аспектів тестування
Коли це може бути потрібно:
* немає розуміння, з чого почати автоматизацію на проєкті
* тести є, але вони нестабільні, на них ніхто не дивиться й вони нікому не потрібні
* складно обрати інструменти та стек для автоматизації
* користі від автоматизації мало, але часу вона займає дуже багато
* не знаєте, як краще організувати процес тестування на складних проєктах із багатьма підсистемами
З чим я можу допомогти: зробимо аналіз системи, команди та інструментів; продумаємо найкращу стратегію автоматизації, яка працюватиме саме у вашому контексті.
Якщо маєте питання або хочете домовитися про дзвінок — пишіть у директ чи @al8xr. Завжди радий допомогти.
#services
В ІТ я вже понад 14 років. Автоматизував різні проєкти - від вебу до мобільних застосунків, від ігор до блокчейну.
Зараз мій стек - Python / Rust. Також мав справу з Java, Scala та C#.
Крім того, час від часу я залучений як технічний інтервʼюер у різних компаніях.
Давайте розповім, із чим саме я можу вам допомогти.
Підготовка до співбесіди
Коли це може бути потрібно:
* ви не впевнені, які теми вчити перед співбесідою
* маєте страх технічних запитань чи live-coding задач
* вам складно презентувати свій досвід
* ви думаєте, що нічого не знаєте - спойлер: це зовсім не так!
* у вас були невдалі співбесіди, але незрозуміло, чому ви отримали відмову
З чим я можу допомогти: проведемо розбір вашого резюме, потренуємося на мок-інтервʼю, розберемо типові запитання для різних компаній.
Індивідуальний план розвитку карʼєри
Коли це може бути потрібно:
* незрозуміло, який у вас зараз рівень і що потрібно знати на позиціях Middle / Senior / Lead
* хочеться вивчити багато тем, але немає часу та системи
* складно пріоритезувати теми для навчання й тримати фокус
* незрозуміло, як практикувати отримані навички
З чим я можу допомогти: зробимо аналіз ваших поточних навичок, а також пробілів у знаннях і вміннях; створимо індивідуальний план розвитку вас як спеціаліста під вашу конкретну ціль, як-от отримати нову цікавішу роботу або підвищення всередині компанії.
Подальший шлях ви обираєте самі: самостійний розвиток або індивідуальний менторинг зі мною.
Консультації з автоматизації тестування та інших аспектів тестування
Коли це може бути потрібно:
* немає розуміння, з чого почати автоматизацію на проєкті
* тести є, але вони нестабільні, на них ніхто не дивиться й вони нікому не потрібні
* складно обрати інструменти та стек для автоматизації
* користі від автоматизації мало, але часу вона займає дуже багато
* не знаєте, як краще організувати процес тестування на складних проєктах із багатьма підсистемами
З чим я можу допомогти: зробимо аналіз системи, команди та інструментів; продумаємо найкращу стратегію автоматизації, яка працюватиме саме у вашому контексті.
Якщо маєте питання або хочете домовитися про дзвінок — пишіть у директ чи @al8xr. Завжди радий допомогти.
1🔥25❤8👍1