Хабр, привет!
Меня зовут Борис. Я AQA iOS-engineer в Vivid Money.
В этой статье я хочу рассказать про snapshot тесты и показать, как их можно эффективно применять в своём проекте.
Данная статья будет полезна начинающим iOS-автоматизаторам, либо разработчикам, которые решили изучить XCUITest и покрыть свой проект ui-тестами.
В рамках статьи мы разберем:
• Что такое snapshot тесты и когда их применять;
• Какие есть библиотеки;
• Поэтапно расскажу и покажу как внедрить их у себя в проекте.
В двух последних постах Что такое тестирование? и Организация тестирования я поделилась своими соображениями об испытаниях. Хотя между понятиями «тестирование» и «качество» есть тесная связь, одно из них не обязательно подразумевает второе. Тестирование лишь дает нам какое-то представление о качестве.
Я хотела завершить эту серию публикаций постом, полностью посвященным качеству и управлению качеством, но у меня оказалось так много мыслей на эту тему, что его пришлось разделить на две части. В первой из них я расскажу о своем взгляде на качество.
В предыдущей статье «Часть 1. Что такое тестирование?» я поделилась с читателями мыслями о том, в чем заключается суть тестирования. Во второй части моих рассуждений о тестировании и управлении качеством я подробно рассмотрю различные типы тестирования и проанализирую модели, которые помогают разработчикам визуализировать процесс тестирования, чтобы вовлечь в него всех участников команды.
Тестирование — это не только поиск багов. Также оно заключается в поиске различной информации, которая помогает выявить риски. Собранные данные облегчают принятие решений по устранению этих рисков.
Приветствуем тебя, читатель Хабра. Возможно, тема непрерывной поставки и интеграции микросервисов покажется немного избитой, ведь сегодня любой идальго путем нехитрых манипуляций при помощи обучающих видео может натравить Jenkins/TeamCity/GitLab (нужное подчеркнуть) на свой репозиторий и начать называть себя испанским доном. Вся соль, на наш взгляд, в тех шагах сборки, которые он для себя определит и какой смысл в них вложит. Не менее чем сама сборка важен процесс автоматизации контроля качества. В этой статье мы расскажем вам о том, что в этом вопросе сделали для себя мы, команда разработчиков всех розничных фронтов банка «Открытие».
В предыдущей статье мы поведали о том, как построили конвейер, который непрерывно поставляет релизы на продуктивную среду без страха разломать ее. Одним из факторов, позволяющих нам это сделать, является контроль обратной совместимости через версионирование контрактов, который мы описали в статье. Но этого далеко не достаточно. Важнейшими шагами сборки мы считаем прохождение автоматизированных и ручных этапов контроля качества, которые и позволяют нам поставлять изменения быстро и без страха.
Рассмотрим конкретный пример.
В момент, когда триггерится сборка, например, когда разработчик сделал коммит в свою ветку, запускается процесс, который выполняется специально написанными скриптами и утилитами. Этот процесс состоит из нескольких обязательных шагов. Ошибка в любом из них приводит к полному падению всей сборки. Ну и, само собой разумеется, шаги расположены в таком порядке, чтобы сужать воронку потенциальных проблем. Если Quality Gate предыдущего этапа не пройдет, то на проверку следующего уже можно не тратить ресурсы.
С одной стороны, “Постоянство не заслуживает ни похвал, ни порицаний, ибо в нем проявляется устойчивость вкусов” (с) - зачеркнуто “Привычка - страшная сила”. Но с другой, когда ты выпускаешь цифровые продукты, такая ригидность часто ведёт в тупик. В данной статье хотим рассказать, почему мы пошли на риск и решились перетаскивать с привычного инструмента тысячи тест-кейсов, и что из этого вышло.
Даже правильно выбранная TМS нуждается в кастомизации. Я, Марина Каприз, занимаю должность заместителя руководителя Блока обеспечения качества и выпуска изменений ПО в ООО «РСХБ-Интех», расскажу, как в Россельхозбанке происходил переход к автоматизированной системе управления тестированием.
Здорова, Хабрчане!
Недавно мне на глаза попадалась публикация на Хабре про сервер взлома паролей с кучей GPU.
Ссылку я добросовестно где-то профукал, но помню, что в статье говорилось про феноменальную скорость перебора паролей на этом «девайсе». Что 8-значный пароль по полной раскладке клавиатуры и всем регистрам ломался чуть ли не за 5-10 секунд, аж GPU нагреться не успевали.
Вот тут-то меня и посетила мысль: а как вообще при современных вычислительных мощностях оберегать свои пароли от компрометации?
Собственно, и решил поделиться двумя методами, которые использую лично я:
1) Парольная фраза;
2) Двойной слепой пароль.
Привет! Меня зовут Ольга Ермолаева. Я работаю в тестировании с 2008 года. Сейчас руковожу департаментом качества в компании «Инттерра» и помогаю студентам на курсе для тестировщиков в Яндекс.Практикуме в качестве наставника.
Все, кто работает в IT-сфере, когда-то задавались вопросом, как найти первую работу. Ведь все работодатели требуют опыт, но никто не говорит, где его взять.
Начинающие программисты пишут свои pet-проекты, выкладывают на Github и добавляют ссылку в портфолио. Дизайнеры могут показать свою страницу на Behance или Dribble. Но что делать начинающим тестировщикам?
Можно пойти на платные курсы и приобрести учебный опыт, но его не всегда бывает достаточно для получения желаемой работы. Можно самому писать тестовую документацию, проводить тестирования, оформлять баги, но не факт, что итог будет приемлемого качества, потому что нет обратной связи.
В статье я поделюсь с вами одним из вариантов решения этой проблемы.
В последние несколько лет я часто задумывалась о том, что означает качество. У меня были и лекции на эту тему, и дискуссии с различными людьми. Недавнее обсуждение в LinkedIn направило мои мысли в новое русло: я начала рассматривать взаимосвязь тестирования и качества. Это моя первая (из двух) заметка с мыслями о тестировании. Впоследствии я опубликую как минимум одну статью, посвященную качеству.
Что такое тестирование?
Выкорчевывая сорняки в саду (очень неблагодарное дело, тем более что они отрастут завтра, если их не выдергивать с корнями), я начала проводить различные аналогии с этим процессом в контексте дискуссии о тестировании и управлении качеством. В той дискуссии был высказан следующий тезис.
Привет всем. Меня зовут Таня. Я автоматизирую тесты на Go уже около года, до этого занималась 4 года автоматизацией на Java.
В этой статье расскажу:
- Как писала интеграционные тесты на Go + Allure
- С какими проблемами столкнулась
- С какими библиотеками и инструментами работаю
Автоматизация тестирования – неотъемлемая часть процесса обеспечения качества. Мы в нашей практике чаще всего разрабатываем тесты для веб-, мобильных приложений и API, но сегодня хотим рассказать о более редком направлении – тестировании десктоп-приложений.
Кратко рассмотрим подходы, инструменты, технологии и «грабли», на которые можно наступить при выполнении этой задачи. Статья будет полезна специалистам, которые хотят попробовать автоматизировать ежедневную монотонную работу, а также коллегам по цеху в сфере автоматизации gui-тестирования – как начинающим, так и разработчикам с опытом.
Встречали ли вы баги, где было недостаточно информации для понимания про что это? А тикеты, в которых было сложно найти нужную информацию, хотя где-то она все-таки есть? Кажется, команды сами усложняют себе работу не используя стандарт заведения тикетов-багов. И я решила поделиться шаблоном, который используем мы.
Меня зовут Иванов Александр, я тестирую приемники цифрового телевидения. В статье расскажу о том, как наша команда GS Labs набралась смелости и сменила неудобный и дорогой TestRail на новый инструмент управления тестированием. Я описал процесс поиска TMS и переезда тестов и автотестов, настройку нового инструмента под себя, а также рассказал о том, как мы тестируем ТВ-приемники и их программное обеспечение.
Этот, казалось бы, глупый вопрос задают с завидной регулярностью. Казалось бы уже давно все должно быть понятно, но нет.
Disclaimer: данная статья написана с учетом опыта разработки в определенной (хоть и самой массовой) сфере ПО, а именно e-commerce. В других сферах правила игры могут разительно отличаться.
Я работал в тестировании 3 года, в автоматизации 7 лет, и в разработке - все оставшееся время, и вскоре я буду выступать на Национальной Конференции по Тестированию в Великобритании с ответом на этот вопрос. Но конференция еще не скоро, а многим, видно, интересно узнать ответ уже сейчас.
Эта статья является переводом статьи из блога Uber. Обычно мы в Qameta Software не занимаемся переводами, но мимо этой статьи пройти не смогли. Хороший и исчерпывающий материал о том, что такое flaky-тесты, какие они бывают и как с ними справляться (с некоторыми проявлениями). Часть материала, посвященную переезду Uber с микросервисов на монорепо я опустил, оставив только то, что напрямую связано с отработкой flaky-тестов.
Юнит-тесты лежат в основе любой Continuous Integration (CI) системы. Они позволяют обеспечить контроль над качеством кода при высоких темпах разработки, предупреждая инженеров о багах в новом коде и регрессии в кодовой базе. Кроме того, они снижают стоимость разработки за счет обнаружения ошибок на ранних этапах. Именно поэтому построение стабильной и работающей тестовой инфраструктуры является одним из базовых требований для любой крупной разработки.
К сожалению, flaky-тесты осложняют жизнь тем, кто это требование пытается выполнить. Давайте считать, что мы будем принимать тест как flaky если на любых двух воспроизведениях он возвращает разные результаты: прошел или упал, — без изменения кода. Такие тесты чаще всего возникают в результате одной из двух причин: недетерминированность на уровне кода (порядок исполнения тредов и другие сложности с многопоточностью) или неоднородностью окружений, в которых выполняется тестирование (на одной машине все работает хорошо, а на CI-сервере тесты падают).
Давайте рассмотрим простой пример, на котором будет понятно, откуда у проблемы ноги растут:
У Филиппа Кросби заслуженная репутация лидера в вопросах качества в обрабатывающей промышленности, он написал множество книг о качестве в период с 1968 по 1999 год. Среди его известных и цитируемых работ — «Качество бесплатно», «Ноль дефектов с помощью предотвращения» и «4 абсолютных принципа качества». Хотя Кросби говорил об этих темах в контексте компаний с производственными линиями, его уроки часто без изменений можно перенести на разработку ПО.
После участия в Твиттере во многих обсуждениях работ Кросби и прочтения некоторых его книг, я написал эту статью, чтобы передать на более глубоком уровне мои мысли о «4 абсолютных принципах качества» Кросби из его книги «Качество бесплатно». По моему мнению, эти четыре принципа поддерживают дискуссии о концепции отсутствия дефектов и качестве без затрат.
Примечание: у Кросби много хороших работ! Эта заметка не критикует его творчество. Она подчёркивает, как я использовал идеи Кросби и применил их в контексте моей работы с программным обеспечением. Вы можете согласиться со мной, а можете не согласиться. И это нормально. Я лишь делюсь своими знаниями и взглядом на мир качества в моём представлении.
Четыре абсолютных принципа качества
1. Качество определяется как соответствие требованиям.
2. Способ обеспечения качества — предотвращение, а не оценка.
3. Стандартом работы должно быть Отсутствие Дефектов.
4. Мера качества — цена несоответствия, а не индексы.
Исследователь безопасности обнаружил ряд ошибок, позволяющих взламывать банкоматы и широкий спектр терминалов продаж по-новому — взмахом телефона над устройством для чтения бесконтактных банковских карт. К старту курса Этичный хакер делимся переводом статьи о возможностях, которые открываются при эксплуатации обнаруженных уязвимостей, о том, что делал автор, чтобы обнаружить их и о том, как отреагировали производители банкоматов.
Важно выстроить процесс работы с автотестами, требующими поддержки и особенно с нестабильными(flacky) тестами. Если сразу не уделять должного внимание к автотестам доверие к ним упадет и в конечном итоге упавшие тесты будут полностью игнорироваться
Обычно мы делаем это так:
