Добрый день goodfree! Не соглашусь с вами 🙂Я лид QA на одном из крупных проектов Сбертеха, у моих QA работы всегда много. Но ее не больше, чем заявленных мною ресурсов на проекте, а ресурсы заявлены с учетом автоматизации.
И речь не о том, что мы молодцы - это вопрос качества продукта в среднесрочной-долгосрочной перспективе. У нас тысячи тестов, их количество растёт. Без автоматизации мы будем постоянно отсекать и отсекать менее приоритетные кейсы, чтобы уложиться по времени, пока в какой то момент не останутся лишь самые критичные.
К какому качеству продукта это приведёт, даже представить страшно.
Кстати, на текущем проекте примерно 15% от общего числа тестов у нас нельзя автоматизировать, в среднем у меня так выходит на каждом проекте.
Как вы считаете, в чем преимущество SQL-of-thought над ручным написанием SQL запросов?
100% точности здесь, кажется, добиться крайне трудно. Таким образом любой сгенерированный SQL запрос в любом случае необходимо проверять вручную, а значит - обладать значительными знаниями SQL.
Таким образом, я не вижу экономии времени (нужно перепроверять сложные запросы а простые быстрее написать на sql чем оформлять промпт) и не вижу возможности людям без знаний SQL пользоваться Text-to-SQL поскольку это банально опасно для бизнеса.
Просто многие все хотят ворваться в IT через QA, хотя есть множество других вариантов. Наша команда бы с радостью взяла к себе даже Junior DevOps - только их очень мало
Добрый день! Спасибо за интересную статью. Я QA и мне по должности частенько приходится писать тесты. Но я не очень понимаю, как мне применить данную информацию.. Верно понимаю, что статья ориентирована на разработчиков и unit-тесты?
Добрый день! Спасибо за интересную статью. Что вы думаете насчет карьерных перспектив технического эксперта и тест менеджера? Или по вашему, это уже тупик развития QA?
Добрый день! Спасибо за интересную статью. Отчего для python выбран такой древний инструмент (поддержка кончилась лет 8 назад) pyresttest а не расширяемый плагинами молодежный pytest?
Возможность прикольная, но часто сырой playwright код нужно причесывать.. Хотя бы приводить к page object, base element паттернам. Не уверен, что данный подход сэкономит время, если уже написан некоторый фреймворк
Немного работал с Fiddler, но я как-то больше по Charles Proxy - чисто субъективно приятнее интерфейс. Не так давно познал Wireshark - там вообще монстр по возможностям, однако порог вхождения в него повыше, конечно..
Расширения на то и расширения, что расширяют базовые возможности браузера :) В данной статье как раз представлены базовые возможности. Кстати говоря - на основе Chromium различные компании могут делать свои собственные браузеры, в которых по причинам безопасности убирают возможность установки расширений.
Добрый день goodfree! Не соглашусь с вами 🙂Я лид QA на одном из крупных проектов Сбертеха, у моих QA работы всегда много. Но ее не больше, чем заявленных мною ресурсов на проекте, а ресурсы заявлены с учетом автоматизации.
И речь не о том, что мы молодцы - это вопрос качества продукта в среднесрочной-долгосрочной перспективе. У нас тысячи тестов, их количество растёт. Без автоматизации мы будем постоянно отсекать и отсекать менее приоритетные кейсы, чтобы уложиться по времени, пока в какой то момент не останутся лишь самые критичные.
К какому качеству продукта это приведёт, даже представить страшно.
Кстати, на текущем проекте примерно 15% от общего числа тестов у нас нельзя автоматизировать, в среднем у меня так выходит на каждом проекте.
Пожалуйста! )
Добрый день! Видел эту тему на докладах Heisenbug. Отличное выступление и статья!
Алексей, мне кажется, я даже был на этом вашем докладе на гейзенбаге - надо будет пересмотреть!
Добрый день! Спасибо за интересную статью.
Как вы считаете, в чем преимущество SQL-of-thought над ручным написанием SQL запросов?
100% точности здесь, кажется, добиться крайне трудно. Таким образом любой сгенерированный SQL запрос в любом случае необходимо проверять вручную, а значит - обладать значительными знаниями SQL.
Таким образом, я не вижу экономии времени (нужно перепроверять сложные запросы а простые быстрее написать на sql чем оформлять промпт) и не вижу возможности людям без знаний SQL пользоваться Text-to-SQL поскольку это банально опасно для бизнеса.
Просто многие все хотят ворваться в IT через QA, хотя есть множество других вариантов. Наша команда бы с радостью взяла к себе даже Junior DevOps - только их очень мало
Благодарю за ответ!
Добрый день! Спасибо за интересную статью. Я QA и мне по должности частенько приходится писать тесты. Но я не очень понимаю, как мне применить данную информацию.. Верно понимаю, что статья ориентирована на разработчиков и unit-тесты?
Добрый день! Спасибо за интересную статью. Что вы думаете насчет карьерных перспектив технического эксперта и тест менеджера? Или по вашему, это уже тупик развития QA?
Любопытно, надо будет ознакомиться )
Большое спасибо! Добавил в закладки
Добрый день! Спасибо за интересную статью. Отчего для python выбран такой древний инструмент (поддержка кончилась лет 8 назад) pyresttest а не расширяемый плагинами молодежный pytest?
Тогда огонь )
Возможность прикольная, но часто сырой playwright код нужно причесывать.. Хотя бы приводить к page object, base element паттернам. Не уверен, что данный подход сэкономит время, если уже написан некоторый фреймворк
К сожалению, статус код подменить нельзя - я упомянул об этом в заключении в разделе недостатки.
Согласен, с кешем есть такой момент.
Немного работал с Fiddler, но я как-то больше по Charles Proxy - чисто субъективно приятнее интерфейс. Не так давно познал Wireshark - там вообще монстр по возможностям, однако порог вхождения в него повыше, конечно..
Вот с такой точки зрения не рассматривал ))
Расширения на то и расширения, что расширяют базовые возможности браузера :) В данной статье как раз представлены базовые возможности. Кстати говоря - на основе Chromium различные компании могут делать свои собственные браузеры, в которых по причинам безопасности убирают возможность установки расширений.
You are welcome!
Точно! Очень удобно, что все под рукой )