Картинка для привлечения внимания взята тут
Пиццерия Папа Джонс открыта во многих странах, движок сайтов же практически везде разный. Тем не менее, движок, который разработали где-то в России, также используется на сайтах для Польши, Киргизии и Беларуси. Его и рассмотрим.
Читать полностью »
В этом посте я расскажу о том, как я писал консольную программу на языке Go для выгрузки данных из БД в файлы, стремясь покрыть весь код тестами на 100%. Начну с описания, зачем мне нужна была это программа. Продолжу описанием первых трудностей, некоторые из которых вызваны особенностями языка Go. Дальше немного упомяну сборку на Travis CI, а затем расскажу о том, как я писал тесты, пытаясь покрыть код на 100%. Немного затрону тестирование работы с БД и файловой системой. А в заключении скажу о том, к чему приводит стремление максимально покрыть код тестами и о чём говорит этот показатель. Материал я сопровожу ссылками как на документацию, так и на примеры коммитов из своего проекта.
Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.
Из моего личного опыта внедрения методов надежного программирования в своей компании, в компаниях, которые я консультировал, общения на конференциях, а также из публично доступных источников, я сформулировал типичные возражения и сопротивления, которые препятствуют внедрению культуры автоматического тестирования.
Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня:Читать полностью »
На ранних этапах разработки можно обходиться ручным тестированием по заданному тест-плану. Но с появлением модульной архитектуры, когда несколько команд разработчиков могут вносить свои изменения одновременно, происходит экспоненциальное увеличение количества сценариев тестирования. Прогонять их вручную становится все сложнее и сложнее.
В этой статье мы расскажем о том, как мы в компании Virto Commerce автоматизируем тестирование важных бизнес-сценариев.
Читать полностью »
В этой части статьи мы продолжим рассматривать различные виды тестирования в продакшене. Те, кто пропустил первую часть, могут прочитать её здесь. Остальным — добро пожаловать под кат.
Читать полностью »
Мнемоника — слово или фраза, которая помогает нам что-то запомнить. Самая известная мнемоника — «каждый охотник желает знать, где сидит фазан». Кого не спроси, все с ней знакомы.
А вот в профессиональной сфере все немного грустнее. Спросите товарищей, знают ли они, что такое SPDFOT или RCRCRC. Далеко не факт… А ведь мнемоники помогают нам прогнать тесты, не забыв проверить самое важное. Чек-лист, схлопнутый в одну фразу!
Англоязычные коллеги-тестировщики активно используют мнемоники. Знакомая, читающая иностранные блоги, говорит, что американцы придумывают их чуть ли не на каждый чих.
И я думаю, что это здорово. Чужая мнемоника может не подойти именно под вашу систему или ваши процессы. А свое, родное, напомнит «не продолбать проверить вот это и это» и ограничит количество багов в продакшене.
Сегодня я хочу поделиться с вами своей мнемоникой БМВ для исследования граничных значений. Ее можно:
В этой статье рассматриваются различные виды тестирования в продакшене и условия, при которых каждый из них наиболее полезен, а также рассказывается о способах организации безопасного тестирования различных сервисов в продакшене.Читать полностью »
Изначально просто хотел бросить ссылкой к некоторым комментариям для первой ветки вот этой статьи, в качестве примера, почему торчать портами наружу (почём зря) — не есть хорошо.
Ну и ответ вырос в простыню в эту статью, да и коммент увидит раз-два человека (а так возможно кому пригодится).
Речь пойдет совсем не про уязвимость в прямом смысле этого слова, а про то как по недосмотру (халатности или лени) выстрелить в ногу сразу длинной очередью.
Команда UpGuard Cyber Risk нашла "дыру", где многия документы, в том числе и секретные, валялись (другого слова не подберу) в прямом публичном доступе.
Чтобы оценить серьёзность — среди компаний накрытых той "дырой" подразделения VW, Chrysler, Ford, Toyota, GM, Tesla и ThyssenKrupp.
Данные у всех разного типа и грифа секретности, но...
Привет! Представляю вашему вниманию перевод записи "#[test] в 2018" в блоге Джона Реннера (John Renner), которую можно найти здесь.
В последнее время я работал над реализацией eRFC для пользовательских тестовых фреймворков для Rust. Изучая кодовую базу компилятора, я изучил внутренности тестирования в Rust и понял, что было бы интересно этим поделиться.
Читать полностью »
Знакомьтесь, авторы июльской статьи для «Календаря тестировщика» Андрей Марченко и Марина Третьякова, тестировщики-аналитики Контура. В этом месяце ребята расскажут о моделях рабочего процесса по тестированию аналитики, и как они начали тестировать аналитику до стадии разработки. Опыт ребят будет полезен менеджерам, тестировщикам и аналитикам некрупных продуктовых команд, которые не живут в рамках стартапа и для которых качество важнее скорости.
Тестировщик работает с аналитикой после того, как ему передали готовую задачу. Он проверяет задачу, читая аналитику, как документацию того, что сделал разработчик. Ошибаются абсолютно все, вне зависимости от уровня профессионализма. Дефекты могут быть в аналитике или в коде разработчика.
Ошибки аналитики, выявленные при тестировании, стоят дорого или очень дорого.
Тестировщик подключается к задаче еще до того, как ее передали в разработку. Он смотрит прототипы по задаче или просто читает документацию. Все вопросы по задаче тестировщик задает аналитику. Аналитик оперативно исправляет замечания. Тестировщик составляет приемочные тесты.
