Ещё один стереотип, который стали воспевать в мемах. Вот чем вам тестеры не угодили? Ведь в конечном продукте багов (по крайней мере явных) быть не должно. Хотите, давайте уберем тестеров, вот только тогда тестировать придется самим, до посинения, а ещё штрафы какие-нибудь придумают за баги выявленные клиентами.
И да, я не тестер, но в начале деятельности мне самому и приходилось полностью тестировать свои программы.
И да, я не тестер, но в начале деятельности мне самому и приходилось полностью тестировать свои программы.
раскрыть ветку (76)
На практике подобное вряд-ли где-то встречается, но существование подобного стереотипа, позволяет создавать подобные мемесы. От данного я взоржал в голос.
И да, я тестер
И да, я тестер
раскрыть ветку (9)
До драк не доходило. До криков "Вы там охуели вообще", "давайте пожмём этим мужественным людям их лица" иногда доходило, обычно в релиз или при обнаружении особо эпичной регрессии. Со стороны разрабов в свою очередь слышал возмущения вида "нахуя я туда полез" и "где откопал такие ебаные краевые значения".
Иногда отношения бывают напряжёнными. Особенно когда у разрабов и тестеров разные менеджеры и они не являются одной командой работающей над общей задачей.
раскрыть ветку (8)
раскрыть ветку (6)
Спорно. Иногда люди лезли в легаси и не то чтобы им там быть не надо.
Но не надо сейчас. Известно что функционал проблемный, но раскапывать и перетряхивать его будут организованно.
А по части краевых значений иногда это был таки не баг. И не фича. Это был гэп, то есть дырка в описании логики. И я бы не сказал что это что это чья-то вина, иногда действительно находили комбинации параметров этак из 4-5 которые доводили логику до парадокса и здоровый человек до такой комбинации не допрёт. Но иногда начинались метания говна на тему кто должен был первым заметить и поднять проблему, разраб, аналитик, тестер или заказчик.
раскрыть ветку (5)
И я бы не сказал что это что это чья-то вина, иногда действительно находили комбинации параметров этак из 4-5 которые доводили логику до парадокса и здоровый человек до такой комбинации не допрёт.Ммм... Тестирование методом "мыльной оперы", когда пользовательские сценарии разгоняются до абсурда. И, кстати, не надо недооценивать некую извращённую фантазию пользователей. Они порой такого могут наворотить, что в жизни бы не подумал, а приложение крашнулось.
раскрыть ветку (1)
Согласен. Как говорится для пользователя есть только 2 состояния. Разрешено или запрещённо. Никаких "да это никому в голову не придёт" или "да ни один дурак столько времени не потратит" быть не может.
Но иногда начинались метания говна на тему кто должен был первым заметить и поднять проблему, разраб, аналитик, тестер или заказчик.
А зачем метания говна? Нашли проблему - хорошо, решайте.
раскрыть ветку (2)
ага, ты её решишь, а потом тебе заказчик хуёв на воротник навешает, "потому что так удобно, мы так специально хотели, мы вот этим значением всю непонятную хуйню затыкали"
раскрыть ветку (1)
В смысле? А у вас что, на кого тикет открыть сам тестировщик решает?
Тестировщик нашёл бяку - доложил кому надо. А кто надо уже сам принимает решение: баг это, фича, кто будет исправлять и будет ли вообще.
У меня разрабы просто охуевали от комб, которые я в софте раскапывал :D Добавили функционал в виде таблички - я нашёл способ запустить ядерную ракету через неё. Обратно в дев, ёпть.
раскрыть ветку (2)
раскрыть ветку (1)
Тут ещё обязательно должен всплыть анекдот, чья актуальность примерно на уровне книжки Савина - про бар и туалет.
багов (по крайней мере явных) быть не должно.Для больших продуктов - нереально. Хороший критерий для релиза уже - в очередную итерацию - багов меньше чем в предудущей, и отсутствуют критикалы и мейджоры.
раскрыть ветку (7)
Насколько я помню количество багов это не критерий, точнее он только для условного несведущего менеджмента или для отчета заказчику. Хороший критерий это именно отсутствие критикал и мейджор багов
раскрыть ветку (1)
Тут критерий не конкретное количество багов, а сравнение с прошлой неделей, для того чтобы увидеть тенденцию - увеличивается или уменьшается. Впрочем, на каждом проекте свои критерии, но вот такой - тенденция на уменьшение количества и на снижение критичности - мне кажется в среднем оптимальным для подготовки в релиз.
раскрыть ветку (4)
ну покрытие автотестами на релиз не влияет вообще никак, а вот интенсивность потока багов и их серьезность обычно очень даже)
раскрыть ветку (3)
тестеры в проектах чуть более чем простых обязательно должны быть. когда разработчик тестирует - он двигается по простому шаблону в голове как он представил как будет действовать пользователь. Но это совершенно не так. тестер же действует за гранью того что может себе представить как разраб так и пользователь.
раскрыть ветку (2)
А никто и не спорит. Но тогда я работал один, делая небольшие утилиты, вот сам и мучился, дажи иконки сам рисовал))
раскрыть ветку (1)
смотря как воспринимать эти мемы) я поржала. И у нас есть тестер, а я прогер. И когда тестер отдает задачу с багом, всегда мысль - "ну бляяя". Но это же не потому что тестер кАзёл))) Да и манагер наш не совсем в стороне танцует - если по задаче найдена какая-то мелочевка-недоработка, а есть что-то более приоритетное - откладываем "драку" на попозже
p.s. каким бы ни был хорошим прогер, если тестер не находит баги - это плохой тестер
раскрыть ветку (2)
У некоторых QA присутствует лёгкая ненависть к разработчикам. Особенно у API-тестеров, так как глядя на респонсы кровь вытекает из глаз и начинаются вопросы вида "За что вы ненавидите человечество".
Молодые разработчики часто не любят QA за привычку доебаться до столба, например до строчных и заглавных букв в сообщении о ошибке или отсутствии точек в некоторых служебных сообщениях. Лечится это когда на демо заказчик придирками запихивает эту якобы мелочь разрабам в жопу и отказывается принимать фичу.
АТ часто являются просто сгустками ненависти. Особенно в отношении фронт-эндеров, это специфика работы и поиска объектов в UI тестировании. Несколько раз видел сцену вида.
АТ фронтам - Так вы, ...
Фронты не сговариваясь - Пидорасы?!
АТ - я хотел спросить заливали ли вы что-то вчера, но курс мыслей мне нравится.
Реально, примирить фронт-эндера и АТ иногда очень трудно. Хотя с опытом это проходит. Но неопытных фронтов автотестеры ненавидят тщательно отфильтрованной чистейшей ненавистью, хоть и понимают что они ломают автотесты не со зла.
раскрыть ветку (11)
Эх... А как я был рад, когда у меня появился тестер... Тут наверное только посочувствовать можно.
раскрыть ветку (9)
Разное бывает, часто фронт не всегда задумывается о тестопригодности фронта) В итоге приходится городить костыли(потому что пока через менеджмент допросишься приведения в тестопригодный вид), а потом - с очередным релизом все костыли опять ломаются.
раскрыть ветку (4)
Фронт в целом не задумывается о тестопригодности фронта до первой встречи с АТ.
Когда фронты узнают что используется для поиска, у них случается когнитивный диссонанс и приступ омерзения пополам с сочувствием.
Через два месяца они уже перестают вздрагивать от вопля "Кто и нахуя поменял генерацию ID у элементов." . Но кстати, вполне реально найти общий язык и достигнуть некоего консенсуса. Как минимум отучить от самых уебанских практик, что уже очень круто и ускоряет работу в разы.
раскрыть ветку (3)
Что у вас за галера, где все кричат и обзываются? Интересуюсь, чтобы не попасть туда как-нибудь.
У нас есть описание основного флоу, в котором описано большинство особенностей и вещей, которые могут что-то зааффектить, а по поводу конкретных задач всегда можно связаться и спокойно уточнить и обсудить детали. Ни разу ни тестер ни разраб не были в обиде друг на друга.
Исключение составляет когда тестер раскатывает не ту ветку и кричит "Чувак, ничего не работает, иди сюда, давай разбираться".
"Кто и нахуя поменял генерацию ID у элементов."
Поэтому нужно вообще завязывать не на ID, а на кастомные атрибуты чисто для QA) Заметно надежнее выходит)
Ты уточни кому посочувствовать, тебе или тестеру. А то мало ли, ты критически оцениваешь качество своего кода и тебе хотя бы стыдно.
Скажем так, если разработчик понимает что его трудами будут пользоваться люди, ну такие с мозгом(а чаще без) и без четырёхъядерного процессора, а респонсы иногда будет читать человек, а не парсер это помогает дружбе между специалистами.
Не помогают большая часть антипаттернов, например не имеющие смысла названия полей в респонсе, за это я натурально кидался в джависта кубиками.
С другой стороны тестер должен понимать что разработчик в некоторых ситуациях избирательно тупой и документам верит больше чем здравому смыслу. Не надо за это ругать.
Ну, ещё за одну вещь у нас автотестеры объясняли разработчику очень долго всю степень его неправоты и то о каких изменения надо уведомлять проект.
Он URL поменял, на одну букву. 2800 упавших автотестов, полтора десятка горящих жоп, паника.
раскрыть ветку (2)
У меня как-то раз тестеры требовали, чтобы в описании я писал не бэкап, а backup или резервная копия
Тоже не понимаю этих мемов. В небольшой компании, где есть постоянно развивающийся продукт, отдел разработки, но не было тестеров разработка убедила ПМ, что нужен тестер, а тот убедил директора и всем сразу стало легче жить. Это так, из опыта.
Почему сразу не угодили? Но при разработке нового продукта встречается дофига сценариев и там начинается заруба - это баг или так и должно работать, а потом чтение документации, чатиков и опять перекидывание - баг или не баг )
раскрыть ветку (7)
раскрыть ветку (6)
раскрыть ветку (5)
Без историй) Такие решения принимает BA или PO, а не QA с программистами (какой смысл драчек людей, не наделенных полномочиями?). Если команда регулярно делает подобные внезапные открытия только на этапе тестирования, значит планирование вообще не особо качественное, а не случайный заскок отдельного персонажа.
раскрыть ветку (4)
БА может и отсутствовать, иногда куа документируют требования, а речь шла вообще про другое - увлекательный квест найди какое требование обосновавывает это поведение ) Ну и как бы решения технически обоснованные и девелопмент тим.лидом тоже принимаются.
раскрыть ветку (3)
иногда куа документируют требования
Документирует - это не значит, что они их придумывают. Правки/уточнения должны утверждаться.
у и как бы решения технически обоснованные и девелопмент тим.лидом тоже принимаются.
Лидов в скраме нет, это такой же член команды, как и остальные. Истоичник истины - это PO.
раскрыть ветку (2)
ПО насрать как что-то будет реализовано, ему нужны бизнес-требования, так что согласуется только окончательное поведение ) конечно без наличия тех.лида со стороны клиента.
раскрыть ветку (1)
Потому что на практике очень часто в тестеры набирают девушек, которые свою рабочую обязанность видят в плане "тут надо понажимать и получить такой-то результат". Говорить о том, что там присутствует какой-то креативный подход и знание тестируемого процесса не приходится.
раскрыть ветку (25)
Возможно мне очень повезло, но девушки тестеры, с которыми я работал, были более креативными.
Ну а парней таких не существует что ли? или девушки тупее? Почему вы написали именно про девушек? :о
раскрыть ветку (17)
раскрыть ветку (15)
раскрыть ветку (14)
раскрыть ветку (13)
раскрыть ветку (12)
раскрыть ветку (11)
У каждого своя реальность, в моей есть и тупые бабы, и тупые мужики и их количество примерно равно.
Насчёт тех же тестировщиков, тестировщик у меня на работе неделю не мог научиться клонировать с гита и мне нужно было кидать ему код архивчиком. Могу ли я сделать вывод на основании этого что мужики тупее?
раскрыть ветку (10)
раскрыть ветку (9)
раскрыть ветку (8)
раскрыть ветку (7)
раскрыть ветку (6)
раскрыть ветку (5)
раскрыть ветку (4)
раскрыть ветку (3)
Я, к примеру, иногда делаю ошибки, потому что русский язык в моей школе не преподавался. Ты совершаешь крайне элементарные ошибки, из чего могу сделать вывод, что ты либо тупой, либо русского в школе у тебя тоже не было.
раскрыть ветку (2)
Если бы ты была королевой, я бы последил за орфографией и заменой Т9. Но ты никто, так что не обессудь.
раскрыть ветку (1)
У Вас не IT компания что ли? Обычно неумехи не проходят испытательный, ну а если такое каким-то чудом произошло, то их пихают на манки джоб.
раскрыть ветку (1)
Я тебя удивлю, но испытательный и реальная работа - это две разные вещи, оцениваемые разными людьми.
Чаще всего тестеры создают кривые тикеты в которых нифига непонятно как репродюсить баг.
раскрыть ветку (2)
Так налаживайте процессы. У нас был шаблон тикета, тестеры друг другу помогали писать норм тикеты. Плюс скрины, ссылки на документацию и в особо сложных случаях запись видео.
ещё комментарии
ещё комментарии
IT-юмор
5.6K постов52.5K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору