Comments 45
Когда вам задают вопрос, ответ на который очевиден — выждите пятнадцать минут.
А для техподдержки такой совет прокатит? 8-()
Часто задаю двум вышестоящим "коллегам" вопрос, "ответ на который очевиден".
В случае несовпадения ответов - меняю работу.
совершенно справедливо)
Увы, у техподдержки нет возможности переложить решение проблемы на обратившегося.
Но могу дать совет - отвечать с посылом искренней любви к тому, что техподдерживаешь и того, что команда действительно делает всё возможное для удобства пользователей. Некоторые пользователи почему-то с этого бесились, но ясчитаю это неадекваты какие-то) Большинство удовлетворялось полученным ответом
Прокатит. Это называется "время реакции" и прописывается в SLA
А где пункт, когда тестер не понимает элементарно, что когда в таблице бд он не заполнил поле, то с бэка приходит пустым это поле... И достаточно наглый (судя по всему, несильно то и смекалистый) тестировщик заводит баг.
А как же пункт, когда тестиррвщик не видит на фронте в списке нужного элемента, и вместо того чтобы узнать, что приходит с бэка, тупо заводит баг на бэк... А косяк на фронте... А постманом запросить бэк слишком мудро... Проще баг.
я совершенно неслучайно прописала пункт 2 про то, что тестировщик действительно может быть недостаточно умён :)
но на самом деле это больше подходит под незнание работы системы. Просто вот у этого отдельно взятого тестировщика не выстроены правильные нейронные связи о том, откуда что берётся и куда идёт. Я на вебе именно так и туплю. При этом в мобильных приложениях почему-то взглядом наискосок понимаю, фронт или бэк виноват, с безошибочностью в 80%
Дело в том, что сообразительность тестировщика не должна превышать сообразительность самого "тупого" юзера, который будет работать с программой.
И если тестер что-то там не завел, то ему должно приходить сообщение, какую ошибку он сделал и как ее исправить. Потому что потом эту ошибку сделают 100500 юзеров и будут каждый раз звонить в поддержку, которая будет вынуждена на словах им все объяснять.
Должна. Тестировщик может с некоторой вероятностью определить, является ли ситуация невнятным текстом ошибки (т.е. ошибка должна происходить, но с другим описанием) или это баг, который требуется починить.
Дело в том, что сообразительность тестировщика не должна превышать сообразительность самого «тупого» юзера, который будет работать с программой.
После полугода ежедневного тыкания в одно и то же приложение любой человек будет ориентироваться в системе лучше, чем даже умный средний пользователь.
Это неизбежно. Да, из этого могут возникнуть проблемы (и поэтому я всегда радуюсь новичкам на проектах). Мой способ - глядя на новую фичу представлять себе, что с этим делала бы моя бабушка. Иногда помогает
Сообразительный и погружённый в проект тестировщик с большей вероятностью найдёт баги в затронутых фичой областях, при этом к фиче не относящихся. Более точно локализует проблему и сделает работу разработчиков более комфортной. Отловит те баги, которые пользователям вообще не видны, но влияют на метрики и внутренние процессы. Ну а ещё сможет протестировать интеграции, которые руками кроме тестировщиков вообще никто не трогает
И если тестер что-то там не завел, то ему должно приходить сообщение, какую ошибку он сделал и как ее исправить.
Да, тестировщикам для развития жизненно необходимо знать обратную связь от пользователей и информацию о том, какие ошибки они пропустили. Встречающаяся оторванность техподдержки от тестирования в этом ключе очень удручает.
А вот знать, как исправить - это уже немного не к тестированию :)
Потому что потом эту ошибку сделают 100500 юзеров и будут каждый раз звонить в поддержку, которая будет вынуждена на словах им все объяснять.
У меня в анамнезе четыре года работы в техподдержке. Я прекрасно это понимаю. И тем не менее - правда в том, что вся команда разработки стремится выпустить приложение без багов. Но на каждом этапе есть свои ограничения - это могут быть и сроки выпуска и человеческий фактор, и баг, который не воспроизводится на тестовой среде. Да, ошибка тестирования дороже, чем ошибка техподдержки. Ошибки продакта могут быть абсолютно незаметными со стороны, но критическими для компании. Но ошибки случаются, как бы мы ни старались. Это жизнь.
Со своей стороны вы можете подумать о том, что в техподдержке также есть процессы, которые возможно оптимизировать. Например, недавно я пошла в приложение одного провайдера с настроем рвать и метать потому, что у меня нет интернета. Чат-бот без привлечения человека уведомил меня, что случилась авария и уже всё исправляют и предложил уведомить, когда работы будут закончены. Реальный оператор не смог бы меня оповестить вовремя о завершении работ, так что это со всех сторон позитивный опыт (кроме часа без интернета).
Ещё один вариант решения проблемы - канареечные релизы, когда новая версия продукта выпускается только на часть пользователей и таких массовых "падений" не происходит. За такие решения отвечает не отдел тестирования, т.к. может потребоваться участие разработки, а менеджер продукта/отдела и т.д. Со стороны техподдержки в этом случае можно предоставить статистику по частоте массовых сбоев и обозначить, какие потери фактически компания при них теряет.
Да, идеальный тестировщик должен совмещать "тупость" и сообразительность. )
И если тестер что-то там не завел, то ему должно приходить сообщение, какую ошибку он сделал и как ее исправить.Да, тестировщикам для развития жизненно необходимо знать обратную связь от пользователей
Не, я о том, что если тестировщик\пользователь сделает какую-нибудь ошибку - полк там не заполнит или еще что, то программа не должна выполнять действия с некорректными данными, а выдавать подсказку пользователю.
80% как-то слишком мало. :)
Выше верно упомянули - нужно посмотреть ответ бека. Он верный? Если да, то косяк фронта, если нет, то косяк бека. 5% - и там и там, 5% - косяк требований и 5% - очень мутная ситуация, ничего не ясно.
Ну, вот. А потом ещё говорят, что тестировщик - это самая простая специальность, чтоб вкатиться в ит.
самая простая специальность - всё-таки техподдержка. Просто "вкатывальщики" почему-то не считают поддержку труЪ айти.
Описанные проблемы актуальны больше для миддла или QA-лида, которому нужно подтянуть своих джунов. Грамотный онбординг и последовательный подбор задач для вхождения существенно снижают сложность (а если ещё и процессы отлаженные - то вообще красота). К сожалению, не все компании/команды в компаниях могут позволить себе такую роскошь. Тогда правильные нейронные связи не выстраиваются и работа тестировщиком может оказаться непосильно тяжёлой.
Другой способ нивелировать сложности требует самостоятельных действий, но тоже довольно простой - интересоваться тем, как работают приложения/сервисы, изучать Computer Science с приложением знаний на свой проект - и сложные задачи внезапно окажутся всего лишь увлекательным квестом по поиску причин такого поведения системы
Квест этот какой то не очень веселый)))
Я бы не сказал, что самая простая специальность это техподдержка. Бывает по разному, вот кусочек из регламента ТП - Перцептивно-семантический сеттлинг структурированно-репрезентированных текстовых сообщений, по возможности логистико-логически преобразованных, может проводиться при необходимости с применением рефлектизации, пэсификации, процедуризации структурированно-репрезентированных текстовых сообщений.(с) Вот честно, с ходу переведешь на простой язык без инета и прочих подсказок ?-)
Даже пытаться не буду)
Уточню - речь шла о самой простой специальности для входа в айти. Предметную область что в техподдержке, что в тестировании, всегда можно найти такую, что мозг в трубочки свернётся только от попытки понять что вообще тут происходит. Такие области есть, например, и у менеджеров по продажам, но "по умолчанию" менеджер по продажам не считается профессией, требующей особых хард-скиллов
Или если пользователь из России — исключаем товары с валютой USD и выводим только рублёвые в порядке убывания?
Если в задаче требование сделать сортировку, а тестировщик думает, нужно ли ожидать фильтр - это плохой знак. Либо в требованиях постоянно путают фильтр и сортировку (встречал такого человека) и он уже не уверен, чего хочет постановщик, либо он крайне невнимательно читает задачу.
Ответ, абсолютно точно - отсортировать по конвертированной цене.
это была попытка натянуть сову на глобус перевести некоторые реальные, более сложные, случаи на простой и наглядный пример. А в том, что хочет поставщик, я уже давненько не бываю уверена.
как и в том, что в описанном примере, при указанной структуре данных в БД, разработчики не забудут сделать конвертацию. Особенно если это задача с низким приоритетом в ворохе фич, оценённых на месяц, но нужных вчера
Вы правы, могут и забыть. И в требованиях этого может не быть вообще. И постановщик может не знать о долларовых ценах, а когда узнает, у него парадигма задачи вообще поменяется. Либо это легаси, а компания с долларами вообще не работает и такие цены уже пять лет отфильтровываются совершенно по другому критерию (потому что у них указан способ доставки, который много лет уже выключен), но этот критерий на тесте почему-то не применяется, поэтому эти цены видно.
Вот только можно ли ожидать, что тестировщик всё это хоть как-то рассмотрит? Если да, то скажите диапазон зарплат (просто что бы понимать рынок).
Я от тестировщика жду только проверку на соответствие требованиям, либо указание, что требования непонятны/не полны. Плюс, по возможности, проверку на очевидные, но неописанные требования (например, нельзя купить больше, чем есть в наличии или что при переходе на вторую страницу списка сортировка должна сохраняться)
Вот только можно ли ожидать, что тестировщик всё это хоть как-то рассмотрит? Если да, то скажите диапазон зарплат (просто что бы понимать рынок).
Можно ли ожидать? 50/50. Два варианта - или невыгоревший сеньор, или тестировщик любого грейда, но с повышенной тревожностью. Написанный мной пример, хотя сам кейс не реален, списан с вполне реального человека. Тестировщик стремился проверить всё, предусмотреть всё и... получил заочное звание сложного человека, с которым неудобно работать и который затягивает сроки по задачам. Выгорел, уволился, ещё и поди самооценку себе подорвал. Так что это может быть совершенно любой тестировщик. Соответственно и диапазон зарплат можно смотреть просто по специальности QA :)
Урезанные сроки на тестирование, вердикт что баги минорные и рассматриваться не будут, один раз я прямым текстом получила наставление проверять только позитивные кейсы от ПМа (вышедшего из QA, на минуточку!). Бизнес очень не любит затягивание сроков по задачам, в том числе поэтому явление кажется редким.
Тестировщик стремился проверить всё, предусмотреть всё и...
Как конкретно сортировать - это не вопрос тестирования, а вопрос сбора требований и/или полноты ТЗ.
проверять только позитивные кейсы от ПМа
Так если программисты не тянут, другого выбора может не быть. Пусть сработают хотя бы позитивные кейсы, иначе вообще ничего в продакшн не уйдет.
Тут, конечно, просто недопонимание. Тестировщик, бывает, нужен что бы сделать качественное ПО без багов, а бывает - что бы был хоть какой-то фильтр от полного шлака.
Соответственно и диапазон зарплат можно смотреть просто по специальности QA :)
А где посмотреть-то? Совершенно непонятно, каким цифрам доверять. Скажем, 180 - это слишком мало или слишком много? Вопрос практический, есть трудности с выбором тестировщика.
А где посмотреть-то? Совершенно непонятно, каким цифрам доверять.
Например, тут https://habr.com/ru/specials/748058/
я не занимаюсь подбором людей, поэтому что-то знаю только что про свою зарплату. А это вполне может быть ошибочная оценка.
К тому же есть зависимость от того, насколько сложное у вас приложение.
Тестировщик, бывает, нужен что бы сделать качественное ПО без багов, а бывает - что бы был хоть какой-то фильтр от полного шлака.
да, именно так. Но не все умеют переключаться
один раз я прямым текстом получила наставление проверять только позитивные кейсы от ПМа
Ничего дурного в этих требованиях нет. При поступлении таких требований нужно только спросить о готовности принять риск, что сервер сложится как карточный домик, когда клиент нажмёт не туда (и этих "не туда" может быть много). И множество-множество других потенциальных проблем.
Главная проблема практически на любых проектах где-бы я не работал последнее время не "глупые" тестировщики, а сам принцип работы.
Тебе дают какой-то таск, ты погружаешься в контекст задачи, изучаешь ТЗ (постановку задачи, или как оно там в конкретной команде называется, не важно), трепешь нервы аналитикам своими дурацкими вопросами и непониманием очевидного (tm), потом на основе полученного понимания задачи, запиливаешь одну или кучу фич с реализацией всего этого, сдаешь готовый таск в тестирование, и берешься за следующую задачу..
Как правило тестирование сразу же не берется за сданные задачи, и получается так, что когда ты вовсю занимаешься новой задачей, к тебе подкатывает тестировщик с той, старой фичей и начинает тебе выносить мозг глупыми и не особо глупыми вопросами. Но ты то уже вышел из того контекста, что-бы его вспомнить надо напрячься (и выйти из текущего), плюс еще и стресс от того что отвлекаясь на ту фичу, ты можешь продолбать все сроки по текущей. Это сильно напрягает, и так оно почти везде получается.
Хуже всего когда по той фиче начинают сыпаться баги (а они практически всегда бывают, не бывает реализаций без багов почти никогда), и тебе приходится переключаться на них. Все это раздергивание внимания, постоянное ожидание каких-то проблем со старыми задачами, постоянное самокопание - а правильно ли я вообще понял ту задачу и не налажал ли я где-то, не подставил ли всех этим.. Это хорошая такая почва для выгорания.
Вы описали вполне себе стандартный рабочий процесс в разработке. Почва для выгорания - это все-таки другое, кмк.
То что плохая практика настолько распространена, что стала практически стандартом, не делает ее менее плохой.
Я практически нигде, ни на одном проекте в котором участвовал, не встречал такого, что-бы при планировании реализации фичи закладывались не только на ее реализацию, но и на работу над багами и доработками. Обычно все сверхоптимистично закладываются на то, что разработчик один раз напишет фичу, и сразу же перейдет к новой, забыв о старой, потому что там все сделано идеально и ни одной проблемы с ней не возникнет.
Я практически нигде, ни на одном проекте в котором участвовал, не встречал такого, что-бы при планировании реализации фичи закладывались не только на ее реализацию, но и на работу над багами и доработками.
Я знаю несколько фирм где просто 20-30% всего времени планируется на фикс багов и всякие незапланированные доработки.
именно про это у меня п.6 - отсутствие описания реализации. Мне, как тестировщику, тоже сильно комфортнее было бы, если бы задача приходила в тестирование сразу с описанием от разработчика: "вот эти требования изменились вот так; сохранение сущностей реализовано через метод апи такой-то (и он есть в сваггере), записывается всё в БД в таблицу и столбцы такие.
Но почему-то такой практики просто не существует. То ли разработчики не хотят ещё и текстом описывать, что сделано, то ли слишком дорого запрягать разработчика писать тексты. Не понятно) Хотя где-то есть технические аналитики, которые всё это старательно переносят в описание задачи.
от багов это не избавляет, конечно, но кажется, что пачку вопросов по фиче может отсечь
"Предположим, что у нас в БД три столбца: название товара, цена и валюта. И валюты бывают разные!"
Ну добавьте же четвертый, цена в чем-то одном, и по нему и сортируйте. Это не тестировщика проблема, а дизайнера.
но ведь в разных валютах цены разные?
Имеется ввиду что добавляете столбик с "цена в тугриках" и пишете туда цену конвертированную в тугрики.
Правда это на самом деле не особо решает проблему потому что курс тугриков постоянно меняется и следовательно цену в тугриках надо постоянно актуализировать. Кроме того не факт что заказчик действительно хотел именно такую сортировку :)
Ну поставьте себя на место пользователя. Какую ценность для вас имеет таблица с такими тремя столбцами? Сортировать по цене абсурдно, она же в разных валютах. Разве что это будет "умная" сортировка, которая будет подтягивать для каждой валюты курс, пересчитывать все цены по нему, и сортировать. Собственно, это и есть вариант с еще одним столбцом, в котором будет цена в У.Е.
Умные тестировщики в тестировщиках не задерживаются.
Аргументируйте. Тестировщиком может быть довольно сложно, несколько раз слышал от коллег разрабов которые радуются что они не тестировщики. Так как они запилили свой кусочек и все, а тестировщику нужно разбираться во всей системе, зависимостях и т.д. Тестить бэк, бд, веб сервисы. Есть конечно более простые проекты и простые задачи, но стать действительно хорошим тестировщик довольно не просто, не проще чем, к примеру, автоматизатором. Может вхождение проще на ранних этапах но на этом все.
К слову стиль статьи мне тоже не нравится, отождествлять любого специалиста даже в шутку с тупым это неуважение к своей же профессии.
Смело. Но фигня. Ну и как всегда возможна вполне вкусовая дефиниция слова "умные".
полностью поддерживаю
Любимое - это когда в постановке задачи скрин из кибаны
Быть тупым тестировщиком