🟢Дайджест полезных материалов по тестированию🐞4-14 декабря
«В современном мире у меня выработался новый рефлекс. Когда кто-то, кого я не знаю близко, делится со мной отчётом, анализом или просто на первый взгляд вдумчивым текстом — первой реакцией у меня стало не верить, что он сам это сделал»
🛠TestEngineer
Делайте документацию минимальной, но достаточной.
Компании проигрывают не потому, что их инструменты слабы. А потому, что их взгляд слишком близорук.
Определения модульного и интеграционного тестирования не дают нам четких указаний, как их разграничить. Используются довольно-таки расплывчатые определения, что такое модуль/юнит и что такое компонент - и эти определения недостаточно конкретны.
➕Также
Почему именно интеграционное тестирование влияет на стабильность больших систем и на бюджет команды? Как снизить риск инцидентов, убрать хаос в микросервисах и ускорить выпуск обновлений? Мы собрали рабочие практики и инструменты, которые реально дают эффект.
Для масштабируемых продуктов автоматизация тестирования API играет критическую роль. Она позволяет быстро выявлять ошибки, поддерживать стабильность и обеспечивать высокое качество.
Топ-10 полезных и актуальных советов по тестированию юзабилити для начинающих от эксперта с 20-летним стажем
В мире разработки программного обеспечения популярна идея, что за тестирование отвечает вся команда.
Исходя из этого, некоторые люди встают на крайнюю позицию: раз уж тестируют все, специализированные тестировщики больше не нужны. Дескать, разработчики, или аналитики; или сами заказчики могут и сами выполнять тестирование.
Есть и противоположное мнение (что раздражающе часто исходит от самих тестировщиков): разработчики якобы не умеют тестировать, а потому каждая команда разработки обязательно должна иметь собственного тестировщика или даже целую команду тестирования.
Обе эти крайности — непродуманные и наивные. Это примеры того, что я называю «тирания слова всегда».
Глупо утверждать, что разработчики не умеют тестировать. В процессе написания продукта они постоянно что-то тестируют: пишут код, проверяют, работает ли он; если нет — чинят; если да — двигаются дальше. Разработчик не может стабильно писать полезный код, не проверяя хоть что-нибудь хотя бы время от времени. И всё же было бы опрометчиво полагаться на то, что у разработчиков всегда есть время, мотивация, стимул и нужный взгляд на вещи, чтобы полностью взять на себя весь объём тестирования.
Если вы выдаете чужую работу за свою — вас не будут уважать ни окружающие, ни вы сами. Если вам платят за умственный труд, а заказчик начинает подозревать, что умственным трудом у вас и не пахнет — у него пропадёт желание платить. Если вы шлете кому-то ворох идей и данных, а потом выясняется, что вы просто ввели короткий промпт, а потом вставили сгенерированный текст в файл — произойдёт как минимум одно из двух: либо результат понравится, и человек поймёт, что вас можно заменить ИИ, либо адресат не поверит содержанию и решит, что вы его просто заспамили.
В современном мире у меня выработался новый рефлекс. Когда кто-то, кого я не знаю близко, делится со мной отчётом, анализом или просто на первый взгляд вдумчивым текстом — первой реакцией у меня стало не верить, что он сам это сделал. Я автоматически обесцениваю работу людей, у которых нет репутации оригинальных мыслителей.
⚙️Хабр
В тестировании я уже 11 лет, занимаюсь построением процессов, внедрением практик качества, автоматизацией и развитием QA-организаций. Обладаю полным набором сертификатов ISTQB Expert Level Test Management, а всего у меня 9 ISTQB сертификатов от Foundation до Expert.
Набор задач обширный. Поэтому, на мой взгляд, для новичка в команде очень важен этап онбординга. Спустя год я хочу поделиться впечатлениями о первых трёх месяцах работы в компании. Расскажу об этапах онбординга в отделе тестирования, курсе молодого бойца и поддержке со стороны команды в течение всего периода.
Если вы когда-нибудь бывали на ИБ конференциях, то знаете этот ритуал. Бесконечные ряды стендов, много кофе, улыбок, разговоров и... обещаний. Обещания, что новое решение может то-то, что теперь нам что-то не грозит, что теперь оно «производительнее, выше, сильнее…». Да, иногда показывают железо, а чаще только интерфейс, но потом брошюры, каталоги и презентации. Мы тоже так делали, но в этот раз решили сделать по-другому. Если уж мы занимаемся тестированием, то давайте вместо разговоров об этом дадим людям возможность… потестировать тестирование.
Когда твой тестовый стенд разбросан по этажам, IP-адреса живут своей жизнью, а нужное устройство стабильно «гуляет» между кабинетами — это не инфраструктура, это квест. Три года назад я подключался к железкам по SSH и даже не знал, где они физически находятся. Сегодня всё иначе: у нас универсальная тестовая лаборатория, собранная как из конструктора LEGO — аккуратная, управляемая, с централизованной сетью, удалённым регулированием питания и мониторингом.
ИИ фактически обнулил модель «эксперта, который знает всё». Почему исчез поток джун-вопросов, куда делась токсичность и что теперь считается настоящей экспертностью — разбираю на примерах.
Безопасность Wi-Fi остаётся одной из тех тем, где одновременно сосуществуют мифы, неоправданные ожидания и огромное количество недопонимания. Кто-то уверен, что WPA2 и тем более WPA3 взломать невозможно, потому что «это же криптография». Кто-то считает, что всё решается набором трёх команд в Kali. И на практике обе позиции оказываются одинаково далеки от реальности. Wi-Fi — это не магия, не «сеть, работающая на духах», и не «непробиваемая защита». Это обычный протокол уровня 802.11, который живёт в открытом эфире и подчиняется вполне конкретной структуре пакетов, таймингов и встроенных процедур. Понимание этих процедур моментально показывает, что подавляющее большинство атак — не взлом, а закономерное следствие того, как устроено взаимодействие клиент ↔ точка.
Вы смотрите на дашборд: Average Response Time = 200ms. Клиенты довольны? Скорее всего, нет. Вы видите, что сервер загружен на 50%, и думаете, что выдержите рост нагрузки в 2 раза? Математика говорит, что вы упадете гораздо раньше.
Разбираться в Swift, Kotlin или Flutter по‑прежнему не придется: вместо этого используем конструктор. На примере посмотрим, как сайт превращается в приложение, какие настройки важны, чтобы оно адекватно работало и выглядело хорошо на Android и iOS. И как довести этот результат до состояния, когда не стыдно использовать.
Но хотелось всё-таки на Хабре ответить на вот эту вот разочаровывающую статью: Безумный эксперимент: запускаем GTA V на Pentium 4 — возможно ли это? Почему разочаровывающую? Во-первых, «автор« не довел дело до конца. Во-вторых, в той статье много неточностей, бывает путаница, странные картинки, да и вообще кажется, что это была какая-то выдумка… Вернее, казалось бы несколько лет назад. А сейчас даже выдумывать ничего не нужно, за тебя всё сделает нейросеть. Ну а я же решил повторить этот «безумный эксперимент» своими руками.
Концом истории случился массовый отзыв дефектных чипов и многомиллионные убытки на их бесплатную замену. Работники Intel в назидание получили вот такой сувенир, где под слоем эпоксидки покоился кристалл того самого процессора. Хотя этот просчёт сам по себе никого не убил и ничего не уничтожил, удар по репутации был сокрушительным (хотя, конечно, и не фатальным).
Если вы работаете с монорепозиторием — особенно большим — то мой рассказ покажется вам знакомым. Вы либо видите эти проблемы в своих проектах, либо уже боретесь с ними. А если ваш репозиторий пока только растет, то со временем и ростом проекта вас ждут те же сложности, ведь это закономерный этап развития любого большого проекта.
👀Посмотреть
The episode centres on real-world examples where systems get it wrong. Parcels delivered to the wrong house because the scanner says so, cars confidently reporting incorrect speed limits, and checklists that are followed perfectly while the actual problem sits right in front of you. Ady shares a classic server-room story about power cables and blind checklist following, while Demi reflects on teaching computers through explicit instructions and how easily assumptions creep in when context is missing.
- How to Report AI-Assisted Work ⏱️30 минут
James and Michael discuss their system for reporting on the status of work they have done with the help of AI.