На самому початку було тестування. Ніхто не розрізняв сценарне та дослідницьке тестування. У 1961 році Джеррі Вайнберг у книзі «Основи комп'ютерного програмування» в главі про тестування визначив його як в основі своїй дослідницьке і попросив з обережністю ставитися до його формалізації.
«Звичайно ж, складно змусити машину визначити, наскільки програма відповідає поставленим програмістом цілям без внесення величезного пласта інформації про цю мету. Якби у нас був простий спосіб надавати машині такого роду інформацію для перевірки, ми з таким же успіхом могли б повісити на машину і сам процес написання програми. Давайте не забувати про те, що складні логічні операції відбуваються за рахунок простих інструкцій, які виконує комп'ютер, і це не комп'ютеру вирішувати, що логічно при введенні/виведенні.»
Джеррі розумів різницю між машинною та людською працею. Але потім з'явилися формалізатори і всіх заплутали. Формалізатори, офіційно починаючи в 1972 році з публікації першої книги з тестування «Методи тестування програм», зосередилися на формах тестування, а не на його суті. Під формами ми маємо на увазі слова, зображення, рядки бітів, файли даних, блок-схеми та інші явні форми моделювання. Це все те, що ми можемо побачити, прочитати, на що можемо вказати, перенести з місця на місце, підрахувати, зберегти, повернути назад тощо. Так і підмиває поглянути на всі ці артефакти і вигукнути «Нехай буде тестування!» Але суть тестування — не в якомусь з цих артефактів. Тестування, на перетині людських процесів мислення та реалізації, дозволяє застосовувати ці артефакти. Артефакти тестування без людей — це як лікарні без лікарів і медсестер, возведені в ранг творів мистецтва: в кращому випадку, від них зовсім мало користі; в гіршому — вони представляють небезпеку для тих ні в чому не винних людей, які вирішать поправити там своє похитнуте здоров'я.
Ми не звинувачуємо інноваторів. На той момент вони мали справу з новими блискучими гіпотезами. Їх обмежувала лише небесна твердість! Але формалізація разом з механізацією незабаром вирвалися з лабораторії. За цим послідували божевільні розмови про «тестувальні фабрики» та спроектовані на швидку руку стандарти IEEE. Потім у «приличних» колах заговорили про сценарно-орієнтоване тестування. Неформальне тестування було прирівняно до непрофесійного тестування. Роль мислячих, чутливих, обмінюючихся інформацією людей була заміщена.
Джеймс вліз у бійку в 1987 році і намагався хоч якось вивести сенс з усього цього. Шляхом звичайного спостереження за процесом тестування він виявив, що «ситуативне» тестування значно краще справляється з виявленням багів, а сценарне тестування — ні. (Це відкриття далося не так вже й просто. Ми маємо на увазі, що неочевидні істини щодо тестування можуть бути доведені всім тим, що нас оточує, коли ми відкладемо фольклор убік і уважно подивимося, як люди справляються з щоденною рутиною.) Він почав писати і говорити про свої спостереження. Пройшовши кілька років роботи тест-менеджером, коли активно використовувалися тестові компілятори та інструменти для розробки, він дізнався, що Джем Канер придумав термін «дослідницьке тестування», щоб показати процес, протилежний сценарному тестуванню. У первісному визначенні, яке займало всього кілька сторінок, Джем ледь його окреслив, але він був першим, хто заговорив про проектування тестів під час їх виконання.
Так з'явилося те, що ми називаємо ІТ 1.0.
ІТ 1.0: Восстання
Тестування зі сценарієм і без нього — це різні поняття. Спочатку ми були практично поглинуті якістю тих ідей, які виникли під час несценарного тестування. Коли ми проводили ІТ, ми знаходили більше багів. Сам процес відчувався як якісне тестування. Тоді ми ще не розуміли, чому. Таким чином, перша ітерація дослідницького тестування як риторика і теорія була націлена на позбавлення від смиренної сорочки сценарію, щоб було більше місця для цього «кращого тестування». Ми стикалися з аргументами про те, що «ситуативне тестування неконтрольоване і неуправляєме, і займатися ним не варто». Ми виступили проти такого підходу, в подібному контексті дослідницьке тестування було певним особливим набором дій. Таким чином, крестоносці ІТ ставилися до нього як до техніки, тим самим виправдовуючи її використання. «Відкладіть убік свої сценарії і подивіться на продукт. Взаємодійте з ним! Шукайте баги!»
Велика частина світу досі розмірковує про дослідницьке тестування саме в такому ключі: як про техніку і чітко виражений порядок дій. Але ми помилилися з визначенням. Адже через нього ми загнали і спотворили суть дослідницького тестування. Спочатку все було нормально, але якщо розглядати ІТ як техніку, то в підсумку можна зайти в глухий кут. І в наші дні багато людей, навіть ті, хто написав книги про дослідницьке тестування, все ще з радістю дотримуються подібного визначення.
Ера ІТ 1.0 почала згасати в 1995 році. На той момент лише жменька людей в індустрії активно намагалася розвинути дослідницьке тестування в дисципліну, незважаючи на те, що всі тестери несвідомо або неформально слідували їй, як і завжди. Для тих кількох людей відмовитися від ІТ у темряві було неприпустимо.
ІТ 1.5: Тлумачення
У 90-х роках минулого століття виникле в Північній Америці невелике товариство тестувальників (яке згодом виросло у всесвітнє контекстно-орієнтоване (context-driven) товариство, торкнувшись також спільноти Agile-тестування) також боролося за чітке визначення навичок і процесів, необхідних у процесі тестування. Для цього вони застосували два дослідницькі методи. Першим був гуманістичний підхід до розробки програмного забезпечення, запропонований Джеррі Вайнбергом, який поєднував системне мислення з сімейною філософією. Другим було обґрунтування когнітивної науки Джема Канера і критичний раціоналізм Карла Поппера. Ця робота незабаром змусила нас переглянути наше уявлення про сценарне і дослідницьке тестування. Чому? Тому що наше розуміння глибинних основ самого тестування швидко розвивалося.
Коли Джеймс приєднався до ST Labs у 1995 році, він вперше був повністю залучений до розвитку бачення і методології тестування програмного забезпечення. Саме тоді вони з Джемом і почали своє п’ятнадцятирічне співробітництво. Тоді ж і сформувалася методологія швидкого тестування ПЗ. Однією з перших великих інновацій на цьому шляху була направляюча евристика (guideword heuristics) як практичний спосіб налаштування в реальному часі на тестувальне мислення з комплексною базовою моделлю тестувального процесу. Списки технік тестування і шаблонів ведення документації ще довго були в обігу, але з загальним розвитком термінології та когнітивних моделей для просунутого тестування програмного забезпечення ми почали розглядати дослідницьке тестування в новому світлі. Ми почали порівнювати і зіставляти важливі структури сценарного і дослідницького тестувань та зв’язки між ними, замість того, щоб бачити в них підходи, які мало чим відрізняються.
У 1996 році Джеймс створив перший тестувальний клас, названий «Дослідницьким тестуванням». Він схилявся до розробки шаблонного підходу і намагався включити його до класу. Він визначив саму компетенцію тестування.
У цей період Джеймс ще розділяв дослідницьке тестування і ситуативне тестування, чого ми більше не робимо. ІТ – це процес ситуативного тестування, у розрізі термінології: ситуативне означає «для цього; для такої-то мети». Він дуже намагався розділити кваліфіковане і некваліфіковане тестування, але зараз нам відомі куди більш підходящі для цього способи. Тепер ми визначаємо некваліфіковане ситуативне тестування як ІТ, адже некваліфіковане приготування їжі все ще є приготуванням їжі, а некваліфіковані (аматорські) танці залишаються танцями. Термін «дослідницьке тестування» описує характер діяльності, яка, до всього іншого, може бути і ситуативною.
У 1999 році Джеймсу було доручено визначити формалізований процес дослідницького тестування для Microsoft. Однак ідея «формалізованого ситуативного процесу» здавалася парадоксальною, що дало початок конфліктам, які були вирішені серією конструктивних суперечок між Джеймсом і Джемом. Ці дебати призвели до того, що ми назвемо ІТ 2.0.
Був також прогрес у тому, щоб зробити дослідницьке тестування більш дружнім до управління проектами. У 2000 році, натхненні роботою в Microsoft, Джеймс і Джон Бах розробили «Сесійне управління тестами» для відділу в Hewlett-Packard. Це була своєрідна узагальнена форма процесів в Microsoft, з метою створити вищий рівень врахування для в принципі неформальної дослідницької роботи. СУТ було покликане захистити дослідницьку роботу від нав'язливих формалізаторів, які звикли моделювати тестування в рамках тест-кейсів. В якомусь сенсі СУТ досить успішно допомагало людям зрозуміти, що дослідницька робота абсолютно керована. СУТ перетворювало позицію «не роби цього» в «добре, блоки дослідницького тестування також мають право на існування, як і тест-кейси.»
До 2000 року більшість тестувальників щось чули про дослідницьке тестування. Ми почали перетворювати світ на місце, безпечне для більш якісного тестування.
ІТ 2.0: Інтеграція
Ера ІТ 2.0 була найтривалішою, основаною на ключовому постулаті: дослідницько-сценарний континуум.
Це шкала, по якій тестування ранжується від повністю дослідницького до повністю сценарного. Уся тестувальна робота укладається в ці рамки. Прийнявши це, ми перестали говорити про дослідницьке тестування як про техніку — це в більшій мірі був підхід, що застосовувався до методик (або, як Джем любить висловлюватися, «стиль» тестування).
Ми могли розмірковувати про тестування в даному ключі, оскільки, на відміну від того, що було 10 років тому, тепер у нас сформувалося поняття про навички та елементи, необхідні для тестування. Це вже більше не було якесь «творче і містичне» дійство, ніби деякі люди вже з народження «інтуїтивно» розуміли сам процес. Ми розглядали тестування як вже пов'язані специфічні структури, моделі та когнітивні процеси, а ніяк не дослідження, тому ми вирішили, що можемо з користю для справи відокремити дослідження від тестування. Більшу частину з того, що в 90-х ми називали дослідницьким тестуванням, ми почали називати «вільним дослідницьким тестуванням».
До 2006 року ми прийшли до простого визначення ІТ: це одночасне вивчення, розробка тестів та виконання тестів. Щоб дати цій сфері імпульс, Джеймс і Джем у січні організували зустріч, названу Самітом з розвитку дослідницького тестування. Участь брали Джеймс Бах, Джонатан Бах, Скотт Барбер, Майкл Болтон, Елізабет Хендриксон, Джем Канер, Майк Келлі, Джонатан Кол, Джеймс Ліндсі та Роб Саборін. Готуючись до зустрічі, ми здійснили тривожне відкриття: кожен учасник саміту погоджувався з визначенням ІТ, але лише небагато зійшлися на тому, що це визначення означає. На той момент ми не знали, як позначити цей феномен, але тепер у спільноті контекстно-орієнтованого тестування його називають тіньовою угодою. Щоб кинути виклик тіньовій угоді та просунути краще розуміння ІТ, деякі з нас вирішили запозичити більш запам'ятовуване та детальне визначення, запропоноване Джемом і пізніше мавше кілька інтерпретацій: «стиль тестування, що вирізняється свободою та відповідальністю окремого тестера за постійну оптимізацію якості його роботи під час створення тестів, їх виконання, інтерпретації їх результатів разом із заздалегідь узгодженим навчанням, яке проходить паралельно з ходом розробки всього проєкту». Незалежно один від одного, Джон Бах і Майкл запропонували «свободу та відповідальність» як частину цього визначення.
Таким чином, ми прийшли до специфіки та гнучкої ідеї дослідження і його ролі в тестуванні. Дослідження можна розглядати по-різному: це пошук невідомого, творчий процес, робота без карти, здійснення дій, які ніхто більше не підприємствував, опір труднощам, спонтанне використання і так далі. З появою концепції континууму (яку Джон, брат Джеймса, назвав «ступенем свободи тестувальника») і обговореннями на конференції ExTRS, ми усвідомили, що більшість з цих різних понять дослідження вже займають центральну роль у тестуванні. Як додавати прикметник «дослідницьке», і як воно протиставляється «сценарному», кожен для себе визначав сам.
Усі наслідки нового визначення стали зрозумілі в наступні роки, а Джеймс і Майкл почали проводити навчання та надавати консультації з методології швидкого тестування програмного забезпечення. Тепер ми враховуємо, що під «дослідницьким тестуванням» ми маємо на увазі детальне, компетентне, самодостатнє тестування. Іншими словами, у всіх аспектах, що не стосуються засобів тестування, компетентне дослідницьке тестування мало чим відрізняється від компетентного сценарного тестування. Але засоби набагато важливіші за документацію, роздуми, витрачений час, інструменти, свідомі наміри. Ви можете проводити сценарне тестування, навіть не маючи під рукою якогось клаптика паперу (при сценарному тестуванні не вимагається буквального дотримання сценарію). Ви можете проводити сценарне тестування без попереднього планування (хтось, продумуючи ідею тесту, може в реальному часі говорити вам, що робити). Ви можете миттєво приступати до сценарного тестування (хтось міг передати вам скрипт, або, можливо, ви тільки що дописали свій сценарій). Ви можете йти за сценарієм з інструментами або без них (інструменти роблять тестування більш різноманітним, але не обов'язково більш заскриптованим). Ви цілком можете проводити сценарне тестування навіть неусвідомлено (можливо, вам і здається, що у вас є вільний вибір, але ваша модель поведінки і звички створили для вас невидиму в'язницю). Суть сценарного тестування полягає в тому, що тестувальник нічого не контролює — в більшій мірі, він сам знаходиться під контролем засобів або процесу. Нам знадобилися роки, щоб прийти до цієї простої, але життєво важливої ідеї!
У ті часи ми зосередилися на уявленні про те, які специфічні навички повинні застосовуватися при дослідницькому тестуванні. Джеймс і Джон Бахи створили довідник дослідницьких навичок і тактик, щоб відшліфувати специфіку і тонкощі для відповіді на питання «що конкретно дослідницьке є в дослідницькому тестуванні?»
У 2007 році стався ще один, хоч і повільний, але досить вагомий прорив. Все почалося з дрібниці: частково натхнений книгою «Форма дії», Джеймс почав розрізняти процеси, що вимагають людських міркувань і здорового глузду, і ті, де цього не вимагалося. Він назвав їх «усвідомленими» та «неусвідомленими» (вольний переклад понять sapient і non-sapient). Для нас це стало новою віхою: систематичне вивчення і розвиток неявних понять.
У 2009 році Майкл також до цього прийшов, розділивши тестування і перевірку. Тестування не може бути автоматизованим, а перевірка може бути автоматизована повністю. Перевірка включена в тестування. Спочатку Джеймс заперечував цьому, оскільки вже існувала концепція усвідомленого тестування, і розрізняти їх не було потреби. На його думку, перевірка була просто-напросто неусвідомленим тестуванням. Але, кілька років підряд застосовуючи ці ідеї під час консультацій і тренінгів, ми прийшли до висновку, що перевірка і тестування краще укладаються в голові, ніж усвідомленість і неусвідомленість. Через те, що «неусвідомленість» звучала як «тупість»; ми ніби засуджували перевірку, називаючи її неусвідомленою.
Звернули увагу, що для точного визначення термінології та підходів можуть знадобитися роки? Це ті інструменти та ідеї, які потрібні нам для того, щоб на практиці приймати оптимальні рішення. Але, як і нові ліки, що з'являються на ринку, іноді може знадобитися значний багаж досвіду, щоб зрозуміти не лише переваги, а й потенційно небезпечні побічні ефекти наших ідей та термінів. Це цілком пояснює, чому ті з нас, хто вже довгий час займається цим ремеслом, не завжди виявляють терпіння до своїх колег і клієнтів, які знизують плечима і кажуть, що «це всього лише терміни». Але для нашої діяльності подібні терміни означають різницю між зрозумілою комунікацією, яка є основою робочого процесу і дисципліни, та крихким фольклором, що змінюється з кожним новим натовпом слівечок, покликаних облечи в форму фантазії менеджменту.
ІТ 3.0 Нормалізація
У 2011 році соціолог Гаррі Коллінз почав змінювати все для нас. Це почалося з Майкла, який прочитав «Умалчувані та неявні знання». Ми швидко підсилилися на ясний стиль оповіді та блискучу інтуїцію Гаррі. Протягом багатьох років він вивчав вчених за роботою, і його ідеї про те, як відбувається науковий процес, ідеально підходять до того, що ми маємо на ниві тестування.
Ознайомившись з роботами Гаррі та його колег, ми зрозуміли, як взагалі говорити про умалчувані та неявні поняття, що дозволило нам визначити, що можна, а що не можна закодувати в сценарій або інші артефакти. Він розрізняв поведінку (спостережувані, піддатливі опису аспекти діяльності) та дії (поведінка з певною метою, що, до речі, надихнуло Джеймса розділяти усвідомлене і неусвідомлене тестування). Він розплутав відмінності між мімоморфічними діями (дії, які ми хочемо копіювати і повторювати в одному й тому ж вигляді раз за разом) та поліморфічними діями (дії, які ми повинні щоразу змінювати, щоб впоратися з соціальними умовами); цим він допоміг визначити обсяг і обмеження для автоматизації. Разом з Тревором Пінчем він написав книгу про те, з чого складається науковий процес; і ще одну, у співавторстві з Робом Евансом — про експертизу; ще одну — про те, як вчені вирішили оцінювати специфічні експериментальні результати.
Робота Гаррі допомогла надати структуру іншим ідеям, які ми зібрали по ходу справи.
- Ідеї МакЛюена про медіа та інструменти;
- Робота Карла Віка про осмислення;
- Поняття темпів Ванкатеша Рао, які призвели нас до понять про чіткість Джеймса С. Скотта;
- Усвідомлення (до якого ми прийшли завдяки невинному запитання тестувальника з банку «Берклі») того, що «дослідницько-сценарний континуум» насправді є «формальним континуумом». Іншими словами, формалізувати дії означає зробити їх більш сценарними;
- Усвідомлення важливого розмежування між спонтанним і консенсусним тестуванням, яке лише частково відображає те, чим займається тестувальник;
- Концепція «відповідального тестувальника» (в значенні тестувальника, який бере на себе повну і персональну відповідальність за якість своєї роботи);
- Поява важливого розмежування між перевіркою та тестуванням, яке замінило необхідність говорити про «усвідомленість»;
- Наступне перепридумування терміна «тестування» у глосарії швидкого тестування програмного забезпечення, щоб зробити його більш наочним.
Про останній пункт
ІТ 3.0 — поняття трохи парадоксальне, оскільки те, чим ми займаємося в рамках методології швидкого тестування ПЗ, відправляє на пенсію термін «дослідницьке тестування».
Так, все вірно, через 22 роки ми відправили цей термін на пенсію. Чому?
Тому що зараз ми визначаємо будь-яке тестування як дослідницьке. Тепер визначення тестування звучить так:
Тестування — це процес оцінки продукту шляхом його вивчення через дослідження та експериментування, що включає в себе: опитування, опрацювання, моделювання, спостереження, висновки, вихідну перевірку тощо.
Чи підходить сценарне тестування під це визначення? Під «сценарієм» ми маємо на увазі будь-яку контрольну систему або фактор, який впливає на ваше тестування і знаходиться поза сферою вашого вибору (навіть тимчасово). Це не стосується тільки отримуваних вами конкретних інструкцій, яким вам доводиться слідувати. Ваші схильності заганяють вас у сценарій. Як і ваше незнання. Сама організація робочого процесу також є сценарієм. Вибір дій, який ви здійснюєте і ніколи не переглядаєте — теж сценарій.
Визначивши тестування як дослідницький процес, ми переводимо сценарій у розряд гостей у нашій майстерні; потенційно корисний, але чужорідний елемент тестування, про який цікаво міркувати і застосовувати як тактичний маневр у певних ситуаціях. Хороший тестувальник не повинен нехтувати сценаріями, так само як і тесляр не нехтує складною технікою. Це вам або допоможе, або знищить, серйозні професіонали таке не ігнорують.
Ви займаєтеся тестуванням? Значить, ви вже займаєтеся дослідницьким тестуванням. Проводите сценарне тестування? Якщо ви проводите його відповідально, то ви також займаєтеся дослідницьким тестуванням зі сценаріями (і, можливо, з перевіркою). Якщо ви проводите тільки «сценарне тестування», значить, ви просто проводите немотивовану перевірку, і цілком можна стверджувати, що насправді ви не тестуєте. Ви намагаєтеся поводитися як машина, а не як відповідальний тестувальник.
ІТ 3.0 — це, своєрідно, пониження посади сценарію до техніки і підвищення дослідницького тестування до просто тестування.
Даний матеріал є перекладом статті Джеймса Баха і Майкла Болтона.
