Холиварофорум
Вы не вошли.
Объявление
Холиварка празднует День Чтеца!
Ознакомиться с праздничными чтениями можно в соответствующем разделе
#1 2014-04-18 11:36:50
- Анон
Тема айти
Каталог полезных советов и ссылок, принесенных разными it-анонами, c 1-й по 332-ю страницы:
Пока, вроде, полет нормальный, ттт. #501 2017-09-30 18:23:58
- Анон
Re: Тема айти
При ручном тестировании чёрным ящиком и не надо разбираться в коде,
Ну, знаешь, посматривать в инспектор и в консоль браузера не помешает. Чтобы хотя бы знать, на чьей стороне проблема. Например, данные с формы не сохраняются. Мне, верстальщику, ставят баг с такой формулировкой. Я иду и проверяю, что запрос на бек ушел, почему он там дальше неправильно обработался - не мои проблемы. Так нафига баг стоит на мне? Мне кажется, это вполне может определить тестировщик. И такого дофига.
#502 2017-09-30 18:30:48
- Анон
Re: Тема айти
Проверить, не выскочила ли ошибка скрипта, ушёл ли запрос, или приложить логи сервера не значит разбираться в коде.
#503 2017-09-30 19:00:03
- Анон
Re: Тема айти
Слушай, а у вас нормальное тестирование? Потому что мне иногда кажется, что наша только и может, что руками в кнопочки на сайте тыкать, а в коде вообще ничерта не понимает.
Это моя главная боль после дизайнерши ) у нас ручное тестирование, сейчас девица вообще тупенькая, например
Так нафига баг стоит на мне? Мне кажется, это вполне может определить тестировщик.
Я иду и ругаюсь с тестировщицей или с пм-кой или с обеими сразу, или с тем, кто пилил бэк 
Или сама правлю, если настроение хорошее и мне по зубам .
#504 2017-09-30 20:24:02
- Анон
Re: Тема айти
Проверить, не выскочила ли ошибка скрипта, ушёл ли запрос, или приложить логи сервера не значит разбираться в коде.
Ну вот у нас, судя по всему, тестировщица даже базовыми знаниями не обладает. Отсюда и результат.
Это моя главная боль после дизайнерши )
Не дай бог начнется срач на тему того, кто и что должен знать, но я всё-таки прошу кулсторей)) Поорать про дизайнеров - что может быть лучше? XD
Смотрю гит - он, сука, месяц существует и тестировщица его не видела вообще
Бывает так, да. Очень бесит. Какое-нибудь подчёркивание ссылочки заметит, а два запроса вместо одного - фиг.
Ещё люблю, когда условия воспроизведения бага приходится самой выяснять. Формулировка задачи будет что-то вроде "фоточка загружается через раз", а на деле окажется, что она не загружается, только если её повернуть боком увеличить и два раза повернуть в другую сторону 
Я иду и ругаюсь с тестировщицей или с пм-кой или с обеими сразу, или с тем, кто пилил бэк Или сама правлю, если настроение хорошее и мне по зубам .
Я как-то стесняюсь)) Положение у меня немного не то, чтобы учить работать человека, который работает сильно дольше меня, и все ж в своей работе, наверное, получше меня разбирается.
#505 2017-09-30 21:16:22
- Анон
Re: Тема айти
ИМХО это все потому что тестирование было разрекламировано, как простой способ "войти в АйТи", и вот туда рванули студенты и те, кто надеялся, что это реально простой способ загребать бабло.
Окей, простое ручное тестирование - тоже нужно. Но упс, его недостаточно.
#506 2017-09-30 21:23:58
- Анон
Re: Тема айти
ИМХО это все потому что тестирование было разрекламировано, как простой способ "войти в АйТи", и вот туда рванули студенты и те, кто надеялся, что это реально простой способ загребать бабло.
Окей, простое ручное тестирование - тоже нужно. Но упс, его недостаточно.
Ну яхз кто сейчас этих войтивайтишников берёт.
Первая работа у них это всегда трамплин - поучиться и нарисовать релевантного опыта в резюме, как только там проявляется способность приносить пользу работодателю, то сразу же идёт соскок в другую фирму.
#507 2017-09-30 22:48:54
- Анон
Re: Тема айти
Окей, простое ручное тестирование - тоже нужно. Но упс, его недостаточно.
Для чего недостаточно? На каком проекте? С каким процессом разработки? Если хватает ресурсов провести регрессионное тестирование вручную между релизами, процесс тестирования нормально организован и документирован и qa участвует на всех этапах разработки начиная с формирования требований, то и простого ручного тестирования хватит для тестирования функционала. А если тестированием у вас занимается одна девушка, которая что-то там случайно иногда тыкает, то от того, что она будет так же случайно писать автотесты, которые что-то там случайно тестируют, ничего не изменится.
Отредактировано (2017-09-30 22:49:20)
#508 2017-09-30 23:01:35
- Анон
Re: Тема айти
Мне нравится этот подход. Один тестер на команду, автоматизации, похоже, нет (юниты хоть пишете, горе-разработчики?), т.е., весь регресс на ней, приемочное на ней, новые фичи на ней же, все это вручную - и ой-ой-ой, реквесты им смотреть не стали, просто написали функциональный баг. Может, за вас этот баг еще пофиксить и зачекинить? Вообще обалдели.
Отредактировано (2017-09-30 23:10:03)
#509 2017-09-30 23:13:28
- Анон
Re: Тема айти
А это... у меня тут знакомый есть, молодой, гуманитарий. Хочет войти в айти через ручное тестирование. При этом он, честно сказать, ленив и инертен.
Расскажите, кто знает, на сколько денег может претендовать полный ноль в дс на ручное тестирование. Или там вообще глухо, надо хотя бы курсы закончить? Или даже и после курсов фиг возьмут?
Если можно, то скажите без личного возмущения, дескать, "нет, такие нам не нужны, пусть даже не суется в айти". В смысле... как в реальности? Точно никто такого не возьмет или както можно попытаться?
Проведите плиз ликбез, для человека не в теме.
#510 2017-09-30 23:16:16
- Анон
Re: Тема айти
Я тоже читаю и охуеваю. Ай мин, это, конечно, хороший тон, прикладывать как можно больше информации и разбираться в причинах бага, но вообще она вам должна только шаги воспроизведения, по которым можно воспроизвести баг с первого раза, expected result и actual result. Тестирование оно вообще не про выяснение причин бага. Лид у вас, кстати, чем занимается, почему баги идут напрямую на разработчика, а не он решает, кому фиксить?
Отредактировано (2017-09-30 23:16:45)
#511 2017-09-30 23:44:13
- Анон
Re: Тема айти
Расскажите, кто знает, на сколько денег может претендовать полный ноль в дс на ручное тестирование.
В смысле, чтоб человек пришёл, сказал "я нихуя не умею, возьмите" и его взяли?
Такие времена если и были, то давно прошли. Ну или по очень хорошему знакомству разве что.
#512 2017-09-30 23:53:07
- Анон
Re: Тема айти
Анон пишет:Расскажите, кто знает, на сколько денег может претендовать полный ноль в дс на ручное тестирование.
В смысле, чтоб человек пришёл, сказал "я нихуя не умею, возьмите" и его взяли?
Такие времена если и были, то давно прошли. Ну или по очень хорошему знакомству разве что.
Ну типа того. Я такой умный, хороший, быстро учусь вот эти все слова стандартные, но... нихуя не умею возьмите)
1. Ну а что нужно уметь для ручного тестирования? На кнопочки тыкать и говорить "вот тут глюк" разве не любой может? Простите за нубские вопросы.
2. А что нужно знать по самому минимуму, чтобы при везении могли бы куда-то взять?
#513 2017-09-30 23:59:44
- Анон
Re: Тема айти
Вот тут, например, обзорно рассказывают про тест-дизайн и подходы к тестированию: http://33testers.blogspot.ru/2013/07/bl … 0.html?m=1
#514 2017-10-01 00:10:56
- Анон
Re: Тема айти
Мне нравится этот подход. Один тестер на команду, автоматизации, похоже, нет (юниты хоть пишете, горе-разработчики?), т.е., весь регресс на ней, приемочное на ней, новые фичи на ней же, все это вручную - и ой-ой-ой, реквесты им смотреть не стали, просто написали функциональный баг. Может, за вас этот баг еще пофиксить и зачекинить? Вообще обалдели.
Мне нравится, анон, как ты сходу рассуждаешь о нашей работе, не зная нихуя - ни сколько у нас "команд", ни сколько тестеров (я, кстати, писал, что она одна в принципе на всю компанию), ни о том, есть ли у нас вообще автоматическое тестирование. Но как же, наших бьют, промолчать нельзя.
Не надо за нас баги фиксить, мы сами справимся, спасибо. Только с таким тестированием разработчик и сам в состоянии справиться. Может тестировщики вообще тогда не нужны?
и ой-ой-ой, реквесты им смотреть не стали, просто написали функциональный баг.
То есть ты считаешь, что это как бы тестировщик делать и не должен. Окей. А что он должен тогда, если от него больше ничего и не требуется?
И нет, не "просто написали функциональный баг". Бага из-за дублирующего запроса нет (и задачи мне, соответственно, нет). Он просто лишний.
Я тоже читаю и охуеваю. Ай мин, это, конечно, хороший тон, прикладывать как можно больше информации и разбираться в причинах бага, но вообще она вам должна только шаги воспроизведения, по которым можно воспроизвести баг с первого раза, expected result и actual result.
Хреново ты читаешь, я смотрю. Я ж написал - формулировка бага четкой последовательности действий не содержит.
Лид у вас, кстати, чем занимается, почему баги идут напрямую на разработчика, а не он решает, кому фиксить?
Потому что кто разрабатывал проект - тот и правит. А как должно быть? Вася накосячил, а правит пусть Петя? С чего бы? Такое бывает только если Вася занят срочным проектом фулл-тайм. В остальных случаях сам накосячил - сам исправляй. Это и проще и правильнее.
#515 2017-10-01 00:14:37
- Анон
Re: Тема айти
Только с таким тестированием разработчик и сам в состоянии справиться. Может тестировщики вообще тогда не нужны?
Блин, я думала этот подход ушёл в 2000ых)))
#516 2017-10-01 00:29:01
- Анон
Re: Тема айти
А что он должен тогда, если от него больше ничего и не требуется?
Анон, я начала писать длинную простыню про планирование тестирования, тестовое покрытие, тест дизайн, тестирование требований и тд, но потом подумала, что ты можешь погуглить. Но я бы посмотрела, как разработчики в свободное от работы время справятся с поддержкой базы на нескольких тысяч тест-кейсов, например
#517 2017-10-01 00:41:10
- Анон
Re: Тема айти
Анон, я начала писать длинную простыню про планирование тестирования, тестовое покрытие, тест дизайн, тестирование требований и тд, но потом подумала, что ты можешь погуглить.
Зря не написал, я б почитал с удовольствием.
Если что, говоря про "больше ничего не требуется" я имел в виду именно нашу компанию, где нет никакого тестирования кроме ручного.
#518 2017-10-01 00:55:55
- Анон
Re: Тема айти
Но анон, я именно про ручное тестирование и говорю. Ты думаешь, ручное тестирование - это, я не знаю, кликать от балды, надеясь попасть на баг? Одна из целей тестирования, хоть автоматического, хоть ручного, - своевременно предоставить команде и менеджменту информацию о том, насколько продукт соответствует требованиям и ожиданиям. И для того, чтобы ответить на этот вопрос, в любом случае надо это тестирование планировать, проанализировать требования, проанализировать риски, написать тесткейсы, руководствуясь классами эквивалентности (выделить группы тестов, где протестировав один ты трестируешь все, и тестировать только один тест из группы) и граничными значениями, чтобы их одновременно было достаточно для тестового покрытия, но не избыточно, расписать негативные сценарии, потому что в требованиях о них обычно забывают, проанализировать, как новая фича повлияла на старый функционал и добавить в план какое-то количество старых кейсов. И вот когда у тебя есть план тестирования, можно начинать кликать. И это - все ещё ручное функциональное тестирование.
Отредактировано (2017-10-01 00:57:58)
#519 2017-10-01 01:21:26
- Анон
Re: Тема айти
Только с таким тестированием разработчик и сам в состоянии справиться. Может тестировщики вообще тогда не нужны?
Может и не нужны. Поговори с начальством, увольте тестировщицу, в идеале выкатите релиз под новый год, чтобы откатывать и чинить на продакшне пришлось под куранты и шампанское. Есть, анон, ровно два случая когда тестирование не нужно: первый, когда это технический продукт, хорошо покрываемый юнит и интеграционными тестами, и пишут и код, и тесты разрабы высокого класса. Библиотеки, иде, компиляторы живут по этому принципу.
Второй - когда на продукт очень мало обратной связи, или цена этой связи крайне невысока. Проще говоря, шарашкина контора, у которой критикал может жить в продакшне годами, а проблемы клиентов шерифа не волнуют.
Разработчики первой категории даже если и не пользуются выделенным QA, то обычно знают, для чего он нужен. Так что догадайся сам, какая категория у тебя.
Потому что кто разрабатывал проект - тот и правит. А как должно быть? Вася накосячил, а правит пусть Петя?
Правит кто накосячил. А знает, кто делал и накосячил, обычно лид, ему и распределять.
QA вообще не обязан знать, кто там в команде чем занимается. Примерно так же, как ты не обязан разбираться в работе QA (чем здесь старательно и гордишься)
И нет, не "просто написали функциональный баг". Бага из-за дублирующего запроса нет (и задачи мне, соответственно, нет). Он просто лишний.
Хреново ты читаешь, я смотрю. Я ж написал - формулировка бага четкой последовательности действий не содержит.
Лично я (и возможно, анон #509) отвечала про эту ситуацию:
Например, данные с формы не сохраняются. Мне, верстальщику, ставят баг с такой формулировкой. Я иду и проверяю, что запрос на бек ушел, почему он там дальше неправильно обработался - не мои проблемы. Так нафига баг стоит на мне? Мне кажется, это вполне может определить тестировщик.Если ты кроме своего поста про дублирующийся запрос нихрена не видишь, то может хреново читаешь ты, а не другие аноны?
То есть ты считаешь, что это как бы тестировщик делать и не должен. Окей. А что он должен тогда, если от него больше ничего и не требуется?
Ну и вот это просто бомба. Тебе, как деву, тестировщик должен сообщение о баге. А основным потребителем результатов работы qa является менеджмент, и ему требуется информация об общем качестве продукта, соответствии требованиям и возможности выпуска в релиз.
Отредактировано (2017-10-01 01:22:15)
#520 2017-10-01 01:48:50
- Анон
Re: Тема айти
Но анон, я именно про ручное тестирование и говорю.
Анон, это всё замечательно, но какая мне разница, пишет он там тесткейсы или не пишет? Я начал с того, что тестировщик не замечает баг, потому что не смотрит реквесты. Его задача (как минимум одна из) - баг найти. Планирует он там свою работу или нет - мне не важно. Так что я не очень понял, к чему ты это, прости.
Может и не нужны. Поговори с начальством, увольте тестировщицу, в идеале выкатите релиз под новый год, чтобы откатывать и чинить на продакшне пришлось под куранты и шампанское. Есть, анон, ровно два случая когда тестирование не нужно: первый, когда это технический продукт, хорошо покрываемый юнит и интеграционными тестами, и пишут и код, и тесты разрабы высокого класса. Библиотеки, иде, компиляторы живут по этому принципу.
Второй - когда на продукт очень мало обратной связи, или цена этой связи крайне невысока. Проще говоря, шарашкина контора, у которой критикал может жить в продакшне годами, а проблемы клиентов шерифа не волнуют.
Разработчики первой категории даже если и не пользуются выделенным QA, то обычно знают, для чего он нужен. Так что догадайся сам, какая категория у тебя.
Это вообще-то был сарказм. Но нет, критикал баги у нас годами не висят. Не всё в мире чёрно-белое.
QA вообще не обязан знать, кто там в команде чем занимается. Примерно так же, как ты не обязан разбираться в работе QA (чем здесь старательно и гордишься)
Смотря какие масштабы у компании. Можно вообще всё деловое общение вести исключительно через таск-трекер, но иногда проще прийти и спросить. У нас тестировщик знает, кто чем занимается. Моя претензия не к тому, что он не разбирается в чужих обязанностях, а в том, что он не знает, на чьей стороне баг. Можно и на дизайнера его поставить, чего бы нет, никто ничего знать не обязан.
Лично я (и возможно, анон #509) отвечала про эту ситуацию:
Например, данные с формы не сохраняются. Мне, верстальщику, ставят баг с такой формулировкой. Я иду и проверяю, что запрос на бек ушел, почему он там дальше неправильно обработался - не мои проблемы. Так нафига баг стоит на мне? Мне кажется, это вполне может определить тестировщик.
Если ты кроме своего поста про дублирующийся запрос нихрена не видишь, то может хреново читаешь ты, а не другие аноны?
Это моё сообщение и было
Ну и вот это просто бомба. Тебе, как деву, тестировщик должен сообщение о баге.
Да ёбаный ты ж нахуй. Анон, скажи честно, ты тестировщик? Чего орешь так, как будто тебе на хвост наступили? Я и пишу о том, что мне, как деву, тестировщик должен сообщение о баге, а я это сообщение не получаю, потому что тестировщик не смотрит в консоль. На что ты начинаешь орать, что никто мне ничего не должен и вообще у тестировщика и без меня дел полно.
#521 2017-10-01 08:58:44
- Анон
Re: Тема айти
Ты спросил, что должен делать qa (хотя у вас скорее qc), раз от него, кроме багов, ничего не требуется, я ответила. Потому что от него требуются как раз не просто баги, а общая картина того, что происходит с системой, чтобы менеджмент мог принять решение о релизе. И да, для этого в том числе надо подтвердить, что описанный в требованиях функционал работает, системно покрыв его тестами и проверив, и это тоже будет являться результатом работы отдела тестирования.
Этот твой двойной реквест вообще как-то влияет на функционал или это внутренние явно не видимые конечному пользователю заморочки? Он прописан в функциональных требованиях?
Я тестировщик, и ты судишь о тестировании настолько безграмотно, что у меня глаз дёргается. Я понимаю, что скорее всего ты просто слаще редьки ничего не видел и не работал с нормально организованным qa, но все равно. Просто я уже много лет не сталкивалась с таким подходом от девелоперов и, видимо, отвыкла.
#522 2017-10-01 13:35:42
- Анон
Re: Тема айти
Ты спросил, что должен делать qa (хотя у вас скорее qc), раз от него, кроме багов, ничего не требуется, я ответила.
Я пояснил, что я имею в виду конкретно нашу компанию. Ты описываешь ситуацию в идеальной компании, где всё по уму. У нас я, честно признаюсь, ничего подобного не слышу. Тестеру дают тз и макеты. Он идет и методично во всех браузерах и на всех устройствах протыкивает весь сайт. Когда разрабы закроют все баги, поставленные тестером - проект запускается (после последней итерации тестирования, конечно). К тестеру никто не идёт и не просит от него ни общую картину, ни чего либо ещё. Баги закрыты - значит, ок.
Этот твой двойной реквест вообще как-то влияет на функционал или это внутренние явно не видимые конечному пользователю заморочки? Он прописан в функциональных требованиях?
Это, конечно, не видимые пользователю заморочки. Но пользователю много чего не видно. Упомянутое мной подчеркивание ссылки в каком-то конкретном месте тоже на функционал не влияет.
В функциональных требованиях прописано, что вот здесь должно происходить заполнение формы, например, и данные должны сохраняться. Сколько при этом должно идти запросов - естественно, никто не пишет. Но неужели их можно сделать 10 вместо одного, раз там не написано и пользователь не видит? С таким подходом можно много чего наворотить.
Я понимаю, что скорее всего ты просто слаще редьки ничего не видел и не работал с нормально организованным qa, но все равно.
This, анон. Я не говорю обо всей области тестирования. Я говорю конкретно о своей компании. Нет, у нас не шарашкина контора. Просто, видимо, специфика области.
#523 2017-10-01 23:14:32
- Анон
Re: Тема айти
Анон, это всё замечательно, но какая мне разница, пишет он там тесткейсы или не пишет? Я начал с того, что тестировщик не замечает баг, потому что не смотрит реквесты.
Это моё сообщение и было
Товарищ, у тебя какая-то беда то ли с формулировками, то ли с логикой. Ты начал с того, что тестировщик завел на тебя баг о том, что не сохраняются данные с формы. Откуда внезапно взялось, что тестировщик баг не замечает? Факт не соответствующего поведения в трекер занесен, усе.
он не знает, на чьей стороне баг.
В двадцать пятый раз говорю: и не обязан.
Анон, скажи честно, ты тестировщик? Чего орешь так, как будто тебе на хвост наступили?
Тестировщик. А ору потому, что, как заметил коллега выше, от твоих представлений о тестировании глаз дергается. И это еще очень мягкое высказывание.
Я и пишу о том, что мне, как деву, тестировщик должен сообщение о баге, а я это сообщение не получаю, потому что тестировщик не смотрит в консоль. На что ты начинаешь орать, что никто мне ничего не должен и вообще у тестировщика и без меня дел полно
Сообщение о баге, по твоим же словам, у тебя было. Или ты под сообщением о баге стектрейс имеешь в виду?
"Не должен" относилось к претензии, что тестер обязан смотреть реквесты и по ним выяснять, на чьей стороне ошибка. Вот этого он действительно делать не должен.
Кстати, что-то мне кажется, что логирования бэка у вас либо нет, либо хреновое. Если для того, чтобы определить что валится сохранение там, надо реквесты смотреть, а не лог.
Это, конечно, не видимые пользователю заморочки. Но пользователю много чего не видно. Упомянутое мной подчеркивание ссылки в каком-то конкретном месте тоже на функционал не влияет.
Отсутствие подчеркивания у ссылки, если в других местах они подчеркиваются - это плохой юзер экспириенс. И пользователю очень даже заметно.
Сколько при этом должно идти запросов - естественно, никто не пишет. Но неужели их можно сделать 10 вместо одного, раз там не написано и пользователь не видит? С таким подходом можно много чего наворотить.
Дорогой мой, об этом вы, девелоперы, должны думать. И никто иной.
И да, извини, но по всему, что ты здесь пишешь, у вас именно что шарашкина контора. Или, возможно, конкретно твое подразделение неудачное.
Отредактировано (2017-10-01 23:16:52)
#524 2017-10-01 23:40:02
- Анон
Re: Тема айти
Откуда внезапно взялось, что тестировщик баг не замечает? Факт не соответствующего поведения в трекер занесен, усе.
Оттуда, что я три случая описывал.
В двадцать пятый раз говорю: и не обязан.
Окей, никто никому ничего не должен.
А ору потому, что, как заметил коллега выше, от твоих представлений о тестировании глаз дергается. И это еще очень мягкое высказывание.
Я свои представления о тестировании держу при себе. Писал, повторяю, о конкретно нашем рабочем процессе и том, что мне в нем кажется неправильным. И если с вопросом о том, кому ставить баг, ещё можно согласиться, то недописанные шаги воспроизведения бага вы почему-то тактично обходите молчанием.
"Не должен" относилось к претензии, что тестер обязан смотреть реквесты и по ним выяснять, на чьей стороне ошибка. Вот этого он действительно делать не должен.
Окей, я готов с этим согласиться. Ещё претензии ко мне есть?
Отсутствие подчеркивания у ссылки, если в других местах они подчеркиваются - это плохой юзер экспириенс. И пользователю очень даже заметно.
Пошёл разбор частных случаев. Где-то подчёркивается, где-то нет, где-то это место - единственное подобное на всем сайте. Я не говорю, что это не баг, я говорю, что пользователю это может быть не важно (если, к примеру, у этой ссылочки меняется цвет).
Для юзера это может быть важно только если у этой ссылочки нет никакого другого выделения и он её тупо не заметит. Если она в этом месте не подчеркивается (но имеет другое выделение), а в других да - юзер от этого сайтом пользоваться не перестанет.
Дорогой мой, об этом вы, девелоперы, должны думать. И никто иной.
Дорогой мой, я и не говорю, что об этом должен думать кто-то кроме меня. Но что-то мне подсказывает, что раз лишний запрос - это баг, то при тестировании его должны найти. Мне не важно, каким образом. Или я снова ошибаюсь?
И да, извини, но по всему, что ты здесь пишешь, у вас именно что шарашкина контора. Или, возможно, конкретно твое подразделение неудачное.
Ну-ну. Ты, анон, как в вебе вообще, работал? Когда компания долго пилит один продукт, не важно, для себя или клиента - там будет и тестирование нормальное и разработка хорошо организована. А когда компания делает корпоративные сайты клиентам - никого там не ебет ни качество кода, ни тестирование должным образом, нихрена. Роляет скорость и чтоб работало, хотя бы внешне.
Отредактировано (2017-10-01 23:47:05)
#525 2017-10-02 00:23:49
- Анон
Re: Тема айти
Анон, организованный процесс тестирования не тормозит процесс разработки. Я раньше работала в вебе для клиентов, где быстро клепали сайты, все равно тщательно тестировали, ручное тестирование, но с организованным процессом. А если есть нормальная инфраструктура для автотестов, сильная команды и желательно написан фреймворк под себя, то автотесты тоже быстро пилятся, параллельно разработке, и потом регрешн можно хоть на каждый коммит гонять.
Твои два невидимых запроса при функциональном тестировании скорее всего действительно никто не найдёт, если они никак не влияют на задокументированные в требованиях функции программы, это вопрос реализации, который остаётся на откуп разработке. Юзер их не видит, на функции не влияет, функциональным требованиям программа соответствует. Тут скорее при перформанс тестинге могут вылезли вопросы, но его вручную обычно не делают, там своя специфика.
Другой тестер