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

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

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

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

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

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

І майже те саме можна сказати і про те що «Це вже було», ну блін, в нас на рік вайтішників по 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 роки досвіду, на проєкті вже був Тім лід і вона відповідала за то. А я, у свою чергу, оптимізував деякі частини стратегії та плану

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

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

Валідне запитання, але не зауваження 😉
Я на той час мав 2 роки досвіду та не був QA лідом. Цю роль обіймала інша людина та відповідала відповідно за увесь процес, а я по факту, оптимізував окремі її частини

А ваш досвід дуже крутий та цікавий мені :)

По цьому нічого специфічного не потрібно було описувати, оскільки було декілька уроків по JMeter та як виміряти base line ну і які репорти використовувати для реального прогону перевірок

Погоджуюсь що ефективність автоматизації можна виміряти й дуже правильно вимірювати!
Оцінка успіху автоматизації по внутрішніх відчуттях це не серйозний підхід.
Але не у всіх є час займатись мєтріками, потрібно тут і зараз копать) І добре коли є хоч якась стратегія, я вже мовчу про мєтрікі) ІМХО

Насправді в оригіналі була інша трохи фраза
"""
При такому підході рівень підготовки інженерів з тестування має бути сильніший, ба більше, рівень кваліфікації та/або хоча б свідомості ВСІХ інженерів має бути вищій. Так — такі інженери дорожче, але вони можуть бути ефективнішими 2-100 разів.
"""
І мабуть, слід було б додати до цього судження хоч якісь пруфи. Тому зроблю це в коментарях

В першу чергу це вже старий тред про 100x інженерів, www.google.com/search?q=100x engineer
В індустрії це вітає досить давно, хтось може протиставляти свої аргументи цьому судженню, але це реальність