Комментарии 11
душнилой
Если позволите, я бы предложил другой термин, гораздо более уместный в контексте материала - дотошный.
Мне кажется имелось ввиду именно это качество.
душнилой
<режим БОЛЬ вкл.>
Когда квалифицированные сотрудники разных базовых специализаций (проектирование и разработка; тестирование; эксплуатация; информационная безопасность) применяют в адрес друг друга подобные слова, руководитель, которому подчиняются эти сотрудники некомпетентен именно как руководитель. Он не умеет организовать производственный процесс так, чтобы у этих товарищей была чётко определена зона ответственности, и понимание, кто, что и почему делает.
<режим БОЛЬ выкл. Но это не точно!>
Говорю это, как человек, которому посчастливилось трудиться в компаниях, где мы в адрес друг друга подобными гадостям не бросались. А вовсе даже и наоборот, нередко неформально заканчивали рабочие недели вместе, потягивая напитки, например, разные.
Хороший QA
У хорошего тестировщика свежий продукт безо всяких исследований ломается. Просто потому что в нём гарантировано есть ошибки. А ещё инженер-тестировщик, выслушав восторги разработчика по его (разработчика) новым гениальным идеям, объясняет, как и что в коде по этим идеям будет сломано. Флегматично, так, с ленцой, потягивая, например, чай. И получив код на тестирование, показывает свою правоту, ломая так, как и рассказывал.
грани (и новые способы его уронить), о которых никто не подумал при планировании.
Именно поэтому, тестировщики должны подключаться на этапе тех.задания.
Сегодняшний стандарт для серьёзного QA — это уверенное владение Python как самым гибким инструментом автоматизации и глубокое понимание Linux.
Уже давно убедился в одном: чтобы заниматься каким-либо делом, надо, в первую очередь, иметь соответствующие способности. Всё остальное - мелочи. И собственно для тестировщика.
Вы становитесь экспертом, который может построить инфраструктуру качества с нуля.
Тестировщик, как и разработчик, не смогут построить инфраструктуру, просто потому, что построение инфраструктуры - это задача эксплуатации. Как эксплуататор не сможет создать и полноценно протестировать более-менее сложный программный продукт. Увы и ах.
Подводя итог:
После школы я хотела быть учителем и поступила в педагогический вуз, на специальность «Информатика и английский язык».
Отсутствие инженерного образования и системного подхода статья демонстрирует наглядно: собственно, сумбурный текст с какой-то структурой, но с полным отсутствием системы, как таковой.
И да. Искусственного интеллекта не существует в принципе. Потому что ИИ - это не более чем программные комплексы. А программные комплексы, в силу понятия алгоритма (а программы пишутся по алгоритму!) интеллектом быть не могут.
Душнила
Вы предвзято проводите дискриминацию по признаку профобразования. Причем голословно, да и просто ошибочно. В тексте есть структура и вы это признали. Но нет якобы системы. Это ложное утверждение, так как структурироаанный текст автоматически становится системой, как только он становится средством коммуникации или обучения. В данном случае оба условия выполнены. Мы же обсуждаем его и оставляем комментарии - коммуницируем. Также текст содержит обучающие признаки - я кое-что почерпнул. Система-с. А вот если бы был написан и никогда не опубликован, то тогда бы и не было системы. Это все по определению понятий. Или вы какое-то альтернативное определение системы имели в виду?
Откройте форточку кто-нибудь :)
Вы предвзято проводите дискриминацию по признаку профобразования. Причем голословно, да и просто ошибочно.
Высшее профобразование помимо фундаментальных знаний, даёт и терминологию. Не зная которой, новички придумывают свои термины, либо, что ещё хуже для языка общения, волокут иностранное, хотя в родном есть вполне себе устоявшиеся термины.
Я вот не знаю, что такое оркестрация. И как человека, как имеющего профильное высшее образование и учившегося в музыкальной школе, т.е. не в принципе, а реально знающего, что такое оркестр, и как он внутри устроен, меня этот термин (судя по тому, в каком контексте термин "оркестрация" применяется) весьма сильно напрягает. Потому что есть вполне себе грамотное и понятное русское слово - управление, которое уместно, как со смысловой, так и с технической точки зрения.
Второй момент. Поисковые системы, а ныне, новомодные системы, претендующие на название искусственного интеллекта (а такого интеллекта не существует в принципе, как мной было доведено) - это коммерческие проекты, главной задачей которых является прибыль для своих владельцев, а не выдача достоверной информации по запросу, поэтому я уже очень давно посылаю в поиск только при соблюдении следующих условий:
посланный сумеет отфильтровать поисковую выдачу, т.е. обладает знаниями в той области, в которой его послали;
результаты поисков будут однозначны;
Так вот. Для фильтрации результатов поисковых запросов нужны знания, которые у новичков, не имеющих образования, отсутствуют по определению.
структурироаанный текст автоматически становится системой
Неверно. Система - это упорядоченное и взаимосвязанное множество, если грубо упрощено. Текст же представляет никак не упорядоченную мешанину мыслей. Описания того, кто есть тестировщик, и какие требования к нему предъявляются, разбросанные по всей статье, об этом говорят более, чем красноречиво. Причём при описании требований автор даже не пытается разделить навыки владения конкретными инструментами от более других, таких как искать и находить причины сбоев, например. Т.е. и требования навыков владения инструментами в материале есть, и требования уметь искать и находить причины сбоев вроде бы есть. Но вот эти описания - они даже не структурированы, не говоря уже о систематизации.
Устал писать предыдущий комментарий. Поэтому продолжу вопросом, ответ на который, будет очень интересен, в первую очередь, тестировщикам конечных программных продуктов и администраторам БД.
Предварительное замечание. У меня опыт администратора баз данных таков, что экземпляры постгреса меньше 1Тб - это небольшие экземпляры, которые не требуют серьёзного внимания. Но 1 Тб - это, на самом деле, серьёзный объём, в первую очередь, по цене. И руководители компаний очень часто не выделяют средства, или выделяют недостаточно на разворачивание среды для нагрузочного тестирования. Просто потому, что дорого.
Соответственно, вопрос:
как организовать среду нагрузочного тестирования, чтобы получать идентичные планы запросов в указанной тестовой среде и промышленной эксплуатации? Да и вообще, как организован процесс нагрузочного тестирования в ПгПро?
Любопытный вопрос, даже, и для неспециалиста, который только недавно установил PostgeSQL и попробовал прокрутить несколько запросов (включая и новые для меня оконные функции).
К сожалению, гарантировать идентичные планы можно только если приближать тестовый стенд к проду. Но если отходить от частных случаев того что лежит в базе на 1Тб, где, например, одна только табличка может быть полтерабайта, то в целом, алгоритм можно предложить следующий:
Сделать дамп схемы продакшена и снять статистику.
Собрать планы запросов, выделить 20% таблиц, которые дают 80% нагрузки и это перенести на тестовую базу.
При переносе важно учитывать индексы метаданные.
Перенести схемы больших таблиц и загрузить часть данных например каждую 100 запись, загрузить записи содержащие MIN и MAX значения для всех колонок больших таблиц
Перенести настройки postgresql с прода и привести к характеристикам тестовой среды (shared_buffers, work_mem, maintenance_work_mem, effective_cache_size и т.д.) Важно выделить то, что зачастую планы могут зависеть от окружения и подкладывать их нужно исходя из статистики. Проведение нагрузочного тестирования в большей степени относится к работе приложений, мы со своей стороны ведём внутри обширную работу по тестированию именно производительности БД.
Статья называется PostgreSql, а в итоге получаешь сборную солянку с маленьким кусочком про БД. В итоге 10% контента отражают название. Статья обо всем и ни о чем одновременно .
Существует стереотип, что тестирование — это «лёгкий вход в IT»
И
После выпуска у тебя ещё нет хард-скилов, и одна из самых простых точек входа в IT — QA-инжиниринг
Одно из доказательств того, что стереотипы не рождаются на пустом месте
Почему QA должен быть душнилой: тестируем PostgreSQL и не даём разработчикам расслабиться