Тестирование IT-систем *

Я решил потестировать статический анализатор Java-кода IntelliJ IDEA и с его помощью проверил проект The Chemistry Development Kit. Здесь я приведу некоторые ошибки, которые я нашёл. Думаю, что часть из них характерна для Java-программ в целом, поэтому могут быть интересны.

The Chemistry Development Kit — это Java-библиотека с открытыми исходниками для решения задач хемоинформатики и биоинформатики. Когда я занимался биоинформатикой, мы активно её использовали. Проект разрабатывается уже более 20 лет, у него десятки авторов, и качество кода там очень неровное. Тем не менее, в проекте имеются юнит-тесты, а в pom.xml прописана интеграция с анализатором покрытия JaCoCo. Вдобавок там настроены плагины целых трёх статических анализаторов: FindBugs, PMD, Checkstyle. Тем интереснее проверить, какие же предупреждения остаются.

• Введение (Krste Asanović) видео слайды
• Тулчейн RISC-V (Andrew Waterman) видео слайды
• SoC-генератор RISC-V “Rocket Chip” в Chisel (Yunsup Lee) видео слайды
• Структура программного стека RISC-V (Sagar Karandikar) видео слайды
• Отладка на RISC-V (Albert Ou) видео слайды
• Портирование нового кода на RISC-V с OpenEmbedded (Martin Maas) видео слайды
• Окружение тестирования RISC-V (Stephen Twigg) видео слайды

Вместо вступления

Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.

Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задач. При этом не всегда получается отказаться от старых обязанностей. Приходится совмещать две роли на проекте. Так и я, имея опыт в тестировании и аналитике, дополнительно стала получать задачи руководителя проекта. Со временем я полностью перешла в управление проектами.

В этой статье я делюсь наблюдениями и выводами. Как в одном человеке конфликтуют привычки тестировщика и обязанности руководителя проекта? С какими проблемами приходится сталкиваться? Какую пользу можно извлечь при таком переходе? Если хотите получить ответы на эти вопросы, добро пожаловать под кат.

На Хабре совсем нет информации про TestContainers. На момент написания этой статьи, в поисковой выдаче есть анонсы наших же конференций, и всё. Между тем, в проекте на GitHub у них уже более 700 коммитов, 54 контрибьютора и 5 лет истории. Похоже, все эти пять лет проект тщательно скрывался спецслужбами и НЛО. Настало время выйти из тени на свет.

Чукча — читатель, а не писатель. Поэтому, вместо написания своего текста, я попросил разрешения на перевод соответствующей статьи из блога RebelLabs.

Итак, здесь мы поделимся парой слов о наимоднейшей Java-библиотеке для интеграционного тестирования — TestContainers. Кроме этого, будет немного о том, почему интеграционное тестирование настолько важно для ZeroTurnaround и их требования к интеграционным тестам. И конечно, будет полнофункциональный пример интеграционного теста для Java-агента. Если кто-то никогда в глаза не видел код Java-агента, то сейчас самое время. Добро пожаловать под кат!

1. Тестирование CSS не имеет смысла, так как это декларативный язык, а его результатом является сверстанное изображение страницы, которое можно оценить лишь визуально.
2. Протестировать CSS можно с помощью снятия битмапов с сгенерированной страницы и сверка ее с эталонным изображением. Для этого даже есть некоторые инструменты.
3. Нашлась некоторая библиотека CSS-Unit.

Статья Галины Шайдуровой

Психология тестировщика: почему критическое мышление – это суперсила

Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.

Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъяренных пользователей.

Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберем, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход, и как нестандартное мышление спасает проекты (и иногда ночной сон).

Пандемия сделала свое дело, и мы уже не представляем рабочий день без ВКС. Спрос на сервисы видеоконференцсвязи продолжает расти, западные вендоры остались позади, а от российской разработки разбегаются глаза. В тренде – унифицированные коммуникации (UC):  производители стремятся сделать единое решение, в котором будет и ВКС, и мессенджеры, и интеграция с другими корпсистемами. На деле - у каждого свои сильные и слабые стороны, которые нужно учитывать при выборе системы. 

В этом обзоре мы собрали основные представленные на рынке продукты, сравнили функционал и варианты реализации. Это результаты тестирований и труда команды, специализирующейся на внедрении ВКС больше 17 лет. Под катом вы найдете сравнительные таблицы и наши рекомендации по выбору и внедрению. 

Привет! Меня зовут Катя, я тестировщик.

Когда я только пришла работать в 2ГИС, я занималась тестированием фронтенда карты. Всё было чётко и понятно, ведь был один проект. Но когда я переключилась на тестирование бэкенда, ситуация радикально изменилась. В работу команды, связанной с пользовательским контентом, входило 30+ проектов разного размера и приоритета, с разным уровнем покрытия тестами. Из общего только, что все проекты разработаны на Go, а автотесты — на Python.

Ситуация была настоящий «омагад🫣». Даже опытным сотрудникам было сложно ориентироваться в каждом проекте, не говоря о новом члене команды. Это приводило к неприятным последствиям. Например, перед внедрением фич мы часто не могли прогнозировать время тестирования и оценивать необходимые усилия. Бизнесу давались одни сроки, но на практике они сдвигались из-за неожиданно обнаруженных проблем. В результате доставка фич на бой затягивалась или срывались сроки, нарастал техдолг, и вся эта вакханалия повторялась по кругу.

Расскажу, что мы сделали, чтобы навести порядок. Это история о том, как системный подход упростил жизнь нашей команде, ускорил тестирование и повысил прозрачность процессов. 

Привет! Меня зовут Денис Веренцов, я Android-инженер из команды Emcee, это технопродукт Авито. В статье я расскажу, как можно развернуть облачную инфраструктуру для запуска нативных автотестов Android-приложений на основе разработанного нами решения.

Статья будет полезна тем, кто хочет организовать инфраструктуру для запуска тестов, но не обладает подходящим для этого «железом». Материал также будет интересен тем, у кого есть желание попробовать технологию Emcee в деле.