Контекстне тестування ПО: практичні рекомендації, Різне, Програмування, статті

Якийсь час назад, я і не підозрював про те, що існує таке поняття як Context-Driven Testing, буду називати його контекстне Тестуванням (або КТ для стислості). Хоча я і сказав, що не підозрював про це, але як виявилося, протягом всієї моєї кар’єри інженера з тестування, я керувався принципами, проголошеними такими відомими фахівцями в тестуванні ПО як Cem Kaner, James Bach і Bret Pettichord, які є авторами і проповідниками КТ.


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


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


1. Школи тестування


Для повного розуміння того, що таке КТ, необхідно дізнатися звідки з’явилося таке поняття і які є альтернативи. Матеріал цієї глави заснований на презентації:


“Schools of Software Testing” (www.io.com/~wazmo/papers/four_schools.pdf)
Автор: Bret Pettichord (Copyright © 2003-2007)


Автор вищевказаної презентації, виділив 5 шкіл тестування. Поділ на школи тестування було вироблено виходячи з:



Школи не базуються ні на будь-яких спіцефіческіх методах тестування, ні на загальній теоретичній основі або методології.


Ось ці 5 шкіл:


Аналітична школа (Analytic School) . Базується на аналітичному і логіко-математичному підході до тестування. Приклад – оцінка покриття коду тестами (code coverage)


Стандартна школа (Standard School) . Базується на чіткому плануванні, відстеження прогресу і перевірці правильності (validation) розробляється ПО. Приклад – матриця простежуваності (traceability matrix)


Школа забезпечення якості (Quality School) . Базується на процесах, встановлених правилах (policies) і метриках. Приклад – критерії закінчення тестування, метрики і аудит вихідного коду.


Школа “гнучкого” тестування (Agile School aka Example-driven School) . Базується на перевірці користувальницьких сценаріїв (user “s story) і наборі автоматизованих регресійних тестів. Приклад – розробка через тестування (test driven development).


Школа контекстного тестування (Context-Driven School) . Базується на поточних потребах проекту, предметної області та направлено на надання інформації про поточний стан справ у проекті. Приклад – дослідне тестування (exploratory testing).


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


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


2. Базові принципи КТ


За матеріалами: www.context-driven-testing.com/Автори: Cem Kaner, James Bach


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


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


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


Люди працюють над проектом – найцінніша складова проектного контексту. Запитуйте у колег, а що в даний конкретний момент важливіше всього. Чим ви максимально ефективно можете допомогти. Дізнавайтесь у розробників як це працює і чому це працює саме так. Не кажіть програмісту, який попросив вас прогнати пару тестів на приватній збірці, що не будете цього робити бо за планом ви іншими справами повинні займатися. Може бути, в даний момент, вивчити таку приватну збірку – це найактуальніша задача і ви заощадите купу часу собі і іншим в майбутньому.


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


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


Гарне тестування – напружений інтелектуальний процес. Не чекайте, що прийде хтось і скаже вам що треба робити (хоча і будуть приходити). Пропонуйте послуги з тестування. Придумуйте нові послуги, нові тести. Складіть свою думку про якість продукту, про те яке воно повинно бути. Підштовхуйте колег до того, щоб досягти такого рівня якості. Не перестарайтеся – пам’ятайте: ідеальних рішень не буває – до вашого продукту це теж стосується.


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


3. Контекст – що це?


Тепер, коли ми ознайомилися з принципами КТ прийшов час зрозуміти, а що ж таке цей контекст, про який йде мова.


Контекст – Це сукупність знань про розроблюваний проект в певний момент часу.


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


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


Помилковий контекст. Застарілі дані, неправильно зрозуміла або двозначна інформація. Що-небудь бажане, що видається за дійсне. Справжній стан справ не може бути таким, тільки тому, що хтось хоче, що б воно було таким. Слід уникати будь-якого спотворення або приховування інформації. Не кажучи про навмисне спотворення фактів. Викрити невірні знання – одне із завдань тестування.


Прихований контекст. Інформація, з якихось причин, не доступна зацікавленим особам. Можливо втрачена ланцюжок логічних висновків, непомічені зміни в специфікаціях, розбіжність поточної реалізації з її істинними цілями. Завдання людей працюють у тестуванні знаходити такий прихований контекст і негайно інформувати всіх, кому це необхідно знати.


4. КТ і процес тестування


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


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


Другий момент, який допоможе зберегти ресурси і дозволити проводити більше дослідів – це тестова документація. Давно пора перестати описувати тести так, щоб їх міг прогнати “людина зі сторони”. Не буде “Людина зі сторони” тестувати ваш продукт. Ніколи не буде. Такі надзвичайно докладні описи тестів шкідливі з кількох причин – а) їх у 99% випадків будуть виконувати як є, не дивлячись на всі боки; б) будь-яке мінімальне зміна в продукті зазвичай тягне за собою зміну опису тесту; в) вони потребують більше ресурсів на створення; г) вони не дають виконавцю “включити голову”.


Третя область де, ймовірно, можна виграти час – звіти про тестування. Звіти повинні бути змістовними та корисними. Не варто писати нікому непотрібні звіти, особливо робити це регулярно. Інформація міститься в звіті за результатами роботи, в першу чергу повинна бути корисна співробітникам відділу тестування. Ні керівництву, ні програмістам не потрібна дуже докладна інформація. Таким чином, максимальний рівень деталізації звітів повинен регулюватися потребами самих інженерів, які проводять експерименти.


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


Останнє, і напевно найголовніше, це команда. Процес повинен визначатися тими людьми, які його дотримуються. Чим рівніше рівень професіоналізму в команді тестування, тим ефективніше можна організувати процес тестування. Найбільш важливі якості це самодисципліна і відповідальність кожного з учасників.


5. КТ і процес розробки


Команда тестування – команда, що надає послуги іншим учасникам розробки. При цьому всі задіяні в розробку (включаючи тестування) люди повинні переслідувати єдину мету – вчасно випустити якісний продукт, вирішальний поставлені завдання. Ось декілька порад основним учасникам процесу розробки.


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


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


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


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


6. КТ – стиль життя думаючого інженера з тестування ПО


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


7. Як навчитися КТ


Так як я не займаюся професійним навчанням, а сам вчився тільки на практиці, то можу навести ще кілька порад для самонавчання, якими я і керуюсь:



8. Висновок


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


Хіба ситуація, коли команда тестування дізнається про якісь зміни останньої є винятковою? Хіба не вважається, що думкою інженера з тестування можна, в певний момент, знехтувати? Хіба не загальноприйнята практика, що краще набрати побільше низькооплачуваних і недосвідчених співробітників в тестування, бо вважається що для цієї роботи ні розуму ні досвіду багато не потрібно? Хіба недбайливих розробників не переводять у “заслання” в відділ тестування? Хіба керівники не обговорюють ситуації, коли вони не розуміють, навіщо їм взагалі це тестування, що вони там взагалі роблять? Можна продовжувати список питань “хіба не …”. Сумно, але факт, що все перераховане досить часто зустрічається. А найсумніше в тому, що люди працюють в тестуванні, найчастіше, самі підтверджують сумніви в складності і важливості їх роботи, просто тому, що роблять не те, що від них вимагається.


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*