Ну дуже проста ідея, яка підвищує ефективність тестування в рази

Як зазвичай будують процес тестування непросвітлені тест-менеджери?

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

Реліз.

Не працює основний функціонал.

Чому таке можливе?

1. Заклад всіх підряд помилок заважає розробці. Розробники витрачають свій час на виправлення мінорних помилок і вносять нові, часто більш серйозні.

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

3. Зворотній зв’язок за статусом зборки проекту надавалася розробникам із запізненням: замість критичних дефектів безперервно сипалися мінори (другорядних або дрібних багів).

4. Проектний закон «дохла риба» зіграв свою справу: всі учасники команди чудово розуміли, що протестувати все не можна, і це не могло не позначитися на якості роботи. А реалістичних цілей їм ніхто не поставив …

Що просвітлені тест-менеджери роблять по-іншому?

Що вони поміняють в першу чергу?

Пріоритети!

На самому початку XX століття Чарльз Шваб, президент компанії «Bethlehem Steel», зустрівся з консультантом у галузі суспільних відносин та управління Івом Лі, так як хотів поліпшити продуктивність своєї компанії. «Ми знаємо, що нам слід було б зробити, – пояснив Шваб, – але якщо ви можете показати нам кращий спосіб досягнення цього, то я вас із задоволенням вислухаю і заплачу будь-яку суму в межах розумного».

Лі сказав, що може допомогти і що це займе всього 20 хвилин. Він простягнув Швабу чистий аркуш паперу і сказав: «Напишіть шість найважливіших справ, які ви повинні зробити завтра». Шваб зробив, як йому було сказано.

«Тепер пронумеруйте їх відповідно до їх важливості для вас і для компанії». Коли Шваб закінчив, Лі продовжив: «А тепер покладіть цей папір в кишеню, і перше, що ви повинні зробити завтра вранці, це витягнути цей аркуш паперу і подивитися на пункт номер 1. Не дивіться на інші пункти – тільки на перший, і починайте працювати згідно з ним і до тих пір, поки він не буде повністю виконаний. Потім приступайте таким же чином до пункту 2, потім до пункту 3 і т. д., поки ваш робочий день не підійде до кінця. Не турбуйтеся, якщо встигнете впоратися тільки з одним або двома пунктами. Зате ви будете працювати над найважливішими. Без них ви все одно не виконали б інші. А не маючи чітко складеної системи, ви, ймовірно, витратили б у десять разів більше часу на їх завершення – і, можливо, виконували б їх не в порядку важливості.

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

Через кілька тижнів Шваб прислав Лі чек на 25.000 доларів разом з листом, де говорилося, що це самий корисний урок, який він коли-небудь отримував. І дуже скоро після цього компанія «Bethlehem Steel» стала найбільшим незалежним виробником сталі свого часу.

Ця проста ідея допомагає заощадити на великих проектах значно більше, ніж $25.000!

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

2. Завжди пріорітезуйте тести. Пріоритет тесту визначається як важливістю фічі, так і ймовірністю виникнення помилки (яка визначається емпірично, за результатами спілкування з розробниками, виходячи зі змін у функціоналі і т.д.)

3. Акцент на слові «документуйте»! .. Якщо післязавтра реліз, і все в запарці, то про усних домовленостях ніхто не згадає, і почнеться швидкісне натискання на кнопки. Вам правда потрібно знайти ще 10 мінорів? Або Вам важливіше перевірити працездатність основного функціонала?

4. Ніколи не давайте співробітникам об’ємні завдання, які можуть не вкластися в терміни. Ріжте їх на шматочки, пріоритезуйте і визначайте послідовність. В іншому випадку Ви ризикуєте знову ж зіткнутися з хаосом і законом «дохла риба», переклавши відповідальність на співробітників.

5. Створіть набір приймальних тестів. Що має працювати при релізі, що ОБОВ’ЯЗКОВО має працювати, а що – тільки бажано? Таким чином Ви завжди зможете оцінити трудовитрати на тестування релізної збірки проекту – а не час на безцільне проклікування інтерфейсу.

6. Маючи пріоритезовані перевірки, Ви завжди можете розраховувати на продуктивний діалог із керівництвом про розширення штату співробітників. Замість слів «Нам не вистачає співробітників» Ви зможете сказати «Нам не вистачає Х людиногодин для перевірки тестів з пріоритетом Y». Керівництво дуже рідко чує такі виразні висловлювання, тому Ваші шанси зростуть у рази 😉

Результат роботи не визначається витраченим на неї часом. Більш того, трудовитрати і результат взагалі ніяк не пов’язані, особливо у тестуванні.
Працюйте над результатом, а не над підвищенням обсягу робіт. І пріоритезація тестів – найперший і найголовніший крок в цьому напрямку.

Leave a Reply

Your email address will not be published.