Думаю, всех раздражают неумные тестировщики, которые больше задают вопросы о том, как это должно работать, и отнимают время разработчика, чем собственно тестируют.
Так вот, здравствуйте, на этой неделе это я. Пять лет опыта тестирования, перескакивание с одной области (мобилки) в другую (веб/энтерпрайз). Даже хорошие отзывы о моей работе были, мамой клянусь!
Но сегодня третий день, как я мучаю разработчика тупыми вопросами и не могу пройти позитивный сценарий хоть в какой-то вариации. Предлагаю немного разобраться в ситуации и выяснить, почему тестировщик с квалификацией как минимум миддл при работе над задачей кажется тупым, как пробка.
-
У него недостаточно накопленных знаний о проекте
…для работы в текущих процессах. Я искренне убеждена, что при идеально отлаженных процессах свои задачи смогут выполнять даже обезьяны. Но отлаженные до такой степени процессы — утопия, недостижимая мечта. Реальность же оборачивается отсутствием документации, аналитика, у которого можно спросить всё, и нормального описания задач. Спасением здесь может быть хорошая погружённость в предметную область или опыт работы на проекте («мы такое уже делали полгода назад в задаче Х»). Но не всегда они есть.
-
Он действительно недостаточно/слишком умён
…для работы на текущем проекте/над текущей задачей.
Даже в диких условиях чистого ад-хок тестирования люди выполняют свою работу, находят баги, спасают релизы от блокеров и помогают команде достичь счастья заказчика при выпуске релиза. При этом условный Вася гордо держит голову и вывозит, а условный Игорь на более простой задаче замучил вопросами уже всю команду настолько, что все, кроме него, проставили себе статус «на собрании» и не отвечают на сообщения. Особенно Вася.
Причина проста, как чистый лист: у каждого человека есть свои ограничения при выстраивании логических связей о работе продукта. И для кого-то уложить в голове все зависимости в рамках области функциональности в энтерпрайзе даже за полгода — невыполнимая задача. Зато он с легкостью и задором проверит все UI элементы там, где критически важен UI, ещё и дизайнеру укажет на несоответствие гайдлайнов, а «энтерпрайзер» впадёт в уныние уже на четвёртой кнопке и будет требовать вернуть его в родные SQL' и и консоль. Возможно, начнёт писать скрипт по сверке цветов кнопок и потратит на задачу в три раза больше времени.
-
Способность удержания фокуса внимания
Фича на 40 часов, а у тестировщика через пять часов работы обнуляется мозг. И всё по новой. Затупы, паника, выгорание и вопросы.
И наоборот — фича на пять часов, а тестировщик полноценно переключится с предыдущей задачи только через три часа курения документации и тыканья кнопок по новой таске. Затупы, паника...
-
Выученная беспомощность и неумение «гуглить» по документации и задачам.
— Я не вижу кнопку «Редактировать», а фича про изменение цвета кнопки на странице редактирования.
— Она отображается только для «Админа»Когда вам задают вопрос, ответ на который очевиден — выждите пятнадцать минут. Возможно, за это время спрашивающий смирится, что не получит быстрого ответа, подумает, что он может сделать сам, и этот самый ответ найдёт. После нескольких повторений — поверит в себя и начнёт сначала искать информацию, а потом спрашивать. Но злоупотреблять этим методом, конечно, не стоит. В конце концов, например, в функциональности, над которой бьётся тестировщик, спрятался блокирующий баг, и тогда сам он не справится.
-
Разная трактовка задачи
Сколько песен об этом спето, сколько абзацев во всевозможных обучающих трактатах написано! Разработчик понял задачу так. Тестировщик — эдак. И пытается тестировать так, как понял. И всё время всё не складывается.
Тестировщик, скорее всего, в абсолютно шокированном состоянии, потому что ничего не работает. Разработчик после тонны вопросов, скорее всего, в несколько другом состоянии, но тоже не позитивном.
Созвонитесь, поговорите, выясните, кто, что и как понял. По спорным моментам привлеките третье лицо, которое сможет точно сказать, что тут всё-таки нужно.
Время всё равно будет потрачено. Но при разговоре — с двойной продуктивностью: и вопросы будут обозначены, и более-менее контакт налажен. После наладки контакта до 100% читать задачи будете одинаково. Возможно даже, что одинаково неправильно (тогда это беда, а не тестировщик, конечно).Чтобы минимизировать такие ситуации существует, тестирование требований, которое позволяет избавиться от неоднозначного прочтения. Разумеется, для этого нужно нормальное описание требований. И небольшая магия со временем, чтобы на тестирование документации оно выделялось.
-
Отсутствие описания реализации функциональности
«Я нажал кнопку и всё сломалось». «Я отправил POST запрос, ответ 200, а сущность на сайте не появилась, не понимаю, что произошло, в логах криминала не вижу».
На самом деле такого зверя — описание реализации — в жизни в глаза не видела (и возможно он как‑то по‑умному называется). Зато неоднократно писала. Данные из поля А передаются в запросе U как значение L, записываются в таблицу S столбец K потом вычитаются, уже обработанные, из другой таблицы.
Это первое, что должен спросить тестировщик после разработки задачи. Что именно было сделано. Какие таблицы и поля затронуты, где что смотреть и как отслеживать. Какие контракты апи изменены/добавлены, и как это всё связано.
Причём если это не зафиксировано текстом в документе конфлюенса, то через полгода, когда всплывёт баг в этой области, тестировщик или саппорт снова придёт с теми же вопросами.
Почему-то эта тема, в отличие от тестирования требований, поднимается редко. Но переоценить её сложно: это и снижение количества вопросов, и уточнение оценки тестирования, и оптимизация тест-кейсов по факту, и прокачка в технических дебрях. Да, и если у вас есть техподдержка с доступом к БД — они скажут спасибо за такое описание.
Можно, конечно, попробовать хранить эту информацию в шагах тест-кейсов. Но это всё ещё значит, что тестировщик должен выпытать информацию у разработчика, потом занести все проверки баз данных в шаги тест-кейсов, а когда информацию придётся восстанавливать в памяти — откапывать все тест-кейсы, возможно связанные с этой функциональностью, и смотреть, где какое поле на что влияет.
-
Неинформативные ошибки в логах
Та же история — «я нажал кнопку и всё сломалось, что‑то не так». Опытный и (как следствие) достаточно наглый тестировщик просто заведёт баг на неадекватные тексты ошибок. И будет прав. Неопытный будет ходить за расшифровкой логов по каждой ошибке к разработчику. Или аналитику. Или другому тестировщику. На что хватит фантазии.
То же будет с ошибками на бою.
Сейчас в вакансиях часто светится, мол, нужно умение читать лог приложения. На такие вакансии не откликалась, но очень хочется парировать: нужно писать нормальные ошибки в лог, чтобы они были информативны — тогда в него будут заглядывать. А неинформативные логи да, не умею читать. Могу кусок кода из экспекшна заскриншотить и кинуть разработчику.
-
На самом деле никто не знает, что должно быть реализовано в фиче
Боль маленьких команд, отсутствия аналитика и подхода «быстро‑быстро и в продакшн» (иногда немного виновато легаси).
В качестве примера можно привести мои любимые сортировщики на сайтах с товарами — ну, тех самых, где сортировка по цене идёт с вариантами «А‑я» и «я — А». Вроде всё очевидно — убывание и возрастание, какие тут могут быть вопросы. Но приблизим задачу к более реальной для бэка, а не фронта. Предположим, что у нас в БД три столбца: название товара, цена и валюта. И валюты бывают разные! А сортировка «А‑я». Это сначала по валюте сортируем? Или всегда по значению цены? Или доллары переводим в рубли и сортируем по цене? Или если пользователь из России — исключаем товары с валютой USD и выводим только рублёвые в порядке убывания?
Каждый такой шаг при тестировании оборачивается ответом «сейчас уточню», вопросом к заказчику, в особо тяжёлых случаях ещё и ответом «да всё равно как, главное, чтобы сортировка была». И задача растягивается, растягивается… прокачки по предметной области не происходит, количество «тупых» вопросов только увеличивается («пользователям из Белоруссии доллары показываем? — нет, не очевидно, что не показываем — а из Казахстана?»). Тестировщик выгорает, разработчик выгорает, менеджер рвёт волосы на головах разработчика и тестировщика и просит как‑то уже эту задачу закончить и выпустить.
К сожалению, решение этой проблемы требует многих телодвижений. В частности, введения процесса ревью требований, в том числе со стороны разработки. То есть ещё сначала нужно нормально требования прописать. А потом заставить как-то команду их просмотреть. В качестве финала ревью требований назначить встречу и дополнительно всех замотивировать задавать вопросы, которые потом ещё и разрешать придётся. Мрак, в общем. И ничего бы не было, если бы тестировщик вопросы свои глупые не задавал!
Безусловно, почти всё решается адекватным ТЗ, наличием документации по проекту, анализом и тестированием требований.
Легче дышать, если кто-то умный и педантичный до вас подробно описал тест-кейсы для всяких разных случаев. И обновлял их. Спасибо такому человеку, даже если это вы сам в прошлом.
Что-то решается корректировкой процессов. Что‑то — только сменой работы.
Если у вас нет никаких из этих проблем — мои искренние поздравления!
А я, собрав комбо из нескольких пунктов сразу, пока продолжу быть тупым тестировщиком. С надеждой «поумнеть» после ближайшей ретроспективы :)
Комментарии (38)
stackjava
24.07.2023 16:47+2А где пункт, когда тестер не понимает элементарно, что когда в таблице бд он не заполнил поле, то с бэка приходит пустым это поле... И достаточно наглый (судя по всему, несильно то и смекалистый) тестировщик заводит баг.
А как же пункт, когда тестиррвщик не видит на фронте в списке нужного элемента, и вместо того чтобы узнать, что приходит с бэка, тупо заводит баг на бэк... А косяк на фронте... А постманом запросить бэк слишком мудро... Проще баг.
happymammont Автор
24.07.2023 16:47я совершенно неслучайно прописала пункт 2 про то, что тестировщик действительно может быть недостаточно умён :)
но на самом деле это больше подходит под незнание работы системы. Просто вот у этого отдельно взятого тестировщика не выстроены правильные нейронные связи о том, откуда что берётся и куда идёт. Я на вебе именно так и туплю. При этом в мобильных приложениях почему-то взглядом наискосок понимаю, фронт или бэк виноват, с безошибочностью в 80%
diakin
24.07.2023 16:47+3Дело в том, что сообразительность тестировщика не должна превышать сообразительность самого "тупого" юзера, который будет работать с программой.
И если тестер что-то там не завел, то ему должно приходить сообщение, какую ошибку он сделал и как ее исправить. Потому что потом эту ошибку сделают 100500 юзеров и будут каждый раз звонить в поддержку, которая будет вынуждена на словах им все объяснять.
Hardcoin
24.07.2023 16:47+2Должна. Тестировщик может с некоторой вероятностью определить, является ли ситуация невнятным текстом ошибки (т.е. ошибка должна происходить, но с другим описанием) или это баг, который требуется починить.
diakin
24.07.2023 16:47Ну может и так, это зависит от того, что на тестировщика возложить. Должен ли он разобраться, откуда ноги растут или просто зафиксировать ошибку и описать ситуацию.
happymammont Автор
24.07.2023 16:47+3Дело в том, что сообразительность тестировщика не должна превышать сообразительность самого «тупого» юзера, который будет работать с программой.
После полугода ежедневного тыкания в одно и то же приложение любой человек будет ориентироваться в системе лучше, чем даже умный средний пользователь.
Это неизбежно. Да, из этого могут возникнуть проблемы (и поэтому я всегда радуюсь новичкам на проектах). Мой способ - глядя на новую фичу представлять себе, что с этим делала бы моя бабушка. Иногда помогает
Сообразительный и погружённый в проект тестировщик с большей вероятностью найдёт баги в затронутых фичой областях, при этом к фиче не относящихся. Более точно локализует проблему и сделает работу разработчиков более комфортной. Отловит те баги, которые пользователям вообще не видны, но влияют на метрики и внутренние процессы. Ну а ещё сможет протестировать интеграции, которые руками кроме тестировщиков вообще никто не трогаетИ если тестер что-то там не завел, то ему должно приходить сообщение, какую ошибку он сделал и как ее исправить.Да, тестировщикам для развития жизненно необходимо знать обратную связь от пользователей и информацию о том, какие ошибки они пропустили. Встречающаяся оторванность техподдержки от тестирования в этом ключе очень удручает.
А вот знать, как исправить - это уже немного не к тестированию :)Потому что потом эту ошибку сделают 100500 юзеров и будут каждый раз звонить в поддержку, которая будет вынуждена на словах им все объяснять.У меня в анамнезе четыре года работы в техподдержке. Я прекрасно это понимаю. И тем не менее - правда в том, что вся команда разработки стремится выпустить приложение без багов. Но на каждом этапе есть свои ограничения - это могут быть и сроки выпуска и человеческий фактор, и баг, который не воспроизводится на тестовой среде. Да, ошибка тестирования дороже, чем ошибка техподдержки. Ошибки продакта могут быть абсолютно незаметными со стороны, но критическими для компании. Но ошибки случаются, как бы мы ни старались. Это жизнь.
Со своей стороны вы можете подумать о том, что в техподдержке также есть процессы, которые возможно оптимизировать. Например, недавно я пошла в приложение одного провайдера с настроем рвать и метать потому, что у меня нет интернета. Чат-бот без привлечения человека уведомил меня, что случилась авария и уже всё исправляют и предложил уведомить, когда работы будут закончены. Реальный оператор не смог бы меня оповестить вовремя о завершении работ, так что это со всех сторон позитивный опыт (кроме часа без интернета).
Ещё один вариант решения проблемы - канареечные релизы, когда новая версия продукта выпускается только на часть пользователей и таких массовых "падений" не происходит. За такие решения отвечает не отдел тестирования, т.к. может потребоваться участие разработки, а менеджер продукта/отдела и т.д. Со стороны техподдержки в этом случае можно предоставить статистику по частоте массовых сбоев и обозначить, какие потери фактически компания при них теряет.diakin
24.07.2023 16:47Да, идеальный тестировщик должен совмещать "тупость" и сообразительность. )
И если тестер что-то там не завел, то ему должно приходить сообщение, какую ошибку он сделал и как ее исправить.Да, тестировщикам для развития жизненно необходимо знать обратную связь от пользователей
Не, я о том, что если тестировщик\пользователь сделает какую-нибудь ошибку - полк там не заполнит или еще что, то программа не должна выполнять действия с некорректными данными, а выдавать подсказку пользователю.
Hardcoin
24.07.2023 16:4780% как-то слишком мало. :)
Выше верно упомянули - нужно посмотреть ответ бека. Он верный? Если да, то косяк фронта, если нет, то косяк бека. 5% - и там и там, 5% - косяк требований и 5% - очень мутная ситуация, ничего не ясно.
happymammont Автор
24.07.2023 16:47не, ну с просмотром ответа от бэка это будет 100% для мобилок) я именно про интуитивное понимание
cat_chi
24.07.2023 16:47+1ИМХО, какие-то очень узкие и специфические сценарии. У автора они всё-таки пошире.
И достаточно наглый (судя по всему, несильно то и смекалистый) тестировщик заводит баг.
В приведённом примере "в вакууме" за такое просто нужно:
Сначала, если тестировщик неопытный, просто объяснить, как посмотреть данные в БД, например. Может он просто пришёл из другой сферы, где вообще не доводилось работать с БД. А так немного покопается в кишках, разберётся...
Если это происходит несколько раз, стоит разобраться, а не системная ли проблема? Может тестировщика банально душат сроками и он в мыле не успевает разобраться. А тут завёл баг – как будто бы работа сделана. Или, скажем, регламенты QA-отдела предписывают всё валить на программистов. Или есть какие-то нетривиальные моменты в самой задаче, а документации на это как обычно нет. И времени у разработчиков не хватает, чтобы ответить. Короче, причины могут быть разные.
Если в итоге выясняется, что проблема всё-таки в тестировщике – ну что сказать. Видимо он уже и не тупой, а просто необучаемый. Либо IT – это не его. Обычно такое приводит к увольнению.
Короче, я к тому, что прежде чем обвинять друг друга – мол, тестировщики наглые и несильно смекалистые, а разработчики ленивые токсичные багоделы – лучше сначала слегка "заземлиться" и разобраться в проблеме.
0Bannon
24.07.2023 16:47+1Ну, вот. А потом ещё говорят, что тестировщик - это самая простая специальность, чтоб вкатиться в ит.
happymammont Автор
24.07.2023 16:47самая простая специальность - всё-таки техподдержка. Просто "вкатывальщики" почему-то не считают поддержку труЪ айти.
Описанные проблемы актуальны больше для миддла или QA-лида, которому нужно подтянуть своих джунов. Грамотный онбординг и последовательный подбор задач для вхождения существенно снижают сложность (а если ещё и процессы отлаженные - то вообще красота). К сожалению, не все компании/команды в компаниях могут позволить себе такую роскошь. Тогда правильные нейронные связи не выстраиваются и работа тестировщиком может оказаться непосильно тяжёлой.
Другой способ нивелировать сложности требует самостоятельных действий, но тоже довольно простой - интересоваться тем, как работают приложения/сервисы, изучать Computer Science с приложением знаний на свой проект - и сложные задачи внезапно окажутся всего лишь увлекательным квестом по поиску причин такого поведения системыstackjava
24.07.2023 16:47Квест этот какой то не очень веселый)))
happymammont Автор
24.07.2023 16:47Возможно вы просто не умеете его готовить ;)
stackjava
24.07.2023 16:47Просто я не зануда))) ну или как модно толлерантно - не увлеченный или "не с горящими глазами" )))
BeLord
24.07.2023 16:47Я бы не сказал, что самая простая специальность это техподдержка. Бывает по разному, вот кусочек из регламента ТП - Перцептивно-семантический сеттлинг структурированно-репрезентированных текстовых сообщений, по возможности логистико-логически преобразованных, может проводиться при необходимости с применением рефлектизации, пэсификации, процедуризации структурированно-репрезентированных текстовых сообщений.(с) Вот честно, с ходу переведешь на простой язык без инета и прочих подсказок ?-)
happymammont Автор
24.07.2023 16:47Даже пытаться не буду)
Уточню - речь шла о самой простой специальности для входа в айти. Предметную область что в техподдержке, что в тестировании, всегда можно найти такую, что мозг в трубочки свернётся только от попытки понять что вообще тут происходит. Такие области есть, например, и у менеджеров по продажам, но "по умолчанию" менеджер по продажам не считается профессией, требующей особых хард-скиллов
Hardcoin
24.07.2023 16:47+2Или если пользователь из России — исключаем товары с валютой USD и выводим только рублёвые в порядке убывания?
Если в задаче требование сделать сортировку, а тестировщик думает, нужно ли ожидать фильтр - это плохой знак. Либо в требованиях постоянно путают фильтр и сортировку (встречал такого человека) и он уже не уверен, чего хочет постановщик, либо он крайне невнимательно читает задачу.
Ответ, абсолютно точно - отсортировать по конвертированной цене.
happymammont Автор
24.07.2023 16:47это была попытка
натянуть сову на глобусперевести некоторые реальные, более сложные, случаи на простой и наглядный пример. А в том, что хочет поставщик, я уже давненько не бываю уверена.
как и в том, что в описанном примере, при указанной структуре данных в БД, разработчики не забудут сделать конвертацию. Особенно если это задача с низким приоритетом в ворохе фич, оценённых на месяц, но нужных вчераHardcoin
24.07.2023 16:47Вы правы, могут и забыть. И в требованиях этого может не быть вообще. И постановщик может не знать о долларовых ценах, а когда узнает, у него парадигма задачи вообще поменяется. Либо это легаси, а компания с долларами вообще не работает и такие цены уже пять лет отфильтровываются совершенно по другому критерию (потому что у них указан способ доставки, который много лет уже выключен), но этот критерий на тесте почему-то не применяется, поэтому эти цены видно.
Вот только можно ли ожидать, что тестировщик всё это хоть как-то рассмотрит? Если да, то скажите диапазон зарплат (просто что бы понимать рынок).
Я от тестировщика жду только проверку на соответствие требованиям, либо указание, что требования непонятны/не полны. Плюс, по возможности, проверку на очевидные, но неописанные требования (например, нельзя купить больше, чем есть в наличии или что при переходе на вторую страницу списка сортировка должна сохраняться)
happymammont Автор
24.07.2023 16:47Вот только можно ли ожидать, что тестировщик всё это хоть как-то рассмотрит? Если да, то скажите диапазон зарплат (просто что бы понимать рынок).
Можно ли ожидать? 50/50. Два варианта - или невыгоревший сеньор, или тестировщик любого грейда, но с повышенной тревожностью. Написанный мной пример, хотя сам кейс не реален, списан с вполне реального человека. Тестировщик стремился проверить всё, предусмотреть всё и... получил заочное звание сложного человека, с которым неудобно работать и который затягивает сроки по задачам. Выгорел, уволился, ещё и поди самооценку себе подорвал. Так что это может быть совершенно любой тестировщик. Соответственно и диапазон зарплат можно смотреть просто по специальности QA :)
Урезанные сроки на тестирование, вердикт что баги минорные и рассматриваться не будут, один раз я прямым текстом получила наставление проверять только позитивные кейсы от ПМа (вышедшего из QA, на минуточку!). Бизнес очень не любит затягивание сроков по задачам, в том числе поэтому явление кажется редким.Hardcoin
24.07.2023 16:47Тестировщик стремился проверить всё, предусмотреть всё и...
Как конкретно сортировать - это не вопрос тестирования, а вопрос сбора требований и/или полноты ТЗ.
проверять только позитивные кейсы от ПМа
Так если программисты не тянут, другого выбора может не быть. Пусть сработают хотя бы позитивные кейсы, иначе вообще ничего в продакшн не уйдет.
Тут, конечно, просто недопонимание. Тестировщик, бывает, нужен что бы сделать качественное ПО без багов, а бывает - что бы был хоть какой-то фильтр от полного шлака.
Соответственно и диапазон зарплат можно смотреть просто по специальности QA :)
А где посмотреть-то? Совершенно непонятно, каким цифрам доверять. Скажем, 180 - это слишком мало или слишком много? Вопрос практический, есть трудности с выбором тестировщика.
happymammont Автор
24.07.2023 16:47А где посмотреть-то? Совершенно непонятно, каким цифрам доверять.
Например, тут https://habr.com/ru/specials/748058/
я не занимаюсь подбором людей, поэтому что-то знаю только что про свою зарплату. А это вполне может быть ошибочная оценка.
К тому же есть зависимость от того, насколько сложное у вас приложение.Тестировщик, бывает, нужен что бы сделать качественное ПО без багов, а бывает - что бы был хоть какой-то фильтр от полного шлака.
да, именно так. Но не все умеют переключаться
tagetdmb
24.07.2023 16:47один раз я прямым текстом получила наставление проверять только позитивные кейсы от ПМа
Ничего дурного в этих требованиях нет. При поступлении таких требований нужно только спросить о готовности принять риск, что сервер сложится как карточный домик, когда клиент нажмёт не туда (и этих "не туда" может быть много). И множество-множество других потенциальных проблем.
vvbob
24.07.2023 16:47+1Главная проблема практически на любых проектах где-бы я не работал последнее время не "глупые" тестировщики, а сам принцип работы.
Тебе дают какой-то таск, ты погружаешься в контекст задачи, изучаешь ТЗ (постановку задачи, или как оно там в конкретной команде называется, не важно), трепешь нервы аналитикам своими дурацкими вопросами и непониманием очевидного (tm), потом на основе полученного понимания задачи, запиливаешь одну или кучу фич с реализацией всего этого, сдаешь готовый таск в тестирование, и берешься за следующую задачу..
Как правило тестирование сразу же не берется за сданные задачи, и получается так, что когда ты вовсю занимаешься новой задачей, к тебе подкатывает тестировщик с той, старой фичей и начинает тебе выносить мозг глупыми и не особо глупыми вопросами. Но ты то уже вышел из того контекста, что-бы его вспомнить надо напрячься (и выйти из текущего), плюс еще и стресс от того что отвлекаясь на ту фичу, ты можешь продолбать все сроки по текущей. Это сильно напрягает, и так оно почти везде получается.
Хуже всего когда по той фиче начинают сыпаться баги (а они практически всегда бывают, не бывает реализаций без багов почти никогда), и тебе приходится переключаться на них. Все это раздергивание внимания, постоянное ожидание каких-то проблем со старыми задачами, постоянное самокопание - а правильно ли я вообще понял ту задачу и не налажал ли я где-то, не подставил ли всех этим.. Это хорошая такая почва для выгорания.
Kriminalist
24.07.2023 16:47"Предположим, что у нас в БД три столбца: название товара, цена и валюта. И валюты бывают разные!"
Ну добавьте же четвертый, цена в чем-то одном, и по нему и сортируйте. Это не тестировщика проблема, а дизайнера.
atygaev
24.07.2023 16:47но ведь в разных валютах цены разные?
Kanut
24.07.2023 16:47+1Имеется ввиду что добавляете столбик с "цена в тугриках" и пишете туда цену конвертированную в тугрики.
Правда это на самом деле не особо решает проблему потому что курс тугриков постоянно меняется и следовательно цену в тугриках надо постоянно актуализировать. Кроме того не факт что заказчик действительно хотел именно такую сортировку :)
Kriminalist
24.07.2023 16:47Ну поставьте себя на место пользователя. Какую ценность для вас имеет таблица с такими тремя столбцами? Сортировать по цене абсурдно, она же в разных валютах. Разве что это будет "умная" сортировка, которая будет подтягивать для каждой валюты курс, пересчитывать все цены по нему, и сортировать. Собственно, это и есть вариант с еще одним столбцом, в котором будет цена в У.Е.
SerJook
24.07.2023 16:47Умные тестировщики в тестировщиках не задерживаются.
Qatester345
24.07.2023 16:47Аргументируйте. Тестировщиком может быть довольно сложно, несколько раз слышал от коллег разрабов которые радуются что они не тестировщики. Так как они запилили свой кусочек и все, а тестировщику нужно разбираться во всей системе, зависимостях и т.д. Тестить бэк, бд, веб сервисы. Есть конечно более простые проекты и простые задачи, но стать действительно хорошим тестировщик довольно не просто, не проще чем, к примеру, автоматизатором. Может вхождение проще на ранних этапах но на этом все.
К слову стиль статьи мне тоже не нравится, отождествлять любого специалиста даже в шутку с тупым это неуважение к своей же профессии.
diakin
А для техподдержки такой совет прокатит? 8-()
Mirzapch
Часто задаю двум вышестоящим "коллегам" вопрос, "ответ на который очевиден".
В случае несовпадения ответов - меняю работу.
cat_chi
Что удивительно, это работает на всех уровнях. От относительно рядовых до топ-менеджмента
happymammont Автор
совершенно справедливо)
happymammont Автор
Увы, у техподдержки нет возможности переложить решение проблемы на обратившегося.
Но могу дать совет - отвечать с посылом искренней любви к тому, что техподдерживаешь и того, что команда действительно делает всё возможное для удобства пользователей. Некоторые пользователи почему-то с этого бесились, но ясчитаю это неадекваты какие-то) Большинство удовлетворялось полученным ответом
eji
Прокатит. Это называется "время реакции" и прописывается в SLA