Чудес не бывает или я ошибаюсь?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Митоз клетки команды Если продукт или набор сервисов, которым занимается команда, успешно развивается, задач становится все больше, размер команды растет, рано или поздно вы приходите к мысли о трансформировании команды в несколько команд.  Иногда это происходит "органически" - в продукте есть свободно отделяемая часть, которую можно передать новой команде. Иногда все сложнее - продукт разделить тяжело и само разделение драйвится тем, что просто людей становится много (или нужно больше) и текущие процессы становятся неэффективными, а результат работы сложно прогнозируемым.  Я наблюдал 3 варианта "рождения" новой дополнительной команды для существующих задач (речь здесь и дальше не про запуск нового продукта, а про дополнительный импульс в развитии существующего): - команда формируется с нуля. Самый сложный вариант, который скорее всего подойдет, когда процесс работы уже заточен под "многокомандность" и новая команда - это лишь еще одна шестеренка в настро

Возрастной философии твиттер-тред , который я решил переложить в статью, заодно попытавшись поправить правописание. Ну и ссылку на заметку сейчас удобнее отправлять, чем ссылку на твиттер. А желание ее кому-нибудь отправить по-прежнему иногда возникает.   Уже даже не помню, чем было навеяно. В лучших традициях твиттерского жанра "дед ноет". Все как положено: нытье, без конкретных примеров действий и противодействий.  Где-то плюс/минус несколько дней в это время 20 лет назад (тред писался в феврале 2021) заканчивалась моя военная служба и я уже официально (а не в самоволку, как было несколько месяцев до этого) ходил писать новые компоненты для Delphi-библиотек. С тех пор много чего (все?) поменялось в IT-отрасли, но речь сегодня пойдет не про технику.  А будет про людей. Даже скорее про конкретного человека в моем лице, как и что менялось во мне за эти 20 лет, отношение к возрасту, возрастные фобии если хотите :) После увольнения, наверное около 10 лет кряду, возраст коллег не

На базе треда в тви. Признаться, я давно не провожу "каноничные" 1:1.  В 1-ю очередь из-за того, что "каноничность" предполагает регулярность. Практика скорее полезная, но эффективность зависит от многих факторов. Например, количества тех, с кем надо проводить, процессов в командах и твоем в них участии. А я не люблю делать то, что просто "общепринято", но пользы не несет или ее меньше, чем затрат хотя бы времени.  Ну или просто терпения не хватает дождаться реальной пользы. Чаще получаются не классические 1:1, а встречи по онбордингу новичков, обсуждению планов развития, беседы с ребятами, которые сами приходят с запросом. Моя "дверь" для такого всегда открыта и я всем постоянно и везде про это напоминаю. Тем не менее, всегда полезно иметь списочек вопросов, которые можно обсудить: 1.  Вопросы для первой встречи  2. Хорошая замена традиционного вопроса " How's everything going?" -> "What's one thing that could be bett

 Про то, что менеджмент  - это не единственный путь развития :)

Есть тред в твиттере, но пусть тут для удобства тоже будет. Книги большей частью достаточно "возрастные", у некоторых есть свежие переиздания, где добавлены "свежие" темы, типа мобилок и тп. Из-за "возраста" сравнительно легко ищутся не только в магазинах. Вводная по "разработческому" тестированию Про тестирование обзорно для разработчика Developer Testing The Art of Unit Testing (лучшая, на мой взгляд, книга по юнит-тестам) С примерами на С#   С примерами на JS   Применимо и к другим языкам Паттерны для хороших тестов (практически любых) xUnit Test Patterns: Refactoring Test Code (есть книга) То, что мало кто из тестировщиков читал: Теория тестирования Lessons Learned in Software Testing: A Context-Driven Approach Букварь по тест-дизайну A Practitioner's Guide to Software Test Design Гибрид двух предыдущих Software Testing and Analysis: Process, Principles and Techniques: Process, Principles, and Techniques Еще один гибрид The Art of Softw

Лет 5 назад наваял на коленке для рассказа разработчикам про тестирование в команде без тестировщиков. Что такое качество? С точки зрения пользователя: Качество — это пригодность к использованию. Делает ли данный продукт то, в чем я нуждаюсь, облегчает ли он мою работу, могу ли я его использовать так, как мне удобно. С точки зрения разработчика: Качество — это соответствие специфицированным и собранным требованиям. Делает ли данный продукт все то, что указано в требованиях.