У записі "Чи не баги" теж треба заносити в багтрекер "був описаний більш-менш ідеальний випадок" становлення тестувальників "за допомогою занесення в багтрекер всіх» не багів ".
Колега Olga пише правильне зауваження:
це не працює на великих проектах. Якщо проект великий, часто у тестувальників просто немає часу прочитати всі існуючі баги, фізично. Це неправильно, але життя є життя.
За баги, які не є багами ніхто тестувальника не похвалиш (це м'яко сказано).
А позиційний товариш zmei вірно вказує на те, що псевдобагі в трекері нікому крім "медсестер" користі не принесуть.
"Чи не баги" взагалі не приносять користі розробникам 🙂 Це внутрішня кухня тестувальників. До того ж, це залежить від кожного тестувальника окремо. Я їх сприймаю. Інші немає.
У більшості випадків подібні проблеми можна вирішити на рівні внутрікопроратівних легенд, що не документуємо, передаються усно або по внутрішньому месенджер в міру необхідності. Я ще не зустрічав неабияк підготовлений звід "фіч", які не є багами, копроратівно оформлений і визначений на внутрішній сервер. А ось на рівні "дивись в багтрекер" - зустрічав неодноразово. Будь-трекер - це і робочий інструмент, і система зберігання зроблених помилок, так чому б не використати його в якості wiki-системи?
Кілька невескіх доводів
Є кілька доводів зберігання »не багів", які очевидні колишнім учасникам невеликих невітчизняного воєн "за якість".
У великому проекті, що складається з багатьох функцій, одночасно використовуються сили багатьох тестувальників. Рідко буває, щоб всі ці сили уважно спеціалізувалися на окремих функціях. Ну, керівники груп можуть більш-менш на чимось спеціалізуватися. Решту ж членів "великої і дружного колективу" начальство легко перекидає з одного фронту робіт на інший.
Приклад для менеджера: в програмі Excel є функція пошуку. І є функція малювання діаграм. І є функція відображення певних шрифтів. Припустимо, все вже розроблено і випущено "в народ". Народ потроху рапортує про знайдені помилки, а також просить поліпшення функціоналу. З'являються зміни в деяких функціях.
Отже, потрібно перевірити зміни у функції пошуку, а через п'ять днів обіцяють підігнати зміни у функції діаграм.
Розумніше сьогодні направити на тестування "пошуку" всіх "вільних" людей, ніж вирощувати спеців, які бачили в гробах всі види пошуку, тому що вони тестують тільки діаграми ...
Завтра буде інший день, завтра будемо перевіряти функцію "Save as ...", і буде розумніший за всіх своїх "вільних" направити на тестування "сейв ЕСА".
Тепер уявімо, що я до сих пір "сидів" на діаграмах, і бачив я ваші "сейв еси" тільки в гробах. Але на сьогодні у нас запланована перевірка коректності роботи якийсь математичної функції Excel - RANDBETWEEN.
У функції є опис: Returns a random integer between the numbers you specify. Відмінне опис, мені зрозумілі всі прогалини і все слова окремо. Якби не було тест-кейсів, мені довелося б провести багато годин треба документацією проекту, і довелося б ставити багато питань оточуючим. Це реально, особливо в рамках ВЕЛИКОГО проекту?
Ось навіщо потрібні тест-кейси. Ось навіщо потрібно все так детально записувати. Роби, що написано, і не мороч голову / голови.
Представляємо далі: одночасно зі мною цю функцію тестують мої колеги - і тестують її в інших середовищах. Наприклад, в поєднанні з іншими версіями Excel, іншими версіями Windows (їх багато, якщо хто не в курсі), іншими версіями IE ... Там виявляються "свої" баги, які заносяться на трекер.
Гм, забазікався. Гаразд, припустимо, що при натисканні на кнопку Cancel функція припиняє свою роботу, але очищає поля, в які ми вводили вхідні дані.
Міркуємо так: якщо я скасував операцію, значить, я буду вказувати інші вхідні значення. І старі мені потрібні, щоб не забивати все цифри заново. Значить, їх НЕ слід видаляти при натисканні Cancel. Логічне міркування? Так. Баг? Так, це баг (результат не відповідає очікуванням, та ще й веде себе "незручно").
Тепер представляємо, що цей баг, який "не баг", відтворюється у всіх версіях Windows. І все тестувальники "на проекті" хочуть його занести в багтрекер. Що, документація "скаже" їм, що це "не баг"?
Тому - тільки багтрекер, і тільки «не баги" ...
Згодом, коли будемо актуалізувати тест-кейси і проводити багчекінгі, цей баг перетвориться на повноцінний тест-кейс: запустити, раптово натиснути на Cancel, переконатися, що функція припинила роботу і поля введення очистилися.
Є ж загальні знання і поняття про інтерфейси
Кінець музичної паузи. Їдемо далі.
Слідами статті "Чи не баги" теж треба заносити в багтрекер "мені було вказано на дещо некоректну алегорію про порося - адже будь-якій людині ЗРОЗУМІЛО, що ніздрів у поросяти тільки дві. Є ж загальні знання і поняття про інтерфейси, врешті-решт ...
Так, всі знають, скільки ніздрів у адекватного, розумного поросяти. Але тепер, на прикладі функції RANDBETWEEN, спробуйте застосувати підхід "Ну, едріть, бити. Ну невже не зрозуміло, що третя ніздря - НЕ ніздря? "...
Неминучість: «Не баги" завжди з'являються.
Уособлення постулату цієї неминучості: припустимо, що програміст, який працював над функцією RANDBETWEEN, все своє життя поклав на розробку саме цієї функції ... Він знає всі її рухи, все її варіанти відповідей, він знає все, точно так же, як ми знаємо про те , що у поросят трьох ніздрів не буває.
А я, тестувальник, про цю функцію НЕ ЗНАЮ нічого. З допитливістю і відкритістю дитини, я кручу і верчу цю функцію. І цілком можу знайти "третю ніздрю" ...
Чи слід мені уточнювати, що поняття "недосвідчений тестувальник" НЕ означає "гнилий юзер, які боїться комп'ютера"? Особливо зважаючи на вищевикладене.
Ну ось ... У тестуванні такі ситуації трапляються досить часто (тільки про це не слід знати замовникам тестування).
У цих умовах поява будь-яких «не багів" з боку недосвідчених тестувальників неминуче. Треба тільки зменшити ймовірність їх виявлення програмістами. І збільшити можливість ознайомлення тестувальника з усіма ймовірними мутаціями і діями цієї функції. Документація може не допомогти, тому що документація описує те, як функція ПОВИННА працювати. А ми бачимо, як вона працює в дійсності, виявляючи чудеса, які в документації не описані, і не повинні бути описані, і ніколи не будуть ...
Як ще документувати помилки, крім як через багтрекер? Ну і що, що вже є якесь вікі для всіх документів (вимоги, плани, юз-кейси, технологічні специфікації і всяке таке)? Описи багів і "не багів" вже лежать в багтрекер. Ну і нехай лежать, стануть в нагоді.
Аксіома: великий проект неабияк забезпечений документацією. Документація по проекту, як апостольські одкровення, містить всю правду життя, яку треба знати тестувальників будь-якого рангу.
Мій досвід свідчить: ті, хто документацію по проекту все-таки читають, мають більше шансів перейти з молодшого до керівного складу.
Далі мій досвід свідчить недобре: молодший тестіровщіковскій склад цю документацію "не бачить і не чує". Що, молодшому складу запропоновано ознайомитися з архітектурою додатки і захоплюючими взаємовідносинами "Клієнт-Сервер"? Ще реферат на цю тему запросите ...
Документів багато. Але ... «не баги" все одно будуть з'являтися в трекері, і чим БІЛЬШЕ і складніше проект, тим більше і частіше будуть з'являтися ці самі «не баги":
- в проект приходять нові люди, які не знайомі зі специфікаціями і вимогами
- "Старички" йдуть, несучи з собою "недокументовані" знання особливостей, специфікацій і вимог
- функціонал перевіряють то одні тестувальники, то інші
- досвідчені тестувальники божеволіють
Проблема вирішувана в наступних парламентських виразах:
Як можна тестувати то, в чому не розбираєшся?
Хороше запитання: як можна тестувати то, в чому не розбираєшся? Як можна довірити перевірку функції RANDBETWEEN людині, який навіть про її існування не знав?
Чесне слово, МОЖНА тестувати будь-яку функцію з Excel, абсолютно не розуміючи, що і як ця функція робить. Вистачає загальних знань інтерфейсу Excel і основних команд для роботи з меню і виклику функцій, а також ми читаємо докладно написані тест-кейси. А тест-кейси ці написані досвідченими людьми. Наприклад, розробником. Або продакт-менеджером. Або іншим тестувальником, який вже перейшов у кращий світ (в Oracle або Google), і більше з нами не працює.
От якби ця функція відповідала за життя космонавта або пацієнта, підключеного до апарату штучного дихання, тоді так ... Але тоді і не запропонують її тестувати нікому, крім фахівців в області.
Замість епілогу: «Не баги" треба зберігати в багтрекер, не передаючи їх програмістам.