Печалби:
- Възможност за трансформиране на разпръснати наблюдения в доклад, съдържащ ясно заглавие, детерминистични стъпки за възпроизвеждане, очаквани/действителни резултати и доказателства с подкрепата на изкуствен интелект
- Да можеш да наложиш правилото „използвай само информацията, която давам, не я измисляй“ на изкуствения интелект и да гарантира възпроизводимост със собствен контрол
- Да можеш да правиш разлика между сериозност (техническо въздействие) и приоритет (бизнес спешност) и да даваш крайния етикет с бизнес контекста
Грешката, открита от тестера, е ценна само ако е коригирана; Коригирането зависи до голяма степен от качеството на доклада за грешка – запис, който документира дефект по начин, който разработчикът може да разбере, възпроизведе и поправи. Лошо написан доклад за грешка („входът не работи“) ще спре разработчика с часове, ще доведе до кореспонденция напред-назад и често ще се затвори като „не може да се възпроизведе“. Добрият доклад включва ясни стъпки, очаквани и действителни резултати, контекстна информация и доказателства. Изкуственият интелект (AI) е много добър в превръщането на вашите разпръснати наблюдения в професионален, структуриран доклад. Но основното предупреждение важи и тук: AI не може да измисля стъпки, които не виждате; може да попълни липсващата информация с „разумно изглеждащи“, но неточни предположения. Вашата работа е да се уверите, че всеки ред от доклада се основава на това, което действително сте наблюдавали.
Анатомия на добър доклад за грешки
Един ефективен отчет включва следните компоненти:
- Заглавие: Кратко, конкретно, с възможност за търсене. Не "Има грешка"; „Не мога да щракна върху бутона „Плащане“ с повече от 10 артикула в количката (Chrome)“.
- Стъпки за възпроизвеждане: номерирани, проследими от нулата, детерминирани. Разработчикът трябва да може да види грешката, след като изпълни тези стъпки.
- Очакван резултат: Какво трябваше да се случи според критериите за приемане.
- Действителен резултат: Какво се е случило (съобщение за грешка, екран, поведение).
- Среда: Браузър/устройство, версия, среда (тест/на живо), потребителска роля, данни.
- Доказателство: Екранна снимка, видео, дневник, проследяване на грешки (проследяване на стека).
- Тежест и приоритет: Подробности по-долу.
Съвет: Преди да изпратите отчет, попитайте „ако дам тези стъпки на някой друг, може ли той да види грешката без моята помощ?“ попитайте. Ако отговорът е „не“, докладът е непълен. AI може да направи отчета красив, но само вие можете да гарантирате възпроизводимост.
Насилие и приоритет: две объркани понятия
Сериозността е техническият ефект от грешката: дали системата се срива, данните се губят или е печатна грешка? Приоритет е колко спешно трябва да се поправи; е за въздействие върху бизнеса. Двете не винаги вървят в една и съща посока: грешното изписване на името на компанията на началната страница е с ниска тежест, но с висок приоритет (репутация). В редки крайни случаи сривът може да бъде с висока тежест, но с нисък приоритет. AI ви помага да направите това разграничение, когато давате наблюдението; но крайният етикет се дава от вас, които познавате бизнес контекста.
насилие
пример
приоритет
пример
Критичен (блокиращ)
Плащането не може да бъде извършено
Спешно (P1)
Загуба на доходи на живо
Висок (основен)
Отчетът дава неправилна обща сума
Висок (P2)
Задължително за предстоящото издание
Среден (незначителен)
Рядка грешка в крайния случай
Среден (P3)
В планиран спринт
Ниско (тривиално)
Подравняването на бутоните е изключено
Ниска (P4)
Когато има шанс
Слаба подкана / Силна подкана
Слабо: „Подайте сигнал за тази грешка: плащането не работи.“
Силно: „Преведете моите наблюдения по-долу в стандартен формат на доклад за грешки: заглавие, стъпки за възпроизвеждане (номерирани), очакван резултат, действителен резултат, среда, тежест и препоръка за приоритет (обосновани). Използвайте само предоставената от мен информация; компенсирайте липсващите полета, маркирайте „ЛИПСВАЩА ИНФОРМАЦИЯ: ...“. Наблюдения: Chrome 120, тестова среда, 12 елемента в количката, нищо не се случва, когато натисна „Плащане“, Грешка „недефинирано не е функция“ в конзолата, няма проблем с 11 продукта.“
Мощна подсказка; налага формата, правилото за "напасване" и маркирането на липсваща информация. По този начин докладът ще бъде както точен, така и честен.
Откриване на дублирана грешка
В големите екипи същата грешка се отчита отново и отново. AI може да сравни новия ви доклад със съществуващи открити грешки и да маркира потенциални дубликати — това поддържа вашата система за проследяване на грешки (Jira, Azure DevOps, GitHub Issues) чиста. Но внимавайте: две грешки, които изглеждат подобни на повърхността, може да имат различни първопричини; Сравнете повторните производствени стъпки и средата на двата отчета, преди да затворите предложението за „дубликат“ на AI. При случайно затворен „дубликат“ всъщност липсва отделна грешка.
От проследяване на грешка до първопричина: Силата на AI да чете регистрационни файлове
Най-техническата част от доклада за грешка често е проследяването на грешка (проследяване на стека — разбивка на това кой ред код, с коя верига на извикване е задействал грешка). Дългите и сложни журнали могат да уморят дори разработчика. AI чете дневник от стотици редове и обобщава за секунди най-критичните редове, възможната хипотеза за първопричината и кодовата точка, където е задействана грешката. Това съкращава отчета и дава на разработчика директна отправна точка.
Запомнете обаче две ограничения. Първо, основната причина, дадена от AI, е хипотеза, а не доказателство; Разработчикът не трябва да се опитва да поправи това, без да го е проверил. Второ, регистрационните файлове често съдържат лични данни (имейл, потребителско име, токен за сесия); Маскирайте тези зони, преди да поставите трупата върху автомобила. Добра практика е първо да накарате AI да каже „избройте полетата, които трябва да бъдат маскирани в този дневник“ и след това да анализирате почистения дневник.
Съвет: Вместо да поставите целия дневник в отчета, включете най-важните 3-5 реда, които AI обобщава, и връзка към пълния дневник. По този начин отчетът остава четим и разработчикът, който се нуждае от подробности, има достъп до пълния дневник.
Четири копируеми шаблона
1) От наблюдение до доклад:
Вашата роля: старши QA. Преведете следните необработени наблюдения в стандартен доклад за грешка: Заглавие / Стъпки на възпроизвеждане (номерирани) / Очаквано / Действително / Околна среда / Доказателствена бележка / Сериозност + Приоритет (обоснован). ПРАВИЛО: използвайте само предоставената от мен информация; маркирайте липсващото поле като „ЛИПСВАЩА ИНФОРМАЦИЯ:...“ Наблюдения: [сурови бележки]
2) Контрол на възпроизводимостта:
Прочетете този доклад за грешка от гледна точка на разработчик, който никога не е виждал грешката. Следвайте стъпките и маркирайте местата, където няма да произведе грешката: двусмислена стъпка, липсваща предпоставка, липсващи тестови данни, пропуснато условие. Кажете ми каква информация трябва да добавя за всяка празнина. Доклад: [поставяне на отчет]
3) Съветник по тежест/приоритет:
Описвам следната грешка: [грешка + бизнес контекст]. Дайте предложения и обосновка отделно за тежест (техническо въздействие) и приоритет (бизнес спешност). Обяснете защо двете може да са различни. Аз ще взема окончателното решение.
4) Резюме на проследяване на регистър/грешка:
Разгледайте проследяването/регистрацията на грешките по-долу. Дайте ми обобщение на (1) хипотезата за основната причина, (2) вероятната кодова точка, където е възникнала грешката, (3) 3-те най-критични реда, които да добавя към отчета. Маскирайте, ако има лични данни. Дневник: [поставете журнал]
три мини калъфа
Случай 1 — Освобождаване от „Не можах да продуцирам“. В един екип 30% от грешките са затворени като „не могат да се възпроизвеждат“. Шаблонът "проверка на възпроизводимост" е добавен към процеса на докладване; Преди всеки доклад да бъде изпратен, AI маркира липсващи стъпки и предпоставки. Три месеца по-късно процентът „не може да произведе“ спадна от 30% на 8%. Разликата беше, че стъпките бяха точни от самото начало.
Случай 2 — Опасността от фалшиви стъпки. Тестер накара AI да напише доклад с непълни наблюдения; AI добави стъпка, която никога не се е случвала, като например „потребителят включва известия от страницата с настройки“. Когато разработчикът последва тази стъпка, той не можа да намери грешката и загуби време. Екипът наложи правилото „използвайте само информацията, която давам, не си измисляйте“; Измислените стъпки се елиминират.
Случай 3 — Разграничение по тежест/приоритет. Имаше правописна грешка в слогана на компанията на началната страница. Тестерът ще предаде това като "ниско"; Консултантът на AI напомни, че техническото насилие е ниско, но бизнес приоритетът е висок (елементът на репутацията, който всеки посетител получава). Грешката беше коригирана същия ден с етикета "висок приоритет".
Често срещани грешки
- Неясно заглавие. Нетърсени, недискриминиращи заглавия като „Не работи“.
- Липсващи/пропуснати стъпки. Не пишете това, което е очевидно във вашия контекст; неуспех на разработчика да произведе.
- Оставете AI да го измисли. Попълване на липсващата информация с „разумна оценка“; грешни стъпки.
- Ненаписване на очаквания резултат. Казвайки „грешно“, но не уточнявайки какво е правилно.
- Объркващо насилие и приоритет. Объркайте двете като един етикет; Погрешна оценка на въздействието върху бизнеса.
- Чувствителни данни в доказателство. Споделяне на реални лични данни в екранни снимки/дневници, без да ги маскирате.
В обобщение
Стойността на доклада за грешка е, че разработчикът може да възпроизведе и поправи грешката без ваша помощ. AI е много добър в превръщането на разпръснати наблюдения в професионален, структуриран доклад; Той организира заглавието, стъпките, очаквания/действителния резултат, средата и доказателствата и предоставя консултации относно разграничението между тежест и приоритет. Но AI може да компенсира липсващата информация; Налагайте правилото „използвайте само предоставената от мен информация, маркирайте липсващата“ и сами гарантирайте възпроизводимост. Маскиране на лични данни в доказателства.
Задача за приложение
Вземете грешка, която наскоро сте открили, и превърнете необработените си наблюдения в доклад, като използвате модела „наблюдение към доклад“ (с правилото „напасване“). След това извършете „проверка за възпроизводимост“ и попълнете отбелязаните пропуски. Дайте отчета на колега и вижте дали той може да изведе грешката без ваша помощ. Накрая определете етикетите с „консултанта по насилие/приоритет“ и го финализирайте по свое усмотрение. Обърнете внимание на всяка информация, която AI се опитва да измисли в процеса.
контролен списък
- [ ] Заглавието ми е конкретно и може да се търси.
- [ ] Стъпките за възпроизвеждане са от нулата, детерминистични и завършени.
- [ ] Написах отделно очакваните и действителните резултати.
- [ ] Информацията за настройките и доказателствата е пълна; Маскирах личните данни.
- [ ] Наложих правилото „измислете, отбележете липсващото“ на AI и сам попълних празнините.
- [ ] Оцених отделно тежестта и приоритета и взех окончателното решение.