Протестировал. Страница 9

Таблица сравнения 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."

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

Раздел о тестировании документации в курсе по документированию API https://starkovden.github.io/about-fifth-module.html

​​​​Увлекательные истории о багах, которые можно встретить при разработке СУБД, от разработчика ClickHouse - Отъявленные баги и как их избежать на примере ClickHouse: презентация и видео.

#bugstory

​​Грустная история одного бага в QEMU https://twitter.com/a13xp0p0v/status/1220303108389122048
#bugstory

Когда я работал в Parallels над Virtuozzo, то в одной из версий мы добавляли функциональность создания кластера отказоустойчивых виртуальных машин и контейнеров. Один из сервисов должен был выполнять балансировку виртуальных сущностей между серверами в случае отказа одного из них. Стандартное название сервиса с такой функциональностью - DRS (Distributed Resource Scheduler) и человек, который делал дизайн фичи так и назвал сервис, но в начало добавил первую букву из названия компании (стандартная практика в больших компаниях). Так получился pdrs. Функциональность DRS нетрививальная для тестирования и часто сервис работал не так как надо. Но мы не расстраивались, потому что pdrs он и есть pdrs. Продуктом Virtuozzo компания Parallels уже не занимается, но следы pdrs все ещё можно найти в документации.

#шапито

​​Авторы статьи "Taxonomy of Real Faults in Deep Learning Systems" проанализировали более тысячи проблем в ПО на основе нейросетей и составили классификацию ошибок в таких системах.

А ещё нашел твиттер, в котором собирают ссылки на публикации об ошибках в ПО на основе машинного обучения - https://twitter.com/mlfailures

Давно не было свежей литературы по тестированию.

Два профессора из Делфтского технического университета выложили в открытый доступ под лицензией CC-BY-NC-SA 4.0 книгу "Software Testing: From Theory to Practice". В книге они рассмотрели такие темы, как автоматизация тестирования в целом, тестирование с помощью моделей, тестовая пирамида, TDD, мутационное и фаззинг тестирование и др. Часть глав пока ещё в стадии написания и они будут выложены позднее. В первую очередь книга ориентирована на студентов 1-го курса.

Chapter 1 - Why software testing?
Chapter 2 - Software Testing Automation
Chapter 3 - Testing Principles
Chapter 4 - Specification-Based Testing
Chapter 5 - Boundary Testing
Chapter 6 - Model-Based Testing
Chapter 7 - Structural-Based Testing
Chapter 8 - The Testing Pyramid
Chapter 9 - Mock Objects
Chapter 10 - Design for Testability
Chapter 11 - Test-Driven Development
Chapter 12 - Test code quality and test code smells
Chapter 13 - Design by Contracts and Property-Based Testing
Chapter 14 - Web testing (soon)
Chapter 15 - Database/SQL testing (soon)
Chapter 16 - Mutation testing
Chapter 17 - Fuzzing testing
Chapter 18 - AI and Search-Based Software Testing (soon)
Chapter 19 - Security Testing (soon)
Chapter 20 - Responsible/Ethical Software Testing (soon)
Chapter 21 - Performance testing (soon)
Chapter 22 - Software testing for embedded devices (soon)
Chapter 23 - Software testing for mobile apps (soon)
Chapter 24 - Continuous

Помимо самой книги (https://sttp.site/) доступны слайды (https://github.com/sttp-book/video-slides).

На этой неделе в твиттере sqaunderhood новый автор. Присоединяйтесь к дискуссиям.

На выходных полистал старые треды и вспомнил про "Тред. 1 лайк = 1 факт про тестирование/качество программ от @asatarin". Пожалуй это один из лучших тредов в этом твиттере, поэтому приведу здесь твиты из него. (Поговаривают, что если поставить лайк, то Андрей допишет ещё один факт.) P.S. Не знаю насколько пересекаются аудитории этого канала и твиттера, надеюсь что не сильно и многие ещё не читали.

1. Программисты должны тестировать
2. Тестировщики должны программировать
3. Автоматизировать надо все тесты, которые требуют автоматизации
4. Нужно уметь различать тесты, которые требуют автоматизации, от тех что не требуют — это важный навык тестировщика и программиста
5. Как дешевле, проще, надежнее, быстрее писать автотесты — тоже важный навык
6. Раскладывание тестов по уровням “той самой пирамиды” — первая часть удешевления
7. Чем на более низкий уровень пирамиды вы положили тест, тем лучше. Всегда, без исключений.
8. Следующие шаги по удешевлению поддержки — делать хороший дизайн, про который написано 100500 книг для программистов (стоит почитать)
9. Частота чтения/написание кода оценивается как 10 к 1, для тестов соотношение еще больше в сторону чтения. Поэтому важность читаемости тестов сложно переоценить
10. Разработка (фреймворка) тестов — это разработка многих разных domain specific languages, некоторые из которых могут существовать только в одном тесте
11. Надежность тестов больше вопрос гигиены и избегания плохих практик, не делать sleep и вот это все
12. Внутренне качество кода тестов надо поддерживать на том же уровне или выше, что и продуктовый код
13. Надо писать тесты на ваши тесты и тестовый фреймворк, иногда даже тесты на тесты тестов
14. Дешевые, быстрые, надежные, поддерживаемые тесты никому не нужны, если они не находят важные дефекты
15. Что такое важный дефект — открытый вопрос. "Quality is value to some person (who matters)"
16. Чтобы находить важные дефекты, надо знать про риски в вашем ПО и искать дефекты там где риски выше — потеря данных, денег, репутации, рынков и т.д.
17. Для выявления рисков в ПО есть мнемоники, например FURPS+ — Functionality, Usability, Reliability, Performance, Security плюс что-то еще
18. Управляет рисками в проект менеджер, а тестирование информирует его о состоянии этих рисков
19. Вы решили написать тесты на ваше ПО и вам надо понять, где баг, а где фича. Для это вам нужны, нет НЕ требования, вам нужен — оракул
20. Тестовый оракул — это такая штука, которая умеет отличать баг от фичи. Это могут быть требования, здравый смысл, знания предметной области, маркетинговая брошура, документация или продукт конкурентов, человек, который все знает, прошлая версия продукта, схема на доске и т.д.
21. Ваш тестовый оракул может ошибаться, или противоречить другому оракулу, или себе
22. Умение искать оракулов настолько важно, что привело к попытке их материализовать и документировать в тест кейсах
23. Все эти граничные значения, классы эквивалетности, pairwise и т.д. — эвристики на поиск типичных ошибок, ничего более

Инструмент для визуализации покрытия кода с поддержкой разных форматов и, что интересно, истории изменения покрытия - ReportGenerator https://github.com/danielpalme/ReportGenerator#supported-input-and-output-file-formats

Давно у нас в коллективном твиттере @sqaunderhood не было новых авторов. Если чувствуете, что вам есть что рассказать о тестировании ПО, то дайте знать.

Хотел бы поделиться одной довольно хорошо работающей у нас практикой.

Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой-то полезный рецепт - то все хорошо. Но конференции сейчас большие, многопоточные, самих конференций много, всем везде не успеть.

Поэтому применяем простую практику - ретроспектива конференции. После поездки надо заполнить простую таблицу - какой доклад | какая оценка полезности | чем интересен | что хотелось бы применить; Таблицу потом обсуждаем, чтобы дополнить упущенное

Теперь польза:
1) участники выделяют и формулируют главное в услышанном. это очень важный этап в усвоении объемной информации, но мало кто достаточно дисциплинирован чтобы делать это самостоятельно
2) участники обсуждают свои оценки полезности доклада. это вскрывает разность взглядов, создает поле для дискуссии и расширения кругозора
3) не-участники видят какие доклады были наиболее полезны и чем, и могут выбрать какие доклады стоит посмотреть, как только появятся записи (а записи докладов выкладывать сейчас общепринято)
4) отдельное выделение "что хотелось бы применить" позволяет возвращаться к итогам конференции позже и оценивать, а не свалились ли мы в пассивное слушание, когда все всё понимают, но никто ничего не делает

@program_man - один из немногих каналов, в которых автор пишет редко, но исключительно полезные вещи, основанные на своём многолетнем опыте разработки ПО. Пост ниже про ретроспективы конференций.

Для меня приятно слышать от разработчиков, что тестирование нелёгкая работа. Chris Evich, разработчик libpod: "I once said “testing code is at least 10x harder than writing it”. This is especially true when a software-engineer believes their code is “perfectly good” (meaning, tons of bugs). At the same time, test automation is generally as reliable, as the inverse of its simplicity (especially when it’s never simple)."

Микросервисная архитектура получила широкое распространение и с ростом количества этих самых сервисов усложняются коммуникации между ними, увеличивается объем разработки серверной и клиентской частей, тестирования этого кода. Для сокращения издержек на написание кода общепринятым подходом считается использование так называемых схем, из которых код клиента и сервера генерируется автоматически. Стандартом схем де-факто является Open API 3.0, инструменты для которой также позволяют генерировать интерактивную документацию.

А вот с тестированием API не все так однозначно. Я думаю не надо объяснять, что при несоответствии реализации схеме возможны неблагоприятные последствия: от необработанной ошибки, которая ломает приложение, до проблем с безопасностью, которые могут повлечь серьезные финансовые потери. Классический подход с example-based тестами не является дешёвым ни в разработке, ни в поддержке. Подход с тестированием с помощью свойств может сократить стоимость тестирования. schemathesis позволяет рутинные проверки с простыми запросами генерировать автоматически из схемы.

Для демонстрации возможностей можно попробовать запустить пример, где создается простой веб-сервис с множеством ошибок и генерируются тесты с помощью schemathesis.

#непишитетесты, генерируйте их

Некоторые тестировщики умудряются оставлять браузеры и chromedriver на серверах, доступных публично. Не делайте так :) Если что, для chromedriver можно ограничить доступ по IP-адресам с опцией --whitelisted-ips. Файрволл тоже никто не отменял.

Знакомьтесь - это Тамара. Тамара умеет посылать посылать события мыши и клавиатуры по USB по заранее заданному сценарию. Для обычного человека бесполезная возможность, а для нас неоценимая помощь в тестировании тонкого клиента. Тамару сделал мой коллега из нескольких Ардуино и небольшого количества радиоэлементов. А вы разрабатываете специальные аппаратные средства для тестирования своих продуктов или обходитесь программными? Расскажите.