пятница, 24 апреля 2020 г.

Чем занимается тестировщик



Наверняка вы уже успели что-то поискать про тестирование. Бесплатные видео-лекции, статьи, книгу Романа Савина. Так как вы думаете, в чем основная задача тестировщика? Чем он занимается?

Типичный ответ — ищет баги… «Крушить, ломать, ПО побеждать». Поймал ошибку, сообщил разработчику, все, твоя работа на этом закончилась.


Другой популярный ответ — помогает улучшать качество продукта. А как помогает? Ну, ищет баги и сообщает о них.

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

Мы исследуем продукт и рассказываем команде, как он работает. Или не работает ¯\_(ツ)_/¯ 
На основе полученной информации команда решает, можно ли выпускать релиз (отдавать новую версию приложения пользователям), или стоит исправить баги. Какие баги важно исправить сейчас, а какие можно будет поправить позже. А что вообще никогда чиниться не будет.

Но подумайте вот о чем — даже если тестировщик 3 часа тестировал функционал, прогнал сотни тестов и ничего не сломалось (багов не нашел) → это не значит, что он не работал.
В чем разница между этими двумя понятиями? 
  1. Тестировщик ищет баги
  2. Тестировщик предоставляет информацию о продукте
В том, что мы можем не найти багов, но это не значит, что тестирование плохое или его не было вообще. Мы можем дать отмашку «новых багов нет, старые незначительны, давайте выпускать продукт!» — и это тоже тестирование.

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


Мы заведем кучу ошибок вида «при вводе милллиарда символов в поле имя система рушится» или «если открыть 10 копий интернет-банка, нигде не сможешь залогиниться», или «если нажать вперед, потом назад, потом снова вперед, и так 35 раз — система повиснет»... И что-то из этого списка мы даже исправим, и вроде как не зря тестировали, столько ошибок нашли!

Но потом придет реальный пользователь, не пытаясь сломать систему, попробует зарегистрироваться… а регистрация сломана. Или он войдет в систему, но не сможет пополнить счет. 


То есть мы проверили всякие хитрые комбинации «а выдаст ли система ошибку, если мы вводим отрицательную сумму, если мы вводим буквы вместо цифр и все такое». А про основные позитивные сценарии забыли, это же не так интересно... Не делайте так! ВСЕГДА, всегда тестировщик начинает с позитивного тестирования. Сломать еще успеете, проверить работу — нет. 

См также:

Задача тестировщика — рассказать, что сейчас в продукте работает, а что нет. И поэтому сначала мы проводим более приоритетные проверки, то есть мы изучаем наш продукт, мы выясняем, какой в нем функционал. 

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


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

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиковЗаходите к нам на огонек! ツ

Комментариев нет:

Отправка комментария