Іноді моя команда QA повідомляє про помилки, але ні я, ні вони не мають уявлення про те, як їх відтворити. Це призводить до дуже довгих і розчарувальних сесій налагодження, які іноді навіть не дають результатів.

Моє програмне забезпечення сильно пов'язане з власником обладнання, тому помилки можуть надходити відразу з багатьох напрямків.

Чи варто очікувати від них більше, ніж "ваше програмне забезпечення вийшло з ладу, коли я натиснув кнопку", або я повинен зрозуміти, що сталося?

Редагувати:

Один з моїх колег зазначив, що ми, мабуть, всі розробники тут, тому результати можуть зазнати невеликої упередженості

QA завжди повинен намагатися зробити помилки максимально простими для відтворення, а опис помилки повинен містити вжиті кроки.

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

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

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

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

Існує низка причин, чому потрібна правильна відповідь (не просто хороша, але й необхідна):

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

Отже, як зазначає SteveCzetty: Закрийте це як ніяке докори та поверніться до роботи.

Якщо помилку неможливо відтворити послідовно, як QA коли-небудь дізнається, чи її виправлено?

Так, від них слід очікувати більше. Вони повинні мати можливість сказати:

1. Почався новий екземпляр програми
2. Я натиснув кнопку A
3. Введено "тестовий текст" у поле "ІМЕТА ТЕСТУ" у формі №1
4. Натиснута кнопка B
5. Помічено, що програма вийшла з ладу з цим повідомленням (див. Доданий скріншот).

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

Моя порада - прочитати ці помилки та дати їм добру думку. Якщо ви не можете з'ясувати потенційну причину, забудьте про них наразі.

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

З цими помилками "1 на 1000" QA має спробувати їх трохи відтворити. Якщо вони не мають успіху, вони повинні задокументувати помилку, а потім спробуйте ще трохи.

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

Помилка повинна містити якомога більше інформації. Що б тестер не міг пам’ятати про підсумки вирішення питання, слід записувати до болю детально. Будь-які журнали Crash, знімки бази даних або відповідні знімки екрана також повинні бути додані.

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

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

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

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

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

Невідтворювані помилки, як правило, мають низький пріоритет, але їх обов'язково потрібно записати.

ІМО, ви повинні. QA не виконують свою роботу, якщо вони не можуть дати вам жодних кроків із відтворення. Не витрачайте час на те, щоб відтворити щось, чого ви не можете, просто закрийте це як "Неможливо відтворити" і рухайтеся далі.

Ваш час набагато цінніший за це.

Звіт про помилку повинен містити:

• Кроки до відтворення
• Фактична поведінка
• Очікувана поведінка

Наприклад:

• Я видалив усіх постачальників із бази даних (використовуючи DELETE * FROM tSuppliers), відкрив діалогове вікно постачальника та натиснув на спадний список Постачальник.
• У списку міститься наступне повідомлення: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Коли я натиснув повідомлення, додаток зник з екрана, а Диспетчер завдань.
• Я очікував, що побачу або порожній список, або (бажано) повідомлення типу "Не знайдено постачальників". Клацання порожнього списку або повідомлення не повинно впливати. Додаток, очевидно, не повинно зникати без попередження ні за яких обставин.

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

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

Гроші тут під загрозою. Чому будь-який член команди повинен мати можливість створити неякісну задачу з низькими шансами на успіх, що обтяжує (сподіваємось) високооплачуваного розробника?

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

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

ваша команда QA смокче

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

Зокрема, вкажіть їх на розділ "Покажіть мені, як себе показати" :

Це епоха Інтернету. Це ера світового спілкування. Це епоха, в яку я можу надсилати своє програмне забезпечення комусь із Росії одним натисканням кнопки, і він може так само легко надсилати мені коментарі з цього приводу. Але якщо у нього є проблема з моєю програмою, він не може заставити мене стояти перед нею, поки вона не спрацьовує. "Покажіть мені" добре, коли можете, але часто не можете.

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

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

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