TGViewer
QA HELP QA HELP @qa_help · 94 subscribers
Post #20 166
#Ролевыеигры

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

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

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

И было бы все замечательно, если бы не одно НО: разработчики, помимо кода, создают баги🙂

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

Пример. Разработчик добавил в приложение поле для ввода электронной почты - поле действительно появилось в приложении и в него можно ввести e-mail. Но тут тестировщик, проверив это, начинает думать: “А что, если я введу почту без @ или без .ru? А что, если в этом поле я укажу только цифры? А если напишу адрес на другой раскладке клавиатуры или укажу китайские иероглифы?”. Наконец, сломав приложение довольный (или не очень) тестировщик идет к разработчику и рассказывает, что когда он вводит 20 и более символов в это поле, то получает в ответ ошибку 500 и приложение перестает работать. Разработчик начинает фиксить проблему, снова передает тестировщику и в этот раз наконец-то все работает корректно: теперь это поле можно будет показывать пользователям.

А вот вам и первое #тестовое_задание.
По спецификации при оформлении заказа в одном российском интернет-магазине пользователь должен ввести в одно из обязательных полей название своего города с большой буквы и на кириллице. Во всех иных случаях пользователю выводится сообщение: “Неверное имя города. Пожалуйста, укажите название вашего города с большой буквы на кириллице, например, “Москва”.

Тестировщик набросал несколько проверок и в случае, когда он ввел “Омcк”, получил то самое сообщение, но к разработчику не пошел🤷‍♂️. Как думаете, почему?
More from @qa_help
  1. Nov 4, 2021Обещал рассказать про Agile-конференцию, но мы с нашей командой настолько погрузились в вы…
  2. Oct 22, 2021Тинькофф сегодня проводит Agile-конференцию в Москве для руководителей, продактов, тимлидо…
  3. Aug 18, 2021Сегодня немного необычный пост - про карго-культ😳. Я случайно прочитал на днях статью про…
  4. Mar 31, 2021Провёл пару вечеров за перечитыванием отличной настольной книги для тестировщиков, тимлидо…
  5. Dec 14, 2020photo post
  6. Dec 14, 2020Мой товарищ (и он же Java-разработчик по совместительству), недавно понял, что нет (наверн…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →