Придумал простой способ добавить себе напоминалки о чём-то, что нужно сделать, глядя в консоль — прямо в консоль.

Простейший алгоритм:

1. глянуть на список вопросов к старшакам условному Senior SDET (экспортед ту pdf на всякий случай), или глянуть сюда
2. напрячься и найти ответы на каждый вопрос по списку,
3. по каждому вопросу сделать отдельный файл с собственным рабочим решением, которое можешь выполнить и объяснить самостоятельно.

В примере всё крутится вокруг java, но ЯП не имеет значения, за какой уже хоть как-то взялся, тот и юзай.

Общие вопросы вроде «24. Детально опишите ваш прошлый проект» можно лихо скипнуть, а можно подумать, как ответить, если когда-нибудь такое спросят.

Дело это небыстрое, но благодарное. Кто выплывет — молодец, остальные берут кредиты и записываются на курсы с гарантированным трудоустройством (там постоянно нужны верующие в волшебство).

Когда в мае 2019 я, еще из Харькова, подписывал аренду дома в Монреале, я прочитал контракт. Вот больше всего запомнилось:

— курить нельзя.

— кальян тоже нельзя

— курить нельзя в доме и кругом

— в доме и кругом курить нельзя

— в гараже, на лестницах, и вокруг дома курить нельзя

— ночью тоже курить нельзя. И в другое время суток тоже.

— на бэкярде курить нельзя

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

Я потом выгреб дофига бычков с бэкярда.

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

В таких условиях тестировщики начинают сочинять тесты в стиле «Открыл экран, описываю последовательно все действия на этом экране», и уже с трудом можно сфокусироваться и спросить, соппсно, а в чём был обще-глобальный смысл тестируемой функциональности? Может, оно вообще не о том, о чём кажется.

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

Про всё то, что из нашего царства аутсорсинга постоянно не видно.

Когда все тестировщики помрут, так оно и…

Вы покайтеся да раскайтеся заранее.

Сегодня имел удовольствие поматериццо объяснять начинающему тестировщику, что не существует «автоматизация тестирования» как некий отдельный объект или навык, который нужно учить отдельно от всего; что учить автоматизацию тестирования нужно в комплексе со всем остальным; что не надо «Сперва я выучу html, а затем CSS, потом JS и Selenium IDE», что надо ковырять всё одновременно.

А он не поверил.

Можно ли представить себе хорошего линуксового системного администратора, который не знает общую теорию операционных систем и сетей, не подозревает о существовании Windows и MacOS, не умеет пользоваться для настройки системы консолью так же хорошо, как графической оболочкой? Можно ли считать хорошим инженером-строителем человека, который не владеет сопроматом, не знает про современные строительные материалы и особенности их применения, даже если на текущем объекте строительства они не используются? Можно ли признать хорошим актёром того, кто день за днём играет одну и ту же роль, не знает о современных тенденциях в театральном искусстве и не пытается попробовать себя в других амплуа?

Хороший специалист должен обладать достаточно широкими знаниями. Да, он глубоко изучает какую-то одну тему, специализируется в каком-то направлении, но при этом он должен представлять себе общую картину своей профессиональной области. Если он не будет это делать — мир уйдёт вперёд, его узкая тема окажется устаревшей и невостребованной, а он ничего другого не знает и не умеет.

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

И конечно же надо уметь делать хорошие автотесты. Да, сначала надо научиться понимать, чем «хорошие» автотесты отличаются от «плохих». А потом — научиться делать «хорошие». Эти правила являются общими, независимыми от конкретного используемого инструмента.

Решение мастера крайне одобряю.

Умиляют заколебали дети, которые уверены в том, что надо «или автоматизировать, или тестировать». Странно, что они не выбирают по утрам «или зубы чистить, или глаза промыть».

Откуда-то слышны мягкие пианинные трельки.

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

Легкая задымленность и маниакальный блеск в глазах говорящего:

— …и поэтому я хочу, чтобы вместо тестировщиков на проекте работали автотесты. Тестирование на нашем проекте уже превышает все бюджеты, заказчик оплачивает только треть всей работы, остальное происходит за наш счет. А качества на проекте как не было, так и нет, постоянно находят какие-то баги! Там уже четыре тестировщика фигачат по девять man/hours в день! Это ж деньги впустую уходят! Это же вчерашний день!

— Дык, тестировщики за качество не отвечают… — из глубин кресла. — Это даже бухгалтера знают. Менеджер проекта отвечает за качество всего проекта…

— Ооооо, как заговорили! Оооо! Ооочень хорошо! Так я их и оптимизирую. Они у меня будут шёлковыми! Значит, так. Постепенно уводим ручных тестировщиков с проекта. Заменяем их одним (ладно, двумя) автоматизаторами. Автоматизаторы автоматизируют все тест-кейсы. Ручные тестировщики больше не нужны. Выкатываем новый релиз, напускаем на него автотесты. Бинго!

— Где же удешевление, если час работы автотестера в три раза дороже обычного…

— …но они там ненадолго. Автоматизируют всё, и уйдут!

— Нет, они там поселятся очень надолго. Мадам Козятина, нам ещё угля подсыпьте. Смотри… твоя идея здравая и правильная, если воспринимать ВЕСЬ процесс тестирования как одноразовую задачу. В каком-то смысле, написание и прогон тест-кейса — это одноразовая задача. Но софт не разрабатывается одноразово.

— Чё-то как-то слишком сложно…

— Проект у нас существует только потому, что в него постоянно вносятся какие-то корректировки и хотелки заказчика. Основная часть проекта работает стабильно, ведь её не трогают. Всё остальное надо постоянно проверять. Так?

— Так.

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

Мммм…

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

— Так.

— Так вот, твой автоматизатор НИКОГДА не угонится за ручными тестировщиками, ведь они постоянно будут генерировать новый «контент». А если ручных тестировщиков на проекте не будет, то автоматизатору придется придумывать и прогонять тест-кейсы самому. Долго он будет этим заниматься?

— Так… хз же…

— Что в итоге: твой автоматизатор будет обеспечен постоянной работой, твои «ручные» тестировщики будут обеспечены постоянной работой, расходы на тестирование со временем обязательно вырастают, а качество на твой проект все равно не придёт.

— Сфигали?

— Дык качество не приходит/уходит. Оно или есть, или нет. Тестировщики его просто фиксируют (как твой градусник), а не приносят.

— Эти тестировщики… (убежденно) Таки это падлы…

— Проблема твоего проекта не в тестировщиках. И даже не в программистах. У тебя программисты на проекте откровенно работают в стиле “good enough”. И заказчики используют свой магазин в стиле “good enough” (я видел, что у вас там триста багов постоянно открыты, из одного релиза в другой переходят, и никто от них не страдает). А от тестировщиков ты требуешь работать в стиле “makes perfect”. Why? Fuck you, that’s why!

— Недопонял.

— “Good enough” означает «достаточно хорошо для бизнеса». Не всегда нужно, чтобы весь софт работал идеально. Не всегда необходимо, чтобы процессы в той же логистике были идеально отлажены. Бизнес идет, деньги идут, все ок. Раздуй угли… Так вот, у тестировщиков всё точно так же. Они не могут доказать, что в софте нет багов. Они также не могут доказать, что баги есть — им надо проверять все предположения. Они очень многое предполагают и на очень многое надеются, обычно необоснованно. Это “good enough” для тестирования. Вообще, чего ты к тестировщикам привязался? На твоем проекте всё, вроде бы, нормально.

— Нормально оно только внешне и только сейчас. В принципе же у нас потенциальная проблема. Через полгода на проекте понадобится больше тестировщиков…

— Не понадобится. Тебе понадобится вообще три человека как постоянная команда — двое ручных тестировщиков, которые больше будут работать головой, чем кодить, и один автоматизатор, который больше будет кодить, чем думать. Гибкость понадобится только в распределении задач на тестирование — их всегда нужно будет ограничивать. “Good enough” так “good enough”.

Конкретно: раздели все функциональные возможности проекта на три чек-листа:

1) New features

2) Critical areas

3) General areas

При выпуске каждого билда тестируется в обязательном порядке всё, что попадает в “New features”. Затем (или одновременно с этим) обязательно тестируется всё то, что попадает в раздел “Critical areas”. А “General areas” — фиг с ними. Если до них руки дойдут – ок. Если не дойдут (а всегда не доходят) — пофигу. “Good enough”.

После выпуска билда начинается обязательная подготовка к следующему. Все штуки из раздела “New features” обязательно переносятся в “Critical” или “General” — по ситуации. “General areas” будет постоянно разрастаться, ну и фиг с ним. Внутри этого списка тоже всё будет ранжировано по степени важности, по убывающей, поэтому самые важные пункты будут проверяться первыми. Зачем тебе вообще тестировщики на проекте?

— Ну, надо же знать, если что-то важное не поломалось…

— Чтобы это узнавать, тестировщики не нужны. Это могут сделать и твои программисты, и ты сам. Тестировщики тебе нужны для того, чтобы придумывать, что и как проверять на работоспособность и на вшивость.

Вообще, всё тестирование обычно сосредоточено на том, чтобы сравнить работоспособность функционала (или возможностей), который перечислен в разделе “Critical areas” с предполагаемым идеалом. Но идеал… Если там что-то работает в принципе, то этого “good enough”. Ты постоянно выпускаешь софт с какими-то багами, я видел.

— Но без критикалов! У нас условие такое, что в выпускаемом релизе не должно быть ни одного критического бага. Или, упаси Шива, блокер…

— Вот именно. Проверяется и чинится самое важное. Всё остальное проверяется или на ходу, или по возможности, но редко целенаправленно. И еще баги тоже ранжируются, самые важные баги — из раздела “Critical areas”. Вообще, требовать «тестировать всё!» — это очень, очень, очень глупо и самонадеянно.

— Разве “New features” не самые важные?

— Это важнее важного только в день выпуска, а завтра все твои “New features” уже должны отображаться в списке “Critical” или “General”. Поэтому, всё равно всё сводится к одному и тому же.

— А что из этого надо будет автоматизировать?

— Всё то, что находится в разделе “General areas”. Остальное — если руки дойдут. То есть, никогда.

— То есть, как это — никогда?

— Так, что все штуки из “Critical areas” тестировщики в принципе будут обязательно проверять руками, да ещё и неоднократно. Пусть робот тестирует то, что в “General areas” находится, ведь туда тестировщики могут и не дойти, время на тестирование все-таки ограничено. Да и, как правило, именно такие места реже всего изменяются, что для автоматизации благо. Автоматика будет проверять надежность самого надежного функционала. Ведь хуже всего, когда ВНЕЗАПНО находится баг там, где, казалось бы, все очень надёжно.

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

— А я же встречаюсь с самой красивой тестировщицей в этом городе. Она после секса постоянно болтает о тестировании. Мадам Козятина! Нам еще трошки угля, пожалуйста… Что-то сегодня день дождливый.

— Такое вот начало лета…

— Да… Наверное, черешня не уродится.

— Да, наверное…

Канер, Фолкнер и Нгуен…

Я выступал на ней вчера с докладом о философии автоматизации процессов тестирования.

Резюмирующие репортажи Тани Зинченко раскрывают всю надноготную происходящего, я же хочу посмотреть на его подноготную.

Молдова Нулл

С 14 января 1907 г. по 15 октября 1908 г. в Кишиневе входила и выходила газета с эпикфэйлическим названием «Молдаванин». Чем-то это напоминает заголовки современной «КП» в стиле «Молдаванин зарезал жену, себя и трех навеки онемевших свидетелей своего страшного бытового преступления«.

От нее остался лишь вот такой библиотечный артефакт (Википедия):

Читать это безусловно интересно.

• В оригинале газета называется (и произносится с ударением на «а») «Молдованул»,
• финансировалась губернскими властями,
• стоила три копейки (дорого, имхо),
• была призвана бороться с революционными и сепаратистскими идеями (в 1905 в России случилась первая революция, предтеча 1917-го — властям таки было с чем бороться),
• руководилась нехилым писателем по имени Г.В. Мадан (в детстве читал его произведения; сегодня их вряд ли кто-то найдет),
• и была она составлена из весьма странного по стилистике и орфографии румынского языка. Очевидно, его следует считать оригинальным «молдавским».

Примечательна тем, что…

Нет, сперва важная предыстория, чтобы был правильный антураж.

В 1903 году в Кишиневе состоялся шикарнейший еврейский погром.

Случился он не ВНЕЗАПНО и не случайно, и прошел «При огромном скопленьи народа»© и при попустительстве городских властей.

В 1905-ом аналогичные мероприятия с большим успехом у публики прошли в ряде городов Российской Империи (Одесса, Ростов-на-Дону, Торжок), затем стихли к 1907-му.

На странице в правой колонке видно рассужденьческое воззвание ко всем «землянам» (на самом деле — ко всем землевладельцам, но прямой перевод порождает такой вот двусмысленный кунштюк от которого я не могу удержаться), которых неизвестный автор* призывает своих глупых соотечественников** вступать в земельные товарищества по примеру российских крестьян.

* Вероятно, сам гл. редактор.

** Не шутка, так составлен текст. Чем-то оно напоминает описание национального характера, составленное Дмитрием Кантемиром (кореш царя Петра I-го).

Важными мне тут кажутся не идеи, а стилистика языка и выражения, в которых составлен этот призыв: «Нет никакой другой возможности избавиться от оков бедности, темноты житейской безграмотности и жидовского ярма кроме как […] вступать в земельные товарищества» — дальнейшее пропустим, этого достаточно.

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

Это скриншот-открытие не только проясняет мне кое-чего в истории тогдашней Молдовы, но и с марта сего года постоянно находится на моем рабочем столе.

Смотрится невероятно неземно, хотя и видно редко, да и кто из земель киевских все это дело поймет…

О чем это я?

А! Конфетка!

Расшаривание экранов докладчиков является самым забавляющим моментом любой он-лайновой конференции. Конфетка в этом смысле не исключение.

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

Затем

Случился доклад

Конечно, у меня были слайды. Но были они черно-белыми, без оформления, и представляли собой просто план рассказа, поэтому презентацию я провел безо всяких слайдов.

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

Я «хотел бы знать», когда будет разрешено публиковать в открытом доступе материалы конференции, поэтому видео доклада пока что не будет.

Подождем 70 лет, когда истечет срок копирайта, и закрытый раздел конференции на форуме перейдет в общественное достояние 🙂

Говорить пришлось быстро, очень быстро, еще быстрее.

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

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

Конфетка понравилась.

Сжатый формат понравился, прежде всего, плюс ориентирование на «рассказать о чем-то таком, что можно сразу взять и применить» форматировало выступление определенным образом, плюс необычная «говорильня в монитор».

Да, очень неприятно отсутствие зрительного контакта со слушателями, опыт, мгм, интересный. Чтобы это преодолеть, следует поставить перед собой зеркало, наверное, или веб-камеру…

Какое-то ощущение аудитории приходило из твиттера (#confetqa) — ой, едрён батон, было сложно читать «до того, как», и неожиданно легко после.

После выступления чувствовал себя ВНЕЗАПНО неимоверно «усталым и побитым», но оно того стоило.

Спасибо!

ЗЫ Глянул на свой рабочий стол — в левой колонке-обращении к читателям, давно умерший Георгий Мадан говорит то, что можно было бы сказать и сегодня, но лучше мне свои слова подобрать, бо у него там, елы-палы, новогоднее поздравление.

🙂

В процессе участия я запоролся на слове «воркшоп». Оно ведь как переводится? Пяможитейская логика подсказывает, что речь идет о месте, где продается работа. Дык тогда каждый киевский офис — суть воркшоп…

Оказалось, что воркшоп — это цех (мастерская), в которой можно нахвататься каких-то рабочих навыков.

В общем, не суть важно.

Важное выяснилось только что: стандартный механизм добавления картинок в WordPress под FF7.01 в Ubuntu не видит в каталогах файлы, у которых расширение написано заглавными буквами.

• «файл.JPG» — не видит.
• «файл.jpg» — видит.

Андрей Дзыня в стотысячный раз основывает фреймворк для автоматизации

Важно то, что я давно не видел в офисе SysIQ столько ноутбуков с Ubuntu.

Это впечатлило.

У нас же весь офис под властью винды.

Я даже притащил в зал свой ноут, чтобы не выделяться 🙂 бо у меня ж там тоже Ubuntu, которую я никак не хочу обновлять.

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

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

Вот что получил:

У меня 10.10, но в справке указано 11.04.

Отлично! И обновляться не надо.

Попадание под прицел фотокорреспондента

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

На слайде виден текст: «Заказчик хочет вы… интерациональный уровень«.

Михаил Поляруш объясняет, что "Заказчик хочет вы..."

]]> https://testitquickly.com/2011/10/16/vindem-lucrul/feed/ 8 2603 https://testitquickly.com/2011/07/17/dumb-robot/ https://testitquickly.com/2011/07/17/dumb-robot/#comments Sun, 17 Jul 2011 19:20:30 +0000 http://testitquickly.com/?p=2391 Читать далее »]]> Попробуем протестировать следующие утверждения:

1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам.

Удивительно абстрактно, не так ли?

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

Какого типа вред человеку должен отмечать робот? Физический, моральный, гипотетический, умственный, потенциальный?

Почему не установлен уровень меры в третьем законе?

Каким образом формулировка третьего закона разрешает роботу действовать даже в том случае, если он будет уничтожен?

Что должен делать робот, если Человек выглядит не как человек, или речь вообще идет не о человеке?

Роботы Утренней зари вообще очень абстрактно рассуждали, и принимали не то чтобы самостоятельные, но очень этически обоснованные решения.

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

И программировали их не на Java.

Я попытался представить себе на своем уровне знания Java, каким образом работала бы программа по принятию решений о том, что может приносить вред человеку («чтобы своим бездействием не допустить…»), и очень обломался.

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

Есть ли у кого-нибудь на примете фантастика из области роботехники, написанная программистом?

Читал ли кто-нибудь что-нибудь из фантастики про то, как роботов тестировали?

Азимов тут отпадает почти полностью, в «Как потерялся робот» попытки вычислить робота «без первого закона» происходят в этической плоскости, чего роботам доступно быть не должно в принципе.

— Ты знаешь, что такое гамма-лучи? — резко спросил Богерт.

— Какое-то излучение, сэр?

Следующий вопрос был задан дружеским тоном, как будто между прочим:

— Ты когда-нибудь имел дело с гамма-лучами?

— Нет, сэр, — уверенно ответил робот.

— Гм… Ну так вот, гамма лучи мгновенно убьют тебя. Они уничтожат твой мозг. Ты должен это знать и помнить. Конечно, ты не хочешь быть уничтоженным.

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

— Да, это верно. — Казалось, Богерт был озабочен этим. — Я могу посоветовать тебе только одно. Если ты заметишь между собой и человеком гамма-излучение, ты можешь остаться на месте.

Робот явно почувствовал облегчение.

— Спасибо, сэр. Ведь тогда нет никакого смысла…

— Конечно. Но если никакого опасного излучения не будет, тогда совсем другое дело.

— Ну, ясно, сэр. Без всякого сомнения.

— Теперь можешь идти. Человек там, за дверью, отведет тебя в кабину. Жди там.

Когда робот вышел, Богерт повернулся к Сьюзен Кэлвин:

— Ну как, Сьюзен?

— Очень хорошо, — ответила она вяло.

— А может быть, мы могли бы поймать Нестора-10, быстро задавая вопросы по физике поля?

— Может быть, но не наверное. — Ее руки бессильно лежали на коленях. — Имейте в виду, он борется против нас. Он настороже. Единственный способ поймать его — это хитрость. А думать он может — в пределах своих возможностей — гораздо быстрее, чем человек.