Комментарии 25
Ничего не понял, но, полагаю, они не удаляются, судя по коду, и никакие точки останова не нужны, ибо не тот код, чтобы с этим заморачиваться, слишком простой. А у вас отсутствие понимания назначения спойлеров. И странно, что 2000 мс у вас равно 0,5 с.
И так полстатьи скрыто. Нафига? ))
Я конечно, видел, как люди (не умея в автотесты) занимаются мастурбацией тупой работой каждый раз тестируя какое-либо изменение в коде руками (запускают все приложение и начинают там что-то вбивать и мышкой елозить), но такой жести, чтобы тестировали отладчиком с помощью точек останова я еще не встречал.
И еще. У вас на скриншотах простой, обычный JS. Попробуйте это провернуть с каким-нибудь приложением angular, которое до того как уходит в браузер сначала transpile-ится, пакуется, и минимизируется. Потому что сто лет прошло, а source map в JS так толком и не работает, и, обычно, единственно действующий вариант это вставлять в исходный код руками console.log('Я тут!); и искать нужное место через выхлоп в окне консоли.
А можно просто дать ссылку на Гугл хром девтулз ну чтоб человек ничего не пропустил мало ли
QA теперь ещё и отлаживать код должны? Исправления к найденным ошибкам тоже QA писать должны? Простите, несколько оторвался от жизни.
Если планируете стать QA senior в большой ИТ компании, то должны. Если оставаться на уровне принеси-подай, то не должны получается)
А можно сразу без ручного тестирования, в авто джуном попасть? Или это называется sdet и ты всё равно типа разработчик.
Зачем тогда Dev, если QA это может делать? Сгенерил код в ChatGPT и отдал "QA senior в большой ИТ компании на отладку". Похоже Вас на текущем месте разводят что вы QA, на самом деле вы джун Dev, который реально "принеси-подай" для Senior Dev.
JavaScript для QA - это автоматизированные тесты на playwright/cypress/etc. для этой функциональности.
Да и разве IDE не будет дебажить код гораздо эффективней чем DevTools. Нельзя проблему из статьи попытаться повторить локально через IDE и в ней поймать ошибку? Но опять же, зачем мне как QA это когда либо делать?
Статья о переходе из метода черного ящика в метод серого и белого. Писать про IDE я буду уже для junior+ и middle. Если QA специалист (ключевое слово специалист) владеет навыками Dev, то это не означает, что он это будет делать за разработчика)))) Советую перечитать вступление. Devtools для всех необходим и писать «Зачем ты сюда лезешь, закрой» прям по-детски?
Как QA могу сказать, что всякое приходится делать. Да, если вы откроете ISTQB, то там скажут, что мы баги ищем, а разработчики дебажат.
По факту же, баги могут быть такие, что не посмотрев в код, до нормальных степов чтобы её зарепродюсить ты в разумные сроки не доберёшься. Многие, собственно, и не добираются, создавая вечно весящие в беклоге ошибки с заголовком, начинающимся с "иногда...". При чём хорошо, если это будет "иногда...". Это может быть описано так, будто происходит всегда и при любых условиях. В реальности у разработчика проблема не повторяется, и бага закрывается.
Так что соглашусь с автором: хотите приносить пользу и чего-то достичь в профессии, придётся что-то уметь.
Очень странная статья. Как можно вести web разработку, не зная данных элементарных вещей ?
То, что лучший тестировщик - это тот, кто баг не только нашел, но еще и пофиксил, - это уже бородатый анекдот. Но то, чтобы тестировщики за разработчиков еще и отладку кода делали - это что-то новое. ?
Мануальный тестировщик (в отличие от автоматизатора) не занимает отладкой кода. Это всё-таки обязанность разработчика, как и написание юнит-тестов, и баг-фиксинг, и желательно смоук-тестинг разработанной им же фичи.
Тут хочу пару слов добавить о всё-таки правильном употреблении терминов.
Метод черного ящика - это когда тестировщик делает тестовое покрытие на основе требований и их приемочных критериев. То есть тестировщик читает приемочные критерии и придумывает тесты, которые будут проверять эти приемочные критерии. При этом он может иметь доступ к коду и даже прекрасно в нем разбираться. Но в данном методе эти знания тестировщик не использует, т.к. цель - проверить запланированное ВА/РО поведение фичи/системы без привязки к тому, как именно разработчик его реализовывал.
Метод белого ящика - это когда тестировщик делает тестовое покрытие на основе кода/архитектуры приложения. То есть условно, когда фича сделана, тестировщик открывает код и придумывает тесты, которые будут проверять именно этот код. И для этого существуют специальные техники тест-дизайна, отличающиеся от тех, что применяются в методе черного ящика.
Так что методы тестирования - это о подходе к тест-дизайну, а не о том, знает или не знает тестировщик код. Поэтому на самом деле нет в тестировании метода "серого" ящика. Как нет ни красного, ни желтого, ни т.п. "цветных" методов (хотя и такие в статьях встречаются). Если что - это можно перепроверить по ISTQB Glossary или Syllabus (раздел 4).
Спасибо за письмо! А вы такие письма пишите только когда не согласны с терминами или же еще и хвалите за проделанную работу?
Подскажите, за что похвалить :) Вы перешли в автоматизацию и теперь умеете дебажить код в девтулз. Разве это не обычный базовый навык автоматизатора и разработчика?
Вы хотели поделиться своими новыми знаниями и помочь коллегам? Может, тогда стоило подсветить ценность этой информации не через призму, что якобы мануальный тестировщик, не занимающийся дебаггингом в Devtools и поиском в ошибок в чужом коде, - это пока еще несамостоятельный и с закрытыми глазами тыкающий исследовательское тестирование. А ну и еще он так и останется, по вашему мнению, на уровне принеси-подай.
Хотя, как вам верно подсветили, компетентность мануальных тестировщиков определяется не по умению работать с кодом или дебажить его за разработчиками.
Ну а терминологию тестирования - да, знать полезно.
Большие ИТ компании не стоят на месте и модернизируют взаимодействие внутри команды. Вы можете ссылаться на ISTQB и доказывать теорию. Практика всегда будет отличаться и это не дает вам право жонглировать разделами. Статья про то как стать самостоятельнее. Есть тестировщики, которые переходят из тестирования в fronted dev и для них это будет полезно. И судя по вашей реакции вы вообще любите учиться новому? QA Lead…
Если разработчик решит перейти в проджект менеджмент, разве это будет означать, что он "вырос", стал самостоятельнее и компетентнее в разработке? Так и у всех остальных: если тестировщик захочет перейти в ВА, автоматизацию, разработку, девопс ... - это не рост, а просто смена профессии.
А сарказм ваш зря. Это полезно - знать и понимать терминологию своей профессиональной области. Обычно от практики она как раз-таки и отличается там, где её или не знают, или неправильно понимают/применяют.
P.S. Новому учусь, учиться люблю. :)
Ну смотрите, если человек всю жизнь хочет быть QA и не стремиться к дальнейшему развитию, то, пожалуйста, можете забыть о дебаггере. Но если вы хотите развития своих компетенций, почему бы и нет? Любопытство - это свойство, присущее человеку и животным
JavaScript для QA. Фронтендер учит дебажить код через Devtools