Наверняка вы уже успели что-то поискать про тестирование. Бесплатные видео-лекции, статьи, книгу Романа Савина. Так как вы думаете, в чем основная задача тестировщика? Чем он занимается?
Типичный ответ — ищет баги… «Крушить, ломать, ПО побеждать». Поймал ошибку, сообщил разработчику, все, твоя работа на этом закончилась.
Другой популярный ответ — помогает улучшать качество продукта. А как помогает? Ну, ищет баги и сообщает о них.
Да, мы ищем баги и сообщаем о них. Но главная задача тестировщика — предоставить информацию о том, как работает приложение.
Мы исследуем продукт и рассказываем команде, как он работает. Или не работает ¯\_(ツ)_/¯
На основе полученной информации команда решает, можно ли выпускать релиз (отдавать новую версию приложения пользователям), или стоит исправить баги. Какие баги важно исправить сейчас, а какие можно будет поправить позже. А что вообще никогда чиниться не будет.
Но подумайте вот о чем — даже если тестировщик 3 часа тестировал функционал, прогнал сотни тестов и ничего не сломалось (багов не нашел) → это не значит, что он не работал.
В чем разница между этими двумя понятиями?
- Тестировщик ищет баги
- Тестировщик предоставляет информацию о продукте
В том, что мы можем не найти багов, но это не значит, что тестирование плохое или его не было вообще. Мы можем дать отмашку «новых багов нет, старые незначительны, давайте выпускать продукт!» — и это тоже тестирование.
Вот мы, допустим, решили разработать онлайн банк. И все уже, через неделю у нас реальные пользовали пойдут им пользоваться. И если наша задача — просто поискать баги, то мы будем вводить всякую фигню во все поля, будем просто биться головой о клавиатуру в надежде на то, что хоть что-нибудь где-нибудь сломается.
Мы заведем кучу ошибок вида «при вводе милллиарда символов в поле имя система рушится» или «если открыть 10 копий интернет-банка, нигде не сможешь залогиниться», или «если нажать вперед, потом назад, потом снова вперед, и так 35 раз — система повиснет»... И что-то из этого списка мы даже исправим, и вроде как не зря тестировали, столько ошибок нашли!
Но потом придет реальный пользователь, не пытаясь сломать систему, попробует зарегистрироваться… а регистрация сломана. Или он войдет в систему, но не сможет пополнить счет.
То есть мы проверили всякие хитрые комбинации «а выдаст ли система ошибку, если мы вводим отрицательную сумму, если мы вводим буквы вместо цифр и все такое». А про основные позитивные сценарии забыли, это же не так интересно... Не делайте так! ВСЕГДА, всегда тестировщик начинает с позитивного тестирования. Сломать еще успеете, проверить работу — нет.
См также:
Позитивное и негативное тестирование — что это вообще такое и что в приоритете
Задача тестировщика — рассказать, что сейчас в продукте работает, а что нет. И поэтому сначала мы проводим более приоритетные проверки, то есть мы изучаем наш продукт, мы выясняем, какой в нем функционал.
И в первую очередь мы проверяем то, что будут делать пользователи, не пытаясь сломать систему и найти как можно больше багов, и потом уже, когда остается время, мы проверяем всякие хитрые сценарии.
По предоставленной нами информации уже наш менеджер может сделать вывод, готов продукт к выпуску или стоит его еще немного доработать. Поэтому всегда стремитесь предоставить грамотную информацию, а не просто найти как можно больше багов.
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков. Заходите к нам на огонек! ツ
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков. Заходите к нам на огонек! ツ
Комментариев нет:
Отправить комментарий