QA спільнота

RSS
474 статті, 598 топіків, 19K коментарів, 5437 учасників


← Сtrl 123456...36 Ctrl →

Коментарі

Я співбесідував дуже багато автоматизаторів, які теж не можуть в DevOps, чи хоча б щось важче за find_element :) Проте також і працював та будував команди де автоматизація обов’язкова, а розділень немає, тож треба в тестувати, бо тобі за це відповідати,...
Хто такий General / Fullstack QA? В українському айті це зазвичай спеціалісти, які мануал QA, але трошки навчились писати код на досить примітивному рівні.
Ну в сучасному тренді так, General QA це щось суміжне. Моя ж основна думка бути Quality Engineer, тобто мати повну експертизу автоматизатора, мати змогу відстояти його зарплату і робити все.
Це все чудово, але зарплата у General QA нижча ніж у Automation QA і наче логічно для людини більше переходити в автоматизацію ніж тримати баланс між ручним та автоматизованим тестуванням.
Дякую, тут суть заперечення зовсім інша, і вона справедлива в широкому сенсі — essential complexity Брукса нікуди не поділась, і я не пропоную формалізувати 60%+ вимог усього проєкту перед розробкою.
Тут ок, те що ви пропонуєте це певний сантайзер архітектури, умовно може підказати щось з розряду "данні можуть бути не согласованими, додайте : Транзацію, Сагу, Монітор і т.п.
«Exactly-once» у Kafka — це реальна гарантія, але вона діє всередині транзакційного домену самої Kafka: атомарний запис у топік + producer-транзакція + offset commit, або класичний read-process-write цикл (Kafka Streams).
at-least-once => що спричиняє дубль виконання => at-least-once Тобто це не “помилка розуміння Kafka” з мого боку див. exactly once => Kafka provides various guarantees such as the ability to process events exactly-once.
Щодо Essential Complexity (Брукс): Брукс має рацію: складність ПЗ неминуча.
Essential Complexity закон Брукса. Усіх вимог просто не може бути при створені ПЗ, тому і науково доказовий метод — тестування в простонародії і ітеративні методики розробки.
Щодо Kafka — ви праві в тому ж сенсі, що і Vitaliy та Serhii вище: at-least-once і механізм redelivery — це свідомий дизайн, не збій Kafka.
Конкретний кейс: 1. Consumer отримує івент з Kafka так я вже зрозумів що вома конкретно за кафку грєфнєвая ... імхо помилка тут у розумінні що є кафка What is Kafka?
Alex, дякую за детальну аргументацію. Ви праві в одному: всередині одного процесу event state machine = простий граф, де correctness доводиться per-node. Але мова статті про міжпроцесний crash window. Конкретний кейс: 1.
питання в тому, як переконатися, що архітектура дійсно правильна, коли система складна: кілька consumer’ів, різні timeout’и, кілька брокерів.
в цілому це дефолт менджменту) якщо все працює стабільно і не ломається — це заслуга компанії, якщо щось пішло по бороді — в цьому винен менеджер)