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

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

"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. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то ...

Есть тред в твиттере, но пусть тут для удобства тоже будет. Книги большей частью достаточно "возрастные", у некоторых есть свежие переиздания, где добавлены "свежие" темы, типа мобилок и тп. Из-за "возраста" сравнительно легко ищутся не только в магазинах. Вводная по "разработческому" тестированию Про тестирование обзорно для разработчика 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...

Недавно поучаствовал в Heisenbug Piter 2021 в роли эксперта на очередной серии доклада Андрея Солнцева про flaky тесты. Люблю эту тему. Кажется, это своего рода "дебаг", только для тестов. Иногда расследование похлеще приключений Шерлока. Тема flaky тестов древняя, как сама отрасль. Первое найденное упоминание термина в традиционных интернетах (типа блогов, твиттеров) в 2008 году в блоге гугла . Мне больше нравится называть их “моргающие” или, что четче отражает проблему, случайно успешные. Давайте еще раз зафиксируем то, что поможет меньше попадать в историю, когда тесты у нас "случайно успешные" и что делать, если уже "вляпались". Итак, что делать, чтобы "моргающих" тестов было меньше: тесты должны быть написаны в правильном слое " той самой пирамиды ": чем ближе слой к модульным тестам (а лучше именно в них), тем меньше шансов на моргания, потому что зависимостей меньше. в ту же тему: чем меньше UI-тестов, тем лучше. Открывая в оче...

Глянул, что уже есть в программе Heisenbug Piter 2020 : так как я сейчас не в ПК, то интересно, что там у ребят с программой получается. И я вам скажу, что интересно получается :) Во-первых там есть доклад Адама Торнхила , одного из авторов инструмента CodeScene , которого я рекомендовал пригласить. Очень хочется послушать про жизнь кода. Во-вторых в программе Иван Крутов , один из авторов Aerokube. Еще Аня Чернышова про возможное решение проблемы падучих UI-тестов. Что бы я еще посмотрел: Effective unit testing Тестирование производительности клиентской части React/Redux-приложения с использованием Enzyme Demystifying Cross Browser testing  (от бывшего автора Puppeteer) В общем, еще раз вам ссылка на программу , смотрите-думайте. Если созреете и ваша компания-редиска и не оплачивает вам конфу, промокод на персональный билет   shulga2020pc . Еще интересных вам ссылок, местами философских, но про тестирование: Interaction Resiliency (iXR) is the practic...

И снова с вами рубрика "что интересного было в ленте на этой неделе". 1.  Building and Testing Resilient Web Applications with Toxiproxy. Статья , видео . "A resilient system is one that functions with one or more components being unavailable or unacceptably slow. Applications quickly become intertwined with their external services if not carefully monitored, leading to minor dependencies becoming single points of failure. For example, the only part of Shopify that relies on the session store is user sign-in - if the session store is unavailable, customers can still purchase products as guests. Any other behaviour would be an unfortunate coupling of components. This post is an overview of the tools and techniques we used to make Shopify more resilient in preparation for the holiday season." 2. What is Soak Testing ? "Soak testing (otherwise known as endurance testing, capacity testing, or longevity testing) involves testing the system to detect the pe...

В предверии завтрашнего BOF на Heisenbug по тестированию в продакшене , вот вам набор материалов по теме (валите модератора там). Предыдущая статья по теме . Development → Staging → Production pic.twitter.com/xIohpoaWqw — Daniel Stefanovic (@DaniStefanovic) March 29, 2018

На самом деле, вопрос стоит скорее так: " почему у вас его еще нет "? Изначально хотел просто сохранить себе и дать вам набор ссылок, что нашел на эту тему, потому что сейчас она у меня болит. Потом захотелось сделать какой то анализ. Потом понял, что письменный анализ - это долго и субъективно (и простите, чуток лень), а вам может будет полезно почитать оригиналы. И честно пытался не дублировать у себя их контент, разве что тезисно. Поэтому статья получилась половинчатой и скорее побудительной к действиям или хотя бы к мыслям, чем с практической пользой. Не обессудьте. Ну вот, я вас предупредил. Ссылки все равно есть, поэтому можете уверенно двигаться к их  списку .

Новости и промо по Heisenbug 2019 Moscow . Всем привет. У нас закончился первый этап подготовки к Heisenbug 2018 Piter : костяк программы сформирован, начинаем работать с отобранными докладчиками, кидаем кости серьезно выбираем кандидатов на последние вакантные места в программе. Читаем до конца... Напомню, что конференция пройдет 17-18 мая в Петербурге. Акцент при выборе докладов делается на технический аспект. Не умаляя необходимости и важности процессов, метрик и прочего, мы стараемся выбрать те заявки, которые имеют практическую инженерную ценность. "Пришел послушать про мобилы - ничего не было", "Все доклады про веб и мобилы, как будто больше нигде не тестируют" - такие вот отзывы мы получаем после одной и той же конфы. Хотя стараемся, очень, наполнить программу докладами про все сферы разработки ПО. И в этот раз будет и про мобилы, и про веб, и про облака и тд и тп. Подробностей пока раскрывать не могу, но тематика разносторонняя. Пробуем даже с ...

Взято здесь Интересно, местами спорно и специфично, но полезно посмотреть. Основная тема - автоматизирование проверок, чаще всего, дороже ручных проверок . Начинать надо : с автоматизации получения информации о состоянии тестирования (отчеты и тп) автом.развертывания(передачи в тестирование) обучения (вики, запись видео и тп)  Ну а с проверками - надо оценивать :) Решение зависит от требуемого уровня бездефектности. Что еще было интересного? Сергей на удивление лоялен к тестам разработчиками и к "test first" (тесты до кода). Есть ощущение, что он рассматривает текущее состояние автоматизации тестирования, как автопроверки через GUI. В вопросе эффективности таких проверок я с ним соглашусь. Хотя, конечно, это не единственный способ автоматизации проверок. Серебряной пули нет, везде надо включать мозг и,... калькулятор. В общем, у меня отлегло :)

Тесты "моргают" и в Гугле. Интересный доклад. Радует, что у нас используются похожие методы определения и борьбы с "моргунчиками", хотя сравнение объемов и масштабов может вызвать лишь сочувственную, по отношению к нам, улыбку. Слайды Видео

В рамках подготовки к одной из конференции сделал новый доклад. С конфой не срослось, но доклад решил выложить. Получилось больше осенне-депрессивно про проблемы, на которые мы наступали, когда автоматизировали тестирование  vGate . Надеюсь кому-нибудь будет полезно. Про вебы и прочие Selenuim-ы c Selenide-ами там ничего нет, ибо не наше это все. Но основные вопросы в виде " нафига автоматизация нужна " и тезис про то, что " написать тесты - это не самое сложное, сложнее с ними долго жить ", никуда не деваются. Для экономящих время: слайды тут  (Slideshare), а лучше тут (gdrive) Для совсем ленивых: "автоматизация тестирования - это не только ценный мех, но и 3-4 кг ...здеца". Работать придется много. Для желающих видео ( тут на RUTUBE ) ЗЫ подумалось, что полезные ссылки из слайдов надо сюда затащить, а то не факт, что до конца кто-нибудь долистает Автоматизация тестирования. С чего начинать, возможные проблемы Как перестать бояться...

Всем привет. С 29.08 по 2.09.2016 вел совместный твиттер тестировщиков @sqaunderhood . Авторы твиттера меняются каждую неделю. В планах было (и исполнено): - рассказ про автоматизацию тестирования продукта, которым сейчас занимаюсь ( vGate ) - мысли на тему роли тестировщиков в разработке софта (да я знаю, что уже всех этим достал) - полезные ссылки, которых вы еще может быть не видели. В общем было интересно, но похоже с активностью переусердствовал. Тяжело в твиттере читать размазанную по N-твитам мысль. Подписывайтесь на  @sqaunderhood , трольте, спрашивайте. "все рекламируемые в твиттере инструменты и рекомендации применять с напряжением мозга"

Эта статья висела в черновиках почти полгода. И не факт, что я бы до нее добрался, если бы не свежие новости с "фронтов". Изначально мысль была сделать небольшое ревью этой статьи . Но помню, что тогда я сходу ее не взял. Зацепился за то, что не согласен  с авторами, решил отложить на "подумать". А недавно наткнулся на статьи  Chris McMahon и Alan Page , в которых товарищи выражают несогласие с подходом "автоматизация тестирования - это автоматизация из тулов". В общем кому интересна тема автоматизации, и мозг уже достаточно окреп - можно нырнуть в гущу событий и оценить холивар . отсюда PS неокрепшим умам читать с осторожностью. PS2 Алан упоминает свою книгу " The A Word ". Я делал ее обзор

Перевод твит-ленты Майкла Болтона  тезисно описывающей, что такое "проверки", и почему тестирование не может быть автоматизированно. Update: чуть позже появилась его статья . Disclaimer: не в первый раз замечаю, что литературный слог Болтона тяжело поддается переводу в лоб. Любит он экзотические формулировки. П оэтому что получилось, то получилось :)

Осталось всего 2 дня зарегистрироваться на IT NonStop в Питере Буду там рассказывать про FitNesse+PowerSlim . Доклад всего 30 мин, поэтому будет по верхам, но после доклада можно пообщаться и про "вглубь и вширь" :) Приходите ;) ЗЫ Отчетик чуть позже. Пока вот слайды Можно посмотреть а-ля слайдкаст со звуком. Если запустить видео, то как раз мой доклад будет. Но похоже я вышел за границы камеры и никто мне не маякнул... Заодно и другие доклады технической сессии посмотреть

Всем привет, готова очередная подборка видео. Тема сегодня: роль тестирования и автоматизация (тестирования или в тестировании? :) ) Первым идет  интересный рассказ Atlassian о том, какую роль у них играют QA. Коротко в картинках А вот баттл про тесты :  "Нужно - не нужно. Если да, то кто их пишет". Рекомендую досмотреть до конца и дождаться ответа на вопрос "сколько времени займет фикс, если у вас есть автотесты и без них". Я уверен, что фикс с тестами займет сильно меньше времени. Ну и еще про автоматизацию. Доклад с новомодной темой " Automation in testing "     Есть еще одно интересное, но длинное видео про жизнь без тестировщиков с Codefest. Но я думаю к нему мы вернемся после первого выпуска live-подкаста Radio QA . Приходите 14.05 (уже завтра!) в 18.00 по ссылке, слушайте и задавайте вопросы по теме "Разработка без нянек" - как доверить разработчикам тестирование продукта, чтобы потом не было м...

Один очень хороший человек написал плагинчик для sublime для тех, кому проще редактировать Fitnesse текст (тесты) с подсветкой синтаксиса. По мне так необычно, но может кому пригодится и понравится. Пользуйтесь на здоровье. Как это работает визуально: Стало проще видеть макросы Fitnesse, переменные PowerShell и служебные слова slim-а

Коллеги в настоящее время выбирают себе тестовый фреймворк, на базе которого хотят разрабатывать автоматические тесты. Кстати, сейчас Болтоном и Бахом  активно  продавливается тема, что это не автоматические тесты, а автоматические проверки ( testing vs checking ). Но это тема отдельного поста , холиварить будем там. Я задумался над критериями, которыми, по моему мнению, должен обладать инструмент для написания приемочных тестов, конечно с учетом специфики нашего продукта (Windows (не-веб), продукт распределен по нескольким хостам, виртуализация). Тут же вопросы, на которые полезно знать ответы, когда тебя спросят почему именно этот инструмент, а не другой. 1. Я хочу посмотреть список тестов, какие проверки ими делаются и какая функциональность продукта проверяется. Можно ли это сделать с рабочего места, например Product Manager-а или меня как руководителя разработки, без установки дополнительного ПО? 2. Возможно ли написание одного теста в виде пользов...

Наткнулся недавно на подборку интересных исследований проведенных Empirical Software Engineering and Measurement Research Group. Товарищи на примере деятельности команд разработки Microsoft попытались получить хоть какие-то цифры отражающие влияние различных инженерных практик и процессов, например TDD, на качество получаемых продуктов. Сюда вынес наиболее интересные результаты исследований. Ниже, в качестве критерия качества рассматривается количество ошибок обнаруженных после релиза и требующих зачинок (как самых дорогих для исправления). Влияние покрытия кода тестами на качество Покрытие кода рассчитывается, как процент (отношение) строчек кода, которые вызываются при запускаемых тестах к их общему количеству. Казалось бы логичным считать, что чем больше покрытие - тем лучше качество. Но результаты показали, что не все так просто ( кто бы мог подумать ). Одна метрика не может характеризовать качество для любых продуктов. Процент покрытия кода сам по себе ничего не го...