Тестеры.

2. 10. 2015 13:02:55

Теги: наблюдения, работа, программисткое,
X
123

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

Рабочего настроение мне это не добавило, и хоть я и понимаю, что виноваты во всём тестеры, пистоль вставят всё равно мне, но прогулка и кофе не помогли его (настроение рабочее) вернуть, так что надеюсь бумагомарательство вернёт.

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

У экзаменатора же цель за как можно короткий промежуток времени как можно ближе к реальности оценит знание студента по предмету. Для этого студент выбирает себе случайным образом два-три вопроса из разных частей курса, которые называются билетом. Случайность выбранных билетов обеспечивает то, что, по крайней мере, во время подготовки к экзамену, студент добросовестно учит весь курс. И не смотря на всё это, всё равно - у студента присутствует в большой мере элемент везения. И даже не в том, вытянул ты удачный билет или нет, а понравился ты преподу или нет. Если понравился - простит какие-нибудь косячки, не понравился - будет валить, то есть за косячки зацепится, и начнёт раскручиваться в эту сторону. Нет, бывают такие знания, что ни кто завалить не может, но этот уровень знаний очень сильно выше топа по курсу, и даже может быть выше, чем у преподавателя.

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

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

Вася и Петя одновременно начали писать один и тот же продукт. Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру. А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение. Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы. Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов. У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента. В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге. © bash.im

Часто забывают об одном факте - то, что любая разработка это всегда компромисс. Компромисс между временем разработки, ценой, и качеством разработки. За бесконечное количество времени силой большого коллектива узких специалистов и умеющих эффективно объединять их усилия менеджеров можно создать идеальный продукт. Однако через бесконечное время он не будет ни кому нужен, и стоить он будет столько, что за столько его ни кто не купит. Понятно, что на коленке под пиво состряпанную за викенд программу будут покупать только ограниченное количество времени, если вообще будут. Это - крайние случаи, в настоящей жизни не бывает как того, так и другого, и где проходит эта золотая середина - каждая фирма решает по своему. Apple делал большой упор на качество и продуманность в своё время, при этом не экономил на разработке и не старался завоевать рынок низкой ценой продукта. Booking.com к качеству относится вообще своеобразно - накатывается функция, и смотрят - если ввод функции приносит деньги или от него только потери. Если потери, то функцию откатывают и дальше пытаются смотреть, если надо её всего лишь подправить, или вообще отправить в корзину.

Так вернёмся к эффектам.

Первое - это вот что картинка в верху символизирует. На картинке слева - 335 BMW? справа - Кировец. И тот и другой агрегат имеют внутри себя мотор мощностью около 300 лошадиных сил. Но совершенно очевидно, что если мы попробуем BMW вспахать поле или утянуть стог сена, то она в лучшем случае будет только шлифовать резину, а скорее всего сядет брюхом ещё по дороге к месту выполнения поставленной задачи. Если же мы на Кировце поедем семьёй к морю, то дети по дороге успеют повзрослеть, не говоря уже о том, какую фигуру приобретут тела путешествующих с таким комфортом. Можно ли сказать, что из этих двух агрегатов сильнее при казалось бы равной номинальной мощности? Да нет, разумеется, просто каждый из них выполняет свою задачу. И каждый со своей задачей справляется на пять с плюсом.

То есть требование к производительности должны отвечать реальным задачам. Был у меня эпизод, делали поддержку передачи аварийных сообщений через протокол SNMP. Транспорт не очень сложный, по этому был реализован достаточно быстро. И тут началось тестирование, которое выявило, что аварии начинают теряться примерно с нагрузкой 1000 аварий в секунду. На мои возражения, что если на станции возникнет 1000 аварий, то обслуживающий персонал будет в последнюю очередь решать, у него получено 1000 аварий или 997, у него будет гораздо большая проблема. Нет, не действует аргумент. Ладно, пару месяцев ломаем копья на том, что бы сделать двойную буферизацию принимающих очередей, при этом системную выбираем с как можно большим приоритетом, строит топологию сети так, что бы полезный трафик ни как не мешал проходу аварийный сообщений и т.п. Раз в 10 больше ресурсов потраченно на то, что бы достичь этих 1000 аварий в секунду. На тот момент на наших станциях количество разговоров за секунду было меньше. Достигли результата. Смотрим дальше - упс, на 600 000 авариях всё равно перестаёт система справлять с обработкой. На счастье тут уже удалось сторговаться на то, что обрабатывать мы их и не сможем, но вместо обычного механизма самовосстановимся, когда поток спадёт, опять же многие человекомесяцы тратим на то, что бы удерживать этот DDoS. Случится ли когда-либо ситуация, от которой нужно защищаться - 99,999% что нет, и 100%, что если случится, то решать будут не мониторинг, а вообще - чего такое случилось, что ситуация произошла.

Второй момент, что собственно послужило поводом. Декларация:
- У тебя есть в программе ошибка.
- Ну хорошо, есть, не спорю, рассказывай, что за ошибка, как достигнуть.
- У тебя везде не правильно значения обрабатываются.
- Хм, вот смотри - тут вот правильно обрабатываются, так что давай список, где не правильно.
- Слушай, пора бы научиться признавать свои ошибки.
- Да ради бога, это даже и не мои ошибки - я вообще этот софт от третьих лиц получил на поддержку, но мне надо знать, где ошибка, и как симулируется.

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

Но вторая модель - это ещё куда не шло, хуже гораздо третий сценарий - вот смотри, у меня приложение пало. Хорошо, давай рассказывай, как ронял. А я не знаю, и повторить это не могу. Хорошо, смотрим логи, где примерно находилась программа, когда она упала, смотрим, что примерно могло произойти и приделываем какую нибудь защиту от ситуации, которая теоретически случиться может, но в реальной жизни её ни кто ни когда не видел. Невозможно защититься от всего за конечное время, всегда есть, что улучшить. Отдаю версию, спрашивает, как на симулировать. Говорю - должна произойти ошибка процессора, ни как нельзя на симулировать. Бывает, что и notepad надает. Всё, на этом месте наступает тупик, потому что нельзя проверить, если баг исправлен или нет. Большинство фирм вообще не будет рассматривать случайные падения, но, опять же, не наш случай.

Есть ещё третий с половиной сценарий. Это когда механизм падения известен, но это тщательно тестером скрывается. По совокупности причин от первой и второй модели.

По мелочи - обычно касается дружественности пользовательского интерфейса. Что бы оценить удобен GUI или нет, нужно работать в режиме конечного заказчика. Как с теми же авариями - в реальной жизни из в основном нет, максимум одна две. И нужно как можно больше выдать информации по контексту именно этой проблемы - что бы проблему как можно быстрее помочь решить. Но если у тебя проблемы нет, а есть генератор сообщений, то ты, например, чтобы проверить, не потерялось ли какое сообщение в потоке, настаиваешь на заточке интерфейса к анализу большого количества строк, а это будет всегда в ущерб детализации отдельных строк. Ну и опять же замкнутый круг - первый раз делаешь, как будет удобно заказчику. Потом переделываешь, как будет удобно тестеру, потому что иначе тестами программа не пройдёт. А потом решаешь замечания заказчика, фактически откатывая изменения, и бодаешься с тестером на предмет, что один раз это уже решалось.

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

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

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

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

<< < > >>

Комментарии


Комментарий