Протестировал

Нашёл у Якоба Нильсена прекрасное - отзывчивость UI, комфортного для пользователя. Это же можно в неизменном виде добавлять в требования к продукту.
Цитата из 5-й главы книги "Usability Engineering", изданной в 1993 году:

The basic advice regarding response times has been about the same for thirty years Miller 1968; Card et al. 1991:

- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

https://www.nngroup.com/articles/response-times-3-important-limits/

Протестировал

На сайте подкаста Радио-Т в RSS ленте 21 запись. Похоже на баг граничных значений.

Протестировал

На Хабре зачем-то вспомнили одну из статей Джоэла Спольски про "Вещи, которые вы никогда не должны делать". В ней Джоэл объясняет, почему разработчики склонны к переписыванию кода и что переписывание кода продуктов с нуля может обернуться катастрофой для компании. У меня же с переписыванием кода с нуля связано две истории.

Для одной из первых версий Parallels Desktop for Mac нужно было выпустить обновление с фиксами для виртуализации USB контроллера. Как водится, сборку с фиксами подготовили только под вечер. Нужно было протестировать и выложить на сайт. Вечер, в офисе только разработчик, который отвечал за виртуализацию USB, менеджер проекта, мой руководитель и я. Первая версия сборки: баги для хотфикса исправлены, но есть регрессия для ранее работающих устройств. Разработчик делает фикс, коммит, запуск сборки. Вторая версия сборки: один из багов для хотфикса начинает воспроизводиться, регрессия в плачевном состоянии. Разработчик делает фикс, коммит, запуск пересборки. Третья версия сборки: баги для хотфикса починили, регрессия не проходит. Разработчик чинит, мы все его ждём. Починка затягивается. Уже поздно и хочется домой. Выясняется, что вместо того, чтобы сделать исправления в существующем коде разработчик решил часть кода переписать с нуля! Мы тогда каким-то чудом выпустили обновления, но помню, что разработчику тогда из-за этого сильно влетело от PM.

Когда Parallels Desktop for Mac был уже популярным продуктом, то команда разработчиков решила перейти от монолитной архитектуры к клиент-серверной. Параллельно с поддержкой старой кодовой базы велась разработка новой версии силами нескольких человек. Не знаю сколько кода выкинули во время этого перехода, но такой переход был успешным и с тех пор у Parallels Desktop for Mac и Virtuozzo общая серверная часть.

Протестировал

​​Две мои находки за последнее время:

- Я как-то читал статью об опыте использования мутационного тестирования в Гугле и там авторы рассказывали, что новый код тестов тестируется с помощью мутаций и информация о выживших мутантах добавляется в ревью. Мне тогда понравилась такая идея: это удобнее, чем разбираться в результатах тестов и потом искать код для исправления. `reviewdog` позволяет интегрировать инструменты для автоматического анализа кода в процесс ревью на Гитхабе и указывать проблемные места непосредственно в коде. Вообще сервисы для этого давно были (например houndci и sider.review), но у них общая проблема - ограниченный набор инструментов, с которыми они интегрированы. reviewdog делает позволяет интегрироваться со всем чем можно с помощью scanf-подобного языка описания ошибок. Список того, что уже интегрировано с `reviewdog`, список похожих в проектов.
- pre-commit упрощает управление всеми прекоммитными проверками, которые вы используете в Git. Вместо ручного управления хуками в Git нужно один раз установить хук, создать конфиг в формате YAML и описать в нем каждую из проверок (стат. анализ, тесты и т.д.) и вуаля!
Примеры конфигураций: https://pre-commit.com/hooks.html

Протестировал

Всё-as-a-Code

Мы привыкли, что артефакты для большинства стадии разработки ПО (SDLC) можно представлять в виде кода: тесты как код, инфраструктура как код, документация как код (@docops), архитектура как код, мокапы как код (https://imagineui.github.io/ru/). Потому что в таком случае к этим артефактам применимы все те же подходы, которые используются для кода: версионирование, ревью, автоматические проверки и т.д. Казалось, что требования к ПО были последним бастионом в этом движении, но с doorstop пал и этот бастион и теперь даже системные требования превратить в код. Каждое требование - отдельный файл в формате YAML, есть интеграция с Python.

Кстати требования для самого инструмента описаны в виде требований doorstop - https://github.com/doorstop-dev/doorstop/tree/develop/reqs

Презентация - https://speakerdeck.com/jacebrowning/doorstop-requirements-management-using-python-and-version-control

Протестировал

​​Одной из задач тестировщика является работа по минимизации тесткейса для воспроизведения бага. Это и минимальный набор шагов и минимальный набор данных для воспроизведения. Потому что в таком случае и работа по исправлению бага становится проще и регресионный тест проще добавить. В случае использования тестов на основе свойств (property-based) мы самостоятельно генерируем тесткейсы и в случае проблем всегда можно получить минимальный тесткейс, это один из плюсов PBT. Но часто приходится работать и c не минимизированными данными, например в случае воспроизведения проблем от пользователя.
В таких случаях помогают инструменты для минимизации неструктурированных данных. Классической публикацией по этой теме является статья Андреаса Зеллера Simplifying and Isolating Failure-Inducing Input, в которой он описывает потребность в минимизации тесткейсов для браузера Mozilla и описывает алгоритм, см. графическое представление на картинке. Потом в Mozilla стали использовать lithium, который использует улучшенный алгоритм минимизации, а для компиляторов появился creduce. Я в своей работе пользуюсь halfempty, который написан небезызвестным Tavis Ormandy из Гугла. halfempty написан на Си и работает очень быстро. Посмотрите примеры использования halfempty - https://github.com/googleprojectzero/halfempty/wiki/Examples

Протестировал

Новая неделя - новый автор в коллективном твиттере. На этот раз Сергей Пирогов расскажет про автоматизацию тестирования ПО.

Предыдущие авторы:

- Всеволод Брекелов @brekelov из JUG.ru https://twitter.com/sqaunderhood/status/1224230188571152384
- Алексей Никулин @wrong_habits https://twitter.com/sqaunderhood/status/1219255551516954624
- Алекс Денисов @1101_debian из Uberchord https://twitter.com/sqaunderhood/status/772697945011548161
- Максим Шульга @maxbeard12 из Код Безопасности https://twitter.com/sqaunderhood/status/770170042369576961
- Андрей Сатарин @asatarin из Яндекса https://twitter.com/sqaunderhood/status/766911352958963712
- Артем Кошелев @art_koshelev из Яндекса https://twitter.com/sqaunderhood/status/757168508819996672
- Сергей Бронников @estet из Virtuozzo/Parallels https://twitter.com/sqaunderhood/status/754962466845683712

Протестировал

Forwarded from Alexander Koptyaev
Таблица сравнения e2e-фреймворков тестирования [in progress]:
https://docs.google.com/spreadsheets/d/132A8gAo6t0pS_GUnIx6iT5fPH02jz4EFvDZzJ-NgkZ4/edit#gid=60266495

Предложения по доработке, при желании, можете писать в документе.

При необходимости — переделаю формат, или же посодействую с тем, кто решит взять на себя сбор/обработку информации :)

Протестировал

Сегодня и завтра в Брюсселе проходит конференция FOSDEM.
Одна из секций посвящена тестированию ПО и там есть любопытные доклады: расписание секции, видеотрансляция.

Протестировал

​​Вы когда-нибудь пробовали внедрить использование новую идею или инструмент в рабочий процесс? Например сходили на конференцию и узнали про инструмент Х, который выявляет дефекты определенного типа, и загорелись идеей внедрить использование этого инструмента в своём проекте. Если пробовали, то знаете, что внедрить любую новую идею не так легко: нужно найти людей, готовых к экспериментам, рассказать ("продать" идею) им о своей инновации, помочь в начале использования инструмента X и работать над вовлечением в процесс других коллег. Для процесса внедрения инноваций есть своя теория, которая была описана социологом Эвереттом Роджерсом в статье "Диффузия инноваций". Эта теория, которая стремится объяснить: как, почему и с какой скоростью распространяются новые идеи и технологии. В той же статье приводится график распространения инновации среди групп людей, включающихся на разных этапах распространения инновации.

В 2007 году в одной и статей сотрудники Гугла описали подход "Testing on the Toilet", который они использовали для распространения проверенных практик написания хорошего кода среди разработчиков. Часть содержимого листовок они опубликовали в блоге. Позднее такой подход использовали в компании SchibstedGroup.

В статье Do Developers Discover New Tools On The Toilet? авторы описывают эффект, который имел "Testing on the Toilet". Там описаны инструменты, которые участвовали в исследовании, методология и непосредственно оценка эффективности подхода.
Можете не читать статью, изменение процентов использования разных инструментов после публикации листовок с описанием этого инструмента можно посмотреть в таблице из скриншота. Меня удивило то, как они отслеживали рост использования инструментов: "Google collects log data of how employee software developers use command-line tools. Most development at Google occurs on Linux workstations using a uniform, centrally built toolchain; every binary built for the workstation fleet creates a syslog entry on start. This data provides the number of developers per day using each tool."

#академикипишут

Протестировал
1.3K members
2 photos
103 links
Авторский канал об обеспечении качества ПО (тестирование, верификация) Сергея Бронникова @ligurio. Теги: #история #непишитетесты #шапито #bugstory #академикипишут

Коллективный твиттер: https://twitter.com/sqaunderhood

Читайте также:

Знаете интересный Телеграм-канал, которого нет в данном разделе? Сообщите нам!

По всем вопросам: mail@telegram.one