действительно отличное сообщение

Camille hi how are you ? Оливье, водка, матрёшки ?

https://www.youtube.com/watch?v=7JldQl0qLZA&feature=youtu.be&t=594 -  немного про практику применения Атлассиановской версии Quality Assistance ( https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance )

Анонс к видео провокационный какой-то: "На сегодняшний день качество выпускаемого на рынок ПО существенно снизилось. Любой внимательный пользователь может найти достаточно много ошибок, как серьёных так и не очень, в работе программ, выполняющих самые разные функции. Целью доклада не является установка или представление аудитории причин, влияющих на это, а предлагает ознакомиться с относительно новой методологией на рынке — Quality Assistance."

К чему было упоминание про снижение качества, если доклад про QAssistance?

@atarankoff Э, Саша, я не уверен что автор анонса есть в этом чате 😊

Да я просто в воздух вопрос задал :) Недоумеваю вслух

Чтобы заинтересовать потенциального зрителя же! Вопросы вот появляются, желание поспорить :)

Очень хороший вброс.

Анонс настолько канцелярский, что аж блевать хочется.

Что значит «канцелярский» ?

Написан языком, которым пишут свои бумажки разные бюрократические работники. Очень неконкретным и перегруженным пустыми словами. Так пишут, когда не шарят в теме или когда не хотят брать ответственность.

Ну вот «На сегодняшний день качество выпускаемого на рынок ПО существенно снизилось».

Снизилось по сравнению с каким периодом? Как и что измеряли? Где пруфы, где статистика?

... Или когда не знают что конкретно хотели сказать

Ну да, анонс никуда не годится. Придётся доклад смотреть-таки, потому что вторая часть анонса обещает что-то интересное

Интересно как разработчики с этим согласились. То ли руководство сумело так выстроить процесс и отношение к нему, что все приняли нормально, то ли очень прокачанные софт скиллы у QA, что смогли донести это все "снизу"

Разработчики согласились, потому что им это выгодно. Они так-то тоже не в восторге от того, что приходится возвращаться к уже казалось бы сделанной задаче и фиксить в ней баги, а потом надеяться и ждать, что тестировщики не найдут ничего нового.

С QAssistance у разработчика появляется помощник, который подскажет где ещё что не забыть сделать сразу, чтобы потом не переделывать.

А если ещё при этом разработчик эти проверки и автоматизирует, то ему даже не придётся ждать пока за ним проверит тестировщик - у него всегда тесты под рукой

Так донести снизу легко.. Тестировщик всегда узкое звено.. Не хотите ждать, тогда надо менять процесс и подход... Лучше сделать и закрыть... Чем сделать и ждать..

Не хотите так, предложите иначе...

Как-то мы тут встречались с целью обсудить тестирование производительности, где мы затронули типичные классы проблем производительности.
Так как мы у себя в плеске коллекционируем классы проблем, то я решил их задокументировать:

PERF_LEAK_MEM - классическая утечка памяти, самый простой способ её сделать это использовать C/C++, но если вы профессиональный C/C++ разработчик, то можете развлечь себя написанием собственного аллокатора памяти и сделать утечку уже как профи.
В языках с автоматическим управлением памятью этой утечки можно добиться созданием глобальных объектов без их удаления или удаления ссылок на них.

PERF_LEAK_CPU - выглядит как высокий CPU usage, достигается созданием потоков или таймеров без их удаления, возможно есть способ добиться похожего эффекта в языках с автоматическим управлением памятью через создание большого количества мелких объектов, которые приедается обрабатывать Garbage Collector'у

PERF_LEAK_DISK - создаём какие-то данные на диске и не удаляем за собой, через какое-то время свободное место на диске кончается, очень легко достигается с помощью лог-файлов или бекапов чего-либо, постоянно пишем много логов, создаем бекапы и не ротируем их.

PERF_LEAK_INODES - inode в *nix-like операционных системах это описание файла, которое хранится в структуре фиксированного размера, если создавать десятки миллионов пустых файлов или директорий, то после достижения этого фиксированного размера мы не сможем больше создавать новые файлы

PERF_LEAK_OPEN_FILES - в *nix-like операционных системах, каждый процесс имеет лимит на количество одновременно открытых файлов, обычно 1024, если открывать и не закрывать файлы, то при достижении этого лимита получим ошибку too many open files

PERF_USELESS_WORK - выполняем какую-то работу, которая создаёт нагрузку, но результаты этой работы не нужны все, сейчас или в этом контексте или в таком объёме или с такой точностью(например в time series базе данных задать слишком большую точность, или слишком много данных запросить в SQL запросе)

PERF_CRON_HOUR_X - устанавливаем в датацентре тысячи инстансов продукта у которого у настройках стоит выполнить какую-то работу в час X, например это может быть подсчет статистики или установка обновлений. В час X все тысячи инстансов начинают работу одновременно, что приводит к невероятной нагрузке на сеть, CPU, диски, память.

RACE_CONDITION - классический race condition, не является проблемой производительности, но может быть выявлена при тестировании производительности

Ещё про классы проблем, кажется это довольно полезная практика думать про баги, которые мы находим, к каким классам они относятся, с целью их быстрого поиска или даже недопущения.

Угу, недавно улучшали PERF_USELESS_WORK
Делались долгие запросы, результаты которых в коде потом не использовались вообще)