#качество_по — Public Fediverse posts

Мы пытались заменить QA нейросетью. Не получилось

Мы попытались построить MCP-сервер, который сам читает спеки, пишет автотесты и коммитит код. На практике выяснилось, что токены — не главная проблема, а QA — это не «делатели тестов», а носители контекста и ответственности.

https://habr.com/ru/articles/995020/

#тестирование #qa #qa_automation #qa_engineer #автоматизация_тестирования #искусственный_интеллект #автотесты #качество_по #mcp #llm

Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)

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

https://habr.com/ru/companies/otus/articles/1026818/

#тестирование #qa #качество_по #искусственный_интеллект #наблюдаемость

Мифы о тестировании, в которые я верила в начале карьеры

Меня зовут Диана, я работаю тестировщиком больше полутора лет. Когда я только приходила в профессию, мои представления складывались из статей, курсов и разговоров с друзьями из ИТ. Казалось, что работа у тестировщика довольно простая: технических знаний нужно немного, а зона ответственности ограничена. Практика быстро показала, что это не так. В статье я собрала мифы о тестировании, в которые я сама верила, и то, как все оказалось на самом деле.

https://habr.com/ru/companies/naumen/articles/1016700/

#тестирование #QA #ручное_тестирование #автотесты #баги #требования #начинающий_тестировщик #качество_по

Мифы о тестировании, в которые я верила в начале карьеры

Меня зовут Диана, я работаю тестировщиком больше полутора лет. Когда я только приходила в профессию, мои представления складывались из статей, курсов и разговоров с друзьями из ИТ. Казалось, что работа у тестировщика довольно простая: технических знаний нужно немного, а зона ответственности ограничена. Практика быстро показала, что это не так. В статье я собрала мифы о тестировании, в которые я сама верила, и то, как все оказалось на самом деле.

https://habr.com/ru/companies/naumen/articles/1016700/

#тестирование #QA #ручное_тестирование #автотесты #баги #требования #начинающий_тестировщик #качество_по

Мифы о тестировании, в которые я верила в начале карьеры

Меня зовут Диана, я работаю тестировщиком больше полутора лет. Когда я только приходила в профессию, мои представления складывались из статей, курсов и разговоров с друзьями из ИТ. Казалось, что работа у тестировщика довольно простая: технических знаний нужно немного, а зона ответственности ограничена. Практика быстро показала, что это не так. В статье я собрала мифы о тестировании, в которые я сама верила, и то, как все оказалось на самом деле.

https://habr.com/ru/companies/naumen/articles/1016700/

#тестирование #QA #ручное_тестирование #автотесты #баги #требования #начинающий_тестировщик #качество_по

Мифы о тестировании, в которые я верила в начале карьеры

Меня зовут Диана, я работаю тестировщиком больше полутора лет. Когда я только приходила в профессию, мои представления складывались из статей, курсов и разговоров с друзьями из ИТ. Казалось, что работа у тестировщика довольно простая: технических знаний нужно немного, а зона ответственности ограничена. Практика быстро показала, что это не так. В статье я собрала мифы о тестировании, в которые я сама верила, и то, как все оказалось на самом деле.

https://habr.com/ru/companies/naumen/articles/1016700/

#тестирование #QA #ручное_тестирование #автотесты #баги #требования #начинающий_тестировщик #качество_по

Идеальный Open Source проект, что ты такое?

В данной статье вы познакомитесь с типичными ошибками и привлекающими внимание подходами, которые можно встретить в разных Open Source проектах. Без воды, только конкретные комментарии. Будет полезно и для своих проектов.

https://habr.com/ru/articles/1010580/

#opensource #github #cicd #readmemd #разработка #рефакторинг #качество_по #тестирование_по #открытый_код #contributing

Идеальный Open Source проект, что ты такое?

В данной статье вы познакомитесь с типичными ошибками и привлекающими внимание подходами, которые можно встретить в разных Open Source проектах. Без воды, только конкретные комментарии. Будет полезно и для своих проектов.

https://habr.com/ru/articles/1010580/

#opensource #github #cicd #readmemd #разработка #рефакторинг #качество_по #тестирование_по #открытый_код #contributing

Идеальный Open Source проект, что ты такое?

В данной статье вы познакомитесь с типичными ошибками и привлекающими внимание подходами, которые можно встретить в разных Open Source проектах. Без воды, только конкретные комментарии. Будет полезно и для своих проектов.

https://habr.com/ru/articles/1010580/

#opensource #github #cicd #readmemd #разработка #рефакторинг #качество_по #тестирование_по #открытый_код #contributing

Идеальный Open Source проект, что ты такое?

В данной статье вы познакомитесь с типичными ошибками и привлекающими внимание подходами, которые можно встретить в разных Open Source проектах. Без воды, только конкретные комментарии. Будет полезно и для своих проектов.

https://habr.com/ru/articles/1010580/

#opensource #github #cicd #readmemd #разработка #рефакторинг #качество_по #тестирование_по #открытый_код #contributing

[Перевод] Глобальный упадок качества ПО: как мы справляемся с катастрофой

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ. Эта память не используется, не выделяется, она просто утекает. Простецкое приложение калькулятора страдает большей утечкой памяти, чем компьютеры десятилетие назад. Случись такое в 2000-х, это бы привело к внесению срочных патчей и служебной проверке. Сегодня же это лишь очередной баг-репорт в очереди. Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

https://habr.com/ru/companies/ruvds/articles/959262/

#ruvds_перевод #программирование #управление_разработкой #кризис_по #качество_по

Качество внедрения ERP-систем

Число проектов внедрения и непрерывного развития корпоративных информационных систем достаточно велико, и текущая геополитическая обстановка не является помехой. Наоборот, специальная операция в братской Украине требует более пристального и досконального прорабатывания вопроса импортозамещения программного обеспечения, в особенности классов ERP1-3. В этом нет ничего удивительного, ведь применение автоматизированных программных продуктов позволяет предприятиям обрабатывать большие массивы данных, формировать необходимую для принятия управленческих решений аналитику, а также заменять ручной труд над рутинными операциями на автоматизированную обработку. Внедрения ERP-систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко-дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP-систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4]. Любопытна одна из указанных причин провала внедрения: отсутствие должной поддержки проекта со стороны руководства заказчика. Несмотря на кажущуюся противоречивость и банальность, это действительно так. Лишь мизерный процент ERP-проектов не запускается по прочим причинам, ведь когда руководство заинтересовано в результатах, любые сложности будут решены и для них будет найден обходной путь решения. В рамках данной статьи мы проведем оценку качества как самого процесса внедрения, так и уже внедренной ERP-системы, что поможет выявить наиболее важные моменты реализации проекта.

https://habr.com/ru/articles/929388/

#качество #контроль_качества #качество_по #качество_erp #контроль_качества_по

Качество внедрения ERP-систем

Число проектов внедрения и непрерывного развития корпоративных информационных систем достаточно велико, и текущая геополитическая обстановка не является помехой. Наоборот, специальная операция в братской Украине требует более пристального и досконального прорабатывания вопроса импортозамещения программного обеспечения, в особенности классов ERP1-3. В этом нет ничего удивительного, ведь применение автоматизированных программных продуктов позволяет предприятиям обрабатывать большие массивы данных, формировать необходимую для принятия управленческих решений аналитику, а также заменять ручной труд над рутинными операциями на автоматизированную обработку. Внедрения ERP-систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко-дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP-систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4]. Любопытна одна из указанных причин провала внедрения: отсутствие должной поддержки проекта со стороны руководства заказчика. Несмотря на кажущуюся противоречивость и банальность, это действительно так. Лишь мизерный процент ERP-проектов не запускается по прочим причинам, ведь когда руководство заинтересовано в результатах, любые сложности будут решены и для них будет найден обходной путь решения. В рамках данной статьи мы проведем оценку качества как самого процесса внедрения, так и уже внедренной ERP-системы, что поможет выявить наиболее важные моменты реализации проекта.

https://habr.com/ru/articles/929388/

#качество #контроль_качества #качество_по #качество_erp #контроль_качества_по

Качество внедрения ERP-систем

Число проектов внедрения и непрерывного развития корпоративных информационных систем достаточно велико, и текущая геополитическая обстановка не является помехой. Наоборот, специальная операция в братской Украине требует более пристального и досконального прорабатывания вопроса импортозамещения программного обеспечения, в особенности классов ERP1-3. В этом нет ничего удивительного, ведь применение автоматизированных программных продуктов позволяет предприятиям обрабатывать большие массивы данных, формировать необходимую для принятия управленческих решений аналитику, а также заменять ручной труд над рутинными операциями на автоматизированную обработку. Внедрения ERP-систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко-дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP-систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4]. Любопытна одна из указанных причин провала внедрения: отсутствие должной поддержки проекта со стороны руководства заказчика. Несмотря на кажущуюся противоречивость и банальность, это действительно так. Лишь мизерный процент ERP-проектов не запускается по прочим причинам, ведь когда руководство заинтересовано в результатах, любые сложности будут решены и для них будет найден обходной путь решения. В рамках данной статьи мы проведем оценку качества как самого процесса внедрения, так и уже внедренной ERP-системы, что поможет выявить наиболее важные моменты реализации проекта.

https://habr.com/ru/articles/929388/

#качество #контроль_качества #качество_по #качество_erp #контроль_качества_по

Качество внедрения ERP-систем

Число проектов внедрения и непрерывного развития корпоративных информационных систем достаточно велико, и текущая геополитическая обстановка не является помехой. Наоборот, специальная операция в братской Украине требует более пристального и досконального прорабатывания вопроса импортозамещения программного обеспечения, в особенности классов ERP1-3. В этом нет ничего удивительного, ведь применение автоматизированных программных продуктов позволяет предприятиям обрабатывать большие массивы данных, формировать необходимую для принятия управленческих решений аналитику, а также заменять ручной труд над рутинными операциями на автоматизированную обработку. Внедрения ERP-систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко-дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP-систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4]. Любопытна одна из указанных причин провала внедрения: отсутствие должной поддержки проекта со стороны руководства заказчика. Несмотря на кажущуюся противоречивость и банальность, это действительно так. Лишь мизерный процент ERP-проектов не запускается по прочим причинам, ведь когда руководство заинтересовано в результатах, любые сложности будут решены и для них будет найден обходной путь решения. В рамках данной статьи мы проведем оценку качества как самого процесса внедрения, так и уже внедренной ERP-системы, что поможет выявить наиболее важные моменты реализации проекта.

https://habr.com/ru/articles/929388/

#качество #контроль_качества #качество_по #качество_erp #контроль_качества_по

[Перевод] Почему меня всегда будет злить разработка ПО

Я начал вести свой блог из-за скуки, абсолютного отчаяния от пустой траты ресурсов в технологическом секторе, которую я наблюдаю после того, как окончил университет. Мне сказочно платили, но ничего из создаваемого мной не имело никакой ценности. Никто из моих знакомых в корпоративном мире не считал, что приносит какую-то ценность, кроме совсем уж впавших в иллюзии. Даже самые талантливые тратили всё своё время на то, чтобы безуспешно пытаться помешать равнодушным любителям и обладателям дутых должностей сливать миллионы на ерунду. Два года спустя, после долгих мук и множества постов, я уволился [ перевод на Хабре] , чтобы создать собственную консалтинговую фирму. Неудивительно, что меня совершенно не волновало, получится ли у меня — я осознавал риски, на которые иду. Деньги приходят и уходят, ничего особо страшного со мной произойти не может. Нет, на самом деле, мне не давал покоя такой вопрос: Вспомню ли я два прошлых года написания постов и задумаюсь ли: «Разработка ПО не особо важна почти ни в каком контексте. Мы не запускали людей в космос: возможно, стоило просто брать лёгкие деньги и заткнуться?» Возможно, через полгода я буду жалеть о том, что не выбрал лёгкий путь, и мечтать, чтобы мне снова платили шестизначные суммы лишь за то, что я тихонько сижу каждое утро на совещаниях, пока меня не уволят при следующей реструктуризации пятью годами позже, после чего снова буду повторять тот же надоевший трюк до пенсии.

https://habr.com/ru/companies/ruvds/articles/901356/

#разработка_по #качество_по #качество_кода #общество #консалтинг #ruvds_перевод

Критерии качества требований с примерами (Часть 2)

Продолжение первой части статьи ( ссылка ) про критерии качества требований. Будут разобраны: - Атомарность - Необходимость - Прослеживаемость (трассируемость) - Модифицируемость - Понятность

https://habr.com/ru/articles/843220/

#требования_к_по #критерии_качества #требования_к_системе #требования_к_разработке #качество_по #требования

Критерии качества требований с примерами (Часть 1.)

Требования проверяются на соответствие критериям качества . Часто этот процесс описывают как отдельный вид тестирования — тестирование требований. Понятие критериев качества требований скорее относится к бизнес-анализу, чем к QA. В разных источниках можно встретить разные наборы критериев. При написании этой статьи я руководствовалась своим опытом и тремя хорошими книгами. В этой статье рассказывается про 7 самых часто встречающихся критериев качества c с примерами.

https://habr.com/ru/articles/842296/

#требования_к_по #критерии_качества #требования_к_системе #требования_к_разработке #качество_по

[Перевод] Как Google изменил свой поиск к худшему

Все цифровые предприятия обладают техническими возможностями для дерьмофикации [enthittification]: способностью менять базовые функции бизнеса от момента к моменту и от пользователя к пользователю, что позволяет быстро передавать стоимость между клиентами, конечными пользователями и акционерами В связи с этим возникает важный вопрос: почему компании решаются на ухудшение условий именно в определённый момент, откладывая этот шаг на потом? Ведь, казалось бы, всегда можно извлечь выгоду, ухудшив отношение к клиентам и снизив качество обслуживания. Зарабатывая больше на продукте и уменьшая расходы на поставки, компании увеличивают прибыль для своих инвесторов . Компании могут долго не прибегать к ухудшению условий... до определённого момента. Согласно одной из теорий, о ни постоянно анализируют конкурентную среду, действия регуляторов и моральное состояние своих сотрудников . Когда анализ показывает, что условия благоприятствуют, руководители могут решиться на рискованный шаг...

https://habr.com/ru/articles/811339/

#google #качество_по #статистика #мнение #дерьмофикация

[Перевод] Софт становится хуже?

Технологии разработки развиваются, но качество приложений по-прежнему оставляет желать лучшего. Почему?

https://habr.com/ru/articles/787852/

#качество_по #тренды #рынок_it

Качество ПО: определение и постановка целей

Качество программного продукта — важный критерий. Однако не каждый способен его четко обозначить, а тем более объяснить, как его достичь. Как правило, у каждого члена команды свое представление о качестве. Это связано с тем, что в оценке в большей степени учитываются субъективные мнения. Правильнее сказать, что качество представляет собой набор критериев или параметров. И этот набор может отличаться в зависимости от личного опыта или профессиональной деятельности участника команды: пользователя, разработчика, тестировщика, аналитика, заказчика или др.

https://habr.com/ru/articles/780140/

#качество_по #разработка_приложений #разработка #цели #целеполагание #цели_и_задачи #планирование #управление_качеством #управление #обеспечение_качества

История времен колониального рабства в IT

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

https://habr.com/ru/articles/804103/

#рабство #карьера #карьера_в_itиндустрии #качество_кода #качество_по #плохой_код

[Перевод] Призыв писать компактное ПО, версия 2024 года (с примером кода)

Этот пост посвящён памяти Никлауса Вирта , первопроходца в сфере вычислительных наук, ушедшего от нас 1 января этого года. В 1995 году он написал важную статью A Plea for Lean Software , и в своём посте я постараюсь воспроизвести её почти тридцать лет спустя, с учётом современных кошмаров разработки ПО. Очень короткая версия поста: современные способы разработки/сборки ПО смехотворны, они приводят к созданию пакетов на 350 МБ для рисования графиков , а простые продукты импортируют 1600 зависимостей неизвестного происхождения . Уровень безопасности ПО ужасен, ведь он зависит и от качества кода, и от его объёма. Многие из нас понимают, что ситуация нерациональна. К сожалению, многие программисты (и их руководство) никогда не работали как-то иначе. А остальным редко выделяют время, чтобы выполнять работу качественно. В этом посте я сделаю краткий обзор ужасного уровня безопасности современного ПО, а затем порассуждаю о том, почему он настолько плох. Также я упомяну нормативные/юридические аспекты, которые могли бы снова сделать качество ПО приоритетным. Наконец, я расскажу о написанном мной полезном ПО , позволяющем доказать, что сегодня по-прежнему можно разрабатывать минималистичное и простое ПО, остающееся современным . Надеюсь, этот пост станет моральной поддержкой для страдающих программистов и технологов, стремящихся улучшить ситуацию. Дело не только в вас, и мы не просто страдаем от ностальгии: ПО сегодня действительно очень странное .

https://habr.com/ru/articles/789550/

#хаки #качество_кода #качество_по #зависимости #electron #node #автономная_система