Logos | 

Documentation for students on qc courSes

Oleg Zarevych

Зміст

Поняття Забезпечення Якості 1

Класифікація тестування 6

Рівні тестування 6

Види тестування 8

Методи тестування 11

Статичне та динамічне тестування 11

Підходи до тестування 11

Тестування "білої скриньки" 11

Тестування "чорної скриньки" 12

За часом проведення тестів 13

SDLC – Software development life cycle 14

Методології розробки ПЗ 18

MICROSOFT SOLUTIONS FRAMEWORK 19

RATIONAL UNIFIED PROCESS 20

Agile 20

KANBAN 21

Extreme Programming 22

Поняття Забезпечення Якості

Людина з аудиторії (А): я б із задоволенням використав все те, про що ви нам розповіли, але я не розумію, як це можна впровадити в мій QA відділ. Я: Яка ваша посада? А: QA аналітик Я: І що входить у ваші обов'язки? А: Я пишу тест плани і тест кейси, а також тестую наш продукт Я: А які ще QA посади є у вашій компанії? А: QA менеджер - він управляє процесом тестування Я: Ех ... (або що-небудь в цьому дусі)

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

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

Чи є тестування забезпеченням якості(QA)?

Ні, тестування - це не забезпечення якості

Для того щоб це пояснити, давайте вийдемо за рамки програмного забезпечення. У виробничому процесі фахівці з тестування вивчають яке надходить сировину або беруть продукцію прямо зі складального конвеєра і перевіряють її на відповідність стандартам. І в тому і в іншому випадку, вони перевіряють продукцію на відповідність документованим специфікаціям. Виробничі організації називають цей процес Контролем Якості (QC) і, як ви переконаєтеся пізніше, це абсолютно інший вид діяльності у порівнянні з Забезпеченням Якості

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

Сутність Контролю Якості можна назвати терміном «реагує», тобто його завдання - перевірити на відповідність специфікації після того, як компонент або продукт вже готовий; а також прийняти рішення, як з ним вчинити. Контроль Якості не забезпечує якість, він його перевіряє.

Тоді що таке Забезпечення Якості(QC)?

Повертаючись до фрази: «ви не можете впливати на якість готового продукту» виникає питання: а як якість потрапляє в продукт? Відповідь така: ви повинні його туди «впровадити».

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

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

Отже, якби ви брали участь в процесі Забезпечення Якості ПО, які б попереджувальні кроки ви б зробили, щоб переконатися, що створений продукт відповідає тим характеристикам якості, які вимагав Замовник?

Створення організації щодо забезпечення якості починається з наступних кроків. Їх відносно легко реалізувати і вони приносять дійсно відчутну користь:

• Домовтеся про використання загальних шаблонів

• Визначте послідовність дій

• Переконайтеся, що всі слідують встановленим процесам і стандартам

• Використовуйте досвід минулих проектів

• Аналізуйте інформацію про дефекти

• Застосовуйте те, чому навчилися

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

• Домовтеся про використання загальних шаблонів

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

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

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

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

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

Визначте послідовність дій

Зауважте, в заголовку не сказано, що вам необхідно використовувати стандарти або процеси. Це тому, що кожен з нас вже використовують будь-які встановлені процеси для повсякденних завдань. Хоча у вас напевно вже і є які-небудь напрацьовані процедури, ви повинні самі у себе запитати:

Чи відповідають вони вашим потребам?

Чи часто ви їх використовуєте у відповідних ситуаціях?

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

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

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

Друге питання звертає увагу на якість слідування встановленим процесам. Якщо ви виконуєте свої завдання неналежним чином і непослідовно, ігноруючи домовленості, то ніякої користі навіть від хороших процесів ви не отримаєте. Що означає послідовне використання процесів Забезпечення Якості? Це коли кожна людина чітко вміє їм слідувати, знає, коли і як це робити і суворо їх дотримується. Природно, що така поведінка очікується від усієї команди. «Ось як ми тут працюємо»

Використовуйте досвід минулих проектів

Ви можете називати це «робота над помилками», «постпрограмма» або як завгодно - але це один з найпотужніших інструментів попереджувального поліпшення якості вашої роботи. Ретроспектива - це окремо виділяється відрізок часу, з метою звернути свій погляд на пророблену роботу, вивчити отриманий досвід і задати собі наступні питання: "Що було добре і як зробити так само в майбутньому?" і "Що було не так і як цього можна уникнути?"

Незважаючи на те, що ретроспективи відносять до найкращих практик, я виявив, що використовуються вони вкрай рідко. Дві основні причини цього: «Складно зібрати всю команду на семінар по ретроспективі» і «Ми колись це робили, але це не приносило ніякої користі».

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

Члени проекту завжди доступні, тому що вони все ще закріплені за проектом

Щомісячний семінар за підсумками, наприклад, однієї фази проекту набагато легше запланувати і він займе всього близько години (замість цілого дня).

Весь отриманий досвід та напрацювання все ще свіжі в пам'яті, і навряд чи щось буде упущено

І найважливіше - отримані уроки можна застосувати до залишилася частини проекту.

Друга причина непопулярності ретроспектив - дуже часто вдається зібрати багато цікавої та корисної інформації, але немає ніякої можливості використовувати отримані дані на практиці в майбутніх проектах. (Це обговорюється в главі «Застосовуйте те, чому навчилися»).

Аналізуйте інформацію про дефекти

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

Інформація про дефекти, яка може бути корисна для поліпшення якості, включає наступні питання:

Що було не так? Вирішувати потрібно саму проблему, а не її симптоми. Наприклад, зациклення - це симптом, а зміна індексу циклу - це проблема.

Коли була створена ця проблема? Яка саме дія при розробці стало її джерелом? Це була проблема у вимогах? Проектуванні системи? Коді? Тестуванні? (Так, ми створюємо нові дефекти під час тестування, коли виправляємо старі).

Коли проблема була виявлена? Може вона і не була відразу ж усунена, але що нас цікавить, скільки вона існувала до того, як ми її виявили

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

Чи можна було виявити її раніше? Чи є який-небудь процес Контролю Якості, який міг би її виявити, будь він ефективніше?

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

Якого роду була ця проблема? Коли у вас величезна кількість дефектів, їх категоризація полегшує аналіз і навчання.

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