вторник, 17 апреля 2012 г.

ТОП 13 ошибок тестировщика

Сначала ссылки: 1-ая часть от исходника, в котором это читала я (внизу в схожих статьях есть вторая) и 2-ая часть со ссылкой на первую на сайте software-testing.ru.

Копипастить статью не имеет смысла, поэтому небольшая история...

Работала я себе, работала на небольшом проекте. Проверяла реализацию по ТЗ, про тест-кейсы только краем уха слышала.

Но начальнику моему это не нравилось, показал он мне на тесты с соседнего проекта в TestLink-е. "Напиши и ты".

Сказано - сделано. В свободное от тестирования время (небезызвестные "очереди" в тестировании) начала, как паук, оплетать систему кейсами.

Занятие довольно скучное, быстро надоело. Так что тесты я стала писать копипастой из ТЗ:

Действия:
Ввести значения в поля «A» и «B».
Ожидаемый результат:
Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «А» и «B». (Иногда еще также в графе с ожидаемым результатом встречаются такие «шедевры» как: См. в ТЗ, в соответствии с ТЗ, наблюдаем ожидаемые значения и т.п.).

Не, ну а что? Кому они, в конце концов, нужны то? Мне, единственному тестировщику? Кстати, так до конца проекта я единственным и оставалась...

Начальник посмотрел, посмотрел, потом кинул мне ссылку на статью, "на, почитай".

Почитала. Устыдилась. Переписала тест-кейсы, в итоге наш ма-а-а-аленький проектик обогнал  по количеству (и качеству!) самый большой в компании.

Погордилась собой :) И перешла к чек-листам.

Однако эту статью я вспоминаю до сих пор. Даже спустя 4 года третий пункт всегда всплывает у меня в мозгах, когда хочется схалтурить...

Крайне рекомендую прочитать, если вы вдруг по каким-то причинам видите ее впервые.

12 комментариев:

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

    ОтветитьУдалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. А вот пример в стиле BDD (Given/When/Then):

    Сценарий: Расчет суммы для двух натуральных чисел

    Когда я рассчитываю сумму для A = <VA> и B = <VB>
    То сумма должна быть <R>

    Примеры:
    |VA | VB | R |
    |2  | 3  | 5 |
    |3  | 2  | 5 |
    |0  | 0  | 0 |
    |0  | 1  | 1 |
    |1  | 0  | 1 |
    |-1 | 0  | -1|
    |0  | -1 | -1|
    |-1 | -1 | -1|
    |1  | -1 | 0 |

    ОтветитьУдалить
  4. Да, в виде таблички - почему бы и нет?
    Я сейчас кейсы в виде таблички и расписываю, если, конечно, они небольшие.

    Сергей, а вы вообще не пишите ни кейсов, ни чек-листов?
    Как вы тогда, например, проверите чужой автотест без описания? Это слишком долго :)

    ОтветитьУдалить
  5. |-1 | -1 | -1|
    Это что же за сложение такое странное?
    явна бага в тестах.

    ОтветитьУдалить
    Ответы
    1. >> Teklaron:
      >> |-1 | -1 | -1|
      >> Это что же за сложение такое странное?
      >> явна бага в тестах.

      Это бизнес-логика такая :)

      Удалить
  6. этот пост сделан наверное ради шутки.
    toTeklaron: да, сложение и впрямь очень

    ОтветитьУдалить
  7. Почему же ради шутки? Полезная ссылка, мое имхо

    ОтветитьУдалить
  8. Как раз насчет пунктов 3 и 4 в статье можно поспорить (пункт 2 принимается при соблюдении пары условий).
    Таким подходом впустую убито немало времени при минимальном выхлопе.

    ОтветитьУдалить
  9. А чем хороши тест-кейсы из п.3 от "ленивого тестировщика"?
    Зачем дублировать конфлюенс?

    А п.4 нужен не всегда, да.

    ОтветитьУдалить
    Ответы
    1. Они плохи тем,что из класса эквивалентности выбрали 1 фиксированное значение. Недостаток скриптованного тестирования всегда заключается в отсутствии гибкости. Классы эквивалентности не дают 100% уверенности в том, что для приложения действительно все значения класса эквивалентны. Если указывать в тест кейсах диапазон значений, из которых следует выбрать А и В, вероятность постепенной проверки бОльшего количества вариаций значений растет => вероятность поймать баг специфических значений.
      Я говорю о мануальном тестировании. С автоматизацией еще проще.

      Удалить
    2. Диапазон - это хорошо.
      Но указать диапазон - не есть написать "согласно ТЗ" в результате :)

      Удалить