Перезавантаження полювання на баги. 5 способів дати копняка тестуванню.
Навчіться застосовувати ці швидкі та ефективні лайвгаки для “полювання на баги”!
“Іноді, зробивши щось інакше вже перед початком тестування, ви можете знайти приховані проблеми. Це як шукати загублені іграшки під диваном”
Ви тестувальник початківець? Робота над додатком з командою з п’яти або більше розробників здається надійним способом створити продукт без помилок. Але правда полягає в тому, що кількість розробників, які працюють над проєктом, не має ніякого впливу на кількості багів, зрештою. Незалежно від того, наскільки досвідченим є розробник, баги траплятимуться. Не існує такого поняття, як “продукт без помилок”.
Через деякий час розробники уже знають, які типи багів ви зазвичай знаходите, і, як правило, ви бачите менше однотипових багів в продукті, ніж бачили лише декілька спринтів тому. Однак це не привід спочивати на лаврах. Робота тестувальника полягає в тому, щоб постійно знаходити нові способи виявлення помилок до того, як вони потраплять у продакшн.
Не кожна стратегія “полювання на баги” вимагає від вас вдосконалення ваших здібностей як технічного тестувальника, хоча вдосконалення в цій сфері повинно бути метою для вас. Іноді кілька способів, які здаються швидкими лайвгаками, можуть підвищити вашу майстерність у “полюванні на баги”.
Ось кілька простих способів, які я вважаю корисними.
Щоразу йти різними шляхами: мавпяче тестування (Monkey Testing)
Ви коли-небудь бачили, як ваші розробники створюють нову функцію лише для того, щоб зламати іншу, вже наявну? Швидше за все, ви бачили або побачите з часом.
Зрештою, якщо є помилки в основних функціях продукту, нових чи старих, ваша команда (включно з вами) не виконала те, що від неї вимагалося.
Помилка: Ви тестуєте одну функцію за раз, проводячи достатньо тестування, щоб переконатися, що ця функція в ізоляції не має дефектів.
Що можна спробувати? Після того, як ви протестували функцію ізольовано, увійдіть у додаток з різних точок “шляху користувача”, зупиняючись на функції, яку ви тестуєте. Це варіація того, що дехто називає “мавпячим тестуванням”, коли тестувальник “вкидає” випадкові вхідні дані у додаток, що тестується, як мавпа, що хаотично тицяє в друкарську машинку.
Швидке тестування vs Пошук помилок: Знайти баланс
Іноді тестування схоже на перегони в шльопанцях. Ти хочеш бігти, але в підсумку падаєш обличчям вниз.
Бути швидким — це добре, але поспіх може призвести до пропуску навіть очевидних помилок.
Помилка: Ви намагаєтеся йти в ногу з розробкою без обговорення з командою того, що вам потрібно як тестувальнику. В результаті ви скорочуєте кількість своїх тестів. Мовчання тут НЕ є золотом.
Що можна спробувати? Подивіться, як ви можете покращити свої тест плани й скільки часу знадобиться для запуску нових тест кейсів. Потім обговоріть з розробниками та продукт менеджером, як додати часові буфери для тестування до їхніх графіків.
Створення правильної речі — це командна робота.
Будьте ласкаві до себе (і до свого продукту): Робіть перерви
Припустимо, у вас щільні дедлайни, і ви боїтеся не використати весь доступний на тестування час. Тому ви тестуєте, тестуєте і ще раз тестуєте.
Відчуваєте втому? Занадто багато завдань під рукою? Перемикаєтеся між великою кількістю завдань і тестів?
Помилка: Ви тестували продукт безперервно, або вам так здавалося. Ви відчували, що втомлюєтеся і розчаровуєтеся. А потім 50% функцій потрапляли у продакшн з помилками.
Що можна спробувати? Робіть невелику перерву після кожного тесту. Це допоможе зменшити втому і тримати під контролем ваші когнітивні упередження. (Так, тестувальники також мають ці упередження).
Визначте період часу у кожному дні, коли ви найбільш креативні. Це може бути рано вранці, може бути пізно ввечері після чаю. Скористайтеся цими періодами “підйому”: саме тоді ви знайдете найбільше помилок.
Це найскладніша порада, якої важко дотримуватися, але вона дійсно може окупитися. Пам’ятайте: якщо ви втомилися, ви не побачите помилок. Краще зробити перерву і почати з чистого аркуша.
Похід у (когнітивний) спортзал: Розв’язуємо головоломки
Звучить безглуздо, я знаю. Але корисно тримати свій розум відкритим до нових горизонтів.
Коли ми починаємо тестувати продукт, через місяць він може здатися застарілим. Ніяких нових функцій не було додано, але все ж таки, нові помилки прослизають у продакшн.
Помилка: ви застрягли в когнітивній колії й не можете знайти вихід.
Що можна спробувати? Розв’язування головоломок допомагає залишатися креативним і гнучким. Якщо ви не можете іноді мислити нестандартно, то з тестуванням покінчено.
Ось кілька моїх улюблених сайтів з головоломками: blackboxpuzzles, testingchallenge
Наша пам’ять підводить! Використовуйте чеклісти для тестування
Ви грали в GTA Vice City? Якщо так, то ви, напевно, вже створювали шпаргалку.
Навіщо ви зробили шпаргалку, якщо вже знаєте чіт-коди? Тому, що це давало майже миттєвий доступ до кодів і не доводилося покладатися на пам’ять.
Ця ж техніка може бути корисною і в тестуванні. І неважливо, чи є у вас Jira тікет, чи інструмент з набором тестів або списком тест кейсів.
Помилка: Люди іноді не мають ментального доступу до всього, що зберігається в пам’яті, особливо під час виконання нового завдання.
Що можна спробувати? Візьміть ручку та папір і запишіть, що ви збираєтеся тестувати. Простого маркованого списку слів може бути достатньо. Ось хороший приклад: A Checklist for Login Page Testing.
На завершення
Іноді, зробивши щось інакше перед початком тестування, ви можете знайти приховані проблеми. Це як шукати загублені іграшки під диваном.
Використання техніки “лайвгакерського” тестування може допомогти вам вийти за рамки підготовленого тест плану і знайти критичні баги. Ці швидкі лайвгаки можуть допомогти покращити тестування настільки, що ви почнете кидати собі виклик знаходити нові помилки вже через 10 хвилин після початку тестування.
Чи є у вас подібні лайвгаки, які покращили ваше тестування? Поділіться ними з нами.
Перекладено та адаптовано на основі оригіналу: редакція
Джерело: ministryoftesting.com (оригінал допису)
