Як мануальному тестувальнику уникнути рутинності та зберегти ефективність в роботі

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт усім вигорілим та не дуже!

Мене звати Галина Захарова, і я працюю Middle QA Engineer у ІТ-компанії Customertimes. Ви вже могли читати мої статті на DOU про те, як я шукала роботу в ІТ, як пройшов мій перший рік в ІТ та техніки тест-дизайну для «чайників». Настав час поговорити про рутину!

Впевнена, всі знайомі з робочою рутиною, яким би цікавим проєкт не був. У вас немає сил, ви втомлені, фокус уваги постійно перемикається, мозок кричить «нумо дивитись YouTube», а сповіщення з Instagram так і манять, як сирени: «Відкрий мене, залипни в мене!». Ефективність роботи, звісно, падає і падає. Бувало у вас таке? Але ця рутинна яма до добра не доведе, бо не за горами і вигорання.

Мануальне тестування, перш за все, про людину, про її уважність до деталей, про залученість у процес. Тестувальник — завершальна ланка в розробці програмного забезпечення. Користувачі хочуть налагоджене, безбажне, гарне ПЗ від користування яким будуть отримувати задоволення і писати позитивні відгуки.

Щоб зменшити кількість рутинної роботи, варто або виправити вже наявне, або одразу зробити добре. Розгляньмо, що можна зробити, щоб зменшити монотонність і зробити процес тестування ефективнішим.

Створення зрозумілих тест-кейсів

Що складного у написанні тест-кейсу? Врахування всіх деталей і особливо такої деталі, як те, що тест-кейс має бути максимально простим і зрозумілим для людини, яка тільки прийшла на проєкт або для вас самих, коли ви півроку не будете тестувати той функціонал і щось забудете. Якщо ви пишете в тест-кейсі в передумові «Упевніться, що модуль „Іграшки“ доданий на сторінку» — це погано. Треба написати ще й те, як додати той модуль на сторінку, якщо його все ж таки немає там (підійде не для всіх проєктів, але мій, наприклад, на Salesforce, дозволяє це робити).

Детально розпишіть вхідні дані, які потрібні для тестування. Це може бути JSON, якийсь документ чи ще щось. Додайте всі ці дані, щоб потім не довелось шукати або вигадувати нове на льоту.

Чітко визначте очікувані результати для кожного етапу тестування.

Вичерпне тестування неможливе, але згадайте, що вчили з теорії тестування, усі техніки тест-дизайну і використайте їх, щоб покрити різні аспекти функціональності.

Систематизація тест-кейсів

Треба систематизувати тест-кейси так, щоб їх легко було знайти. Можна їх згрупувати за версіями та за приладами, на яких відбувається тестування (Web, iPad, iPhone наприклад). Уявімо, що я тестую інстаграм, і він ще, як мала дитина, вміє мінімальний мінімум. У першій версії перевіряємо на різних пристроях створення акаунта та його налаштування. У другій версії — створення постів та сторіз. Це буде виглядати так:

Ліворуч можна побачити, як все систематизовано:

Або ж використовуйте категорії / мітки для тест-кейсів у тест-менеджері. Наприклад, «Регресія», «Сумісність», «Інтерфейс». Така систематизація полегшує пошук і фільтрацію тест-кейсів, що може бути корисним під час планування тестування.

Використовуйте інструменти для управління тестовими сценаріями

Не на всіх проєктах пишуть тест-кейси чи пишуть їх у Exel, але є інструменти значно ефективніші за таблички. Наприклад, ріднесенький український Testomat.io чи іноземні TestRail, Zephyr. Ці інструменти не лише дозволяють керувати тест-кейсами, але і створюють структуру, яка полегшує організацію та пошук тестів (дивіться структуру в попередньому пункті).

Регулярні огляди та оновлення

Щоб інформація залишалась актуальною, необхідно регулярно після нововведень у ПЗ переглядати тест-кейси та оновлювати їх, щоб потім не думати, а чому не працює так, як описано у тест-кейсі. Якщо нова фіча — писати під неї тест-кейси одразу. Якщо тестовий сценарій уже не потрібен — видаляти.

Щоб не бути таким котиком, не забувайте робити все, що описано вище та буде нижче 🙂

Воскресіть у собі креативну частину

Креативність та інтелектуальний підхід дозволять вам ефективно взаємодіяти з продуктом, виявляти неочевидні проблеми та знаходити рішення. Креативність вб’є рутинність і трохи розворушить ваш мозок. Ось кілька аспектів, які підкреслюють роль креативності у мануальному тестуванні:

Розуміння користувача

Креативний підхід: ви можете намагатися думати, як користувачі, та генерувати цікаві сценарії використання, які не завжди визначені у вимогах. Вихід за рамки буде лише на користь.

Інтелектуальний підхід: станьте на місце користувача та подумайте над реальними потребами, це дозволить вам ставити інтелектуальні питання, спрямовані на виявлення потенційних проблем та вдосконалення користувацького досвіду.

Сценарії тестування

Креативний підхід: можна розробляти нестандартні сценаріїв тестування, які в змозі виявити проблеми, що виникають у реальних умовах використання.

Інтелектуальний підхід: аналіз сценаріїв тестування з точки зору ризиків та пріоритетів дозволяє фокусуватися на критичних аспектах продукту.

Емпатія до користувача

Креативний підхід: спробуйте відтворити ситуації, які можуть зустрітися реальним користувачам (знову уявіть, що ви — користувач), та досліджуйте, як програма веде себе в таких умовах.

Інтелектуальний підхід: займіть позицію користувача та допоможіть розробникам у розумінні причин та контексту виявлених проблем.

Взаємодія з розробниками

Креативний підхід: беріть активну участь у спільній роботі для виявлення та обговорення можливих проблем та шляхів їхніх вирішень.

Інтелектуальний підхід: будуйте конструктивний діалог, висловлення думки та ідеї для поліпшення якості продукту.

Обмін досвідом та знаннями з командою

Наприклад, у вас є проєкт з фічами з додавання товару в корзину, за реєстрацією та за підпискою на розсилку. Тестувальник-1 постійно тестує додавання товару в корзину, Тестувальник-2 — реєстрацію, Тестувальник-3 — підписку на розсилку.

З часом кожен тестувальник буде знати свою фічу як свої п’ять пальців та зможе із заплющеними очима все робити (умовно 🙂). Спочатку це буде прикольно для них, бо робота буде швидше йти, але згодом їм стане ну-у-удно (мені це знайомо), а ще можна буде пропустити баг через замиленість ока.

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

Обмін досвідом та знаннями допомагає збадьорити мозок. Коли ми навчаємо інших, самі краще запам’ятовуємо інформацію.

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

Парне тестування: коли два тестери працюють разом, вони можуть швидше виявляти проблеми та обмінюватися ідеями щодо того, як вирішити їх (якщо це можливо зробити, якщо ні — заводити баг-репорт). Парне тестування стимулює активні обговорення та забезпечує подвійну перевірку для важливих функціональностей.

Відстежування та аналіз результатів

Застосування відстежування та аналізу результатів може значно покращити ефективність і виявити рутинні завдання. Постійний аналіз допомагає виявляти патерни та тренди в тестуванні та спрямовувати зусилля на найбільш важливі сторони продукту, покращувати якість тестування. Ось кілька етапів та прикладів:

Визначення ключових метрик

Встановлення ключових метрик, як-от кількість знайдених дефектів, час виконання тест-кейсів, покриття тестування. Наприклад, якщо багато часу витрачається на тестування одних і тих самих функцій, це може свідчити про рутинну в тестуванні.

Якщо з іншим усе зрозуміло, то стосовно дефектів у вас можете виникнути питання «Як воно впливає на визначення рутинності?». Наприклад, якщо програма стабільна, і кількість знайдених дефектів несуттєво змінюється протягом тривалого періоду, це може означати, що тестування переважно рутинне та звичайне (око замилилося). Тому варто переглянути підходи до тестування.

Відстежування поточних результатів

Створення щоденних чи щотижневих звітів з результатів тестування, вказуючи кількість виявлених багів, опис пройдених тест-кейсів та тривалість тестування. Аналіз цих даних може допомогти виявити області, де виникає більше проблем або де витрачається більше часу.

Створення графіків та діаграм

Використання графіків для візуалізації трендів у часі, покриття тестування та інших ключових показників. Наприклад, графік, який показує, як змінюється кількість виявлених дефектів протягом релізу, може вказати на особливість у якійсь частині продукту.

Виявлення рутинних завдань

Виявлення тест-кейсів, які виконуються кожен раз під час випуску нової версії. Якщо ті самі тест-кейси постійно успішно проходять, може виникнути питання про їхню доцільність та можливість їхньої автоматизації.

Креативний підхід до оптимізації

Пошук нестандартних методів оптимізації. Наприклад, виявлення тест-кейсів, які можуть бути згруповані чи автоматизовані, щоб заощадити час та ресурси.

Колективний аналіз та обговорення

Регулярні зустрічі команди для обговорення результатів та аналізу трендів. Це дозволяє виявляти загальні висновки та шукати креативні рішення для уникнення рутинності. Одна голова добре, а декілька — краще 🙂


У той час коли технологічний світ стрімко розвивається, робота мануального тестувальника залишається актуальною та необхідною під час розробки ПЗ. Важливо, щоб кожен тестувальник був уважний до деталей і залучений у процес на 100% для відмінного результату.

Рутинність та вигорання стають на заваді цієї мети. Але якщо вчасно помітити рутинні завдання, які віднімають інтерес та знижують ефективність, оптимізувати та автоматизувати процеси, можна цього уникнути!

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному11
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

трошки буду токсік , але візьміться за автоматизацію, ваша рутина переросте в страждання , і наступною статтею буде — як вийти із айті )))))

Все в порівнянні. Після армії «страждання в айті» і «вийти з айті» звучить як роздуми здорової людини відрубати собі ноги щоб зручніше в кріслі сидіти :)

Я гадаю що потрібно поєднувати автоматизоване E2E/UI тестування(коли тобі треба тестувати критичний функціонал), та так зване exploratory testing... тобто інколи людина може знаходити досить незвичайні кейси, проводячи багато часу з інтерфейсом ( шось схоже як шукають артефакти у іграх)

людина може знаходити досить незвичайні кейси

А кому це треба? Основний фокус же завжди на happy paths.

Як мануальному тестувальнику уникнути рутинності та зберегти ефективністьв роботі

Развиваться индивидуально. «Мануальный тестировщик» это 2, максимум 3 года.
Если клацать формочку 10 лет и описывать все сценарии бананами — техническая вовлеченность в проект будет равна 0.
Про все остальные пункты уже описали в комментариях.

Вибачте. Я скоріш за все пожалкую про це питання, але все ж «а що з мануальним тестувальником через 3 роки»?

Та все дуже просто. Далі йде зупинка в розвитку.
Люди або залишаються на цьому ж рівні роками або обирають два шляхи розвитку, які можуть перетинатись з часом взалежності від вподобань і схильностей людини.

1. Більш гуманітарний шлях. Людина все більше вникає власне у розвиток продукту, бізнес-аналіз, комунікаціїю зі стейкхолдерами, менеджмент, лідання, скрам-мастеринг тощо. І відповідний розвиток BA-> Product Owner / Scrum Master/ Management.
2. Більш технічний. Людина вивчає якусь мову програмування із найбільш поширених для автоматизації та власне автоматизацію і росте як автомейтер чи дженерал куей. У програмуванні ніколи не заскучаєш і все не вивчиш. Як наслідок цілиться стати солідним Senior QA / AQA / QA Lead. При бажаннні з часом теж перейде у менеджмент або буде вдосконалювати свою експертизу як технічого спеціаліста.

Третього не дано. Третє — це вічні мідли мануальщики, де можна сидіти роками на медіанній 1.5-2.5к зп, якщо повезе. Працював з лідами, які нічого не розуміли у автоматизації і мені такий підхід не сподобався, коли не технічний лід каже, що буде ре’вювати код, що зробили автомейтери або просто не може сфорулювати завдання чи оцінити скоуп робіт з менеджентом тощо. Працював з класними мануальними лідами, але в них або був досвід в минулому у автоматизації або вони вже поєднували роль бізнес-аналітика або поєднували роль і здавали якісь сертифікації по скрам-мастерингу.
Все все одно зводиться до двох шляхів розвитку кар’єри. Знаю особисто кількох амбітних людей, які досягнули кар’єрного успіху обираючи як перший так і другий варіант.
Тому я повністю погоджуюсь, що для чисто суто мануального тестування вистачає максимум 3 роки кар’єри, далі в ідеалі потрібно обирати шлях розвитку, бо рано чи пізно все одно до цього будуть рухатись. Хто не погоджується, то він на даному етапі нічого не хоче вивчати і розвивати кар’єру, і відкидає від себе такі думки, що не є погано, кожен сам собі обирає, що йому потрібно. Інший варіант, що можливо вже виконує частину обов’язків певного проксі а-ля бізнес аналітика на проекті із навішеними тасками по цьому. Або ж в особистих розмовах більшість мануальних куеїв, які вже мають 3+ роки досвіду, ділились своїм невиконаними бажаннями стати автомейтерами. Бо пробували і не вдалось в силу складності або не було часу і ще планують спробувати.

А в embedded можна більше 3 років? Там формочек немає.

Вітаю, Галино! Потихеньку набираєтесь досвіду? :)
Потрапила до уваги ваша стаття, зацікавився, то ж давайте конструктивно подискутуємо.

а. Для кого стаття написана? Для мануальних тестувальників, які на проекті самі, або їх декілька і скоріше за все над ними нема тест ліда/менеджера? Для тест ліда? Для Тех.ліда, який не розбирається в тестуванні і у якого в команді є тестувальник? Для тестувальника, яки розуміє, що йому вже набридло те мануальне тестування і він не знає, що змінити? Здається ніби перший варіант, але як бачите, з огляду на аудиторію вибір і подача інформації можуть бути різними. У вас вийшов мікс, і таким чином, як на мене, трошки втрачається фокус і концептуальність.

б. Ще в назві ви надали думку, що рутинність = зниження ефективності в роботі, яка не є аксіомою сама по собі, оскільки можуть буть варіанти/передумови:

  • передбачається, що людина вже була ефективним тестувальником, що не очевидно.
  • передбачається, що рутинність знижує ефективність через «втому» і як наслідок зниження концентрації на роботі, але як на мене цей факт може компенсуватись набуттям досвіду, коли людина просто відчуває де шукати дефекти і робить це без всього того складного тест дизайну. 10 тестів, 7 з яких знайдуть дефекти.
  • а як щодо тих людей які дуже полюбляють рутину і хотіли би поменше думати і побільше проганяти тести і репортити баги. Чи їм теж треба зменшувати рутину? Особливо під час війни, коли безкінечне регресійне тестування є чт не єдиним острівцем стабільності в їх житті?

Тобто я б не ставив тут знаку тотожності або якихось прямопропорційних звязків, з яких випливали б саме ваші рекомендації.

Тепер йдемо по тексту:

1. Втому і прокрастинацію на роботі ви повязуєте з рутиною, але це тільки одна з можливих причин серед інших: складний проект, нестача знань та скілів, проблеми в компанії/команді/сім’ї, тощо

2.

Створення зрозумілих тест-кейсів

... хм, а що заважає рутинно створювати зрозумілі тест-кейси, теоретично це навіть збільшує монотонність роботи, тому що ви починаєте в моменті більше писати нудних, очевидних тестів. І це як раз приклад, коли рутинність може конфліктувати з ефективністю підтримки тестів для складного проекту.
У прикладі ви вказали, що precondition треба розписати прямо в тест-кейсі (принаймні я так зрозумів з тексту). Дуже спірно, я б навіть сказав шкідливо, оскільки ви тільки обтяжуєте тест-кейси цим, а от посилання на інший тест-кейс, який переводить систему в це стан (і вони наприклад обєднані в єдиний test suite), або ці preconditions розписані в якомусь документі, наприклад у тому ж тест плані, це вже більше до справи.

3.

Систематизація тест-кейсів

— знову ж таки процес систематизації досить рутинний, але підвищує ефективність команди (хоча якщо команда — це тільки ви, а проект короткостроковий, то це знижує ефективність команди ? ;)

Вибачте, не знаю деталей, але чому тест-кейси з ID C1, C3, C5 у вас мають однакову назву — Instagram: Create account? То це однаковий тест чи є між ними різниця? Якщо є, то її треба відобразити у назві, якщо ні — то це повинен бути тест C1, що повторно використовується для тестування в різних test suites

4.

Використовуйте інструменти для управління тестовими сценаріями

Легким розчерком руки ви надали тестувальнику обовязки тест менеджера або й цілого директора департаменту :). Тестуємо на тому, що компанія має/використовує. Ой як рідко тестувальник може повпливати на вибір інструменту. Це на адресу того, для кого ця стаття.

5.

Воскресіть у собі креативну частину

Зробили припущення, що вона вмерла. Якщо була живою та вмерла, то тут треба розібратись чому і чи була взагалі необхідна? Може там якісь інші є проблеми ніж рутина? А чи потрібна на цьому місці була б креативність. Комусь знаєте і просто баги репортити треба, чи тести проганяти.
Чим пункт «розуміння користувача» відрізнається від «емпатія до користувача»?

6.

Обмін досвідом та знаннями з командою

Тут трохи не зрозумілий приклад, оскільки якщо 3 тестувальники працюють в одному проекті, то вони начебто всі повинні знати про ці фічі, або принаймні приймати участь в їх обговоренні, бо з вашого прикладу навіть виникають кейси коли з розсилки ми можемо перейти по посиланню і авторизуватись (тільки не кажіть що рестрацію та логін теж відповідають різні тестувальники :) ) або незавершена покупка в корзині может потрапити до теми розсилки. І якщо ж кейс такої прям «ізоляції» людей в команді, то це питання до менеджерів.
Якщо обмін знаннями іде просто «щоб не було нудно» і ці люди навряд чи будуть робити тести одне одного, то тут ще питання для чого це?
З точки зору тім ліда, то тут треба уникати ситуацій наявності «унікальних знань» які втрачаються разом з людиною. В розвязанні проблеми тут допоможе такий інструмент як star map або skill map. Але також як рішення проблеми — створення документації і діставання знань з будь-якої голови. Тобто взагалі не згоден з цим пунктом якщо говоримо про ефективність і дуже умовно згоден, якщо це про рутину, хоча навіть в цьому контексті, саме рутина виглядає не такою великою з інших можливих наявних.

7.

Відстежування та аналіз результатів

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

Застосування відстежування та аналізу результатів може значно покращити ефективність і виявити рутинні завдання.

Я б це написав як:
— Застосування відстежування та аналізу результатів може виявити рутинні завдання і внаслідок їх оптимізації значно покращити ефективність.

І тут як висновок моє бачення ситуації. Поділений на дві частини:

Рутина не є поганою сама по собі і вона обовязково виникає в роботі. Буває що з процесом все ок і він просто не передбачає «довічного» задоволення людини. Може статися, що замість всього описаного вам просто прийшов час змінити проект/роботу і це абсолютно нормально і треба було б вказати це в статті. Також «рутина» — це клондайк для автоматизації та оптимізації, тому що не завжди ці двоє доречно застосовуються з огляду на їх доречність та повернення інвестицій. Якщо ж рутину визначили на власному досвіді — це ж клас, з нею тепер можна працювати. І знову на останок — не всі люди креативні і не всі креативні весь час свого професійного життя, комусь і рутина на радість.

Ефективність дуже знаєте такий спірний момент. Вона зачасту має лише 2 варіанти: ефективний і неефективний. Ви або робите вашу роботу і влаштуваєте команду, або не робите і не влаштовуєте. Всі будь-які спроби її підрахувати метриками, а тим паче підвищити начебто працюють в моменті, а потім призводять до спотворення системи і роботи саме на метрики, а не на результат. От ця от низька ефективність, рутинність задач — це можуть бути вже наслідки якихось процесів, на які навіть на рівні тест менеджера можна повпливати дуже опосередковано. То що ж тоді, махнути на все рукою? Ні, ваші поради мають сенс, але всі вони лише поверхнево торкаються проблеми, яку ви пропонуєте вирішити власноруч. Все це можна замінити однією порадою — пійдіть до свого лінійного менеджера і скажіть, що у вас якась хрінь з роботою і працювати взагалі не виходить. Якщо у вас гарний менеджер, то він обовязково вас вислухає і серйозно візметься за вирішення вашої проблеми, а якщо поганий — слухайте, ну то може це і є одна з причин вашої низької ефективності?

Всім гарного дня і цікавого тестування!

Доброго дня)
Так, потрохи набираюсь досвіду і писала статтю більше опираючись на те, що відбувається у мене на проєкті, де не 1 QA. Відповідно як записка собі на майбутнє і тим, хто шукає шляхи покращення.

передбачається, що рутинність знижує ефективність через «втому» і як наслідок зниження концентрації на роботі, але як на мене цей факт може компенсуватись набуттям досвіду, коли людина просто відчуває де шукати дефекти і робить це без всього того складного тест дизайну. 10 тестів, 7 з яких знайдуть дефекти.
а як щодо тих людей які дуже полюбляють рутину і хотіли би поменше думати і побільше проганяти тести і репортити баги. Чи їм теж треба зменшувати рутину? Особливо під час війни, коли безкінечне регресійне тестування є чт не єдиним острівцем стабільності в їх житті?

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

... хм, а що заважає рутинно створювати зрозумілі тест-кейси, теоретично це навіть збільшує монотонність роботи, тому що ви починаєте в моменті більше писати нудних, очевидних тестів. І це як раз приклад, коли рутинність може конфліктувати з ефективністю підтримки тестів для складного проекту.
У прикладі ви вказали, що precondition треба розписати прямо в тест-кейсі (принаймні я так зрозумів з тексту). Дуже спірно, я б навіть сказав шкідливо, оскільки ви тільки обтяжуєте тест-кейси цим, а от посилання на інший тест-кейс, який переводить систему в це стан (і вони наприклад обєднані в єдиний test suite), або ці preconditions розписані в якомусь документі, наприклад у тому ж тест плані, це вже більше до справи.

— не завжди можна послатись на такий тест-кейс і не завжди передумова буде полотном. Якщо можна, то краще послатись на конфігураційний тест-кейс, тут моя прогалина у тексті. Стосовно тест-плану чи посилання на інші документи — не знаю на скільки це зручно, не стикалась, тому судити не можу. Може це також дієво, треба мати з цим справу, щоб оцінити.

Вибачте, не знаю деталей, але чому тест-кейси з ID C1, C3, C5 у вас мають однакову назву — Instagram: Create account? То це однаковий тест чи є між ними різниця? Якщо є, то її треба відобразити у назві, якщо ні — то це повинен бути тест C1, що повторно використовується для тестування в різних test suites

— Тому що перевірка на різних пристроях (web, iPad, iPhone) одного й того ж функціоналу. В мене на проєкті така система і вона достатньо зручна. Якщо можна по іншому згрупувати — чому б ні, не заперечую :)

Легким розчерком руки ви надали тестувальнику обовязки тест менеджера або й цілого директора департаменту :). Тестуємо на тому, що компанія має/використовує. Ой як рідко тестувальник може повпливати на вибір інструменту. Це на адресу того, для кого ця стаття.

— так, що маємо те й використовуємо, але знати, що є взагалі варінти — чому ні? :)

Чим пункт «розуміння користувача» відрізнається від «емпатія до користувача»?

— досить схожі, але розуміння користувача може базуватися на дослідженнях, аналітиці даних, опитуваннях, спостереженнях та інших методах для отримання об"єктивної інформації. Емпатія до користувача включає емоційний аспект, тобто базування на суб«єктивності, як би Ви діяли емоційно на місці користувача.

Тут трохи не зрозумілий приклад, оскільки якщо 3 тестувальники працюють в одному проекті, то вони начебто всі повинні знати про ці фічі, або принаймні приймати участь в їх обговоренні, бо з вашого прикладу навіть виникають кейси коли з розсилки ми можемо перейти по посиланню і авторизуватись (тільки не кажіть що рестрацію та логін теж відповідають різні тестувальники :) ) або незавершена покупка в корзині может потрапити до теми розсилки. І якщо ж кейс такої прям «ізоляції» людей в команді, то це питання до менеджерів.
Якщо обмін знаннями іде просто «щоб не було нудно» і ці люди навряд чи будуть робити тести одне одного, то тут ще питання для чого це?
З точки зору тім ліда, то тут треба уникати ситуацій наявності «унікальних знань» які втрачаються разом з людиною. В розвязанні проблеми тут допоможе такий інструмент як star map або skill map. Але також як рішення проблеми — створення документації і діставання знань з будь-якої голови. Тобто взагалі не згоден з цим пунктом якщо говоримо про ефективність і дуже умовно згоден, якщо це про рутину, хоча навіть в цьому контексті, саме рутина виглядає не такою великою з інших можливих наявних.

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

З останнім абзацом згодна і як бачите, мені в голову воно не прийшло через брак досвіду. Але зауваження слушне, дуже дякую, є над чим задуматись :)

Вибачте, що не вдаюсь в деталі, і не розбираю кожен пункт окремо. Але більшість з описаного вище більше схоже на рожеві окуляри Manual QA, який говорить собі «от я коли стану QA Lead — у мене такого безладу не буде». На жаль, але Буде.
Кожен окремий випадок потребуватиме окремого розгляду, але завжди будуть обставини непереборної сили. Так, з ними можна боротись, але останнім завжди іде «прийняття».
Рутина і вигорання — це неодмінні супутники QA, професійні особливості, уникнути які можна лише змінивши спеціалізацію чи спеціальність.

Вітаю, Віктор)
Так, все не буде ідеально. Але «прийняття» не завжди і щось потрохи змінювати у підходах до роботи можливо.
Озираючись на проєкт, на якому працюю, багато підходів застосовані, що робить роботу в якомусь сенсі легшою. А боротись із вигоранням та рутиною шляхом зміни професії — дивно, бо ці супутники є в кожній професії і від себе не втечеш.

Цікава стаття, ще 20 років тому обіцяли що мануальне тестування зникне.

Було б круто побільше прикладів, бо пунктів багато, а прикладів нема

Все змінюється, а мануальне тестування досі потрібне :)

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

Підписатись на коментарі