Дуже цікава стаття
Я зі свого досвіду скажу, я жив в Тбілісі 3 місяці їздив трохи по країні
Це афігезна для Українців країна, в нас з ними однакова проблема з рускімі, тому виключно тепло вас там будуть зустрічати

Всім раджу спробувати на пару місяців переїхати в Грузію, спробуйте — це дуже приємна країна

Тільки пару речей не сподобалось вони люблять їздити швидко та як навіжені, тому будьте пильні, ну і в Тбілісі я зустрівся з тим що вони дуже погано пропускають швидкі та пожежні машини — при тому в них ультра сильний культ сім’ї

P.S. Найкрутіші та найправильніші хінкалі з рубленого м’яса є в Пасанаурі (ближче до Тбілісі)

Ви помиляєтесь з приводу друкування грошей
Друк коштів — це шлях до їх знецінення
Як раз таки друкування грошів роздуває кульку — із-за чого як раз і може виникнути фінансова криза

Топ, всьо по поличках
Пару пропозицій ще на пробу:
Спробуйте замість/в додачу підхід API first для контрактних тестів, для опису комунікації сервісів
Та рест ашуред в сирому залишку може бути не достатньо для покриття тестами бекенду, із-за свого примітивного синтаксису, хоча залежить від того як ви його юзаєте

Давно так не вчитувався в статтю
Дякую, було дуже цікаво

Якщо перебільшити трохи з висновком, то можна сказати наступну річ: «задавайте багато питань клієнту та не вірте відповідям, все одно все піде не за планом» 🤣

З тестувальників такє враження, що можна все що завгодно зліпити)

Що це за фрукт «Методи психологічної обробки»?
Наведіть приклади, цікаво

Відсутність релігійних кафедр не зробило упішніше могилянки, Шевченки та політєхі за Львівський УКУ :)

Приєднуюсь до коментаря від Віталія)
Доповню лиш тим, що ця фраза капітанська
І так зрозуміло, що не існує сільвер булєтів,
А просто комусь, може в певній ситуації, із певною командою командою, із певною культурою, із певними можливостями, із певним настроєм, із певним бюджетом може мабуть підійти будь який підхід — і якщо пощастить

І майже те саме можна сказати і про те що «Це вже було», ну блін, в нас на рік вайтішників по 20к з 200к
Певні знання мають повторюватись, актуалізуватись з часом та спливати в «медіа»

Хай вже і сто років тому написано, але далеко не кожен матеріал ідеально кожному розуміється за буде корисним.
І варіативність знань це кльово!

Хоча кожен має право на капітанство)

Амінь)

Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

Раз шмаркнути й 100500 тестів написати 😸

Я вірю, що наша спільнота, колись виросте з тверджень: «Це підходить не всім», «Це вже 100 років тому придумано» 🙏

Іронія долі) Євген працює в паріматч)

топ)))

Гуд для початківців та тих хто заклопотався в роботі/рутині
А що з приводу Тестової стратегії, моделі та інших артефактів?

А чому програма починається з селеніума, а не з джави?

Ватра контент!
Останнім часом dou прям агонь контент лупить!

Круть! Маю декілька доповненнь та свого ІМХО)
1. Найкращі друзі тест інженера — це автоматизація та аналітика. Бюрократія тільки прикриває «сраку» коли інженер не повноцінно проаналізував та не автоматизував — тобто як батьки, в разі чого прикриють сраку сина)
Але все ж я більше схиляюсь до гнучкого балансу між аналітикою, автоматизацією та бюрократією, який залежить від культури в команді/компанії
Деякі баги та не доробки прикриваю фічами та тасками, все повноцінно автоматизувати важко але позитивні та базові негативні речі можливо, а аналітика як мати того всього
2. Гарно підмічено, що дуже важливо розібрати як все на проєкті влаштовано. Я б додав тільки що покращення можливі не тільки в QA та менеджмент частині, а ще й продуктовій частині та технічній. Продукт формується на захцянках замовників — якщо вони погано обробляються, то є проблеми (порою дуже дорогі). Продукт розробляється мовою розробки — тут потрібні і Code convensions, і статичні аналізатори коду, і баланс покриття тестами всіх рівнів коду, і як виконються доставки коду до проду, які в принципі існують qulity gates. Також як виконується observability та збір аналітики з реальної системи — як користувачі користуються нею.
3. Підтримую повністю, що розробники теж є найкращі друзі тест інженера. Але іноді щоб не задавати глупих запитань, треба розумітися в програмуванні та порою фіксити баги коли їх помічаєш замість розведення бюрократії 😉
4. Аналізуй, потім плануй та порівняй в кніці чи співпли плани із релаьними справами.
Я користуюсь Onenote щоб планувати дні, тижні та місяці, а потім переглядаю чи все було виконано
5. Так :)
6. Автоматизовуй тест кейси та автоматизуй їх створення в тест менеджемент системі 😉
7. Ооо так) Мало хто вміє гуглити
8. +
9. Ну замість сторі, маю фільтри в жирі на баги та на те що створено мною
10. Ооо так!

Так покриття коду тестами та покриття вимог це різні речі.
Вимоги покрити на 100% більш можливо ніж на 100% код.
Але звісно, залежить від того як саме будуть покриті ті вимоги
Але все одно, вимог то менше ніж вхідних даних на кожну стрічку коду 😉

Круто, що ви стратегію тестування для себе можете уявити)
Але мушу ще раз наголосити, що я мав 2 роки досвіду, на проєкті вже був Тім лід і вона відповідала за то. А я, у свою чергу, оптимізував деякі частини стратегії та плану

Розумію) Я думав то все сам зробити, але розумів що мабуть буде простіше навчити всіх жаві з селенідом та зробити все масштабніше за той самий період часу
Наодинці по суті я все почав та робив, а під кінець вже більшість інженерів могли робити майже те саме)

Це є алегорія :)
Суть в тому, що дали задачу особисто мені, щось автоматизувати, а я зробив це за допомогою всіх інженерів. В цьому двоплановість «наодинці» 😉