Test Engineering Notes
Україномовний канал про технічні аспекти тестування, розподілені системи, блокчейн та кібербезпеку.
Больше3 189
Подписчики
Нет данных24 часа
+27 дней
-430 дней
- Подписчики
- Просмотры постов
- ER - коэффициент вовлеченности
Загрузка данных...
Прирост подписчиков
Загрузка данных...
Software Testing as a Social Science (Caner) - частина 1
#testing
В одній з книжок я знайшов посилання на презентацію Кема Канера з тестування (2006 року). Було дуже цікаво прочитати слайди. Наче й все зрозуміло, але подача інформації зовсім інша - відрізняється від сучасних книжок та стандартів. Наведу декілька нотаток зі слайдів.
Про соціальні науки
Тестування більше схоже мікс психології, економіки, бізнес менеджменту - ніж на програмування.
Канер також зазначає, що тестування дуже схоже з соціальними науками. Бо вони:
- вивчають яким буде вплив Х на людей
- працюють з кількісними та якісними методами досліджень
- мають високу терпимість до неоднозначності, часткових та ситуативно коректних відповідей
- беруть до уваги етику та цінності
- приймають як норму упередженість спостерігача
Про програми
Програма - це набір інструкцій для компʼютера. Але для чого програма призначена? Адже можна сказати, що дім - це набір матеріалів, зібраний відповідно до паттернів проєктування будинків. Але дім будують для чогось - для людей, які будуть в ньому жити.
Програма - це спілкування між декількома людьми та компʼютерами, що розподілені в просторі та часі, що містить інструкції, які можуть бути виконані компʼютером. Мета програми - надати користь зацікавленим сторонам.
Про тестування та помилки
"Quality is value to some person" (c) Jerry WeinbergДля того, щоб тестувати щось, ви повинні розуміти хто є зацікавленими сторонами та як на них впливає продукт чи система. "Традиційний" погляд визначає тестування лише як функціональне - що фокусується на перевірці програми на відповідність специфікації. Цей концепт легко зрозуміти, легко навчити. Але - за таке тестування мало платять. "Традиційне тестування" - фокусується на пошуку помилок. Але помилка може бути НЕ в коді та може бути НЕ функціональною. Такі підходи працювали при розробці десь в 80-х.
"A bug is something that bugs somebody" (c) James BachПомилка в софті - це атрибут програмного продукту, що зменшує його цінність для зацікавленої сторони. Тестування програмного забезпечення - це технічне розслідування, що проводиться для надання зацікавленій стороні повʼязаної з якістю інформації про продукт. Це наче в серіалі CSI: є багато інструментів, процедур, джерел доказів. Слідчий повинен обрати, які докази вивчати, щоб віднайти якнайбільше корисної інформації за найкоротший проміжок часу. Цілі збору інформації (тестування) можуть бути різними: знайти баги, оцінити якість продукту, допомогти менеджеру прийняти рішення про реліз, перевірити взаємодію з іншими продуктами, оцінити відповідність вимогам чи стандартам. Продовження - у наступному дописі.
👍 20❤ 5🔥 1
Repost from N/a
Фото недоступноПоказать в Telegram
⚡️ Епізод 31: Де тестувальник думає, чи можна працювати без нього / неї
Всім привіт! Ми повертаємось з новим, четвертим сезоном!
Чи можна випускати софт без тестування? Чи виживуть команди та продукти, якщо в них не буде тестувальників? Як боротися зі страхом стати непотрібним - коли всі настільки класно тестують без вас? Ці питання Артем та Олександр будуть обговорювати в черговому випуску подкасту.
Для тих, хто полюбляє слухати:
🔸 Youtube
🔹 Spotify Podcast
🔸 Apple Podcast
А ще ви можете підтримати наш подкаст будь - яким донатом на Buy Me a Coffee ☕️
Окрім того, за різні підписки ви зможете отримати доступ до закритого чату подкасту, отримувати нові епізоди до самого виходу, а також є можливість присутності під час запису 😏
#testingminutes | @a_grygorenko | Test Engineering Notes
🔥 14❤ 3👍 1
Joining Strings in Python: A "Huh" Moment
#coding #python
Невелика стаття про те, що краще використовувати для зʼєднання великої кількості строк в Python - генератори чи list comprehensions? Що швидше?
Joining Strings in Python: A "Huh" Moment
I just love it when random conversations on Mastodon result in a “Huh, I didn’t know that”-moment. The other day I had one such moment about the Python programming language. I’ve been writing Python code for the last 17 years, and quite a lot of it the last 7 years since it is now more or less my full time job. While I still learn things all the time about the language, I’ve started to get more curious about its quirks and surprises.
❤ 5👍 2
Repost from Нотатки суворого QA 💛💙
🎉 Інтенсив - "Естімація задач по тестуванню"
Друзі, запрошую вас приєднатися до мого нового інтенсиву, де ми разом опануємо мистецтво оцінювання задач у тестуванні!
📅 Коли?
29 Липня та 5 Серпня о 19:00 (2 заняття по 1.5-2 години)
💡 Про що?
Знання, як точно оцінити час, зусилля, ресурси та бюджет для тестування продукту, є одним із ключових для успіху будь-якого проекту. Це не тільки допоможе вам виграти битву з дедлайнами, але й стане вашою перевагою у світі QA.
🚀 Що ви отримаєте?
- навчимося використовувати різні підходи до оцінювання задач у різних проектах
- розберемо основні терміни та чому оцінювання важливе
- покращимо навички оцінювання задач
- систематизуємо знання щодо оцінювання в різних компаніях і проектах
Під час інтенсиву ви зможете визначати ключові параметри оцінювання та створювати детальні плани задач, що стане основою для подальшого тестування. Також дізнаємося, на чому тестувальник повинен зосередити свою увагу в роботі і як пріоритезувати задачі.
⚠️ Місця обмежено!
Забирайте своє 😉
🔗 Реєстрація тут
До зустрічі на інтенсиві!
❤ 7🔥 2
TDD CANNOT Work
#testing #coding
Знайшов тут пояснення чому розпіарене TDD (test-driven development) зазвичай не працює в реальному житті.
Я поки не зустрічав ще розробників, які б успішно практикували такий підхід. А ви?
💯 14
Test Engineering Notes — Vol. 15. Про flaky-тести в Uber, “хаос” в serverless та інтернет в Антарктиці
#testing #engineering #digest
Підбірка статей за червень вже готова.
TLDR, або Що у випуску
- як Uber бореться з flaky-тестами та як в Zalando тестують на мобілках;
- наскільки успішно великі компанії застосовують ШІ в роботі інженерів;
- новий інструмент для тестування мобільних девайсів від Google;
- як зробити chaos engineering для ваших serverless-систем;
- зрозуміле пояснення контрактних тестів;
- як працюють токени, cookie та черги в сучасних системах;
- багато іншого...
Test Engineering Notes — Vol. 15. Про flaky-тести в Uber, “хаос” в serverless та інтернет в Антарктиці
Наскільки успішно великі компанії застосовують ШІ в роботі інженерів, новий інструмент для тестування мобільних девайсів від Google, зрозуміле пояснення контрактних тестів та багато інших цікавих знахідок чекають на вас у цьому дайджесті від Олександра Ро
👍 12❤ 2
📖 Про читабельність коду (автотестів)
#engineering #coding
Юніт тести можуть чітко показати чи правильно працює ваш код. А юніт тестів на читабельність поки що не вигадали.
Тому дуже важливо (особливо для мідлів та сіньйорів) - писати код максимально зрозуміло для себе й інших.
Під кодом я маю на увазі код ваших автотестів та солюшенів.
🌀Про "спіраль незрозумілого коду"
Якщо читабельність коду погана - можна потрапити в "спіраль незрозумілого коду". Що це таке? Розберемося на прикладі.
Уявімо, що інженеру - автоматизатору, треба зробити правки в коді тесту, пейджі чи утилітного методу. Читабельність коду дуже низька. Він чи вона витрачає купу часу щоб хоча б трохи зрозуміти, що той код робить.
Але код до кінця зрозуміти не вдалося. Замість покращення читабельності, цей автоматизатор робить мінімально можливі правки, щоб пофіксити тест. Такі правки призводять до ще менш читабельного коду. Наступна людина, що буде дивитись на "підправлений код" витратить ще більше часу на те, щоб розібратись в ньому. А може - здасться, видалить той незрозумілий шматок та перепише усе заново.
💊Що ж робити?
Як протестувати ваш код на читабельність? Викласти його на код ревʼю!
Якщо інша людина зрозуміє його - це вже дуже класно! Якщо його зрозуміє людина з іншої команди - ще краще!
Як зробити код більш читабельним?
- називайте змінні та методи максимально зрозуміло
- структуруйте код відповідно від його функцій
- дотримуйтесь принципів KISS / DRY там, де це доречно
- пишіть коментарі, якщо це потрібно (коментуйте "чому", а не "як")
- постійно покращуйте читабельність коду над яким ви працюєте.
❤ 13👍 5
Про сертифікацію автоматизаторів
#testing #automation
Тут нещодавно Джеймс Бах (той, який разом з Майклом Болтоном робить "Rapid Software Testing") розкритикував вирізки з матеріалів ISTQB для автоматизаторів. "Воно не про тестування, не про стратегію, та все інше" - говорить Бах. Та він ... правий.
Я сертифікат такий не отримував, але я читав рекомендовану книжку - "Test Automation Fundamentals".
Книжка мені сподобалася. В ній я побачив перші спроби подачі знань з автоматизації на більш абстрактному рівні. Тобто так, що підійде будь-якому інженеру майже в будь-якому проєкті.
Але питання залишається - що взагалі в тому сілабусі з автоматизації? Чи варто взагалі отримувати той сертифікат?
Та найголовніше - які зміни трапились з цим сертифікатом після останніх нещодавних оновлень.
Відповідь на це питання можна отримати - й доволі швидко. Для цього треба зареєструватись на безкоштовний вебінар.
Хто? Олександра Ковальова та Артур Шевченко.
Коли? 3 липня о 19:00
Приходьте. Впевнений, що буде цікаво.
Вебінар "Зміни в ISTQB Test Automation" | Certified Unicorns
Безкоштовний вебінар для тестувальників про зміни в сертифікації ISTQB Automation в 2024 році. Спікери: Олександра Ковальова та Артур Шевченко
👍 18❤🔥 2❤ 2
Engineering for Slow Internet
#engineering
Сьогодні хочу поділитись цікавою історією про те, як воно працювати у Антарктиці та намагатися користуватись Інтернетом із слабким супутниковим звʼязком.
Пінгвінів тут не буде, але будуть деякі питання до розробників: чому навіть простий сайт тягне за собою десятки мегабайт того джаваскріпту?
Engineering for Slow Internet – brr
How to minimize user frustration in Antarctica.
❤ 11🔥 1
Про пошук роботи
#interview
Для багатьох людей пошук роботи = пошук вакансії на DOU/Djinni/Linkedin та подання на неї.
Але чим вище у вас позиція та років досвіду, тим менше ефективності від такого пошуку.
Що ще можна зробити, щоб підвищити свої шанси знайти роботу?
Прокачайте свій Linkedin профіль (допоможіть рекрутерам знайти Вас)
- Встановіть чіткий headline: в чому ви кращі, в чому ви спеціалізуєтесь?
- Додайте опис кожної роботи та що конкретно ви там робили (можна написати навіть більше, ніж у вашому CV)
- Застосовуйте ключові слова в секції summary
- Приберіть нерелевантний досвід роботи
Шукайте на Linkedin
- продивіться вашу мережу контактів. Можливо хтось може зробити Вам рекомендацію. Або просто відповісти на питання про те, як працювати в тій чи іншій компанії
- пошукайте цікаві продукти та компанії. Дізнайтесь яких спеціалістів вони шукають (або шукали нещодавно).
- проаналізуйте вимоги вакансій - це допоможе зрозуміти ваші пробіли в знаннях та можливі варіанти росту
- напишіть пост пошуку роботи в Linkedin (це краще працює, коли у вас вже є досвід роботи)
А щоб оцінити свій рівень поточної ЗП - можна прийняти участь в літньому опитуванні від DOU.
Портрет і зарплатне опитування DOU, літо 2024
Не зраджуємо традиції і продовжуємо щопівроку збирати анонімні дані про зарплати українських IT-спеціалістів. Як завжди влітку, до зарплат додаємо ще опитування «Портрет ІТ-спеціаліста». Якщо ви зараз знаходитеся в Україні або переїхали за кордон через війну і плануєте повернутися, будь ласка, приділіть нам 10 хвилин і візьміть участь в опитуванні. Якщо ви зараз не працюєте, заповнюйте анкету з огляду на ваше останнє місце роботи. Результати опублікуємо в липні 2024 року. Підсумки попередніх опитувань можна подивитися тут: зарплатний віджет —
https://dou.ua/goto/M5JFі звіти —
https://dou.ua/goto/B2JN.Усі запитання, пропозиції та побажання щодо опитування надсилайте поштою на [email protected].
❤ 17👍 3
Выберите другой тариф
Ваш текущий тарифный план позволяет посмотреть аналитику только 5 каналов. Чтобы получить больше, выберите другой план.