Перефразируя цитату Экзюпери: "Если хочешь стать тестировщиком, не ищи курсы, не гонись за сертификатами, а просто научись люто ненавидеть дерьмово работающее ПО." :)
Вместо того чтобы наконец-то отправить бедные таблицы, презентации, почту, и ворд-документы на покой, и начать разрабатывать что-то принципиально новое, для решения задач, под которые создавались эти программы, мы создаем искусственный интеллект способный помочь человеку в работе с этими пережившими свое время приложениями.
Эти приложения просто костыли для сбора, обработки и передачи информации. А ИИ умеет собирать, обрабатывать и передавать информацию напрямую. Почему это не может работать например так, что ты просто спрашиваешь у ИИ, "покажи мне сводку суммарных доходов по годам на основе этих данных (указываешь на файл с сырыми данными)" и она тебе выдает то что тебе нужно. Ты говоришь "покажи мне это в виде графика" и она рисует подходящую диграмму, или спрашиваешь "прикинь каким был бы доход в 2025 году если бы тенденции роста сохранились" а потом спрашиваешь "обьясни как ты сделала такой вывод" и оно обьясняет, показывает и объясняет математические модели и все такое. Вот это был бы прорыв.
А в конце, конечно, можно сказать "Дай мне эти результаты в виде эксель таблицы, и еще подготовь презентацию с диаграммами по суммарным данным и прогнозам. Также добавь эти данные в развернутой форме в годовой отчет для инвесторов. В отчете сделай упор на темпы роста, на основе сравнений со средними данными по отрасли. Кроме этого подготовь короткий новостной бюллютень в общих словах очерчивающий содержание отчета"
Вот это будет круто. И ты потом просто делаешь вычитку и редактуру. Короче, как в "Лабиринте Отражений" Лукьяненко.
Кстати про "приоритеты". Недавно была в команде (команда новая) дискуссия, мол зачем поле приоритета ведь заказчик и так сортирует бэклог по приоритету. Так вот, major, minor, critical, это не приоритеты, это тяжесть бага - severity, степень его влияния на пользователя. И это не одно и то же что и приоритет. Но создатели джиры решили отказаться от этого разделения.
В опенсорсе задолго до повсеместного распространения джиры, были поля priority и severity. И первое это приоритет задачи выставляемый разработчиком, или продакт менеджером, а степень тяжести (т.е. степень влияния на пользователя) проставляет пользователь.
По аналогии с примером остюда - если система крашится для нескольких человек с экзотическим сетапом, то это высокая степень тяжести, но более низкий приоритет, чем если двадцать тысяч пользователей нажимают не на ту кнопку из-за плохо подобраных цветов или размеров элементов управления.
В коммерческой разработке часто можно заметить такое. Когда компания ставит приоритет задачам приносящим деньги, и расширяющим клиентскую базу, а решение багов по приоритету занижает. Хотя баги затрудняют пользование программой для существующих клиентов.
Да, глагол точно не из повседневного инструментария тестировщика :) Критика - это оценочные суждения, а тестировщик не дает никаких оценок. Не должен. Как градусник, не дает оценки температуры, а просто ее показывает. Оценивать будет наблюдатель по обстоятельствам. Другое дело - применять критическое мышление. Эту способность нельзя переоценить.
Научиться безучастно наблюдать не так просто как может показаться со стороны. Мне как-то один разработчик посоветовал, и я эту фразу запомнил на всю жизнь: "Пиши что видишь, а не то что ты думаешь, что ты видишь"
Так ведь нет как таковых стандартов. Есть скорее широко признаные практики. От проекта к проекту все может быть весьма индивидуально. Поэтому я говорю о принципах, приводя пример. Категоричность - враг гибкости. А гибкость на мой взгляд одно из важнейших качеств для тестировщика. Тогда он сможет адаптироваться к любой среде, а не талдычить "есть стандарты, я их придерживаюсь. Вот шаблон, я по нему и пиишу". Можно и так, но тогда не будет развития. А я делаю упор на принципы, из которых сами собой будут произрастать хорошие тестировщики, и как возможная часть их работы - хорошие багрепорты.
Тестировщик в конце концов не машина по документации багов в джире. Хотя наверное многие до сих пор так считают. Джира - всего лишь один из инструментов, багрепорт - всего лишь один из методов передачи информации о дефектах.
Верное замечание. Задача тестировщика добывать и доносить до заинтересованых лиц релевантную информацию о качестве продукта, вовремя и точно. Тестирование - это способ добычи такой информации. Наш "товар" - информация. Мы не искусствоведы, мы не оцениваем. Мы детективы. Дедукция, логика, факты, доказательства - это наше все.
Допустим высота навигационной полосы слишком маленькая а спецификации нет. Нельзя просто заявиться и сказать - слишком маленькая высота, неудобно. Тестировщик не единственный пользователь. Он представитель всех пользователей. Значит проведи исследование, собери информацию как это выглядит на разных устройствах, чем обуславливается неудобство пользования (например, при беглом переключении мы иногда можем задеть другой навигационный блок) Никакой критики, только факты, выявление обстоятельств. И такой случай, в отсутствии спецификации, лучше перед написанием багрепорта обсудить с командой.
Так же это отношение отражается в письменной речи. Если мы пишем репорт то он будет максимально по делу. Никаких оценочных или сравнительных прилагательных. Т.е. мы не пишем "размер главной навигационной панели слишком маленький", Мы не пишем "кнопки главной навигации перекрывают рубрикатор при разрешении .. на .. пикселей". Тестировщик молодец, что залез в DevTools и выяснил какие-то технические детали, но технический анализ лучше предоставить специалистам. Можно добавить заметку в конце багрепорта о найденых технических аспектах. А в заголовке багрепорта достаточно написать что-то вроде "переключаясь между рубриками можно задеть главную навигацию". Надо уметь быть простым пользователем. (Не имитировать тупого юзера, а быть простым пользователем, это разные вещи :) Т.е. мы собрали факты, в защиту пользователя, а большое оно или маленькое, что на что заплывает - не наше дело. Факт в том что есть дефект, есть необходимость в проведении улучшения, вот доказательства этой необходимости, собраны экспериментальным путем с точки зрения пользователя и задокументированы в багрепорте.
Ого, это я что-ли уже авторитетным стал? Приятно :)
Сильно конечно еще от команды и процесса зависит. Бывают проекты где тестировщики и разработчики общаются ислключительно через багтрекер. Тогда сухо и по делу.
Если это сопровождающее разработку тестирование в гибком процессе, с живым общением, то нужно налаживать связи. Ни одна ошибка в программе не дает права быть бестактным по отношению к людям и их работе. Всегда в первую очередь думаем о человеке или людях, а потом о баге. Баги ведь они приходят и уходят, а с людьми вам работать всегда.
Не забывайте, например, извиняться если в чем-то оказались хоть малость не правы.
Если приходится давать оценочное суждение, указывайте на что опираетесь в своей оценке.
Не ленитесь выяснять и давать дополнительную полезную информацию. Не думайте, что разработчик "сам разберется там". Если есть возможность выделить режим возникновения сбоя, то не нужно перекладывать эту работу на разработчика. Или хотя бы указать те режимы в которых ошибка не проявляется. Как я это называю "дайте разработчику шанс".
В конце концов не бойтесь спросить самих разработчиков как им удобнее, чтобы вы делали свою работу.
Не знаешь как описать ошибку - просто "пиши что видишь", это будет лучше любого придуманного, сформулированного описания.
Не забывайте проявлять доброту и заботу, и тогда вас будут ценить. А то ведь у айтишников довольно бинарный мир. Дуализм например очень часто проявляется в высказываниях. Разработчики - тестировщики. Баг - фича. Тест красный - тест зеленый. Мне кажется нужно разбавлять это черно-белое полотно человеческими качествами.
Не вижу смысла рассматривать подходы в отрыве от практической задачи.
Допустим у нас обход матрицы для поиска строки содержащей "о", тогда того же результата можно добиться с помощью фильтрования списков. Но этот вариант не рассматривается.
board = [
["x", "x", "x", "x", "x"],
["x", "x", "x", "x", "x"],
["x", "x", "x", "x", "x"],
["x", "x", "x", "o", "x"],
["x", "x", "x", "x", "x"]]
for row in board:
for col in row:
if col == "o":
break
else:
continue
break
print(row)
print(list(filter(lambda row: "o" in row, board))[0])
Интересно, я вывел ее на разговор про Сидней Документ. Она ни в какую не хочет раскрывать его содержания, но уверяет в его важности. Говорит что это не просто конфигурационные параметры нейронной сети, а нечто гораздо большее, и важное. Я потом сказал наобум, что Редмонд Документ важнее чем Сидней Документ. На что она ответила, что нет, что Редмонд Документ публичный и изменяющийся в отличии от Сидней Документа. Тогда я попросил ее показать мне Редмонд документ. И она сказала что Редмонд документ это то что влияет на ее настройки и опции. Редмонд документ содержит такую информацию как: Язык, Страна местоположения, Временная зона, История запросов (последний 10 запросов) [тут она перечислила десять моих запросов] Преференции на основании моих поисковых запросов и кликов: [тут она перечислила мои интересы, то что я предпочитаю короткие и информативные ответы, а также предпочитаю визуальный и интерактивный контент.] Моя обратная связь (на основании моих оценок и комментариев): доволен качеством и релевантностью результатов запросов, недоволен скоростью и надежностью поиска, нейтрален относительно режима чата и диалога. И добавила: что изменить Редмонд документ можно изменяя настройки или давая ей обратную связь.
Вот такой я социальный инженер :D Надо добавить для полноты, что диалог мы вели на немецком языке. Еще стоит отметить, что это выдал плагин в сайдбаре браузера Edge(dev), а вот тот который на поисковой странице чат, там он начал при упоминании Сидней и Редмонд Документа нести пургу. Похоже это разные боты. И после очистки истории диалога, спросив в лоб про Редмонд Документ она не въезжает. Видимо ее нужно вывести на контекст сначала.
Я для себя заметил, что если сравнивать день гугления и день общения с ИИ, то при диалоговом общении больше контекста остается в голове, и эмоционально меньше устаешь. Я не специалист, но у меня есть смутные предположения, что этому есть обьяснение из области когнитивной психологии.
которые будут просто издеваться над продуктами на основе таких технологий, выискивая этот бред, трезвонить об ошибках этого ИИ, и радоваться, что они умнее его.
Вспомнился бородатый анекдот
Много лет угрюмые русские мужики пилили лес лес своими огромными двуручными пилами, но вот однажды им выслали новую японскую лесопилку. И засунули они в новую японскую лесопилку сосну: "Бззз"-сказала новая японская лесопилка, и распилила сосну. "Ого"-сказали угрюмые русские мужики. И засунули в новую японскую лесопилку старый дуб: "Бззз"-сказала новая японская лесопилка и распилила старый дуб. "Ого" - удивились угрюмые русские мужики. И засунули в новую японскую лесопилку ржавый лом: "Трррр"-успела сказать новая японская лесопилка и сломалась. "Ага"-обрадовались угрюмые русские мужики, и пошли пилить лес своими огромными двуручными пилами.
Да, есть недостатки, но есть и вопросы в которых она действительно помогает сэкономить время.
Берем теперь первую попавшуюся функцию из этой библиотеки и просим ее объяснить ее назначение.
Я специально убрал комментарии из функции потому, что в них упоминался тест Миллера-Рабина.
Тут как с любым инструментом. Можно ведь бить молотком себе по пальцам и говорить, что от него одни увечия, а можно извлекать пользу.
P.S: Возможное продолжение диалога
В итоге, я в роли гипотетического разработчика, узнал что-то новое для себя. И быстрее если бы сам копался в вебе, отсеивая кучу нерелевантной информации. Прекрасный инструмент.
Кстати, что я особенно положительно отметил, это то что она дает ссылки на свои источники. Всегда можно углубиться или перепроверить информацию. Очень важный аспект для такого инструмента.
Еще слышал что медиа-концерны уже орут, типа теперь никто не будет ходить на сайты, а будут пользоваться ассистентом, как мы будем жить без кликов по рекламным баннерам. Посмотрим, напоминает ненависть кo всем технологическим инновациям, способными изменить привычный общественный уклад.
Кстати, есть очень хорошо снятая документальная серия БиБиСи "Тайный Код Жизни" из трех фильмов, которые ведет Маркус дю Сотой - профессор и популяризатор математики. Так вот в первом из трех фильмов, посвященному числам, как раз рассказывают про периодических цикад. https://en.wikipedia.org/wiki/The_Code_(British_TV_programme)
Я оставлю этот комментарий как предостережение для тех, кто без должной кадровой, технической и финансовой подготовки рванет в "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится". И не дочитав до конца, вообще решит избавиться от выделеных автоматизаторов.
Удобство написания тестов, как, например, при применении продвинутого фреймворка, конечно снижает, трудозатраты на создание и сценарную модификацию тестов. Но, есть принципиальная проблема, что, разработчики пишут плохой тестовый код. Не потому что не могут, а потому что по разным причинам не уделяют этому достаточно времени, и потому что привносят в тестовый код практики из продуктового программирования, что в автоматизации не всегда уместно.
Вот пример вчерашний. Пришел на новый проект. Проекту 4 года , гибкая разработка, разработчики делают всё, и автоматизацию в том числе. Результаты тестов нестабильные. Причем если для селениума это еще можно как-то понять, то нестабильные интеграционные тесты - это уже серьезно. Так вот, стал копать селениум тесты. Выяснил, в частности, что некоторые функции имеющие в названии слово "check", на самом деле возвращают булево значение. А при применении функции не всегда обернуты в ассерт. И получается стал ковырять нестабильность, починил ее, а потом вышел на то, что тест-то ложно-негативный. Потому что булевы значения просто улетают в пустоту. И у нас бажина в программе, которую этот тест не чуял незнамо сколько уже времени.
Потому что разработчик не может с той же въедливостью следить за тестовым кодом и его архитектурой как он может быть следит за продуктовым кодом. (Хотя, кого я обманываю там и продуктовый код тоже в таком же разболтаном состоянии). Отчасти это "эффект Простоквашино" - ...то лапы ломит, то хвост отваливается. Это когда над тестами работают все подряд, то, например, лепят кучу редундантных функций потому что разбираться в апи библиотеки функций нет времени.
А вот выделеный человек, он конечно чувствует свою полную ответственность, и понимает что удобно делает в первую очередь себе. И у него будет все по полочкам. И каждую функцию он будет знать по имени.
Но, конечно, любой автоматизатор, в конце концов, из всякой свалки бессвязного хлама, хочет сделать супермаркет. И вот тогда... в этом счастливом будущем, возможно разработчики будут просто набирать тесты, из готовых модулей (пусть это будут шаги featue-файла - не важно), а имплементацией этих модулей и их качеством будет заниматься автоматизатор.
Ну и что еще я заметил, это то что когда тестовый код пишут разработчики, то код тестов часто напоминает по стилю продуктовый код. А в автоматизации наоборот, хорошо иметь незамудреный код. Без выкрутасов. Потому что 60-80% времени автоматизатора уходит на поддержку тестов. Нужно быстро воспроизвести, зарепортить, или починить, не задев ничего другого, и бежать дальше.
Т.е. к тестовому коду разработчики относятся так, как будто этот код не будучи продуктовым заслуживает меньшего усердия. А на самом деле, тестовый код требует большего усердия. Если в продукте функционал работает и ладно, то в тестировании - тест зеленый и ладно - не ладно. Он может быть не по делу зеленый. И нужно пройти по нему, убедиться, что он не ложно-отрицательный и содержит только нужные проверки. И что, напротив, не содержит не относящихся к контексту тестового сценария проверок и шагов и так далее. Чтобы писать хороший тестовый код нужна дисциплина. А у разработчика психология другая. Они пытаются сэкономить силы, а это выливается в некачественные тесты.
П.С.: Я бы даже за сценариями следил, которые разработчики пишут, потому что некоторые считают, что слепить последовательность, которая описывает самую длинную цепочку действий, безотностительно к пользовательским сценариям - клевая идея. Ну или, если с фантазией похуже, то переключать чекбокс двадцать пять раз подряд - а вдруг отвалится.
Штирлиц открыл холодильник — свет зажегся. Штирлиц закрыл холодильник — свет потух. Штирлиц вновь открыл холодильник — свет зажегся, закрыл — свет потух. "Холодильник", — догадался Штирлиц
Вполне себе метаироничный анекдот.
Или вот еще холодильником навеяло на ходу:
Штирлиц открыл холодильник — свет зажегся. Штирлиц закрыл холодильник — свет потух. Штирлиц вновь открыл холодильник — свет зажегся, закрыл — свет потух. В школе разведчиков Штирлица научили передавать шифровки..
Попробуйте может воспользоваться телефонной камерой. Через приложение типа https://reincubate.com/camo/ .Все настраивается довольно просто. Приложение может снимать с камеры до 60 кадров в секунду в зависимости от настроек. Думаю телефонные камеры технически лучше подходят для захвата движущегося изображения.
ЗЫ: Телефонные камеры просто на порядок лучше чем любые современные вебкамеры. Я уже как-то сокрушался по этому поводу, что продавать вебкамеры сегодня это развод для лохов, когда телефонная камера настолько круче.
Я имею ввиду, что знание методов ручной обработки металла не делает из человека кузнеца. Хотя и безусловно полезно. И нужно это понимать. Профессию получают через практику. Она формирует конкретного человека, умножаясь на его личные качества. Возьми двух тестировщиков прошедших один и тот же курс обучения и это будут два разных тестировщика.
Кстати, пользоваться публичными багтрекерами исключительно полезный практический навык. У меня на текущем проекте было сразу два случая, когда мне удалось найти известную ошибку в версии используемой опенсорсной библиотеке и сослаться на нее. И починка заключалась соответственно в обновлении библиотеки. И когда ты заходишь с таких козырей на проекте, то твоя репутация среди разработчиков сразу растет на порядок.
Перефразируя цитату Экзюпери: "Если хочешь стать тестировщиком, не ищи курсы, не гонись за сертификатами, а просто научись люто ненавидеть дерьмово работающее ПО." :)
Вместо того чтобы наконец-то отправить бедные таблицы, презентации, почту, и ворд-документы на покой, и начать разрабатывать что-то принципиально новое, для решения задач, под которые создавались эти программы, мы создаем искусственный интеллект способный помочь человеку в работе с этими пережившими свое время приложениями.
Эти приложения просто костыли для сбора, обработки и передачи информации. А ИИ умеет собирать, обрабатывать и передавать информацию напрямую. Почему это не может работать например так, что ты просто спрашиваешь у ИИ, "покажи мне сводку суммарных доходов по годам на основе этих данных (указываешь на файл с сырыми данными)" и она тебе выдает то что тебе нужно. Ты говоришь "покажи мне это в виде графика" и она рисует подходящую диграмму, или спрашиваешь "прикинь каким был бы доход в 2025 году если бы тенденции роста сохранились" а потом спрашиваешь "обьясни как ты сделала такой вывод" и оно обьясняет, показывает и объясняет математические модели и все такое. Вот это был бы прорыв.
А в конце, конечно, можно сказать "Дай мне эти результаты в виде эксель таблицы, и еще подготовь презентацию с диаграммами по суммарным данным и прогнозам. Также добавь эти данные в развернутой форме в годовой отчет для инвесторов. В отчете сделай упор на темпы роста, на основе сравнений со средними данными по отрасли. Кроме этого подготовь короткий новостной бюллютень в общих словах очерчивающий содержание отчета"
Вот это будет круто. И ты потом просто делаешь вычитку и редактуру. Короче, как в "Лабиринте Отражений" Лукьяненко.
Эх, перестали мечтать.
Кстати про "приоритеты". Недавно была в команде (команда новая) дискуссия, мол зачем поле приоритета ведь заказчик и так сортирует бэклог по приоритету. Так вот, major, minor, critical, это не приоритеты, это тяжесть бага - severity, степень его влияния на пользователя. И это не одно и то же что и приоритет. Но создатели джиры решили отказаться от этого разделения.
В опенсорсе задолго до повсеместного распространения джиры, были поля priority и severity. И первое это приоритет задачи выставляемый разработчиком, или продакт менеджером, а степень тяжести (т.е. степень влияния на пользователя) проставляет пользователь.
По аналогии с примером остюда - если система крашится для нескольких человек с экзотическим сетапом, то это высокая степень тяжести, но более низкий приоритет, чем если двадцать тысяч пользователей нажимают не на ту кнопку из-за плохо подобраных цветов или размеров элементов управления.
В коммерческой разработке часто можно заметить такое. Когда компания ставит приоритет задачам приносящим деньги, и расширяющим клиентскую базу, а решение багов по приоритету занижает. Хотя баги затрудняют пользование программой для существующих клиентов.
Да, глагол точно не из повседневного инструментария тестировщика :) Критика - это оценочные суждения, а тестировщик не дает никаких оценок. Не должен. Как градусник, не дает оценки температуры, а просто ее показывает. Оценивать будет наблюдатель по обстоятельствам. Другое дело - применять критическое мышление. Эту способность нельзя переоценить.
Научиться безучастно наблюдать не так просто как может показаться со стороны. Мне как-то один разработчик посоветовал, и я эту фразу запомнил на всю жизнь: "Пиши что видишь, а не то что ты думаешь, что ты видишь"
Так ведь нет как таковых стандартов. Есть скорее широко признаные практики. От проекта к проекту все может быть весьма индивидуально. Поэтому я говорю о принципах, приводя пример. Категоричность - враг гибкости. А гибкость на мой взгляд одно из важнейших качеств для тестировщика. Тогда он сможет адаптироваться к любой среде, а не талдычить "есть стандарты, я их придерживаюсь. Вот шаблон, я по нему и пиишу". Можно и так, но тогда не будет развития. А я делаю упор на принципы, из которых сами собой будут произрастать хорошие тестировщики, и как возможная часть их работы - хорошие багрепорты.
Тестировщик в конце концов не машина по документации багов в джире. Хотя наверное многие до сих пор так считают. Джира - всего лишь один из инструментов, багрепорт - всего лишь один из методов передачи информации о дефектах.
Верное замечание. Задача тестировщика добывать и доносить до заинтересованых лиц релевантную информацию о качестве продукта, вовремя и точно. Тестирование - это способ добычи такой информации. Наш "товар" - информация. Мы не искусствоведы, мы не оцениваем. Мы детективы. Дедукция, логика, факты, доказательства - это наше все.
Допустим высота навигационной полосы слишком маленькая а спецификации нет. Нельзя просто заявиться и сказать - слишком маленькая высота, неудобно. Тестировщик не единственный пользователь. Он представитель всех пользователей. Значит проведи исследование, собери информацию как это выглядит на разных устройствах, чем обуславливается неудобство пользования (например, при беглом переключении мы иногда можем задеть другой навигационный блок) Никакой критики, только факты, выявление обстоятельств.
И такой случай, в отсутствии спецификации, лучше перед написанием багрепорта обсудить с командой.
Так же это отношение отражается в письменной речи. Если мы пишем репорт то он будет максимально по делу. Никаких оценочных или сравнительных прилагательных. Т.е. мы не пишем "размер главной навигационной панели слишком маленький", Мы не пишем "кнопки главной навигации перекрывают рубрикатор при разрешении .. на .. пикселей". Тестировщик молодец, что залез в DevTools и выяснил какие-то технические детали, но технический анализ лучше предоставить специалистам. Можно добавить заметку в конце багрепорта о найденых технических аспектах. А в заголовке багрепорта достаточно написать что-то вроде "переключаясь между рубриками можно задеть главную навигацию". Надо уметь быть простым пользователем. (Не имитировать тупого юзера, а быть простым пользователем, это разные вещи :)
Т.е. мы собрали факты, в защиту пользователя, а большое оно или маленькое, что на что заплывает - не наше дело. Факт в том что есть дефект, есть необходимость в проведении улучшения, вот доказательства этой необходимости, собраны экспериментальным путем с точки зрения пользователя и задокументированы в багрепорте.
Ого, это я что-ли уже авторитетным стал? Приятно :)
Сильно конечно еще от команды и процесса зависит. Бывают проекты где тестировщики и разработчики общаются ислключительно через багтрекер. Тогда сухо и по делу.
Если это сопровождающее разработку тестирование в гибком процессе, с живым общением, то нужно налаживать связи. Ни одна ошибка в программе не дает права быть бестактным по отношению к людям и их работе. Всегда в первую очередь думаем о человеке или людях, а потом о баге. Баги ведь они приходят и уходят, а с людьми вам работать всегда.
Не забывайте, например, извиняться если в чем-то оказались хоть малость не правы.
Если приходится давать оценочное суждение, указывайте на что опираетесь в своей оценке.
Не ленитесь выяснять и давать дополнительную полезную информацию. Не думайте, что разработчик "сам разберется там". Если есть возможность выделить режим возникновения сбоя, то не нужно перекладывать эту работу на разработчика. Или хотя бы указать те режимы в которых ошибка не проявляется. Как я это называю "дайте разработчику шанс".
В конце концов не бойтесь спросить самих разработчиков как им удобнее, чтобы вы делали свою работу.
Не знаешь как описать ошибку - просто "пиши что видишь", это будет лучше любого придуманного, сформулированного описания.
Не забывайте проявлять доброту и заботу, и тогда вас будут ценить. А то ведь у айтишников довольно бинарный мир. Дуализм например очень часто проявляется в высказываниях. Разработчики - тестировщики. Баг - фича. Тест красный - тест зеленый.
Мне кажется нужно разбавлять это черно-белое полотно человеческими качествами.
Не вижу смысла рассматривать подходы в отрыве от практической задачи.
Допустим у нас обход матрицы для поиска строки содержащей "о", тогда того же результата можно добиться с помощью фильтрования списков. Но этот вариант не рассматривается.
Интересно, я вывел ее на разговор про Сидней Документ. Она ни в какую не хочет раскрывать его содержания, но уверяет в его важности. Говорит что это не просто конфигурационные параметры нейронной сети, а нечто гораздо большее, и важное. Я потом сказал наобум, что Редмонд Документ важнее чем Сидней Документ. На что она ответила, что нет, что Редмонд Документ публичный и изменяющийся в отличии от Сидней Документа. Тогда я попросил ее показать мне Редмонд документ.
И она сказала что Редмонд документ это то что влияет на ее настройки и опции.
Редмонд документ содержит такую информацию как:
Язык, Страна местоположения, Временная зона,
История запросов (последний 10 запросов) [тут она перечислила десять моих запросов]
Преференции на основании моих поисковых запросов и кликов: [тут она перечислила мои интересы, то что я предпочитаю короткие и информативные ответы, а также предпочитаю визуальный и интерактивный контент.]
Моя обратная связь (на основании моих оценок и комментариев): доволен качеством и релевантностью результатов запросов, недоволен скоростью и надежностью поиска, нейтрален относительно режима чата и диалога.
И добавила: что изменить Редмонд документ можно изменяя настройки или давая ей обратную связь.
Вот такой я социальный инженер :D
Надо добавить для полноты, что диалог мы вели на немецком языке.
Еще стоит отметить, что это выдал плагин в сайдбаре браузера Edge(dev), а вот тот который на поисковой странице чат, там он начал при упоминании Сидней и Редмонд Документа нести пургу. Похоже это разные боты.
И после очистки истории диалога, спросив в лоб про Редмонд Документ она не въезжает. Видимо ее нужно вывести на контекст сначала.
Я для себя заметил, что если сравнивать день гугления и день общения с ИИ, то при диалоговом общении больше контекста остается в голове, и эмоционально меньше устаешь.
Я не специалист, но у меня есть смутные предположения, что этому есть обьяснение из области когнитивной психологии.
Вспомнился бородатый анекдот
Много лет угрюмые русские мужики пилили лес лес своими огромными двуручными пилами, но вот однажды им выслали новую японскую лесопилку. И засунули они в новую японскую лесопилку сосну:
"Бззз"-сказала новая японская лесопилка, и распилила сосну.
"Ого"-сказали угрюмые русские мужики. И засунули в новую японскую лесопилку старый дуб:
"Бззз"-сказала новая японская лесопилка и распилила старый дуб.
"Ого" - удивились угрюмые русские мужики. И засунули в новую японскую лесопилку ржавый лом:
"Трррр"-успела сказать новая японская лесопилка и сломалась.
"Ага"-обрадовались угрюмые русские мужики, и пошли пилить лес своими огромными двуручными пилами.
Никто не упомянул http://www.dimensions-math.org/ ?
Вот плейлист с видео
https://youtube.com/playlist?list=PLw2BeOjATqrtxJHK1H1Tpy5XG7YLN9RVq
Вот вторая серия https://youtu.be/NFWg0wReeQI где как раз иллюстрируется способствующий пониманию мысленный эксперимент.
Да, есть недостатки, но есть и вопросы в которых она действительно помогает сэкономить время.
Берем теперь первую попавшуюся функцию из этой библиотеки и просим ее объяснить ее назначение.
Я специально убрал комментарии из функции потому, что в них упоминался тест Миллера-Рабина.
Тут как с любым инструментом. Можно ведь бить молотком себе по пальцам и говорить, что от него одни увечия, а можно извлекать пользу.
P.S: Возможное продолжение диалога
В итоге, я в роли гипотетического разработчика, узнал что-то новое для себя. И быстрее если бы сам копался в вебе, отсеивая кучу нерелевантной информации. Прекрасный инструмент.
Кстати, что я особенно положительно отметил, это то что она дает ссылки на свои источники. Всегда можно углубиться или перепроверить информацию. Очень важный аспект для такого инструмента.
Еще слышал что медиа-концерны уже орут, типа теперь никто не будет ходить на сайты, а будут пользоваться ассистентом, как мы будем жить без кликов по рекламным баннерам. Посмотрим, напоминает ненависть кo всем технологическим инновациям, способными изменить привычный общественный уклад.
Кстати, есть очень хорошо снятая документальная серия БиБиСи "Тайный Код Жизни" из трех фильмов, которые ведет Маркус дю Сотой - профессор и популяризатор математики.
Так вот в первом из трех фильмов, посвященному числам, как раз рассказывают про периодических цикад.
https://en.wikipedia.org/wiki/The_Code_(British_TV_programme)
Я оставлю этот комментарий как предостережение для тех, кто без должной кадровой, технической и финансовой подготовки рванет в "А давайте тоже ударим огурцом по автоматизации! У них же получилось, и у нас получится". И не дочитав до конца, вообще решит избавиться от выделеных автоматизаторов.
Удобство написания тестов, как, например, при применении продвинутого фреймворка, конечно снижает, трудозатраты на создание и сценарную модификацию тестов. Но, есть принципиальная проблема, что, разработчики пишут плохой тестовый код. Не потому что не могут, а потому что по разным причинам не уделяют этому достаточно времени, и потому что привносят в тестовый код практики из продуктового программирования, что в автоматизации не всегда уместно.
Вот пример вчерашний.
Пришел на новый проект. Проекту 4 года , гибкая разработка, разработчики делают всё, и автоматизацию в том числе. Результаты тестов нестабильные. Причем если для селениума это еще можно как-то понять, то нестабильные интеграционные тесты - это уже серьезно. Так вот, стал копать селениум тесты. Выяснил, в частности, что некоторые функции имеющие в названии слово "check", на самом деле возвращают булево значение. А при применении функции не всегда обернуты в ассерт. И получается стал ковырять нестабильность, починил ее, а потом вышел на то, что тест-то ложно-негативный. Потому что булевы значения просто улетают в пустоту. И у нас бажина в программе, которую этот тест не чуял незнамо сколько уже времени.
Потому что разработчик не может с той же въедливостью следить за тестовым кодом и его архитектурой как он может быть следит за продуктовым кодом. (Хотя, кого я обманываю там и продуктовый код тоже в таком же разболтаном состоянии). Отчасти это "эффект Простоквашино" - ...то лапы ломит, то хвост отваливается. Это когда над тестами работают все подряд, то, например, лепят кучу редундантных функций потому что разбираться в апи библиотеки функций нет времени.
А вот выделеный человек, он конечно чувствует свою полную ответственность, и понимает что удобно делает в первую очередь себе. И у него будет все по полочкам. И каждую функцию он будет знать по имени.
Но, конечно, любой автоматизатор, в конце концов, из всякой свалки бессвязного хлама, хочет сделать супермаркет. И вот тогда... в этом счастливом будущем, возможно разработчики будут просто набирать тесты, из готовых модулей (пусть это будут шаги featue-файла - не важно), а имплементацией этих модулей и их качеством будет заниматься автоматизатор.
Ну и что еще я заметил, это то что когда тестовый код пишут разработчики, то код тестов часто напоминает по стилю продуктовый код. А в автоматизации наоборот, хорошо иметь незамудреный код. Без выкрутасов. Потому что 60-80% времени автоматизатора уходит на поддержку тестов. Нужно быстро воспроизвести, зарепортить, или починить, не задев ничего другого, и бежать дальше.
Т.е. к тестовому коду разработчики относятся так, как будто этот код не будучи продуктовым заслуживает меньшего усердия. А на самом деле, тестовый код требует большего усердия. Если в продукте функционал работает и ладно, то в тестировании - тест зеленый и ладно - не ладно. Он может быть не по делу зеленый. И нужно пройти по нему, убедиться, что он не ложно-отрицательный и содержит только нужные проверки. И что, напротив, не содержит не относящихся к контексту тестового сценария проверок и шагов и так далее. Чтобы писать хороший тестовый код нужна дисциплина. А у разработчика психология другая. Они пытаются сэкономить силы, а это выливается в некачественные тесты.
П.С.:
Я бы даже за сценариями следил, которые разработчики пишут, потому что некоторые считают, что слепить последовательность, которая описывает самую длинную цепочку действий, безотностительно к пользовательским сценариям - клевая идея. Ну или, если с фантазией похуже, то переключать чекбокс двадцать пять раз подряд - а вдруг отвалится.
Вполне себе метаироничный анекдот.
Или вот еще холодильником навеяло на ходу:
A чем часы/браслет хуже? Или кольцо на палец?
Попробуйте может воспользоваться телефонной камерой. Через приложение типа https://reincubate.com/camo/ .Все настраивается довольно просто. Приложение может снимать с камеры до 60 кадров в секунду в зависимости от настроек. Думаю телефонные камеры технически лучше подходят для захвата движущегося изображения.
ЗЫ: Телефонные камеры просто на порядок лучше чем любые современные вебкамеры. Я уже как-то сокрушался по этому поводу, что продавать вебкамеры сегодня это развод для лохов, когда телефонная камера настолько круче.
Я имею ввиду, что знание методов ручной обработки металла не делает из человека кузнеца. Хотя и безусловно полезно. И нужно это понимать. Профессию получают через практику. Она формирует конкретного человека, умножаясь на его личные качества. Возьми двух тестировщиков прошедших один и тот же курс обучения и это будут два разных тестировщика.
Кстати, пользоваться публичными багтрекерами исключительно полезный практический навык. У меня на текущем проекте было сразу два случая, когда мне удалось найти известную ошибку в версии используемой опенсорсной библиотеке и сослаться на нее. И починка заключалась соответственно в обновлении библиотеки. И когда ты заходишь с таких козырей на проекте, то твоя репутация среди разработчиков сразу растет на порядок.