Проблеми тестування - це результати тестування

Переклад: Ольга Алифанова

В курсі Rapid Software Testing я даю студентам таку вправу: я прошу їх перелічити всі, що, з їхньої точки зору, ускладнює або уповільнює тестування. Їх відповіді, як правило, однотипні - я регулярно чую одні й ті ж варіації (приклад таких відповідей можна подивитися, наприклад, в обговоренні на Stack Exchange). Зазвичай це приблизно наступний перелік:

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

І, в плюс до вищепереліченого,

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

І вишенька на торті:

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

Як можна проаналізувати ці спостереження?

Ми можемо розцінювати їх, як проблеми тестування, але ми також можемо поглянути на них інакше - як на результати тестування.

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

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

Джеррі Вайнберг у своїй книзі "Perfect Software and other illusions about testing" зазначає, що те, що ми отримуємо в якості результату - це перш за все інформація. Якщо тестування, за словами Джеррі - це збір інформації з метою її передачі особам, які приймають рішення, то не можна залишати за бортом потенційно значущі спостереження.

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

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

Допомагаємо ми, як тестувальники, колегам мати уявлення про ризики - особливо про "Чорних лебедів" - які зазвичай асоціюються зі складністю?
Якщо люди уявляють собі ризики, чи звертають вони на них увагу? Панікують вони, або просто ігнорують в надії, що все владнається? Або щось інше?
Чи реагують люди спокійно і прагматично? Чи визнають вони складність продукту, намагаються з нею боротися?
Якщо складність продукту або процесу не можна знизити, робиться щось для того, щоб зробити продукт / процес простіше для розуміння?
Чи трапляється, що програмісти пишуть або змінюють код так швидко, що у них просто немає часу розібратися, що ж там насправді відбувається?
Якщо хтось вважає, що команді потрібно більше тестувальників, чому він так думає? (Я обговорював це питання кілька років тому)

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

Чи вважає хтось в команді, що тестування утруднено або займає багато часу? Хто?
Чому він так думає, які припущення привели його до цієї думки?
Чи не погіршується чи тестове покриття від того, що тестувальники витрачають багато часу на дослідження, локалізацію та оформлення багів? (Я писав про цю проблему раніше).
Виявляє чи тестування однакові патерни відмов?
Систематично ці відмови і їх патерни дивують програмістів?
Чи викликають невеликі зміни коду великі або важковловимий проблеми?
Чи добре програмісти розуміють внутрішні взаємозв'язку продукту? Чи необхідні продукту ці взаємозв'язки, або їх можна уникнути?
Роблять розробники якісь кроки для запобігання або попередження проблем, пов'язаних з інтерфейсами і взаємодіями?
Якщо автоматичні перевірки важко розробити і підтримувати, чи говорить ця ситуація про рівень професійних навичок тестувальників, як інтерфейсів автоматизації, або масштабі перевірок? Або вона сигналізує про щось ще?
Чи заважають нестабільні білди глибокому тестування?
Чи можна інтерпретувати нестабільні білди як знак того, що в продукті настільки багато серйозних проблем, що їх можна знайти навіть при поверхневому тестуванні?
Якщо після низки нестабільних білдів нарешті з'явився стабільний - наскільки він насправді стабільний?

Можливо, отримавши відповіді на ці питання, ми можемо поставити ще більше питань.

Як ці проблеми загрожують успіху продукту в короткостроковому і довгостроковому періодах?
Якщо тестування систематично виявляє патерни відмов і супутніх ризиків, що робить команда з цією інформацією?
Чи зобов'язані програмісти тільки і виключно надати код, або вони зобов'язані надати код з гарантією, що цей код робить те, що повинен (і не робить того, що не повинен), наскільки їм відомо? Наскільки щиро програмістам кращий другий варіант?
Змушує чи хтось програмістів витримувати терміни / обсяги робіт, в які вони насправді не можуть вкластися?
Чи можуть програмісти і тестувальники протистояти нав'язаним їм термінами і обсягами роботи, якщо ці терміни підвищують продуктові або проектні ризики?
Чи прислухається бізнес до побоювань команди? Чи знають вони про ризики, знайдених тестувальниками і розробниками? Коли команда розробки вказує на існуючі ризики, робить чи менеджмент / бізнес адекватні кроки у відповідь на це?
Чи працює команда в комфортному режимі, або продукт / проект серйозно задавлений складністю, внутрішніми взаємозв'язками, крихкістю і труднощами, які перебувають за межами можливостей розробки / тестування впоратися з ними?
Чи справді команда працює по Agile, дотримуючись маніфест Agile? Може, "гнучкість" використовується як карго-культ - практики і артефакти тільки маскують безглуздість проекту?

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

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