Меню

Цей сценарій пояснює, наскільки важливо документувати часто зустрічаються помилки

this scenario explains how important it is document frequently encountered errors

Спробуйте Наш Інструмент Для Усунення Проблем

Чи вірите ви в те, що програмні помилки трапляються лише один раз і що при виправленні вони ніколи не виникають знову? Я відчуваю, що приблизно 30% помилок повторюються.

У цій статті я хочу висвітлити, наскільки важливо задокументувати деякі часто зустрічаються помилки.

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

Сподіваюся, вам це буде корисно!

Документування часто зустрічаються помилок

зображення джерело

Сценарій No1

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

Помилки документування 1

Помилки документування 2

І Джон, і Шерил вирушили шукати Сміта, який раніше бачив ту саму помилку і раніше її вирішував. На жаль, того дня Сміт був у відпустці.

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

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

Сценарій No2

Джон тестує новий випуск і знову натрапляє на відому помилку. Цього разу він знає, що в одному з минулих випусків для нього був створений дефект. Але питання в тому: “як мені знайти номер дефекту та інші пов’язані деталі?”

І в цьому випадку, що, на вашу думку, допомогло б Джону?

Це можливості.

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

Що ви дізнаєтесь:

Деякі області з частими помилками:

1) Файл параметрів - Виходячи зі свого досвіду роботи з інструментом Informatica, у багатьох випадках я помічав файл param, який вказує на неправильне підключення до БД. Це призвело до одних і тих самих проблем кілька разів. Основною причиною було те, що зв'язок був спільним між розробниками та QA. Отже, файл param завжди потрібно було оновлювати відповідно до потреб, щоб уникнути помилки.

2) URL-адреса, що вказує на неправильну БД

3) Проблеми доступу - Користувачі стикаються з проблемами, коли у них недостатньо або неправильні дозволи на доступ до БД, або в цьому випадку документ, що описує кроки, які слід виконати, або особа / особи, до яких слід зв’язатись, буде дуже корисним.

4) Випуск даних тесту - Використання неправильного формату або значень даних частіше за все призводить до проблем.

5) Проблеми з БД - Час очікування з’єднання з БД - одна з таких поширених проблем. Частина простоїв є тимчасовою, плановою, і іноді нам може знадобитися допомога DBA. Користувачів заздалегідь повідомляють про планове технічне обслуговування, але для тимчасових помилок та вирішення тестери точно потребують

Більшість повторюваних помилок є загалом екологічні проблеми .

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

різниця між сценарієм тесту та тестовим кейсом

Також може бути невелика площа дефектів введення даних або помилка використання людиною s .

ЗавантажитиШаблони для відстеження часто зустрічаються помилок

Формат слова

=> Завантажити шаблон відстеження помилок (Світ)

Формат Excel

=> Завантажити шаблон відстеження помилок (Excel)

Переваги документування часто зустрічаються помилок

1) Усуває залежність - У сценарії 1 Джон був залежним Смітом для вирішення проблеми. Якби існував документ для довідки Джона, якого не було б.

2) Швидший поворот - Візьмемо сценарій 2. Тестеру не доведеться переглядати весь список вже зареєстрованих дефектів, якби існував спеціальний документ для високочастотних проблем.

3) Допомагає новим членам команди бути самодостатніми

4) Допомагає у вирішенні людських помилок

Висновок

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

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

Рекомендована література

^