Запровадження
Доброго дня, хабрівчани. Вирішував я тут недавно тестове завдання на вакансію QA Lead для однієї фінтех компанії. Перше завдання, скласти тест-план з повним чек-листом та прикладами тест-кейсів для перевірки електричного чайника, вирішується тривіально:
Найкращого тест-плану з повним чек-листом придумати складно.
А ось друга частина виявилася питанням: "Чи існують якісь проблеми, спільні для всіх тестувальників, які заважають працювати з більшою ефективністю?"
Перше, що спало на думку: перерахувати всі більш-менш помітні проблеми, з якими стикався при тестуванні, відсіяти дріб'язок, інше узагальнити. Але швидко зрозумів, що індуктивний метод відповість на питання, що стосується не всіх, а, в кращому випадку, лише більшості тестувальників. Тому вирішив підійти з іншого боку, дедуктивного, і ось що вийшло.
визначення
Перше, що я зазвичай роблю, вирішуючи нове завдання, це намагаюся зрозуміти про що вона взагалі, а для цього треба зрозуміти зміст слів, якими вона поставлена. Ключові слова, у яких треба розібратися, такі:
- проблема
- тестувальник
- робота тестувальника
- ефективність роботи тестувальника
Звернемося до вікіпедії та здорового глузду:
(інш.-грец. πρόβλημα) у широкому значенні — складне теоретичне або практичне питання, що вимагає вивчення, вирішення; в науці - суперечлива ситуація, яка виступає у вигляді протилежних позицій у поясненні будь-яких явищ, об'єктів, процесів і вимагає адекватної теорії для її вирішення; у житті проблема формулюється у зрозумілому для людей вигляді "знаю що, не знаю як", тобто відомо, що потрібно отримати, але невідомо, як це зробити. Походить від пізн. лат. problēma, з грец. πρόβλημα «кинуте вперед, поставлене попереду»; від προβάλλω «кидати вперед, виставляти собі; звинувачувати».
Сенсу небагато, по суті, "проблема" = "що-завгодно, з чим треба розібратися".
— фахівець (на види розділяти не будемо, оскільки нас цікавлять усі тестувальники), який бере участь у тестуванні компонента чи системи, результатом діяльності якого є:
- Комплекс заходів що відноситься до тестування.
(лат. effectivus) - співвідношення між досягнутим результатом та використаними ресурсами (: 2015).
- Наслідок ланцюжка (черги) дій (підсумок) або подій, виражених якісно або кількісно. Можливі результати включають перевагу, незручність, вигоду, втрату, цінність та перемогу.
Як і з "проблемою" сенсу мало: щось, що вийшло в результаті роботи.
— кількісно вимірювана можливість виконання будь-якої діяльності людини чи людей; умови, що дозволяють за допомогою певних перетворень отримати бажаний результат. Тестувальник — людина, а відповідно до теорії вітальних ресурсів кожна людина є володарем чотирьох економічних активів:
грошових коштів (дохід) - ресурс поновлюваний;
енергії (життєва сила) - ресурс частково відновлюваний;
часу - ресурс фіксований і принципово невідновлюваний;
знань (інформації) — відновлюваний ресурс, це частина людського капіталу, яка може і наростати, і руйнуватися.
Хочу відзначити, що визначення ефективності в нашому випадку не зовсім коректне, оскільки чим більше знань ми використовуємо, тим виходить ефективність. Тому я б перевизначив ефективність як “співвідношення між досягнутим результатом та витраченими ресурсами”. Тоді все коректно: знання під час роботи не витрачаються, але зменшують витрати єдиного принципово невідновлюваного ресурсу тестувальника його часу.
Рішення
Отже, шукаємо глобальні проблеми тестувальників, які погіршують ефективність їхньої роботи.
Найбільш значущим ресурсом, який витрачається на роботу тестувальника є його час (інші так чи інакше можна до нього привести), а для того, щоб ми могли говорити про коректний розрахунок ефективності, треба і результат привести до часу.
Для цього розглянемо систему, життєздатність якої тестувальник забезпечує своєю роботою. Такою системою є проект, до команди якого входить тестувальник. Життєвий цикл проекту можна грубо уявити наступним алгоритмом:
- Робота з вимогами
- Формування технічного завдання
- Розробка
- Тестування
- Випуск у виробництво
- Підтримка (goto п.1)
При цьому весь проект можна рекурсивно розбити на підпроекти (фічі) з тим самим життєвим циклом.
З погляду проекту, ефективність його реалізації тим більша, чим менше часу на нього витрачено.
Таким чином, ми приходимо до визначення максимально можливої ефективності тестувальника з точки зору проекту – це такий стан проекту, коли час на тестування дорівнює нулю. А загальною проблемою для всіх випробувачів є неможливість цього часу досягти.
Як із цим бути?
Висновки цілком очевидні і багатьма давно використовуються:
- Розробка та тестування повинні починатися і закінчуватися практично одночасно (цим зазвичай займається відділ ). Ідеальний варіант, коли вся функціональність, що розробляється, до моменту готовності вже покрита автотестами, організованими в регресійне (а по можливості і передкомітне) тестування за допомогою якого-небудь .
- Чим більше у проекті фіч (що він складніше) тим більше часу доведеться витрачати на перевірку того, що нова функціональність не поламала старої. Звідси чим складніший проект — тим більше потрібна автоматизація. .
- Щоразу, коли ми пропускаємо баг у продакшн, і користувач його знаходить, нам доводиться витрачати додатковий час на проходження за життєвим циклом проекту починаючи з п.1 (Робота з вимогами, в даному випадку, користувачів). Так як причини пропуску бага в загальному випадку невідомі, нам залишається лише один шлях оптимізації — кожен, знайдений користувачами баг, повинен бути включений до регресійного тестування, щоб бути впевненим, що він більше не з'явиться.
Джерело: habr.com