Хоть убейте, не понимаю желания играть в такие авантюры. Это как лотерея, только платишь деньги ты. Не понимаю, зачем в это ввязываться частнику при наличии альтернатив.
Как QA могу сказать, что всякое приходится делать. Да, если вы откроете ISTQB, то там скажут, что мы баги ищем, а разработчики дебажат.
По факту же, баги могут быть такие, что не посмотрев в код, до нормальных степов чтобы её зарепродюсить ты в разумные сроки не доберёшься. Многие, собственно, и не добираются, создавая вечно весящие в беклоге ошибки с заголовком, начинающимся с "иногда...". При чём хорошо, если это будет "иногда...". Это может быть описано так, будто происходит всегда и при любых условиях. В реальности у разработчика проблема не повторяется, и бага закрывается.
Так что соглашусь с автором: хотите приносить пользу и чего-то достичь в профессии, придётся что-то уметь.
Вы как будто бы упустили тот момент, когда учёные развенчали идею о том, что человек представляет из себя рационального агента, действующего из сугубо рациональных интересов. Мало кто готов заниматься чем-то исключительно ради денег, во всяком случае продолжительное время.
Тем более это актуально, когда мы говорим о разработчиках. Эта категория людей получает достаточно высокий доход, где каждая лишняя копейка сверху психологически играет всё менее важную роль. Грубо говоря, заработать лишние $500 при доходе в $1000 и в $4000 это не одно и то же.
На первый план выходит удовольствие от жизни, где классный пет-проект может приносить в разы больше удовольствия, чем овертаймы на работе.
Более того, это вообще довольно редкий вид хобби, который помогает развивать важные для работы навыки. Если вы играете на гитаре или ходите в лес с палаткой в свободное время, никто вам не говорит, что вы могли бы вместо этого овертаймить на работе, не так ли?
Да, тоже бросилось в глаза, что автор как будто бы в розовых очках на всё смотрит, а бизнес-модель гугла как будто бы случайно появилась. Ещё могу поверить, что изначально поиск не собирались монетизировать (или не знали как), но дальнейшее направление движения в виде открытия и закрытия проектов вполне проглядывается. Даже если рядовые инженеры, вроде автора, свято верили в иную миссию.
Я утверждаю, что алгоритмические интервью - лучший вариант для ФААНГА из всех пока придуманных.
Я рад за них. Осталось понять, зачем это аудитории хабра. Рискну предположить, что львиная доля людей здесь в указанных компаниях не работает и не собирается. Информация для нас либо иррелевантна, либо этот тезис тут просто лишний, если полезность выходит за рамки очерченного круга.
Что качественная автоматизация, что качественный анализ и ручное тестирование требуют глубокого понимания конкретных областей, при чём в каждой из них требуется очень разный набор знаний. Невозможно написать и развивать хороший автомейшн фреймворк без достаточно глубоких знаний архитектуры проектов, дизайн паттернов и итеративного улучшения. Невозможно анализировать и планиравать тестирование без достаточно глубоких теоретических знаний о разных методологиях, техник тестирования, их плюсов и минусов, менеджерских навыков. Сейчас компании хотят из одного сотрудника получить швейцарский нож, чтобы одной зарплатой убить двух зайцев. В итоге ни автоматическое, ни мануальное тестирование у них нормально не работают.
Да и мало кому одинаково интересны обе этих области, чтобы вкладывать существенные ресурсы для них изучения. Может топовые компании и способны привлекать эту небольшую долю кадров, но их на всех не хватит.
Сорри, если что-то не так понял. Просто задачи довольно смутно сформулированы. За "обеспечение качества" может скрываться какой угодно набор реальных активностей, так что исхожу из стандартного: 50 на 50 между автоматизацией и мануальным тестированием.
Проблема, на мой взгляд, не до конца описана. Зачем, собственно, решать капчу в автотесте? Бывает надо проверить реальную интеграцию, но как будто бы не очень часто это происходит и не много усилий требует. В остальных тестах DUT конфигурируется так, чтобы она не мешала.
Что касается решения, то судя по коду, капчу решает сторонний сервис. Это рабочее решение, но не шибко интересное.
Мне ChatGPT помогал быстро накидать типовые тест-кейсы по самым распространённым техникам тестирования. Это удобно. Но дальше демо дело не зашло, ибо сливать туда закрытые коммерческие данные было бы глупо.
Зачем его использовать для баг репортов я не очень понимаю. Написать репорт - это простейшая часть работы. Сложная часть предшествует ей, поскольку такие тривиальные баги, как в вашем примере, крайне редки.
Реальные проблемы часто возникают на стыке бекенда и фронтенда, или при определённом стейте одного из компонентов, который вовсе не очевиден без детального анализа этих компонентов, да ещё и скрыт за впнами. И вот сборка этого паззла чат-ботам неподвластна, во всяком случае пока.
Да в общем-то надо ли оно? День, когда чатжпт научится эффективно решать все эти проблемы будет днём, когда вы перестанете быть нужны. Во всяком случае я не вижу, где здесь могут появиться новые таски, которые мог бы выполнять человек. Много людей для составления промтов не нужно, что ударит не только по количеству рабочих мест, но и по зарплатам.
Материал интересный, спасибо. Было бы хорошо указать оригинальные названия когнитивных искажений - на английском. Они всё-равно все из англоговорящей среды идут, и в русском языке их все переводят немного по-разному, что усложняет дальнейший поиск информации.
А обязательно ли для этого использовать Cucumber? Как мне представляется, его главная фича - это создание связи между текстом, написанном на Gherkin, и кодом. Что требует дополнительного эффорта.
Если нужно просто динамически подгружать разные наборы тестовых данных, для этого наверное можно найти более точечные инструменты. Или не так?
Интересно, за промты к артам и спрайтам тоже спасибо. Я так понимаю Midjourney может генерировать только статичные картинки, но не разбитую по кадрам полноценная генерация спрайтов с анимациямианимацию? Не уверен, как это правильно называется.
Из статьи складывается впечатление, что вас больше мотивируют деньги, чем процесс разработки. При чём стремление к деньгам возникло ввиду потребности повысить уровень жизни, так что с его ростом пропадёт и эта мотивация. Когда это случится, программирование рискует стать ещё одной не интересной работой, от которой будет тошнить.
На мой взгляд, с такими вводными сложно достичь чего-то в любой профессии, где требуется высокая квалификация и её регулярное повышение теми или иными средствами.
Найти привлекательный пет-проект может быть сложно. Но именно в них можно попробовать что-то новое и необычное, для чего не всегда есть возможность на регулярном месте работы.
Хоть убейте, не понимаю желания играть в такие авантюры. Это как лотерея, только платишь деньги ты. Не понимаю, зачем в это ввязываться частнику при наличии альтернатив.
Как QA могу сказать, что всякое приходится делать. Да, если вы откроете ISTQB, то там скажут, что мы баги ищем, а разработчики дебажат.
По факту же, баги могут быть такие, что не посмотрев в код, до нормальных степов чтобы её зарепродюсить ты в разумные сроки не доберёшься. Многие, собственно, и не добираются, создавая вечно весящие в беклоге ошибки с заголовком, начинающимся с "иногда...". При чём хорошо, если это будет "иногда...". Это может быть описано так, будто происходит всегда и при любых условиях. В реальности у разработчика проблема не повторяется, и бага закрывается.
Так что соглашусь с автором: хотите приносить пользу и чего-то достичь в профессии, придётся что-то уметь.
Потому что разрабатывать ПО и быть бизнесменом - это две разные вещи. </thread>
Мне бы хотелось, чтобы из введения в статью было понятно, о чём она.
Directed by Robert B. Weide
Книги, может, и хорошие. Но почему этот пост находится в разделе "разработка"?
Может я плохо читал, но не увидел, чтобы автор об этом говорил в посте. И вообще всё заканчивается советом:
Вы как будто бы упустили тот момент, когда учёные развенчали идею о том, что человек представляет из себя рационального агента, действующего из сугубо рациональных интересов. Мало кто готов заниматься чем-то исключительно ради денег, во всяком случае продолжительное время.
Тем более это актуально, когда мы говорим о разработчиках. Эта категория людей получает достаточно высокий доход, где каждая лишняя копейка сверху психологически играет всё менее важную роль. Грубо говоря, заработать лишние $500 при доходе в $1000 и в $4000 это не одно и то же.
На первый план выходит удовольствие от жизни, где классный пет-проект может приносить в разы больше удовольствия, чем овертаймы на работе.
Более того, это вообще довольно редкий вид хобби, который помогает развивать важные для работы навыки. Если вы играете на гитаре или ходите в лес с палаткой в свободное время, никто вам не говорит, что вы могли бы вместо этого овертаймить на работе, не так ли?
У него нет мнения. Он просто генерирует текст, пытаясь угадать следующее слово.
Да, тоже бросилось в глаза, что автор как будто бы в розовых очках на всё смотрит, а бизнес-модель гугла как будто бы случайно появилась. Ещё могу поверить, что изначально поиск не собирались монетизировать (или не знали как), но дальнейшее направление движения в виде открытия и закрытия проектов вполне проглядывается. Даже если рядовые инженеры, вроде автора, свято верили в иную миссию.
Я рад за них. Осталось понять, зачем это аудитории хабра. Рискну предположить, что львиная доля людей здесь в указанных компаниях не работает и не собирается. Информация для нас либо иррелевантна, либо этот тезис тут просто лишний, если полезность выходит за рамки очерченного круга.
Что качественная автоматизация, что качественный анализ и ручное тестирование требуют глубокого понимания конкретных областей, при чём в каждой из них требуется очень разный набор знаний. Невозможно написать и развивать хороший автомейшн фреймворк без достаточно глубоких знаний архитектуры проектов, дизайн паттернов и итеративного улучшения. Невозможно анализировать и планиравать тестирование без достаточно глубоких теоретических знаний о разных методологиях, техник тестирования, их плюсов и минусов, менеджерских навыков. Сейчас компании хотят из одного сотрудника получить швейцарский нож, чтобы одной зарплатой убить двух зайцев. В итоге ни автоматическое, ни мануальное тестирование у них нормально не работают.
Да и мало кому одинаково интересны обе этих области, чтобы вкладывать существенные ресурсы для них изучения. Может топовые компании и способны привлекать эту небольшую долю кадров, но их на всех не хватит.
Сорри, если что-то не так понял. Просто задачи довольно смутно сформулированы. За "обеспечение качества" может скрываться какой угодно набор реальных активностей, так что исхожу из стандартного: 50 на 50 между автоматизацией и мануальным тестированием.
Проблема, на мой взгляд, не до конца описана. Зачем, собственно, решать капчу в автотесте? Бывает надо проверить реальную интеграцию, но как будто бы не очень часто это происходит и не много усилий требует. В остальных тестах DUT конфигурируется так, чтобы она не мешала.
Что касается решения, то судя по коду, капчу решает сторонний сервис. Это рабочее решение, но не шибко интересное.
Мне ChatGPT помогал быстро накидать типовые тест-кейсы по самым распространённым техникам тестирования. Это удобно. Но дальше демо дело не зашло, ибо сливать туда закрытые коммерческие данные было бы глупо.
Зачем его использовать для баг репортов я не очень понимаю. Написать репорт - это простейшая часть работы. Сложная часть предшествует ей, поскольку такие тривиальные баги, как в вашем примере, крайне редки.
Реальные проблемы часто возникают на стыке бекенда и фронтенда, или при определённом стейте одного из компонентов, который вовсе не очевиден без детального анализа этих компонентов, да ещё и скрыт за впнами. И вот сборка этого паззла чат-ботам неподвластна, во всяком случае пока.
Да в общем-то надо ли оно? День, когда чатжпт научится эффективно решать все эти проблемы будет днём, когда вы перестанете быть нужны. Во всяком случае я не вижу, где здесь могут появиться новые таски, которые мог бы выполнять человек. Много людей для составления промтов не нужно, что ударит не только по количеству рабочих мест, но и по зарплатам.
Материал интересный, спасибо. Было бы хорошо указать оригинальные названия когнитивных искажений - на английском. Они всё-равно все из англоговорящей среды идут, и в русском языке их все переводят немного по-разному, что усложняет дальнейший поиск информации.
Что здесь не так? Читать, пока моешь посуду или гуляешь - крайне затруднительно. А вот слушать можно без проблем.
Рекламы в скаченных файлах нет.
А обязательно ли для этого использовать Cucumber? Как мне представляется, его главная фича - это создание связи между текстом, написанном на Gherkin, и кодом. Что требует дополнительного эффорта.
Если нужно просто динамически подгружать разные наборы тестовых данных, для этого наверное можно найти более точечные инструменты. Или не так?
Интересно, за промты к артам и спрайтам тоже спасибо. Я так понимаю Midjourney может генерировать только статичные картинки, но не разбитую по кадрам полноценная генерация спрайтов с анимациямианимацию? Не уверен, как это правильно называется.
Они могут служить одной цели.
Из статьи складывается впечатление, что вас больше мотивируют деньги, чем процесс разработки. При чём стремление к деньгам возникло ввиду потребности повысить уровень жизни, так что с его ростом пропадёт и эта мотивация. Когда это случится, программирование рискует стать ещё одной не интересной работой, от которой будет тошнить.
На мой взгляд, с такими вводными сложно достичь чего-то в любой профессии, где требуется высокая квалификация и её регулярное повышение теми или иными средствами.
Найти привлекательный пет-проект может быть сложно. Но именно в них можно попробовать что-то новое и необычное, для чего не всегда есть возможность на регулярном месте работы.