QA спільнота

Женя, дякую за корисну статтю!

Дякую за змістовне і розлоге пояснення

Дякую за ваш коментар. Значення максимальної ціни 9999.99 було наведено просто як приклад, щоб показати, як може виглядати документація API.

Дякую. Гарна стаття. Про instock value треба пам’ятати — це дуже гарний кейс.

Дякую за коментар!) Погоджуюсь з вами, коли вже гарно орієнтуєшся у проєкті, проходження тест-кейсів може більше нагадувати чекліст

Дякую за цю просту та таку інформативну статтю! Будучи одним QA на проєкті теж використовував Checklist. Іноді правда щось проскакувало повз. Хоча з досвідом роботи, чеклістів справді було достатньо, хоча тест-кейси теж були написані.

Дякую, рада, що сподобалося ☺️

Спасибо. Статья действительно интересная.

Спасибо. Статья действительно интересная.

Тут є проблеми, бо коли складні структури даних передаєш ( map(list(map)) ) - то валідація може давати збій, наприклад, коли один модуль викликає інший і неможливо валідувати значення без apply — тобто зробиш забагато валідацій, частина plan не буде...

Якщо є гроші — можна розгорнути кілька ;) ;) А насправді — кожен свій код все одно тестить якось локально. Це вже перед тим як відправляти до тестувальників код розгортається на DEV щоб подивитись на максимально близькому до робочого оточенні.

Якщо команда велика і відкривається багато PR одночасно в одній часовій зоні, то лише dev/test environments буде недостатньо.

Звісно, використовується. Але пайплайн все одно це все перевіряє.

Для тестування в зв«язці з кодом існують 3 оточення — dev/test/prod — де dev — програмісти можуть розгортати та дебажити свій код, після цього він розгортається в test де його ломають вже qa, і якщо останні його не зломали і незнайшли, до чого доколупатися...

Також від себе добавлю, що мені як software engineer, бажано протестувати на лише IaC (terraform), а в зв"язці з кодом, а також мати локальне середовище для тестування коду, який буде виконуватися в хмарному середовищі — для пришвидшення розробки, для...