Реальность айтишника: боли vs хитрости

хитрости тестировщика + боли разработчика = ?

Вы когда-нибудь задавались вопросом, что дают хитрости тестировщика и боли разработчика в одной комбинации? Мы долго думали над этим вопросом, обсуждали с нашими IT-отделами и нашли ответ. Более того, мы узнали, какие уловки и навыки используют тестировщики и что выводит из себя разработчиков.

О каких хитростях и навыках знает идеальный тестировщик, у которого баги определяются моментально, тестирование проходит молниеносно, а заказчик возвращается потому что понравилось? Нам рассказали ребята с отдела тестирования.

Контроль — основная работа тестировщика. Как только ты видишь, что функционал работает не так, как описан, тут же загорается красная кнопка, а после загорания — решаем: либо менять требования, либо реализацию.

Активность тестировщика — гарантия, что ты получишь задачи по тестированию в нужный момент и тебе хватит времени, чтоб выполнить качественно и быстро. Но об этом тебе не скажут заранее, нужно самому уметь спросить и следить за новостями по проекту.

Чувство юмора должно присутствовать, но в меру. Это когда после регрессионного тестирования говоришь разработчику, что ты нашел только 1 минорную ошибку, он сразу радуется. После, выждав паузу, ты сообщаешь, что помимо одной минорной, нашел 3 блокера и 8 критических. Как видите, это не о нас, у нас — не в меру.

Есть умеет не за компьютером или за компьютером, но очень и еще раз очень осторожно. Ведь голодный тестировщик = злой тестировщик. А тестировщик без компьютера = не тестировщик.

Стрессоустойчивость — наше всё, особенно в случае:
— когда тестируешь проект за 4 часа до демонстрации заказчику, а нужно минимум 8.
— когда 5-й раз с улыбкой (натянутой, конечно) объясняешь заказчику, что система не будет работать самостоятельно, без нажатий клавиш пользователем.

Творчество спасает при выборе способов тестирования и подходов к тестированию, ведь наша задача состоит в том, чтоб поставить себя на место пользователей и предугадать наперёд, какие иррациональные и нелогичные для системы шаги они сделают, будь-то 5-ти летние дети или продвинутые пенсионеры.

Вежливость присутствует в разговоре с заказчиком даже если он свято уверен, что нашел баг, и настойчиво доказывает вам это. Неважно, что на самом деле это фича.

Обаяние включается на 100%, когда ты обнаружил ошибку в функционале, который прошел тестирование вчера. И тогда разработчик пойдёт тебе на встречу ещё не один раз просто потому что уважает тебя.

Отдел разработчиков рассказал нам о совсем другой стороне своей работы: те вещи, которые присутствуют в их жизни постоянно, но не всегда в лучшем ключе.

Полиглотизм по-компьютерному. Каждый программист знает много языков. Правда, общаться на них с другими людьми сложно, ведь если объясняешь по-своему — никто не понимает, только достают телефон с кармана и гуглят.

Реакция — скорость света. Программисты успевают исправлять баг до того как его обнаружат тестировщики или заказчики. Хорошие программисты умеют так делать, плохие — тоже.

Общение с заказчиком. Иногда возникает ощущение, что заказчик ждёт от программиста экстрасенсорных способностей. Клиенты даже сами так говорят: «да, здесь сделано так, как указано в техническом задании, но я совсем не это имел(а) ввиду». А сроки сжаты, и что там имелось в виду нужно понять самостоятельно и заранее, желательно ДО того, как получил ТЗ.

Детектив в жизни. Когда мы слышим: «Я ничего не делал(а), а оно само сломалось» — проявляются способности Шерлока Холмса, чтобы выяснить, что конкретно пользователь «не делал(а)», что оно так сломалось.

Умора внутри.. Юмор разработчиков сложно понять, ведь обычно наши шутки называют сарказмом, который никто не понимает (кроме нас самих). В конце-концов, кто еще заливается хохотом, просто читая код?

Креатив — не про нас. Зачем придумывать велосипед, если за тебя это уже сделал кто-то другой? Нужно просто это найти: мы ищем решения, но не придумываем их.

Ты ж программист. Все говорят «ты ж программист». И неважно, уместно это или совсем неуместно. И да, люди считают, что тебе под силу починить чайник только потому что ты программист. В итоге, ты всё равно чинишь чайник.

Автоматизация зашкаливает. Иногда ты настолько перерабатываешь, что не замечаешь, как создал чат-бота для поиска и покупки билета в кино. И он его купил, а ты не пошел, потому что забыл запрограммировать его на уведомление о начале сеанса. А потом исправляешь ошибки и идёшь на следующий сеанс.

хитрости тестировщика + боли разработчика = качество продукта

Расскажите, какие хитрости используете вы в своей работе и что вы называете своими «болями»?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Это можно как-то развидеть?

Правду говорят, что шутить следует в меру
Если, конечно же, меру знать
Так как унылая шутка сильно хуже
Растерянности и с молчанием промежутка
Отдел разработчиков не рассказал вам о
Совсем другой работе, с овертаймами и нервами
Я лишь вижу рекламу вашей компании
Ненужной, по сути, каждому первому...

за один этот пост нужно забирать диплом по пиару обратно — у меня глаза кровоточат

Не знаю, для чего еще нужен фейсбук, но такие посты туда органично вписываются.
#braggingatfacebook #хвастунишка #булщит #успешнаяя 🤳🧝‍♀️🏆

Главное
Об этом
Всем
Немедленно
Объявить

Боль разработчика в том, что нихера неясны требования в начале работы и в процессе спринта могут еще поменяться, что PM на самом деле не рулит проектом, чайка-менеджмент. Когда объясняешь тому же тестировщику как тестить твой таск и тд. Ну как боль — facepalm скорее.
P.S. буквы в статье напомнили: bash.im/quote/402188

Как бы еще пропиарить контору...

Когда HRу нечего делать, он упражняется в искрометном юморе :)

Шо за дічь... Навіщо таке писати?

Вы читали? Можете, в двух словах, о чем там?

Графоманская дичъ

диплом по лаконичности этому господину

в двух словах
двух
Графоманская дичъ

и по идеальному выполнении запроса тоже

Подписаться на комментарии