Это не ок
не ок одразу оцінювати. ви не знаєте контексту та який проект, не знаєте цілей
Якщо розробники норм тестують, тех дебт та рівень дефектів їх не тормозить — не бачу потреби їх навантажувати ще і додатковим тестувальником
воно обов’язково наєбнеться в наступному кварталі
власне, ось ці всі тести допомагають відтермінувати наступний квартал
потрібно це обговорювати. Якщо, замовник погоджується з цим, ну то він буде платити пізніше більше.
бувають різні ситуації і різні люди. Буває по вашому, але і є багато зацікавлених у якості проектів. Такі речі завжди можна обговорювати та шукати рішення чи компроміс.
трохи не зрозумів, до якого саме твору йде відсилка ? і якої цитати ?
1) не з автоматизаторів зробити мануальщиків, а залучати до командних активностей типу планування і тому подібне. Не раз стикався з тим, що автомейшини живуть дуже окремо, у своєму власному світі
2) взагалі, оцей поділ на мануальщиків та автомейшинів шлях в нікуди. Тестувальник повинен вміти і потестити руками, і написати код. Нажаль, так не є, але варто йти цим шляхом.
3) дуже підтримую розширення відповідальностей. Дев має не лише написати код, він повинен вміти і тестувати. Тестувальник також, має вміти не лише тестувати
100% покриття коду не гарантує те, що все покрито. Рядки коду то покриті, а чи всі вхідні дані ?
Для кінцевих користувачів без різниці скільки і які у вас тести. Тому, краще зосередитись на основних та критичних бізнес сценаріях
аби дешевше вийшло
поясніть йому, якщо сьогодні «дешевше», то через півроку ціна на багфікс та новий функіонал буде рости експоненціально.
Тести вони ж не для галочки, тести дають впевненість, що ваші зміни нічого не ламають. Їхня користь проявляється не одразу, а пізніше.
Якщо замовник має довготермінові плани на продукт — без тестів ніяк. І також, якщо замовнику цікаві часті релізи — без тестів ніяк. Ну можна, але доведеться платити за овертайми, хотфікси на прод, бо у юзера щось поламалось і простенький функціонал будуть робити не день, а тиждень, бо ніхто не знає як воно працює і скільки потрібно перетестувати
якщо тести не великі, то вони і швидші, і стабільніші, і їх можна швидко писати. Звісно, щоб досягти цього потрібно спочатку вкласти багато у сам фреймворк. І важливий момент це як ви будете співпрацювати з девами.
я проганяв всі тести по 3 рази
оо. хотів запропонувати це. а в таблицях середній результат за всі прогони ? чи якоїсь однієї ?
від реалізації http клієнту та багатопоточності
скоріш за все. + можливо, ще метрики по різнову оцінюються. Я колись копав у доках Jmeter, то там Response time рахується від надсилання першого пакету tcp, до отримання першого пакету. Можливо інші тули це по іншому рахують
круто ! дуже крута стаття ! Сам давно цим цікавлюсь і думав над подібним проектом.
Дуже дивно побачити такі відхилення по RPS та response time. Цікаво би знайти корінь проблеми і як зрозуміти, що ці дані корелюються з реальними метриками кінцевих користувачів.
Моя думка, що це може бути проблема з NAS або мережею. Було би круто задеплоїти кудись в клауди і спробувати там
Дістали Нідерланди ? Дорого і дощі ? Миколаїв чекає на вас — dou.ua/...rticles/move-to-mykolaiv
Додам посилання ще на свою статтю : medium.com/...в-тестування-5bdb293b68ec
Цікаво дізнатись як виглядає конкретний GraphQL HTTP запит. От коли виконується query операція
query GetAllFilms {
allFilms {
id
title
episode
}
}
як передається — у тілі POST запита, у посиланні GET запита ?
аналогічно з операцією Subscriptions — як вона реалізовує слухання ? це веб сокети ? чи як ?
Також цікаве порівняння GraphQL та OData ?
Саме місце, щоб пропіарити свій "блог"medium.com/...естування-пз-625b7332d1fa
Дивіться на різні категорії, як на різні аспекти.
Поясню.
Регресивне тестування — це перевірка системи після змін. Вона може бути як і функціонально, так і не функціональною.
Смоук це дуже швидке тестування основного функціоналу. Переважно це функціональне тестування, але якщо вам важливі якісь аспекти безпеки\перформансу, можна і роботи смоук тести безпеки\перформансу
От як з автомобілем — є різні аспекти\характеристики як колір, тип кузова, мотор.
Чи може бути червоний седан на дизелі ? так ! і кожен з цих аспектів не залежить один від одного.
цель перевезти свою семью в Канаду
а чому саме Канада ?
будите писать farewell letter
якщо команда\компанія\проект не підпадають під ваші цінності то завжди є 2 шляхи : або ти впроваджуєш зміни, або ти міняєш компанію\проект\команду
ви не знаєте як працює конкретна команда, якщо вони можуть самі забезпечити собі тестування, без окремої людини, то це дуже правильний напрямок руху.