Метод предугадывания ошибок тестирование

  • Суть методики
  • Особенности
  • Что требуется, чтобы эффективно (пред)угадывать ошибки
  • Примеры
  • Преимущества и недостатки методики

Что это

Техники тест-дизайна — это то, чем должен хорошо владеть каждый тестировщик, даже стажер. Наиболее часто применяемые техники: эквивалентные классы, анализ граничных значений, и предугадывание ошибок.

В данной методике (типологически относится к тестированию черного ящика) нет какого-то специфического метода идентификации ошибок. Тестировщик действует, исходя из своего опыта и интуиции, пытаясь предугадать проблемные места в приложении. Поэтому успешность этой методики сильно зависит от опыта и скиллов, и глубины понимания тестируемого продукта.

Особенности

Как уже сказано, эффективность зависит от опыта, особенно с похожими приложениями ранее. Поэтому лучше и быстрее с такой задачей справляются QA-инженеры с опытом 1 год и более.

Методика направлена на поиск багов, не поддающихся другим методикам черного ящика. Поэтому стандартно выполняется уже после них.

Частыми ошибками в приложениях (следовательно, наиболее вероятными ошибками в тестируемом приложении) являются, например:

  • Ввод некорректных (невалидных) параметров и символов
  • Например, ввод пробела в “цифровые” поля, где это недопустимо
  • Ошибка-исключение null pointer exception
  • Деление на ноль
  • Превышение максимального количества передаваемых файлов
  • И подобные «типичные пользовательские» ошибки

Итак, цель предугадывания — найти ошибки, которые трудно “выловить” другими методиками черного ящика. Готовятся тест-кейсы, направленные на области наиболее вероятных ошибок; по возможности покрываются все проблемные места; но без избыточности.

Методика, разумеется, не является идеальной, способной обеспечить высокое качество — ведь она основана на интуиции, поэтому ограничена по умолчанию, зависит от умений и, главное, опытности QA-инженера. Она вовсе не гарантирует высокого покрытия, и должна сочетаться с другими методиками, дополнять их.

Что нужно, чтобы хорошо угадывать ошибки

  • Интуиция тестировщика
  • И его знание продукта
  • Опыт прошлых проектов
  • Чек-лист
  • Риск-репорты 
  • Знание типичных проблем с интерфейсом
  • Идеальное знание общих принципов тестирования
  • Результаты предыдущих тестов
  • Характерные ошибки, случавшиеся ранее

Примеры предугадывания ошибок

Пример 1 

В приложении есть функция ввода номера телефона клиента, и он должен быть стандартной длины, то есть 10 цифр. Методика предугадывания ошибок в данном случае может проверить, например:

  • Что случится, если ввести не цифру, а букву или пробел
  • Если ввести только 8 цифр
  • Если оставить поле пустым
  • Если ввести не 10, а 12 цифр

Если такие невалидные значения введены, и функция ведёт себя как ожидается — то есть показывает ошибку, она расценивается как не имеющая багов; в противном случае заводится баг, и функция передается разработчикам, чтобы те устранили баг.

Пример 2

Счет на банковской карте настроен так, что принимает только суммы от 5000 до 7000 рублей (так нужно клиенту). Действуя по методике предугадывания ошибок, подбираем значения ввода, пытаясь добиться наибольшего покрытия:

Значение Результат 
6000 ОК
5500 ОК
4000 Ошибка
7200 Ошибка
7400 Ошибка
8000 Ошибка
Пустое Ошибка
100$ Ошибка
… и так далее

Преимущества и недостатки методики

Преимущества

  • Неплохой контроль возможных проблемных мест в проекте (они обычно стандартные)
  • Отлично работает в сочетании с другими техниками тест-дизайна и дополняет их
  • Позволяет довольно просто находить баги, которые доступны только при исчерпывающем тестировании (всех комбинаций ввода, что невозможно из-за недостатка времени)

Недостатки

  • Является как бы ориентированной на личность тестировщика методикой, а не на процессы, что более правильно; то есть не является универсальной, а сильно зависит от скиллов тестировщика
  • Не обеспечивает хорошее покрытие сама по себе
  • Не очень подходит новичкам, неопытным, плохо знакомым с продуктом или областью его применения

***

Продолжаем говорить о техниках тест-дизайна. Сегодня речь пойдет о технике предугадывания ошибок. Она подойдет в том случае, когда мы уже знакомы с продуктом и имеем определенный опыт в тестировании подобного функционала.

Суть техники в том, что чтобы найти все способы, которые могут сломать тестируемый продукт.

По традиции начну с определения. Немного информации из ISTQB:
Предположение об ошибках – это способ предотвращения ошибок, дефектов и отказов, основанный на знаниях тестировщика, включающих:

— Историю работы приложения в прошлом.

— Наиболее вероятные типы дефектов, допускаемых при разработке.

— Типы дефектов, которые были обнаружены в схожих приложениях.

Структурированный подход к предположению об ошибках предполагает создание списка всех возможных ошибок, дефектов и отказов с последующей разработкой тестов, направленных на поиск дефектов из этого списка. Списки отказов и дефектов могут быть построены на основе опыта, исторических данных об отказах и ошибках, а также на общих знаниях о причинах отказа программ.

Получается, что предугадывание ошибки — это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Например, в программе я вижу: «для подтверждения заказа введите свой номер телефона в формате +7(…)… ….» И я, как тестировщик, начинаю думать: «А если не вводить телефон?», «А если ввести в формате не +7, а просто 8? «, и так далее. Это и есть предугадывание ошибки.

Давайте посмотрим на конкретных примерах, как можно использовать этот метод.

Уже знакомая нам игра с молокозаводом

Возьмем объекты, которые нам необходимо построить. Например, каким образом можно сломать курятник на этапе покупки?

  1. Можно попробовать поставить его на другой объект
Ставим на другой объект
Ставим на другой объект

2. Или за границу доступного поля

Ставим за границу доступного поля
Ставим за границу доступного поля

3. За границей поля тоже не получается.. А давайте попробуем поставить на воду? Вдруг разработчики не учли этот момент?

Ставим на воду
Ставим на воду

Тоже никак, все работает как надо… Ладно поставим пока курятник на место. Теперь попробуем проверить, все ли нормально с его работой.

4. В курятник можно покупать и сажать кур. А что если попробовать вместо кур поместить коров?

Размещаем корову в курятник
Размещаем корову в курятник

5. Или попробовать кур поместить на территорию вне курятника

Размещаем кур вне курятника
Размещаем кур вне курятника

6. Или попробовать зайти в магазин, пока покупаем кур

Заходим в магазин во время покупки кур
Заходим в магазин во время покупки кур

«Ладно, видимо не в этот раз» — говорим мы себе и закрываем игру…

Таким образом, путем предугадывания ошибок, мы с вами нашли 6 случаев, при которых возможны проблемы в работе приложения.

А теперь посмотрим на примере сайта

Возьмем один из элементов сайта — форму регистрации. Посмотрим на нее внимательно и подумаем, как мы можем ее «сломать».

Форма регистрации на сайте
Форма регистрации на сайте

Мне на ум приходят вот какие варианты:

  1. Указать e-mail c несуществующим доменом на конце.
  2. Указать e-mail без знака «@».
  3. Заполнить поле «Пароль» без использования обязательных символов. Например, если программа требует, чтобы в пароле были заглавные и строчные буквы, то пробуем ввести пароль без использования заглавных букв.
  4. В поле «Пароль еще раз» ввести символы отличные от символов в поле «Пароль».
  5. Снять галочку «Я принимаю условия Пользовательского соглашения».
  6. Ввести неверные символы с картинки.
  7. Оставить одно поле незаполненным.

________________________________

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

________________________________

В предугадывании ошибок нет четкой и логической схемы, которая позволила бы нам составить тест-кейсы. Т.е. нельзя сказать, что сделав сначала Шаг №1, затем Шаг №2 и т.д. мы на выходе получим готовые проверки с максимально полным покрытием.
Наоборот, эта техника основывается на опыте тестировщика и на его умении думать креативно и деструктивно.

Продолжаем говорить о техниках тест-дизайна. Сегодня речь пойдет о технике предугадывания ошибок. Она подойдет в том случае, когда мы уже знакомы с продуктом и имеем определенный опыт в тестировании подобного функционала.

Суть техники в том, что чтобы найти все способы, которые могут сломать тестируемый продукт.

По традиции начну с определения. Немного информации из ISTQB:
Предположение об ошибках – это способ предотвращения ошибок, дефектов и отказов, основанный на знаниях тестировщика, включающих:

— Историю работы приложения в прошлом.

— Наиболее вероятные типы дефектов, допускаемых при разработке.

— Типы дефектов, которые были обнаружены в схожих приложениях.

Структурированный подход к предположению об ошибках предполагает создание списка всех возможных ошибок, дефектов и отказов с последующей разработкой тестов, направленных на поиск дефектов из этого списка. Списки отказов и дефектов могут быть построены на основе опыта, исторических данных об отказах и ошибках, а также на общих знаниях о причинах отказа программ.

Получается, что предугадывание ошибки — это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Например, в программе я вижу: «для подтверждения заказа введите свой номер телефона в формате +7(…)… ….» И я, как тестировщик, начинаю думать: «А если не вводить телефон?», «А если ввести в формате не +7, а просто 8? «, и так далее. Это и есть предугадывание ошибки.

Давайте посмотрим на конкретных примерах, как можно использовать этот метод.

Уже знакомая нам игра с молокозаводом

Возьмем объекты, которые нам необходимо построить. Например, каким образом можно сломать курятник на этапе покупки?

  1. Можно попробовать поставить его на другой объект

Ставим на другой объект

Ставим на другой объект

2. Или за границу доступного поля

Ставим за границу доступного поля

Ставим за границу доступного поля

3. За границей поля тоже не получается.. А давайте попробуем поставить на воду? Вдруг разработчики не учли этот момент?

Ставим на воду

Ставим на воду

Тоже никак, все работает как надо… Ладно поставим пока курятник на место. Теперь попробуем проверить, все ли нормально с его работой.

4. В курятник можно покупать и сажать кур. А что если попробовать вместо кур поместить коров?

Размещаем корову в курятник

Размещаем корову в курятник

5. Или попробовать кур поместить на территорию вне курятника

Размещаем кур вне курятника

Размещаем кур вне курятника

6. Или попробовать зайти в магазин, пока покупаем кур

Заходим в магазин во время покупки кур

Заходим в магазин во время покупки кур

«Ладно, видимо не в этот раз» — говорим мы себе и закрываем игру…

Таким образом, путем предугадывания ошибок, мы с вами нашли 6 случаев, при которых возможны проблемы в работе приложения.

А теперь посмотрим на примере сайта

Возьмем один из элементов сайта — форму регистрации. Посмотрим на нее внимательно и подумаем, как мы можем ее «сломать».

Форма регистрации на сайте

Форма регистрации на сайте

Мне на ум приходят вот какие варианты:

  1. Указать e-mail c несуществующим доменом на конце.
  2. Указать e-mail без знака «@».
  3. Заполнить поле «Пароль» без использования обязательных символов. Например, если программа требует, чтобы в пароле были заглавные и строчные буквы, то пробуем ввести пароль без использования заглавных букв.
  4. В поле «Пароль еще раз» ввести символы отличные от символов в поле «Пароль».
  5. Снять галочку «Я принимаю условия Пользовательского соглашения».
  6. Ввести неверные символы с картинки.
  7. Оставить одно поле незаполненным.

________________________________

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

________________________________

В предугадывании ошибок нет четкой и логической схемы, которая позволила бы нам составить тест-кейсы. Т.е. нельзя сказать, что сделав сначала Шаг №1, затем Шаг №2 и т.д. мы на выходе получим готовые проверки с максимально полным покрытием.
Наоборот, эта техника основывается на опыте тестировщика и на его умении думать креативно и деструктивно.

  • Суть методики
  • Особенности
  • Что требуется, чтобы эффективно (пред)угадывать ошибки
  • Примеры
  • Преимущества и недостатки методики

Что это

Техники тест-дизайна — это то, чем должен хорошо владеть каждый тестировщик, даже стажер. Наиболее часто применяемые техники: эквивалентные классы, анализ граничных значений, и предугадывание ошибок.

В данной методике (типологически относится к тестированию черного ящика) нет какого-то специфического метода идентификации ошибок. Тестировщик действует, исходя из своего опыта и интуиции, пытаясь предугадать проблемные места в приложении. Поэтому успешность этой методики сильно зависит от опыта и скиллов, и глубины понимания тестируемого продукта.

Особенности

Как уже сказано, эффективность зависит от опыта, особенно с похожими приложениями ранее. Поэтому лучше и быстрее с такой задачей справляются QA-инженеры с опытом 1 год и более.

Методика направлена на поиск багов, не поддающихся другим методикам черного ящика. Поэтому стандартно выполняется уже после них.

Частыми ошибками в приложениях (следовательно, наиболее вероятными ошибками в тестируемом приложении) являются, например:

  • Ввод некорректных (невалидных) параметров и символов
  • Например, ввод пробела в “цифровые” поля, где это недопустимо
  • Ошибка-исключение null pointer exception
  • Деление на ноль
  • Превышение максимального количества передаваемых файлов
  • И подобные «типичные пользовательские» ошибки

Итак, цель предугадывания — найти ошибки, которые трудно “выловить” другими методиками черного ящика. Готовятся тест-кейсы, направленные на области наиболее вероятных ошибок; по возможности покрываются все проблемные места; но без избыточности.

Методика, разумеется, не является идеальной, способной обеспечить высокое качество — ведь она основана на интуиции, поэтому ограничена по умолчанию, зависит от умений и, главное, опытности QA-инженера. Она вовсе не гарантирует высокого покрытия, и должна сочетаться с другими методиками, дополнять их.

Что нужно, чтобы хорошо угадывать ошибки

  • Интуиция тестировщика
  • И его знание продукта
  • Опыт прошлых проектов
  • Чек-лист
  • Риск-репорты 
  • Знание типичных проблем с интерфейсом
  • Идеальное знание общих принципов тестирования
  • Результаты предыдущих тестов
  • Характерные ошибки, случавшиеся ранее

Примеры предугадывания ошибок

Пример 1 

В приложении есть функция ввода номера телефона клиента, и он должен быть стандартной длины, то есть 10 цифр. Методика предугадывания ошибок в данном случае может проверить, например:

  • Что случится, если ввести не цифру, а букву или пробел
  • Если ввести только 8 цифр
  • Если оставить поле пустым
  • Если ввести не 10, а 12 цифр

Если такие невалидные значения введены, и функция ведёт себя как ожидается — то есть показывает ошибку, она расценивается как не имеющая багов; в противном случае заводится баг, и функция передается разработчикам, чтобы те устранили баг.

Пример 2

Счет на банковской карте настроен так, что принимает только суммы от 5000 до 7000 рублей (так нужно клиенту). Действуя по методике предугадывания ошибок, подбираем значения ввода, пытаясь добиться наибольшего покрытия:

Значение Результат 
6000 ОК
5500 ОК
4000 Ошибка
7200 Ошибка
7400 Ошибка
8000 Ошибка
Пустое Ошибка
100$ Ошибка
… и так далее

Преимущества и недостатки методики

Преимущества

  • Неплохой контроль возможных проблемных мест в проекте (они обычно стандартные)
  • Отлично работает в сочетании с другими техниками тест-дизайна и дополняет их
  • Позволяет довольно просто находить баги, которые доступны только при исчерпывающем тестировании (всех комбинаций ввода, что невозможно из-за недостатка времени)

Недостатки

  • Является как бы ориентированной на личность тестировщика методикой, а не на процессы, что более правильно; то есть не является универсальной, а сильно зависит от скиллов тестировщика
  • Не обеспечивает хорошее покрытие сама по себе
  • Не очень подходит новичкам, неопытным, плохо знакомым с продуктом или областью его применения

***

Software application is a part of our daily life. May be in laptop or may be in our mobile phone, or it may be any digital device/interface our day starts with the use of various software applications and also ends with the use of various software applications. That’s why software companies are also trying their best to develop good quality error free software applications to the users.

So when a company develops any software application software testing plays a major role in that. Testers not only test the product with a set of specified test cases they also test the software by coming out of the testing documents. There the term error guessing comes which is not specified in any testing instruction manual still it is performed. So in this article we will discuss about that error then error guessing, where and how it is performed. The benefits that we get by performing it. So let’s start the topic.

Actually an error appears when there is any logical mistake in code by developer. And It’s very hard for a developer to find an error in large system. To solve this problem Error guessing technique is used. Error guessing technique is a software technique where test engineer guesses and try to break the software code. Error Guessing technique is also applied to all of the other testing techniques to produce more effective and workable tests.

What is the use of Error Guessing ?

In software testing error guessing is a method in which experience and skill plays an important role. As here possible bugs and defects are guessed in the areas where formal testing would not work. That’s why it is also called as experience based testing which has no specific method of testing. This is not a formal way of performing testing still it has importance as it sometimes solves many unresolved issues also.

Where or how to use it ?

Error guessing in software testing approach which is a sort of black box testing technique and also error guessing is best used as a part of the conditions where other black box testing techniques are performed, for instance, boundary value analysis and equivalence split are not prepared to cover all of the condition which are slanted to error in the application.

Advantages and Disadvantages of Error Guessing Technique :

Advantages :

  • It is effective when used with other testing approaches.
  • It is helpful to solve some complex and problematic areas of application.
  • It figures out errors which may not be identified through other formal testing techniques.
  • It helps in reducing testing times.

Disadvantages :

  • Only capable and skilled tests can perform.
  • Dependent on testers experience and skills.
  • Fails in providing guarantee the quality standard of the application.
  • Not an efficient way of error detection as compared to effort.
  • Drawbacks of Error Guessing technique:
  • Not sure that the software has reached the expected quality.
  • Never provide full coverage of an application.

Factors used in error guessing :

  1. Lessons learned from past releases.
  2. Experience of testers.
  3. Historical learning.
  4. Test execution report.
  5. Earlier defects.
  6. Production tickets.
  7. Normal testing rules.
  8. Application UI.
  9. Previous test results.

Error Guessing is one of the popular techniques of testing, even if it is not an accurate approach of performing testing still it makes the testing work simple and saves a lots of time. But when it is combined with other testing techniques we get better results. In this testing, it is essential to have skilled and experienced testers. 

Software application is a part of our daily life. May be in laptop or may be in our mobile phone, or it may be any digital device/interface our day starts with the use of various software applications and also ends with the use of various software applications. That’s why software companies are also trying their best to develop good quality error free software applications to the users.

So when a company develops any software application software testing plays a major role in that. Testers not only test the product with a set of specified test cases they also test the software by coming out of the testing documents. There the term error guessing comes which is not specified in any testing instruction manual still it is performed. So in this article we will discuss about that error then error guessing, where and how it is performed. The benefits that we get by performing it. So let’s start the topic.

Actually an error appears when there is any logical mistake in code by developer. And It’s very hard for a developer to find an error in large system. To solve this problem Error guessing technique is used. Error guessing technique is a software technique where test engineer guesses and try to break the software code. Error Guessing technique is also applied to all of the other testing techniques to produce more effective and workable tests.

What is the use of Error Guessing ?

In software testing error guessing is a method in which experience and skill plays an important role. As here possible bugs and defects are guessed in the areas where formal testing would not work. That’s why it is also called as experience based testing which has no specific method of testing. This is not a formal way of performing testing still it has importance as it sometimes solves many unresolved issues also.

Where or how to use it ?

Error guessing in software testing approach which is a sort of black box testing technique and also error guessing is best used as a part of the conditions where other black box testing techniques are performed, for instance, boundary value analysis and equivalence split are not prepared to cover all of the condition which are slanted to error in the application.

Advantages and Disadvantages of Error Guessing Technique :

Advantages :

  • It is effective when used with other testing approaches.
  • It is helpful to solve some complex and problematic areas of application.
  • It figures out errors which may not be identified through other formal testing techniques.
  • It helps in reducing testing times.

Disadvantages :

  • Only capable and skilled tests can perform.
  • Dependent on testers experience and skills.
  • Fails in providing guarantee the quality standard of the application.
  • Not an efficient way of error detection as compared to effort.
  • Drawbacks of Error Guessing technique:
  • Not sure that the software has reached the expected quality.
  • Never provide full coverage of an application.

Factors used in error guessing :

  1. Lessons learned from past releases.
  2. Experience of testers.
  3. Historical learning.
  4. Test execution report.
  5. Earlier defects.
  6. Production tickets.
  7. Normal testing rules.
  8. Application UI.
  9. Previous test results.

Error Guessing is one of the popular techniques of testing, even if it is not an accurate approach of performing testing still it makes the testing work simple and saves a lots of time. But when it is combined with other testing techniques we get better results. In this testing, it is essential to have skilled and experienced testers. 

Сложность Exploratory testing

Думаю многие организации, руководители, менеджеры всегда ставят перед собой цель тестировать качественно и максимально быстро. И это действительно факт. Конкуренция на рынке постоянно растет, особенно если мы говорим с вами о ИТ сфере. Принцип того, что кто первый, того и тапки, что рынок настолько перенасыщен продуктами, и даже если взять мой любимый банковский сектор, то можно насчитать порядка сотен различных продуктов, но тем не менее действительно классных банковских продуктов будет от силы 10, и это те продукты, которые действительно не вызывают проблем у пользователей.

Для того, чтобы быть конкурентноспособным, нужно уметь быстро внедрять продукты на рынок. Скорость тестирования обычно достигается двумя способами:

  • Автоматизация
  • Отказ от формализации

И мы рассмотрим тему отказа от формализации, или, в данном случае, подход Experience-Based Testing.

Изначально, понятие тестирования, основанного на опыте не было, первоначально существовало только Исследовательское тестирование (Exploratory testing), о котором впервые упоминает Сэм Канер еще в далеком 1987 году в книге “Testing computer software”. Но постепенно, со временем появляются другие подходы к тестированию, основанные на опыте тестировщиков, которые в 2004 году международная организация IEEE в документе “IEEE: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society” объединяет в общий подход Experience-Based Testing.

Что же в себя включает Experience-Based Testing?

Стандартно (в том числе и в ISTQB), это 3 техники тестирования:

  • Error Guessing (предугадывание ошибок)
  • Checklist-based testing (тестирование на основе чек-листов)
  • Exploratory testing (тестирование методом свободного поиска или исследовательское тестирование)

Немного расскажу о них.

Предугадывание ошибок.

Достаточно сложная техника тестирования, которая требует хороших знаний тестируемого ПО. Суть техники заключается в возможности тестировщика выполнять тестирование только путем предугадывания дефектов, рисков или проблем в системе. То есть, вы уже 6-й год тестируете одну и ту же систему, помните еще те времена, когда система была старт-апом и вы не спали ночами, пытаясь ее внедрить, к вам бегут все аналитики, чтобы понять, как будет работать функционал. В таком случае эта техника тестирования для вас. Зачем писать тест-кейсы, тестировать весь функционал, если вы интуитивно знаете, где возникнут проблемы с системой.

Немного отступлюсь…

Года 4 назад у меня был такой знакомый, который тестировал систему 5 лет. Так вот на вопрос, почему он все еще сидит и тестирует ее, он отвечал, что ему нравится работать там, где он все знает. Но его тест-кейсы были просто черт голову сломит  “великолепными”. Каждый его тест состоял всегда из 3 шагов:

  1. Что то открыть
  2. Что то сделать
  3. Что то проверить

И все! Как сделать, как открыть, что вводить, где проверять, в общем приходилось садиться и изучать систему.

Но это лирика, вернемся к теме…

Тестирование на основе чек-листов.

Это достаточно часто распространенная практика, особенно для небольших организаций, в которой обычно не более 2-3 тестировщиков. Зачем писать достаточно большие и объемные тестовые сценарии, тратить на них уйму времени, когда можно просто описать основные проверки.

Визуально чек-лист выглядит вот так:

чек-лист

 Ну и последнее и самое интересное  – это исследовательское тестирование.

Есть брать определение из ISTQB, то исследовательское тестирование характеризуется тем, что тестировщик одновременно изучает продукт и его дефекты, планирует работы по тестированию, проектирует и выполняет тесты и отчитывается о результатах. Тестировщик постоянно корректирует цели во время выполнения тестирования и готовит только высокоуровневую документацию. Именно такое определение дал Джеймс Уиттакер в книге  “Exploratory Software Testing”.

Итак, если мы более глубоко погрузимся в исследовательское тестирование, то мы поймем, что исследовательское тестирование невозможно спланировать. Тестировщик начинает тестировать систему и в зависимости от получаемых результатов планирует выполнение следующих тестов. При таком тестировании, в принципе, отваливается необходимость глубоко изучать документацию, проектировать детальные тестовые сценарии, готовить тестовые данные и другие виды активностей, связанных с подготовкой к тестированию по тестовым сценариям.

Если рассматривать тестировщика, как действительно специалиста, выполняющего сложную интеллектуальную работу, а не тупо шмякующего идя бездумно по шагам тест-кейса, что в последнее время встречается все чаще и чаще, то это действительно огромный труд и аналитическая работа, требующего определенного склада ума и желания узнать и познать все необъятное. Сейчас же специалисты по тестированию перестают думать, то ли не чувствуют ответственности, то ли хотят просто работать, как обезьянки и ни в чем не развивать себя. В общем картина удручает…

Лично я  считаю, что работая по тест-кейсам и не прикладывая особо усилий на тестирования только “отупляет” тестировщика. Но при этом, всегда есть возможность даже при сценарном подходе к тестированию, отклоняться от тест-кейсов и проводить исследовательское тестирования.

Поэтому, исследовательское тестирование:

  • Подчеркивает персональную свободу и ответственность тестировщика
  • Показывает индивидуальность тестировщика
  • Позволяет постоянно проектировать новые тест-кейсы по результатам работы

Очень подробно систематический подход к исследовательскому тестированию описывает Уиттакер, используя для этого подход с турами по различным объектам, таким, как “Тур по плохому району”, “Музейный тур” и т.д.

Звучит смешно. Но это действительно так!

Методика исследовательского тестирования с помощью туров заключается в следующем. Ваше приложение, которое вы тестируете – это незнакомый город. Вы – турист. Ваша цель – выполнить конкретную задачу, которую вы себе ставите, тем самым исследуя ваш город (приложения).

Например, если вы берете методику “Музейный тур”, то музей – это место, которое содержит большое количество различных старинных вещей, т.е. это старый код, который обычно часто остается нетронутым разработчиком. Тем не менее, он может содержать дефекты, которые тестировщик должен найти. Поэтому, задача тестировщика – определить те функции, которые уже очень долгое время не были подвержены изменениям и протестировать их. Ведь именно код разработчика, который был написан очень давно, может быть подвержен дефектам просто потому, что он уже давно забыт разработчиком и скорее всего на него уже никто не пишет даже unit тесты.

Очень подробно система туров Уиттакера рассматривается в этой статье Система туров исследовательского тестирования.

Таким образом, для того, чтобы проводить исследовательское тестирование достаточно иметь очень хорошее абстрактное мышление.

Но возникает вопрос. А действительно ли достаточно обладать большим опытом, чтобы проводить исследовательское тестирование?

Возьмем опытного тестировщика, который уже большое количество времени проводит тестирование различных систем. Чем руководствуется в таком случае тестировщик? Опытом, интуицией или техниками тест-дизайна? Очень часто я сталкивался с тестировщиками, которые очень хорошо знали систему. Они понимали, где и как может возникнуть проблема, дефект, что нужно тестировать, а на что можно просто не обращать внимания, потому что “там никогда не возникает проблем”. Да, это опыт, это умение сократить тестирование за счет того, что тестировщик понимает, к чему может привести то или иное изменение кода, но тогда мы говорим уже не об исследовательском тестирования, а о Risk-Based Testing!

Что такое исследование?

Исследование – это систематическое расследование с целью установления фактов, т.е. это процесс изучения чего-либо.

Поэтому, говоря об опыте, мы очень часто подразумеваем именно знания чего-либо. Знание – это уже умение чего-либо, но исследование – это изучение. Говоря об исследовательском тестировании мы должны отбросить все наши знания тестирования, опыт работы с системой, техник тест-дизайна и смотреть на системы новым, абсолютно не “замыленым” взглядом.

Исследовательское тестирование – это в первую очередь умение мыслить, желание обращать внимание на различные аспекты системы, отбросив наши знания и опыт работы с данной системой. Ведь именно опыт зачастую не позволяет нам видеть казалось бы такие простые вещи, на которые обычный тестировщик сразу укажет при тестировании.

Каждый же хоть раз в жизни, работая с молодыми тестировщиками, сталкивался с ситуацией, когда к вам приходит сотрудник и спрашивает, а почему здесь, к примеру, нету возможности изменить какое-либо поле, хотя оно по интуиции напрашивается само собой (потому что в жизни могут быть ситуации, когда нужно это поле изменить). На самом деле это дефект, но мы настолько привыкли тестировать по документации и, к сожалению, в нашей стране не ценят тестировщиков, как высококлассных специалистов, действительно отвечающих за качество работы приложения (именно с точки зрения пользователя), что в ответ мы слышим от Заказчика только одну фразу:

– Раз так написали в ТЗ, значит так должно быть.

Поэтому, говоря об исследовательском тестирования, нельзя говорить, что это тестирование без тест-кейсов.

Исследовательское тестирование – это целое направление в тестировании, требующее от тестировщика не столько знания и опыт работы в отрасли, с системой, как умение неординарно мыслить и находить дефекты не в соответствии с ТЗ, а в соответствии с логикой работы приложения.

Спасибо за внимание! Надеюсь было интересно!

Предугадывание ошибки (Error Guessing — EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? «, и так далее. Это и есть предугадывание ошибки.

Теория тестирования ПО просто и понятно

Время на прочтение
13 мин

Количество просмотров 179K

Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).


ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

  1. планированием работ (Test Management)

  2. проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

  3. выполнением тестирования (Test Execution)

  4. анализом результатов (Test Analysis)

Основные цели тестирования

  • техническая: предоставление актуальной информации о состоянии продукта на данный момент.

  • коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.

Верификация (verification)

Валидация (validation)

Соответствие продукта требованиям (спецификации)

Соответствие продукта потребностям пользователей

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

  • Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

  • Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

  • Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Атрибуты дефекта

  • Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

  • Blocker — ошибка, приводящая приложение в нерабочее состояние, из-за которой дальнейшая работа с системой или ее ключевыми функциями становится невозможна, т.е. тестирование значительной части функциональности становится недоступно

  • Крит (Critical) — неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие непрямые пути (workaround).

  • Значительный (Major) — часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с высоким visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.

  • Minor — часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид; либо незначительная функциональная ошибка, не нарушающая бизнес-логику тестируемой части приложения.

  • Тривиальная (Trivial) — ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие шрифта и оттенка и т.д.

  • Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

  1. Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

  2. Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

  3. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.

  4. Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

  5. Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

  6. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

  7. Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

  8. Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT).

  9. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

  10. Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.

Пример таблицы принятия решений

Пример таблицы принятия решений

ВИДЫ ТЕСТИРОВАНИЯ

Основные виды тестирования ПО

Основные виды тестирования ПО

Классификация по целям

  • Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

  • Тестирование пользовательского интерфейса (GUI Testing)  — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).

  • Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

  • Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.

  • Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.

  • Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

  • Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

  • Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.

Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.

  • Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

  • Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

  • Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.

  • Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.

  • Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.

Классификация по позитивности сценария

  • Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.

  • Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

  • Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

  • Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

  • Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.

Классификация по исполнителям тестирования

  • Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.

  • Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.

Классификация по уровню тестирования

  • Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

  • Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

  • Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.

  • Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.

  • Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

  • Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.

  • Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.

Классификация по исполнению кода

  • Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.

  • Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.

Классификация по хронологии выполнения

  • Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

  • Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.

  • Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.

Основные атрибуты требований:

  • Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

  • Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

  • Недвусмысленность — требование должно содержать однозначные формулировки.

  • Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.

  • Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

  • Что нужно тестировать?

  • Как будет проводиться тестирование?

  • Когда будет проводиться тестирование?

  • Критерии начала тестирования.

  • Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Тестовые сценарии

Функциональное требование 1

Функциональное требование 2

Функциональное требование 3

test case 1

+

+

test case 2

+

+

test case 3

+

+

+

+

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий.

Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

  • Предусловия (PreConditions) используются, если предварительно систему нужно приводить к состоянию пригодному для проведения проверки; т.е. указываются либо действия, с помощью которых система оказывается в нужном состоянии, либо список условий, выполнение которых говорит о том, что система находится в нужном состоянии для основного теста.

  • Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.

  • Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.

  • иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего для Test script), так и независимыми (Test suite).

Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

Шапка

Название/тема: Краткое описание (Summary) некорректного поведения, составляется по схеме WWW, т.е. ЧТО ГДЕ КОГДА (при каких условиях)

Назначен на (Assigned To) сотрудника, который будет с ним разбираться

Статус (Status) бага в соответствии с workflow

Компонент приложения (Component): название тестируемой функции или ее части

Информация по сборке, на которой была найдена ошибка: Номер версии (Version), название ветки

Информация об окружении (Environment): ОС + версия, модель девайса (для мобильных устройств) и т.д.

Серьезность (Severity)

Приоритет (Priority)

Описание

Подробное описание (Description): указывается по необходимости; как правило, сюда вносятся предусловия (PreConditions) или другая дополнительная полезная информация, например, если для воспроизведения бага нужны специальные знания/данные/инструменты

Шаги воспроизведения (Steps to Reproduce), по которым воспроизводится ситуация, приведшая к ошибке

Фактический Результат (Result), полученный после прохождения шагов воспроизведения, часто может быть = теме/краткому описанию (Summary) + расшифровка чего-либо (например, ошибки по коду), если нужно

Ожидаемый результат (Expected Result): который правильный, т.е. описание того, как именно должна работать система в соответствии с требованиями

Прикрепленные файлы

Вложения (Attachment): файлы с логами, скриншот или видео каст либо их комбинация для прояснения причины ошибки


Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется

Понравилась статья? Поделить с друзьями:

Не пропустите эти материалы по теме:

  • Яндекс еда ошибка привязки карты
  • Метод получения информации метод проб и ошибок
  • Метод ошибки выжившего
  • Метод относительной средней квадратичной ошибки
  • Метод обратного распространения ошибки нейронной сети это

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии