Переклад: Ольга Алифанова
Багато років я пропрацював в компаніях, де кожен був зобов'язаний сформулювати свою місію, щоб відповідати внутрішнім стандартам, і тому маю до місій деякий огиду. Однак моя команда все-таки сформулювала наступну "мета" нашого тестування:
"Забезпечити інформоване ухвалення рішень, виявляючи і ділячись своєчасної та релевантною інформацією про цінності рішень і ризики, супроводжуючих їх".
Це наша мета, це те завдання, яке ми вирішуємо. Ми тестуємо, щоб дізнатися щось корисне, знайти інформацію, яка допоможе зацікавленим особам прийняти правильне рішення. Так, це кілька загально, але це непогана стартова точка. Наша місія допомагає нам знайти нові шляхи вирішення проблем тестування.
Більш того, місія служить призмою, через яку ми дивимося на світ. Коли нам говорять "робіть так-то", ми озброюємось своєю місією і запитуємо, чи допоможуть ці дії досягти нашої мети, чи в правильному напрямку ми будемо рухатися?
Стів Джобс говорив: "Люди думають, що сконцентруватися - це сказати" так "тієї речі, на якій ви концентріруетесь. Це не так. Це означає, що ви повинні сказати" ні "сотні інших непоганих ідей. Інновація - це вміння сказати" ні "тисячі ідей". В областях, схожих з тестуванням, там, де процес ніколи не може бути повністю завершено, де кожне рішення - це ризик, подібна концентрація критична для успіху: ми повинні бути в змозі відмовитися від цілком розумних припущень (а також від будь-яких дурниць). Місія - прекрасний інструмент для дослідження припущень і пояснення, чому немає.
Цей підхід можна застосовувати і на проектному рівні. Я помітив, що іноді тестувальники починають міркувати, на які найважливіші питання їм необхідно знайти відповідь, і яка інформація їм потрібна від інших учасників проекту. Частенько я чув, як тестувальники розмовляють з іншими членами команди про цілі своїх проектів і те, яка інформація їм потрібна, щоб цих цілей досягти. Я зрозумів, що стратегія тестування - це не купка логістичних вказівок, а скоріше список відкриттів, які потрібно зробити тестувальника. Постановка інформаційних цілей і їх уточнення поступово стає невід'ємною частиною нашої роботи - не скрізь, але в досить великій кількості місць, щоб цей підхід поширювався і далі.
Однак тут потрібно застереження. Коли ви визначаєте інформаційні завдання проекту, легко скотитися в "закриті" питання на кшталт "Чи робить продукт це?", "Чи можемо ми завантажувати дані?". Найцікавіші питання, які необхідно задати, завжди відкриті: "Що і коли відбувається?", "Скільки часу це займе?", "Скільки користувачів додаток витримає перед тим, як впасти?". Не обмежуйте себе закритими питаннями. Невеликий рада: якщо ви переформуліруете мети тестування в формі питань, стежте, що не всі з них - закриті. Задавати відкриті питання дуже важливо.
На додаток до наших цілей, моя команда сформулювала вісім принципів тестування: контекст, відкриття, інтеграція, звітність, прозорість, інформаційна цінність, гнучкість і навчання.
Я не буду детально розписувати кожен з них. Їх цінність не стільки в самих концепціях або виборі слів, скільки в тому, як ми прийшли до їх формулювання. Ми витратили багато годин, опрацьовуючи їх і уточнюючи формулювання, і вони стали особистим досягненням для кожного з нас. Спільно розробляючи і уточнюючи наші принципи, ми виробили спільний словник, спільну мову. Ми розуміємо, про що говорить колега, якщо він заговорив про "прозорість" або "гнучкості", тому що ми вклали свого часу і свою працю, розбираючись, що саме означають для нас ці поняття. Тепер ми не шкодуємо сил, роз'яснюючи наші принципи іншим нашим колегам.
Принципи можуть бути цінностями або евристиками, що направляють мислення команди. Вони необов'язково повинні бути нормативними або деталізованими, вони можуть бути відкриті для різних інтерпретацій, і навіть можуть один одному суперечити (такі протиріччя покажуть вам, що ви на правильному шляху). Якщо все так - значить, вони змушують людину, що використовує ці поняття, ДУМАТИ, перш ніж застосувати їх.
Альтернатива принципам - правила: механістичні формули, явні інструкції. Заповни шаблон, використовуй цю техніку, відзнач цей чекбокс. Принципи - це зовсім інша справа. Це ключовий фактор для розширення можливостей тестувальника. За допомогою принципів ми регулюємо систему тестування, а не контролюємо її, а у принципів непогана репутація в області регулювання.
- Безліч докладних правил - важка ноша для галузі.
- Жоден набір правил не в змозі передбачити мінливі обставини. Швидше навпаки, правила гальмують інновації або навіть роблять їх неможливими. Вони ретроспективний - тобто схильні вирішувати вчорашні проблеми замість того, щоб розглядати сьогоднішні або завтрашні.
- Докладні правила вводять в спокусу дотримання букви правил замість досягнення цілей регулювання, а "чітко слідувати правилам" зовсім не обов'язково означає "робити те, що потрібно зробити".
- Коли в ходу правила, люди намагаються дотримуватися правил, а не слідувати потрібної мети.
- На відміну від принципів, правила заважають думати і знижують професіоналізм.
Отже, чи хочете ви навантажити тестувальників купою правил (стандартів?), Розписуючи, як їм слід поводитися, чи хочете ви угробити їх професіоналізм і змусити тупо отримувати вказівки і слухатися розпоряджень? Або вам все ж потрібні професіонали, здатні думати головою, приймати самостійні рішення, адаптуватися до змін і впроваджувати щось нове в практики тестування? Якщо ви за професіоналізм, варто подумати про принципи замість правил.
Тут варто зауважити, що Державний Експертний Центр (SEC) вважає, що регулювання, засноване на принципах, не виключає правила як клас. У вищезгаданій бюджетній сфері Великобританії принципи і правила співіснують. Фокус тут в тому, що вони знайшли потрібний баланс між ними. У контексті нашої роботи ми приділяємо багато уваги принципам, але ряд правил у нас все ж існує: наприклад, правила використання даних в тестуванні. Непорушні закони є і у нас.
Пошук потрібного балансу між принципами і правилами в найбільших проектах і нововведення в компанії був найцікавішою частиною моєї роботи за останній рік. В кожному окремому випадку ми починали з довжелезного списку правил, прагнучи до його повноті, а потім, поступово з огляду на можливі варіації в різних проектах, стверджували список принципів, доповнюючи його мінімально коротким набором правил.
Ми віримо, що тестування має бути організовано на тому ж рівні, на якому здійснюється передача продукту замовнику. Люди "в матеріалі" найкращим чином підходять для прийняття правильних рішень щодо використовуваних практик. В результаті, ми не обговорюємо окремі практики на цьому рівні роботи, щоб уникнути нав'язування практик проекту. У нас немає стандартів, документації практик тестування і шаблонів. Команди, відповідальні за тестування, вільні у виборі підходу, і він залежить тільки від їх потреб і завдань.
Не можна сказати, що це легко і просто. Я чітко пояснив колегам, що команди відповідальні за якість свого тестування і повинні забезпечувати прозорість своїх дій. Це дуже важливий момент: розширення повноважень працює тільки тоді, коли в командах є довіра.
Це очевидно, але зазвичай на це не звертають уваги. Багато великих компаній засновані на недовірі: проекти управляються за допомогою розпоряджень і контролю, тому що довіри немає; постачальників зобов'язують відповідати стандартам через відсутність довіри до них; впроваджуються докладні зведення правил, тому що - знову ж - довіру до колективу відсутня. Якщо ви хочете щось змінити, вам потрібно навчитися довіряти. Довіра - це функція звітності та прозорості.
Ми розглядаємо тестування як послугу, і ми відповідальні перед замовником за якість нашого тестування. Ми визначаємо якість тестування в термінах інформаційної цінності - інформація, яку ми надаємо, корисна, тобто надана вчасно, має сенс і може бути застосована. Ми вважаємо, що інформація не має цінності, якщо їй не діляться, тому ми забезпечуємо прозорість прогресу і обмежень нашого тестування.
Уважний Новомосковсктель напевно помітив, що тут наведено три наших принципу - звітність, прозорість і інформаційна цінність. Передумови для розширення прав і довіри міцно впроваджені в нашу роботу.
Люди. Досить складно визначити, яка саме інформація потрібна людям. Складно також оцінити продукт. І зовсім складно донести свої знахідки до інших зацікавлених осіб у зрозумілій їм формі.
Тестувати взагалі непросто. Це досить складно і без нав'язаних зверху безглуздих, негнучких правил! Але ми також повинні визнати, що перейти до розширення прав важко, якщо колектив довгий час жив розпорядженнями і контролем.
Так народилося наше співтовариство тестувальників. Щоб зламати культуру, засновану на правилах, нам потрібно було оточення, в якому люди з задоволенням діляться ідеями і провокують колег на подвиги. Нам потрібна була середа, де люди можуть попросити допомоги і підтримати товаришів. Якщо наші люди впевнені в собі і планують рости як тестувальники, то завдання керівництва - забезпечити підтримку на цьому шляху. Нерозумно перекидатися на трапеції без натягнутою знизу сітки безпеки. Я вважаю за краще упевнитися, що у моїх тестувальників ця сітка є. Це нова для мене область, і я планую серйозно розвивати її в цьому році.
Це було вражаюче подорож. Ми навчилися поважати людей настільки, щоб довірити їм можливість стати прекрасними тестувальниками і звільнити їх від традиційних наказів і контролю, які заважали їм працювати. Парадокс розширення прав передбачає, що ми не можемо вплинути на це безпосередньо, але можемо усунути перешкоди і створити умови, в яких люди зроблять все самі.