Елізабет Хендріксон (Elisabeth Hendrickson)
Ця стаття ставить дуже важливе питання «Чого тут немає, що мало б бути?». Для виявлення «дір проектування і вимог» застосовується ідея, схожа на виявлення чорних дір. Наприклад, часто існують залежності між кількістю помилок, які стосуються певної області, і тим чи була ця область повністю протестована. Також діри можуть бути в тому, що показують типи помилок. Хендріксон готує грунт для пошуку і радить як «шукати там, де нічого немає».
«Тату, як знаходять чорні діри?»
Я задала це питання багато років тому під час прогулянки з моїм батьком ясної зимової ночі, зачарована зірками. Батько подивився на мене, його руки були засунуті в кишені, наше дихання було видно в холодному повітрі, і посміхнувся. «Справді, дитинко, так як вони не можуть бачити те, чого немає, вони шукають там, де багато пустоти (нічого)».
Ідея така: пошук чогось або шляхом перегляду порожнечі.
Ця стаття про те, як я шукала дірки в проектуванні і вимогах. Якщо при проектуванні нічого не говориться про безпеку, ніхто не подумає про неї. Якщо немає вимог від організатора, то, ймовірно, організатор не задіяний у процесі формування вимог.
Перший спосіб - це спостереження за результатами тестування. Якщо з певної областю не зіставлені помилки, це говорить про те, що дана область не була протестована. Звичайно, якщо з деякою областю зіставлять багато помилок, це не означає, що вона добре протестована. Так що я також дивлюся на тип помилок. Досягають чи вони серця функціональності або вони всі поверхневі і несерйозні. Чи відносяться помилки до вхідних даних, переповнення буфера або довжині шляху? Я шукаю вказівку на те, що в нашому тестуванні існують дірки - види помилок, які ще не знайдені.
Шукати відсутність інформації не легко. Ви повинні знати, що ви очікуєте побачити, до того як повідомте, що щось пропущено. Це означає, що вам необхідний інтелектуальний список категорій помилок, які ви можете очікувати знайти в тестованому додатку: проблеми спільного доступу, помилки спотворення даних, тимчасові питання і т.д. Ваш список залежить від тестованого додатки.
Вам також необхідно в подробицях знати те, що вже переглянуто. Якщо ви переглядає помилки, знайдені раніше - читаєте їх перш ніж рахувати - ви можете шукати шаблони у тестуванні, які ведуть до пошуку помилок. Тільки підрахунок недостатній.
У міру розвитку проекту пошук шаблонів пропущених помилок стає більш важким. Чим більше прив'язаних до областей помилок, тим важче позначати області, в яких спостерігається недолік помилок. І ще це час, коли воно стає критичним. Ви майже закінчили. Незабаром, дещо - хто з Виконавчого рівня почне запитувати вас, чому ви до цих пір не закінчили. Наступна річ, про яку ви знаєте, це те, що ПЗ викладена і / або не викладене на Web. Це не підходящий час для з'ясування, що ніхто не намагається поповнювати каталог з двох браузерів спільно.
Один шлях для пошуку дірок тестування.
Зведіть помилки в матрицю, як вони зберігаються в системі відслідковування помилок. Уздовж однієї сторони розділіть тестоване додаток на області. Далі зверху для всіх областей розмістіть список всіх категорій тестів. Наприклад, якщо ви тестуєте програму для редагування, то вздовж сторони можуть розміщуватися Засіб Малювання, Засіб введення тексту, вставку картинок, Друк і т.д.
Категорії зверху можуть включати Скасування введення, Drag and Drop, Міжнародні Символи, Нестача пам'яті і т.д. Ви можете мати кілька десятків елементів на бік, бажано, не більше тридцяти. (Якщо осередків буде занадто мало, ви не зможете отримувати необхідну інформацію. Якщо занадто багато, матриця стане дуже громіздкою). Всі тоді хто - то додає помилки, робіть позначки у відповідних осередках вашої матриці. Ви шукайте осередки без відміток.
Ця матриця легке засіб для вашого власного пошуку чорних дір. Не намагайтеся занести занадто багато інформації в кожну клітинку. Навіть спроба стиснення числа помилок може виявитися надто великою. Якщо ви намагаєтеся відстежувати більше інформації, ніж одна позначка, підтримання матриці в актуальному стані стає скрутним і, можливо, ви не зможете це зробити. Якщо ви використовуєте позначки у клітинці тільки для зберігання кількості помилок, п'яти або десяти хвилин на день для читання помилок і позначок про них в осередках буде достатньо.
Місяці на проекті, і у вас є карта, яка показує кількість помилок по областях ПЗ та категорії тестів. Зараз ви можете знаходити діри. Додатковий бонус: Коли проект закінчений, матриця може також забезпечувати інформацію про слабкі областях ПО, так що ці області можуть бути поліпшені у майбутніх проектах. Кожна особливість мала проблеми з граничними значеннями?
Пошук - чого, шляхом перегляду порожнечі - важкі і час поглинаючого, але що стоять зусилля. Області, де ми залишили не залатані діри, це те, що змушує нас бігати колами з вогненною задишка, відчайдушно намагатиметься завантажити патч для розгніваних користувачів, які (патчі) роздуваються до апгрейда, люто викладати Web сайт, який працює з різними браузерами.