На этой неделе в твиттере 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 и т.д. — эвристики на поиск типичных ошибок, ничего более