Test Lead в Infopulse
  • Знайомтесь, TestOps!

    А ІБ відповідає — це не секюрно, шукайте інший спосіб. Як би все було так просто...

  • Знайомтесь, TestOps!

    воу, стоп! юніт тести — найновіша технологія, якою не вміють користуватися? Чи я вас не правильно зрозумів?
    моя позиція проста — всі учасники проекту мають спільну мету, якщо хтось бачить фігню — він має сказати, що то фігня і так робити не треба, а треба робити правильно. В скрамі для того навіть ритуал спеціальний є — ретроспектива називається

  • Знайомтесь, TestOps!

    ахах! так і я про що — щоб все було в проекті добре в ж щось робите? якщо вам скажуть каву носити замість розробки і тестування, ви скажете ок чи поцікавитесь, чому такий цінний ресурс (без іронії) використовують настільки неоптимально?

    і повертаючись до попереднього питання — писати юніт тести — хороша практика, а вимагати писати юніт тести — прямий шлях до звільнення і взагалі фу. Чому?

  • Знайомтесь, TestOps!

    В стародавні часи термін розробка включав в себе аналіз, дизайн, розробку, тестування, розгортання та підтримку (а ще може принтер заправити і ноут куму вибрати). Нащо в такому випадку взагалі слова тестер, девопс, адмін коли є #тижпрограміст? :)

    Світ стає складніший, підходи до роботи теж. Чому б не давати назву новому?

  • Знайомтесь, TestOps!

    Вас же наймають як експерта не для того, щоб ви тримали думки при собі?

  • Знайомтесь, TestOps!

    farewell letter за пропозиції використовувати хороші практики? Ви драматизуєте!
    Пропозиції можуть бути проігноровані і так часто буває, але з вас це не знімає відповідальності — всі ризики і наслідки мають бути оцінені і озвучені, оскільки наша мета — якісний продукт, хороший процес роботи.

  • Знайомтесь, TestOps!

    ... а senior dev в devops ;)
    люди ті ж самі, робота та ж сама — нові підходи, нові технології

  • Знайомтесь, TestOps!

    я б сказав, від хороший тестер/тест менеджер має знати, для чого потрібні unit-тести та вимагати їх від команди розробки.
    Можна навіть закріпити формально в тест плані як entry test criteria — тестуються лише білди, які мають покриття не менше N та успішно пройшли unit тести

    Поддержал: Саша Цыбин
  • QA дайджест #41: как подсидеть тимлида, бесплатный Cypress Dashboard, Playwright — серьезный конкурент Puppeteer

    дякую за дайджест! сам би точно пропустив кілька гарних статей

    Поддержал: Максим Сальников
  • Як тестувальнику розпочати роботу на проекті з нуля

    Гарна стаття — маю багато заміток і давно хотів структурувати у щось подібне. дякую!

  • Складнощі тестування мікросервісів та що з ними робити

    не в бров, а в око

  • Складнощі тестування мікросервісів та що з ними робити

    Теперь приходят QA и заявляют, что им неудобно тестировать микросервисы :)

    коли штучний інтелект замінить QA, я також зроблю невдоволене обличчя і скажу, що мені це не подобається :)

  • Складнощі тестування мікросервісів та що з ними робити

    хайп вокруг микросервисов пошел на спад

    одразу ж згадав — минулого року кожний другий проект намагався використати блокчейн — це ж круто, модно і за це платять більше

    Поддержали: Loboda Andriy, Igor Azarny
  • Складнощі тестування мікросервісів та що з ними робити

    Для этого поднимается сам микросервис локально (может в контейнере), а все нужные зависимости (вроде баз данных или стриминга) — поднимаются тут же рядом в докер контейнерах

    По-перше, моя думка — я не хочу тягнути з registry та запускати локально всі мікросервіси. Роблю і плачу
    По-друге — вважаю, що тестування в готовому енвайрменті (production like) дає більш правдиві результати. Це як завести баг, а девелопер каже — на локальному білді в мене не репрод’юситься

    Если данные очень сильно между собой связаны — возможно это и не микросервисы вовсе.

    навіть якщо не сильно зв’язані — все одно геморой

    Разные средства коммунации между сервисами: но ведь и в монолите могут быть разные типы апи, которые так же надо тестировать. И тоже — изучать надо много инструментов.

    імхо — зовсім різні рівні абстракції. В моноліті код викликає код, в мікросервісах код викликає умовний рест щоб викликати код в іншому сервісі. Ось вам аналогія: ви живете з сім’єю в квартирі, але замість спілкування напряму використовуєте пошту. Щоб спитати в дружини, чи купила вона суші на вечерю, ви пишете листа, надсилаєте та чекаєте на відповідь. А коли вам кажуть, що так не зручно, паруєте — зате універсально та добре масштабується на будь який розмір сім’ї

    Нужно только иметь самые важные кейсы на этом уровне

    про це і писав

  • Складнощі тестування мікросервісів та що з ними робити

    у всіх своя біль — в нас з контрактами майже не було проблем за 3 роки розробки і вже N релізів в прод

  • Складнощі тестування мікросервісів та що з ними робити

    «батя, я стараюсь» ©

    Поддержал: Денис Дидовский
  • Складнощі тестування мікросервісів та що з ними робити

    це та, в якій треба привести двох друзів та стати золотим членом клубу? вибачте :)

  • Складнощі тестування мікросервісів та що з ними робити

    в чому проблема підняти їх та тестувати на пряму ? це одна з переваг

    По-перше, моя думка — я не хочу тягнути з registry та запускати локально всі мікросервіси. Роблю і плачу
    По-друге — вважаю, що тестування в готовому енвайрменті (production like) дає більш правдиві результати. Це як завести баг, а девелопер каже — на локальному білді в мене не репрод’юситься

    а в чому проблема використовувати різні канали зв’язку ? я певен, що є готові реалізації і для tcp і для RabbitMq і для будь чого іншого

    Синдром обманутих очікувань — спочатку всі кажуть, дивись, як классно ми все придумали, а по факту в мене на компі стоїть зоопарк всього + скрипти на пітоні для всіх типів коммунікації

    власне, мікросервіси дають змогу легко спускатись на нижчі рівні тестування, а не тестувани все через UI чи API.

    в вас ні разу не було такого, що unit, integration, api тести пройшли, а користувачы з продакшену баг заводять? Без UI тестів в складних системах ніяк

    Поддержал: Andrii Podanenko
  • Складнощі тестування мікросервісів та що з ними робити

    поки десь тупив з відповідями, тут вже цілий тред намалювався :)

    23 летние «иксперды»

    дякую за теплі слова, аж зморшок менше стало на чолі. З вас, сподіваюсь, пісок ще не сиплеться ;)

    Вопросы показывают «грабли» по которым прошелся автор

    тут ви праві — я гарно влаштувався. Це лише мої граблі і на істину я не претендую

    У 99% випадків не можна запустити один окремий мікросервіс

    трохи вирвано з контексту, але буду більш обачний з формулюванням — запустити можна, а от перевірити працездатність без моків/стабів/інших сервісів — складно

    2 «Для мікросервісів важко керувати даними...

    тут я,ч есно скажу, не дуже зрозімів посил, почали за дані, закінчили інтеграцією. RMI, COM, DCOM — більше абревіатур зроблять коммент розумнішим ;) Хоча ви праві в тому, що підходи до даних є різні

    3 «Для мікросервісів важко забезпечити транзакційність. » — да/нет, см пункт 2

    так, дійсно, залежить від використання БД, але давайте не будемо вдавати, що проблем взагалі нема

    4 «Мікросервіси можуть використовувати різні канали зв’язку. Коли» — хозяин — барин. Выбирайте то, что выгоднее.

    Вибрали, а щастя не знайшли

    Может поможет — dzone.com/...​ntainerised-microservices часть вопросов покрыта ответами.

    дякую за посилання — почитаю обов’язково

    1 Тут в нашей «галере» кто-то ратует за нано сервисы

    саме цікаве питання, вже питав в коментатора вище — які критерії мікро сервіса? В моємо розумінні — 1 сервіс, одна бізнес задача/логічна одиниця. Чим мікро від нано відрізняється?

  • Складнощі тестування мікросервісів та що з ними робити

    див. висновки

← Сtrl 1234 Ctrl →