#Ролевыеигры
Под этим хэштегом буду рассказывать о взаимодействии тестировщиков с другими членами IT-команды. Начну серию постов с разработчиков - все-таки именно они пишут код, делают его ревью и еще они тоже немного тестировщики - чаще всего именно они пишут Unit-тесты.
Для не очень посвященных вкратце объясню терминологию.
Ревью кода - это проверка одним из разработчиков кода своего коллеги - это позволяет оптимизировать код и улучшить его читаемость, а знания о новых фичах (особенностях) реализации продукта распространяются среди других коллег. Наличие код-ревью на проекте или в компании - это хороший тон, а для тестировщиков, собирающихся устроиться в такую компанию - отличный сигнал.
Unit-тесты - проверки кода на уровне функций, классов, процедур. Выявление ошибок самим разработчиком на самом раннем этапе обходится гораздо дешевле для компании, чем те, которые вылавливают тестировщики или, что еще хуже, обычные пользователи продукта.
И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂
Естественно, это происходит неосознанно и не специально. Более того, хороший разработчик не только тщательно покроет свой код юнит-тестами, но и напишет комментарии к коду, подготовит краткую документацию или статью для других, но и это не спасет его от наличия багов. Именно поэтому большинство задач разработчиков после ревью кода (рецензирования) переходит на следующий этап - тестирование. Здесь подключаются тестеры, которые получают новую версию приложения от разработчика, устанавливают его на тестовый стенд (сервер) и начинают делать самое интересное: пытаются его всячески сломать самыми изощренными способами.
Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.
А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.
Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷♂️. Как думаете, почему?
Post #20
166