Pull to refresh
25
0
Алексей @lxsmkv

тестировщик-автоматизатор

Send message
Ваша КДПВ — мягко сказать, не лучшее из того, что мне приходилось видеть на Хабре. Она даже не нейтральна, а неприятна на вид. Смысловой нагрузки в ней нет. Было бы хоть каким-то оправданием, если бы она была из оригинальной статьи — но это не так.
По идее, во время редактуры такие огрехи убирают. Отсюда вопрос: почему Parallels не делает редактуру своих статей. Не хорошо же для имиджа. Ты показываешь как относишься к своим «продуктам». Без должного внимания к деталям. А статья ведь тоже продукт. Мне уже не хочется заглядывать на их сайт, а вдруг я там увижу эту картинку снова.
оказывается, нужно путь указывать на бинарник на не на обертку
правильно — PortableApps\\FirefoxPortable\\App\\Firefox64\\firefox.exe
неправильно — PortableApps\\FirefoxPortable\\FirefoxPortable.exe
да уж, похоже на вступительный тест в клуб имени Нильса Бора.
Очень актуальная тема. Вчера вон пытался заставить Firefox с селениумом работать, выяснил что geckodriver не работает с FirefoxPortable (https://github.com/mozilla/geckodriver/issues/1028).
Вот и получается что инструменты инструментами, а чтобы заставить это все работать нужно знать много нюансов. Для человека типа менеджера который просто хочет автоматизацию тестирования веб приложения — нужно провести кучу подготовительной работы. Не ясно куда смотреть и как это лучше сделать чтобы не наступить на грабли.
Так что любая подробная информация только на пользу.
О, газетные статьи. Взяли лучшие из одной группы и худшие из другой. Что хотели показать то и показали. Не обращая внимания ни на какие другие факторы. Такая же история с распространением модели водопада в разработке — просто люди не дочитали статью до конца. Терпеть не могу.
Про эникейство:
У нас есть (был) админ, он обладал навыками — его боялись подпускать к компьютерам, потому что он там делал все так как он умеет, а не так как надо тебе. А есть админ старый, он задает тебе максимум три вопроса (и тебе иногда даже кажется что «причем здесь это», но ты смотришь на него как кролик на удава и просто говоришь правду), потом легким движением руки, открывает необходимую настройку меняет в ней то что нужно — это знания — и все работает. И ты потом думаешь — ну конечно, как я сам не догадался.

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

Ведь закидать проблему кодом может любой индус. А вот знание методологий, возможных подходов, позволят инженеру решить где нужно два солдата из стройбата, а где нужен экскаватор. (Кстати, у нас супермаркет на ровном месте за 8 месяцев отгрохали. Причем на стройке каждый день, проходя мимо, я видел от силы человека четыре. Я офигеваю каждый раз как в строительстве это работает.)
Мне всегда казалось, что аитишник это как врач — это или призвание или не надо за это браться. Если ты айтишник, то ты должен копаться в говне с интересом. Или это не твое. Видели брезгливого врача? Я нет.
Что это за «вот этот проект мне нравится там все легко и просто, а этот дремучий лес — трудно и неинтересно»?
К сожалению никакие университеты и семинары по профориентации не донесут до человека того с чем им придется столкнуться на практике.
Мне отец как-то пересказывал со слов знакомого про работу археолога — все думают это кисточкой земельку расчищать и делать удивительные исторические открытия — а на самом деле это 99.9% бумажной работы по описанию найденного барахла, даже если это не то, что ты надеялся там найти.
Крупные организации любой направленности зарастают бюрократией чуть больше чем наполовину. И альтернатива крупной организации — стартап.
Самое удивительное, однако, что люди ничему не учатся. Все понимают, что крупная организация зарастает бюрократией, и теряет гибкость. Все вспоминают как было хорошо десять лет назад когда фирма состояла из десяти человек, однако, каждый раз в ходе развития фирма превращается в уг. Почему же не возникает новых организационных моделей? Ну например, если стартап так хорошо работает, пусть фирма будет зонтиком нескольких самостоятельных стартапов. Но тут возникает вопрос власти, и страха — причина всех человеческих бед — а что если они возьмут и поросто уйдут все разом. Поэтому все крупные фирмы имеют форму пирамиды — пирамиды говна.
А если все крупные фирмы — пирамиды говна, то лучшее что можно сделать, чтобы добиться успеха — стать жуком-навозником :)
прочитав слово «самотестируемая» подумал про что-то из разряда model based testing. A на самом деле это просто DIY система CI. Тесты тут не генерируются сами. Но как инструкция для начинающих девопсов — полезно.
-1 это в понимании разработчика комбинация 0 и valid=false. Просто он это выражает одним не задекларированным значением, и фронтэнд работает с этим значением. И у этой «парочки» (наш фронтэндер + наш разработчик) на данный момент все хорошо. Но этот же поток данных может использоваться без предупреждения и другими клиентами, на то это и интерфейс. И тогда будет мягко говоря неловкая ситуация…
Вот и получается та ситуация которую я в частности критикую «я самый умный, я сделаю как я хочу и пофиг на всех остальных» и этому я не вижу никакого оправдания. Именно эта уверенность в своей правоте порой ошарашивает, нет бы хоть на минуту усомниться. Спросить архитектора или тех лида наконец.
Но не исключено, что это еще и возрастное, как правило разрабы за 30 уже не страдают такой бескомпромиссностью и уверенностью.
Или архитектор, может посмотреть на код и ляпнуть что-нибудь обидное в адрес разработчика. Зачем? Где коммуникационные навыки? Это тоже проявление ЧСВ. Можно ведь все тоже самое обьяснить нормально. Это поможет разработчику улучшить его навыки. А глупым оскорблением хорошего разработчика не воспитаешь. Вот и получается, что общаться между собой команда разработки практически не может, чтобы никогда никого не обижать. И вот о чем я говорю, что как мне кажется такое проявления ЧСВ — в особой мере присуще этой профессиональной группе.
То что по отношению к заказчику все профессионалы бывают чсв-шными от сантехника до врача — это мы знаем. Но между собой. Вот что удивляет больше всего.
ну сервер посылает 0 сервис не доступен, 1 сервис доступен, (хотя внутренне различает четыре состояния, но это клиента не интересует) При инициализации он шлет наружу 0, и то что значение не валидно. т.е. обрабатывать его рано. А в интепретации разработчика поскольку нет других клиентов, он сделал 0, 1 и -1 причем первые две задекларированы а третье значение нет. Ну вот и получается что получается, нужно будет рано или поздно переделывать.
Вернувшись к аналогии с кирпичами, может это связано с тем, что как правило есть много поля для интерпретации в API, интерфейсах, документации. И соответственно там где нет четкого определения «правильно» разработчик включает мозги и делает свою интепретацию. Которая тоже не лишена смысла.
клиент получает обьект с обновлением, и в нем содержится значение, и, используя метод проверки валидности, можно проверить валидность этого значения, т.е. можно этим значением пользоваться или нет. Например до полной калибровки системы значения невалидны и не должны отображаться.
Так вот значения не обязательно числовые, поэтому я так думаю архитектор делал булевый метод который для любого переданного значения дает валидность этого значения. С другой стороны аргументы разработчика тоже понятны. Что делать тестировщику?
так вот, я тестировщик, мне что делать? Как тестировать такой интерфейс. По имплементации программиста или использовать только те константы которые задекларированы в интерфейсе. Т.е с точки зрения стороннего клиента который ни про какие -1 не знает.
Данные о статусе передаются постоянно, и метод проверки валидности для того, чтобы отличать данные которые можно использовать, от тех которые нельзя. Возможно это сомнительный дизайн, но так сделано API передачи данных от системы к программным клиентам. Оно едино для всех системных компонент.
Я не знаю как правильно, я предлагаю придерживаться интерфейса. Я думаю, что если интерфейс будет в дальнейшем кем-то использоваться то, они будут работать с задекларированными константами. И получив -1 удивятся. Им придется звонить-писать нам, спрашивать в чем дело. Программист им обьяснит. Они договорятся. А можно ведь просто придерживаться интерфейса и не придется никому звонить. Вот и все. Так вот зачем эта самодеятельность. Чем она оправдана? Почему программист считает себя умнее архитектора? Вот что мне не понятно. Даже если он умнее архитектора, сделай как все делают, не переломишься ведь.
Вот возьмем работу какого нибудь мелкого гос-служащего, он же не ставит под вопрос недостатки процессов (лишние ненужные формуляры и т.п.), а просто выполняет ввереную ему работу. Но программист так не умеет.
Хорошо, вот коротенький пример:
внутренне система различает четыре статуса соединения, но для сторонних программных клиентов мы выдаем только два. Есть числовые константы обозначающие для программного клиента статус соединения сервиса. Интерфейс поддерживает метод проверки валидности переданного значения. Так вот, чтобы обозначить для клиента что значение на валидно, разработчик решил передавать статус соединения -1. Его нет в константах. Обьяснил тем, что на данный момент у нас только один программный клиент — это мы сами, и там они договорились с разработчиком что -1 это невалидное значение. А если появятся другие клиенты то можно с ними договориться.
Т.е. мы максимально неверно используем собственный интерфейс. Не используем метод проверки валидности значения, а используем незадекларированную константу.
Вот что про это можно сказать. У меня только полярная лисица приходин на ум.
Спасибо за ответ. Я тут еще раз подумал, и в купе с вашим замечанием, пришел к мысли, что вполне вероятно у меня просто искаженное восприятие. Просто у меня незаконченное айти образование, и скорее всего появился комплекс, из-за которого я слишком близко принимаю когда меня поправляют люди с большим опытом работы или знаниями. Или если я задаю какой-то вопрос, то мне кажется, что мне обьясняют категоричным надменным тоном, а на самом деле это просто мой комплекс приплетает подтекст которого нет. Надо будет понаблюдать за собой.
Спасибо Вам за участие в обсуждении. Я эту дискуссию не ради базара начал, мне хочется понять, что делает этих людей особенными. Может мои наблюдения, на которых основаны, мои выводы однобоки. Потому что мне не с чем сравнить.

Мне, вобщем, не понятно, почему айтишники ставят себя всегда особняком. Ни одна инженерная профессия не порождает столько людей с завышеным самомнением, которые кичатся своими знаниями. Хотя в этой профессии нет ничего особенного. Ничего такого, что делало бы ее отличной от других профессий.
Вот когда программист начинает думать что его профессия — творческая, начинаются велосипеды и рвутся все дедлайны. Творческая работа скорее у программного архитектора.
А разработчик просто наполняет систему кодом. Как правило в сложных системах есть сложный фреймворк, но при этом каждый программист а пишет довольно простой код. Кладет свои кирпичи в раму. Но и тут находятся такие, которые кладут кирпичи поперек, поскольку ну раз нет спецификации, и никто не запрещает делать иначе, почему нет. Рама выложена кирпичами — чего тебе еще надо. Лишь бы сделать по-другому. Проявить свое творчество. Такие персонажи встречаются к сожалению. А может просто профессия засорена людьми без профильного образования.
В социальном плане эта профессиональная группа в основном состоит из крайностей. Или нерды-аутисты, или чуваки с синдромом Даннинга-Крюгера. Серединки маловато. У нас в команде из 20 человек «простых» ребят — меньше половины. К остальным, порой, не знаешь как подойти, чтобы не быть раздавленным их умственным превосходством. Не знаю с чем это связано, может и от возраста зависит.
вот, только что в комментариях к статье habrahabr.ru/post/341626 наткнулся:
github.com/web-standards-ru/dictionary/issues/178 — работа переводчика тоже может заставлять его адаптировать и придумывать новое. Это нисколько не тривиальная и не рутинная работа. Но это ремесло. (просто многие программисты относятся к плодам своей работы с преувеличенным трепетом, а на самом деле можно к этому просто относиться как к переводу, перевел, отредактировал, сдал, приняли, отлично, нет, отредактировал второй раз, сдал, забыл)
Однако и в дискуссии переводчиков (причем это однозначно технические переводчики, приобщенные к теме перевода) заметно напряжение, многополярность мнений, но в отличии от айтишников они никого за другое мнение не презирают, не оскорбляют, не минусуют, и не считают дураками, и в целом приветствуют эту дискуссиию.
В них нет этого ничем не оправданного элитизма, который я упоминал в изначальном комментарии и который я надух не переношу. А так все хорошие ребята.
кдпв и подпись к ней — 10/10.
мне кажется все зацепились за слово переводчик, как профессию. Я же скорее имею ввиду переводчика как того, что переводит информацию из источника на язык получателя. И командир в таком случае, переводит информацию которую он получает о ситуации, в информацию (инструкции) для подчиненных, для выполнения задач.

В «защиту» своей «аналогии» процитирую еще книжку
«Решение задач на компьютерах» Москвитина А.А (с.320):

Чтобы понять природу ошибок ( а это нам необходимо при переходе от неформального описания задачи пользователя к формальной реализации ее в виде программы) при переводе рассмотрим модель [...] Ha на ней человек осуществляет перевод информации из представления А в представление B.
Может это более точное описание, той аналогии которую я имею ввиду.

Information

Rating
Does not participate
Location
Германия
Registered
Activity

Specialization

Test Automation Engineer, Quality Assurance Engineer
Senior
Python
Docker
Git
Linux
OOP