Обзор чатов о тестировании ПО

Про рассылки для тестировщиков я уже писал. В какой-то момент мне стало интересно где в онлайне общаются профессиональные тестировщики и я прошёлся по самым массовым чатам:

softwaretesters.slack.com

Внутри несколько каналов: #rss, #flood, #automation, #general, #hunteam. В каждом 2-3 тысячи человек. Канал автоматизации тестирования полностью ангажирован тестировщиками веба.

ministryoftesting.slack.com

Внутри два канала: #general и #random. Поддерживаются небезызвестным Министерством тестирования. В основном ведут разговоры на свободные темы, но связанные с тестированием. Бывают интересные темы. В чате #general четыре тысячи человек и для такого количества там как-то подозрительно тихо. Если правильно понял, то testeersio, это другой адрес этого же чата.

mutation-testing.slack.com

Специализированный канал о мутационном тестировании. Один из немногих полезных каналов. Для приглашения нужно поделиться почтовым адресом.

slack-spb-qa.herokuapp.com

Сообщество питерских тестировщиков.

software-testers.herokuapp.com

Называют себя “Интернациональный чат русскоязычных тестировщиков”, но почему-то в интернациональном чате говорят по-русски.

qa_jobs

Чат, в который рекрутерам разрешают постить вакансии о тестировании ПО.

qa_ru

Русскоговорящее сообщество QA из полутора тысяч человек. “Общаемся на темы, посвященные всем видам тестирования, автоматизации и методологиям. Без мата, грубостей и провокаций. Только по делу.”

qa_flood

Чат для разговора на свободные темы для тестировщиков, так написано в описании. Не знаю чем он отличается от чата для разговора на свободные темы для НЕ тестировщиков.

qa_bad_company

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

QA Alliance

Чатик сообщества тестировщиков QA Club.

QAC: Automation in testing и QAC: Performance and load testing

Я скайпом не пользуюсь, поэтому в эти чаты не заходил. Если вам есть что рассказать он них парой предложений - напишите и я добавлю сюда описание для других читателей.

Formal-methods

Это единственный чат, который совсем не про тестирование ПО, а про верификацию ПО. Людей там немного, порядка сотни, и обсуждают они в основном верификацию ПО от компании Ethereum.

13.10.2017

О визуализации данных в тестировании ПО

Одной из фич PostgreSQL, которую мне довелось тестировать, было расширение для оптимизации запросов по стоимости выполнения. Расширение aqo при помощи методов машинного обучения улучшает оценку количества строк, что способствует выбору лучшего плана и ускорению запросов (но не всегда и не для всех).

Для тестирования модуля я сделал автотест, который запускал SQL запросы нужного нам типа сначала для обучения, а потом уже непосредственно для тестирования модуля. При каждом запуске тест сохранял параметры планировщика: время планирования и выполнения запроса, ошибку оценки количества строк и другие. После этого тест проверял, что параметры планировщика с машинным обучением как минимум не хуже стандартного планировщика. Сначала я попробовал для оценки успешности теста использовать статистические методы. Но чем больше я погружался в нюансы работы модуля, тем меньше я был уверен, что тест правильно оценивает собранные цифры. Поэтому для большей уверенности я начал строить графики для визуализации результатов теста. И как потом оказалось не зря - в ходе тестирования нашел запросы с которыми aqo некорректно рассчитывал время.

Вспомнил я эту историю с тестированием расширения для PostgreSQL когда узнал про квартет Энскомба. Энскомб смог продемонстрировать четыре набора данных, у которых были одинаковые статистические характеристики. У каждого из двумерных наборов данных по каждой переменной совпадают средние значения, оценки дисперсии, они имеют одинаковые коэффициенты корреляции между переменными, а также уравнения линейной регрессии, построенные с помощью метода наименьших квадратов. Но несмотря на такую «статистическую идентичность», мы видим, что это совсем разные наборы с точки зрения выбора модели, описывающей данные:

Поэтому будет не лишним сделать визуализацию данных, если нет уверенности в правильной оценке математическими методами.

Подробнее про модуль aqo можно почитать в статье Олега Иванова и документации.

10.10.2017

RSS подписки в Покете

После того, как Гугл похоронил Google Reader я перешел на rss2email. Я его запускаю на сервере каждые десять минут и у меня всегда свежие посты из подписок. Но в последнее время начал замечать странное: я не читаю письма от rss2email в самой почте. Каждый раз во время разбора почтовых входящих ссылки на новые посты из писем rss2email я добавляю в Pocket, а сами письма удаляю (Inbox Zero у меня). И так каждый день. Очевидно, что звено с почтой в этой цепочке лишнее.

У Pocket есть REST API и я был готов пропатчить rss2email, чтобы добавлять новые статьи сразу туда. Но я везде для установки приложений использую пакеты и мне не хотелось еще поддерживать и собирать отдельный пакет rss2email со своим патчем. Решение нашлось простое - Pocket может добавлять статьи по ссылкам, присланным по почте. Нужно только добавить адрес в список разрешенных и обновить адрес в rss2email: r2e email add@getpocket.com.

Fin

09.10.2017

Анализ данных с Jupyter Notebooks

Недавно открыл для себя такую штуку, как Jupyter Notebooks. Это такой инструмент для интерактивных вычислений.

Вот например я делал анализ статистики корректирующих патчей для OpenBSD. Собрал общедоступные данные о патчах в таблицу, построил графики и скриншоты этих графиков выложил на гитхаб. И хотя я опубликовал скрипт для сбора этой статистики, но вряд ли кто-то захочет проверить эти графики и даже мне нужно будет потратить некоторое время чтобы обновить их для новых выпусков OpenBSD. C Jupyter Notebook мы получаем воспроизводимость для анализа данных, все необходимые куски кода, данных и комментарии к ним находятся в одном месте - в ноутбуке.

То же самое с расчётами #RaceTheTube для Московского метро - всё источники данных, манипуляции над ними я опубликовал, но всё это разрозненно и нужно потратить время, чтобы повторить расчёты. С Jupyter Notebook у вас не будет этой проблемы.

Чтобы попробовать Jupyter Notebook в деле я сделал анализ результатов полумарафона “Лужники”, в котором сам участвовал в прошлом месяце. Комментарий к этому анализу я написал отдельным постом в ФБ.

Ещё начал делать анализ статистики о разработке в проектах CRIU и OpenBSD, но там я пока сделал не все, что хотел.

18.09.2017

Own repository with OpenBSD packages

Right now OpenBSD ports tree contains about 10042 ports according to ports.su. Resources of OpenBSD developers are limited and thus not all new ports are comitted to the official tree. It’s a reason why we have a big number of ports out of tree. See a list of some repositories with out-of-tree ports. Maintaining packages is not so simple when you have more than one OpenBSD machine: build a package on a machine with required CPU architechture, keep it somewhere, rebuild for each new release and so on.

For Ubuntu and Fedora there are convenient services available where you can get your own package repository. Ubuntu has Launchpad PPA and Fedora project has COPR. You can put there source packages which are under an open source license, e.g. development snapshots of your software. Users then only need to add the repository address with one command and can install the packages via apt-get in case of Ubuntu and yum (or dnf) in case of Fedora.

It would be nice to have similar service for OpenBSD. I’m even agree to pay a small amount of money for using such service :)

17.09.2017

Рассылки о разработке и тестировании

Прислали мне список почтовых рассылок и я не нашел в них те рассылки, на которые подписан сам.

Вот какие рассылки читаю я:

Все новости, которые сыпятся в соцсетях, я обычно читать не успеваю. Чтобы оставаться оставаться в курсе того, что происходят в opensource я читаю рассылку Changelog Weekly.

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

Дайджест портала Software-Testing.RU о тестировании ПО. Чтобы понять информативна ли она будет для вас посмотрите архив выпусков.

А вы какими-то интересными рассылками о разработке или тестировании можете поделиться?

10.08.2017

Обратная связь для разработчиков PostgreSQL

Когда я тестировал PostgreSQL, то у меня было много вопросов к тому, в каких условиях используют DBA эти СУБД: на какой файловой системе, сколько RAM и CPU на сервере, какие дополнительные расширения они устанавливают и т.д. Время ресурс не бесконечный, а тестирование ПО вещь дорогая, поэтому хотелось знать ответы на эти вопросы, чтобы правильно спланировать тестирование и фокусироваться на тех конфигурациях тестовых окружений, которые бы покрывали нужды большинства пользователей СУБД PostgresPro.

Чтобы получить ответы на такие вопросы есть два способа:

  1. общение с представителями компаний, у которых больше все установок СУБД и которые приносят больше всего дохода компании-производителю. Такое общение обычно происходит со стороны отдела продаж или со стороны менеджера продукта. С таким способом как минимум два недостатка: вероятность искажения информации пока она дойдет от пользователей до отдела разработки и тестирования и отсутствие оперативности в предоставлении информации.
  2. автоматический сбор нужных метрик средствами самого продукта и отправка их разработчикам.

Второй способ широко используется и для коммерческих продуктов и для открытых проектов. Но для PostgreSQL я не нашёл расширения, которое бы собирало параметры СУБД и отправляло на удаленный сервер. Поэтому решил сделать его сам.

В первую очередь я посмотрел на расширение для MariaDB. Их расширение для сбора статистики по умолчанию установлено и выключено. После включения с заданной периодичностью расширение собирает значения 850 параметров и отправляет их на сервер компании MariaDB. Статистику некоторых параметров можно посмотреть на специальной страничке.

Для своего расширения я решил вместо данных в формате списка key=value использовать JSON. Просто потому что это будет удобнее и в PostgreSQL хорошая поддержка JSON (операторы и тип данных). Отправка отчёта с данными с помощью самого расширения мне показалась излишним. Для отправки проще использовать curl, а периодичность настроить в crontab(1).

Составил список того, что интересно было бы знать при разработке: версия СУБД, список расширений, настройки СУБД из postgresql.conf, размер БД на диске, файловая система диска, на котором находится $PGDATA, информация о CPU и RAM, информация об операционной системе и идентификатор СУБД. Для части параметров можно составить SQL запросы и на выходе получить JSON структуру. А некоторых параметров в БД нет. Для таких параметров сделал отдельные SQL функции на C, вывод которых уже добавлял в отчёт. Так получилось расширение pg_feedback. Было бы здорово сделать ещё сервис с web-ui, чтобы смотреть статистику по полученным отчётам, но пока получилось их только собирать и складывать в СУБД - pg_feedback-webui. Да и не уверен я, что нужно писать специальный сервис, когда есть Logstash и Kibana.

22.07.2017

Переносимый интерфейс операционных систем

Читаю документацию по функции statfs(2), а там такое:

Nobody knows what f_fsid is supposed to contain (but see below).

Дальше идёт объяснение того, как f_fsid используется в разных ОС, но суть в том, что нет единого мнения как значение из этого поля использовать. Это несмотря на то, что поле присутствует в описании struct statvfs в POSIX 1003.1-2001.

19.07.2017

Where is the OpenBSD community?

Yesterday I decided to determine where the OpenBSD community should have its interactive communication. Options included were Google Plus, Reddit and other social networks. The results were not surprising, with community prefer old-style communication - mailing lists maintained by project people. Less popular community resources see below:

03.07.2017