Когда заносить баги в трекер?

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

Но на практике очень многие тестировщики (в том числе и я) не придерживаются такого подхода. На то есть несколько причин и на этот счет каждый имеет свое мнение и свои причины.

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

Конечно, если в процессе тестирования находится по багу в час, то тут нет никаких проблем, чтобы сразу же занести баг в трекер. Но попадаются (и не редко) такие проекты где «баг на баге сидит и багом погоняет». В такой ситуации заводить баги сразу же при их нахождении не очень удобно. Даже совсем не удобно. На переключение между тестированием и занесением уходит довольно много времени. Поэтому, я считаю вполне оправданным занесение багов не во время самого тестирования, а чуть позже.

Единственное, что я считаю неприемлемым – это заносить все найденные баги в конце дня. Во-первых, их тогда очень нудно описывать. Во-вторых, очень велика вероятность провтыкать какой-то баг и не занести. И в-третих, это плохо сказывается на здоровье программистов :), которые не видя в течении дня ни одного нового бага, радуются и спокойно, с чистой совестью собираются себе домой… И тут вдруг обнаруживают несколько десятков багов. А-а-а!!! Так и до нервного срыва недалеко :)

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

А для того, чтобы не забыть баги очень удобно по ходу тестирования делать скриншоты. Ведь практически на каждый баг можно сделать скриншот. А по скриншотам уже очень легко вспоминать суть бага. Также можно делать заметки на бумаге. Завязывать узелки на память :) ... у каждого свои методы.

PS: Про узелки на память - это шутка.

Негативное тестирование

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

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

Во многих ресурсах по тестированию, при описании последовательности выполнения видов тестирования, негативное тестирование отделяют в отдельную процедуру и ставят на 4-е место.
При этом приводится следующий план тестирования:

1. Изучение документации (для того, чтобы понять что, собственно тестируем)
2. Дымовое тестирование или Smoke testing (первый прогон программы, чтобы понять работает ли она вообще)
3. Позитивное тестирование (для того, чтобы проверить работу программы при получении ею "правильных" входных данных)
4. Негативное тестирование

Но почему так?! Почему нужно негативное тестирование отделять от позитивного и выполнять потом? Как показывает практика, оставленное на потом почти всегда остается не выполненным.

А можем ли мы сказать что программа работает, если проверили ее реакцию только на правильные входные данные?

А главное, я вот представляю ситуацию. Сижу я тестирую формочку. Проверила все соответственно ТЗ, проверила как обрабатываются данные, которые ожидается, что пользователь будет вводить в поля (заметьте, ожидается совсем не значит, что так и будет) и тут же в моем тестерском уме возникает небезосновательное подозрение, что если ввести вот в это поле "0" - то произойдет что-то нехорошее :) И что? Я должна сказать себе "Нет. По плану у меня сейчас позитивное тестирование. Негативное на следующей неделе, вот тогда и проверю с нулем"?

По-моему, такой подход неправильный. Он не просто неправильный, он неэффективный.

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

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

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