"Разрабатываем без нянек" (с) или как минимизировать участие тестировщиков в вашей работе

ЗЫ умел я раньше в почти лонгриды. Там, при желании, можно найти ответ на вопрос, смогут ли разработчики тестировать.

#классика #testing

Че-то я как-то излишне серьезно и по-менеджерски жестко начал эту неделю.
Отдыхаем... Наслаждаемся классикой, но... читаем между строк.

"Никакой учености тут нет, сударь. У моего кума была кошка, которая, извините, огурцы ела. Недели две полосовал кнутищем, покудова выучил. Заяц, ежели его бить, спички может зажигать. Чему вы удивляетесь? Очень просто! Возьмет в рот спичку и — чирк! Животное то же, что и человек. Человек от битья умней бывает, так и тварь".

Антоша Чехонте (1883)

А вы говорите, разработчик не может тестировать…

#мысли_вслух #байки #testing #настроение_дня

Недавно в комментах обсуждали о причинах того, как история с CrowdStrike (когда в мире легла виндовая инфра, около 8.5млн компов) пролезла в прод.
А вот и ответ (оригинал, и на русском, тем более оригинал из РФ еще и недоступен): тула типа виновата.

И самая мякотка, что они будут делать, чтобы не повторять:

Тестировать, млин 😂

#testing

Тесты с деньгами, да еще и в продакшене 😱

Тему можно долго мусолить, закатывать глаза и крутить пальцем у виска, но я абсолютно уверен, что хорошо сделанные тесты в проде - это то, что нужно всем. И не надо этого бояться.

Почитайте, кто не видел, и это тоже "Тестирование в продакшене - миф или реальность?"

#testing #тесты_в_проде

10 признаков, что вы не подходите для работы тестировщиком:
1. Вы нервничаете из-за глючного ПО
2. Вы тестируете не зная ожиданий бизнеса
3. Вы устаете от объяснения того, как воспроизвести ошибку
4. Вы не читаете блоги, книги и не посещаете конференции по тестированию ПО
5. Вы стыдитесь своей роли в проекте
6. Вы знаете, как проверять, но не знаете, как исследовать
7. Вы не в курсе технических аспектов IT
8. Вы не любите общаться
9. Вы не знаете о жизненном цикле разработки приложений
10. Вы не можете забыть о найденных дефектах и страдаете, если их не исправляют

ЗЫ это вам немного романтики из прошлого... Эти советы давно уже игнорируются многими

#testing

Testing in prod is not trolling. It's the only way to confirm that your code is working, and *how* your code is working.

(тутъ)
И снова про мой любимый продакшен... Для адептов "руки прочь от прода".
#testing #quality #тесты_в_проде

1997 год
Столько времени прошло, а эти заблуждения и ошибки все так же популярны.

Classic Testing Mistakes

... the testing team is responsible for assuring quality...

... the purpose of testing is to find bugs...

... reporting bug data without putting it into context...

... starting testing too late...

... using testing as a transitional job for new programmers...
... recruiting testers from the ranks of failed programmers...

... programmers can't test their own code...

Эта музыка будет вечной... Ясно и бесповоротно. 😏

#testing #quality

... my testing expertise became less valuable at the end of the cycle and much more valuable at the start.

The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end because less bugs would emerge as a result.
...
I’ve had a lot of discussions this year around the role of the tester. Let’s put that aside from now and start thinking about the role of a software developer.
A software developer needs to be able build a product with confidence that it does what it’s expected to do.
Knowing how to do that at a basic level should be critical to the role of a good software developer.
For that reason, we need more testing in software development. And it needs to be done by the people building the product.

Forget developers in test, we need testers in development (2013)

#testing #quality

Вчера смотрел графики количества багов по командам за год (не спрашивайте меня, как и для чего они появились).
По высоте столбиков явно прослеживаются моменты моих ZBP-обострений (особенно после первого).
Интересно еще и то, каким образом команды перешли на текущий формат работы с ZBP: до банального просто, но не тем способом, что мне нравится. Грустно - да, зато эффективно (визуально во всяком случае).

ЗЫ одно из последний обострений было запротоколировано тут. Вчера после вечернего поста, вспомнив про высоты столбиков, в очередной раз подумал, что отчеты по багам и тестировщики - это неразделяемая история. Одно без другого просто не живет.

#мысли_вслух #testing

Немного 10-летней классики на тему "зачем нам тестировщики, если разрабы сами тестируют свой код"

• Нужны ли тестировщики, если разработчики пишут тесты?
• Thinking about No Testers
• When Programmers (and Testers) Do Their Jobs

Самое интересное, все заметки вышли +/- в одно время (но я был первый 😃), видимо ретроградный Меркурий 🥸.

PS забавно, что мой коммент к моему посту с указанием заметки с "About 98 Percent Done" (2я ссылка выше) привел к сессии тестирования Disqus, который, похоже, на тот момент времени не имел тестировщиков. Получилось весело 🤭

#классика #testing

Что на самом деле стоит за "оцените тестирование":

Сколько времени нам нужно, чтобы узнать все, что нам нужно знать о чем-то, о чем мы пока мало что знаем?

#testing чужие #мысли_вслух и #классика из древних интернетов

API #testing
А какое покрытие у вас? 🙂

Знаю, что никто из новоподключившихся "назад" в ТГ-ленте не смотрит.
Тем не менее, в закрепах есть сообщение со всеми тегами, которыми промаркированы все (ну или 99%) сообщения в этом канале.
.
Делал конечно для себя, но вы тоже пользуйтесь :)

Старое, но интересное исследование про проблемы с обработкой ошибок в коде: 92% критических отказов распределенных систем происходят из-за неправильной обработки ошибок.

Слайды, общая страница

#testing #tech_read

Банальная категоричность.
Думать “как будем реализовывать фичу” всегда должно быть равно “как будем делать” + “как будем проверять”.
Да, вот так вместе.
Да, не по отдельности разработчики и QA (aqa-люди, как же я вас не люблю, терпения мне).
Да, если реализация (еще раз = новые продакшен код + тесты) не соответствует DoD, значит мы непонятно, что релизим.

И значит, если разработчики написали код, но его никто (включая их) не проверил - значит мы написали бесполезный код, который работает стохастическим образом.
Внимание вопрос - зачем нам нужен такой код?

Не хотите писать автотесты - проверяйте руками. И да, автотесты - это не только юниты.
Не хотите проверять свой код, думая, что для этого есть тестировщики - подумайте, действительно ли вы хороший специалист.
ЗЫ Да, можно релизить без автотестов, чего уж там. Только не надо переводить стрелки на автоматизаторов.

#мысли_вслух #test_automation #testing #holywar

Каждый раз читая (даже не в первый раз) статьи "X vs Y" ловлю себя на мысли "хмм, а я по-другому думал".
И потом, спустя N-лет, снова тот же эффект.
Вот и в этот раз, "о, как...".
"Smoke test VS Sanity test"
Понапридумывают терминов, а потом все путаются 🙂

А какие-то термины со временем просто вырождаются. Это как с моками произошло, теперь все заглушки у всех - моки.

#testing #мысли_вслух

Про определения (термины)
Иногда ты долго работаешь или пользуешься чем-то даже не задумываясь, как формально описать эти действия/паттерны/подходы. Просто пользуешься и все.
А меж тем для многих вещей уже давно существуют определения. И часто твое мнение о них могут спросить, например на собесах 😉

И важно скорее не то, знаешь ли ты его дословно, а как понимаешь суть.

Нужны ли определения по работе? Скорее нет, чем да. Показывает ли это твой кругозор и умение формализовывать свои мысли используя общепринятые и понятные определения - да.
Тут правда есть нюанс - не факт, что это определение знает тот, кому ты свои формализации рассказываешь. 😃

Спонсор заметки: "новостная лента соцсетей" и определение "оракулы тестирования" (это была первая из прочитанных мной статей по теме ).
Тестировщики конечно в курсе (правда ведь? "мем с падме"), а остальным может быть интересно, добавить себе энциклопедических знаний 🙂

ЗЫ у меня есть универсальное определение на все, что не знаю: это "опыт и чуйка". Но не советую им пользоваться на регулярной основе.

#testing

Недавно на митапе, в одном из моментов обсуждали про то, насколько ИИ используется и помогает сейчас в тестировании. Из всех присутствующих только у одного из спикеров что-то активно делается в этом направлении в рамках компании.

Тому много разных причин, но сейчас не про это.
В целом люди пробуют и я думаю, что спустя какое-то время ИИ будет тестировать ИИ (пока непонятно с каким успехом).
Но, возможно, ии-шка действительно поможет шире использовать инструменты и подходы к написанию автотестов, которые сейчас несильно популярны из-за "стоимости" их использования.

The Testing Techniques We Couldn't Afford (Until Now)

Разработчики будущего будут оглядываться на нашу эпоху - на тот короткий промежуток времени, когда мы могли генерировать код с невероятной скоростью, но все еще проводили тестирование так, словно на дворе 2020 год, - и задаваться вопросом, о чем мы думали.

PS Я не так часто размышлял над этим вопросом в принципе, потому что все еще скептически ко всем этому отношусь: ибо вижу, как "весело" может поддерживаться код, который был написан тобой не вчера. Но видя, как та же ИИ может помочь "разбирать" старый код, может и не все так страшно?

#testing #ai

State of testing 2015 vs 2025 (простите, меня уже чуток тошнит от подготовки к собесам по сисдизу, решил занять голову чем-то другим, просто стало интересно)

Короче: ничего в глобальном смысле не поменялось, какие-то болтания туда-сюда (особенно если сравнивать 2013, 2015, 2023-2025) 😃.
А с учетом того, что это еще и разные люди отвечали, я бы даже сказал разные поколения, то выглядит как "С - стабильность" в отрасли.

Сами вопросы я не стал искать, но похоже они и методика обработки видоизменялись за эти 10лет (что логично).

Да в 2015 были модные фишки в виде Big Data Testing, Testing in Cloud и чуть больше Agile.
Сейчас больше про ИИ (рекомендую глянуть в доку, там интересно посмотреть по ИИ), а Agile поменьше (он скорее всего "трансформировался" и стал просто частью процессов "как все привыкли").

Состав участников опроса по job titles практически без изменений (из самых интересных позиций):
• лиды/менеджеры ~38%
• тестировщики ~35% (если объединить test engineer/tester в итогах 2025)
• автоматизаторы ~7%

Если принять голосовавших за срез отрасли тестирования в 2015 и 2025, то выглядит так, что лидов в отрасли что-то многовато, а количество автоматизаторов не растет (и слава Байту).
Но, в небольших компаниях автоматизаторов больше (2015) - до 12%. Отсюда можно предположить, что если хочешь двигаться в автоматизацию - лучше небольшие (типа 50-100 человек) компании, что в целом схоже с моими мыслями по этому вопросу.

Что касается покрытия автоматизацией, то как будто то на то и выходит: у 55% опрошенных, автоматизацией закрыто < 50% сценариев. И у 20% покрытие в районе 75%+
Кто-то даже декларирует полный отказ ручных проверок: 💪, ну или 🤡, тут уж кому как.

Важность программерских скилов неожиданно снизилась (снова ИИ-шка?), Ops тоже не в фаворе (видимо из-за того, что выросла отдельная ветка DevOps - Test/простите/Ops)

Зато в 2025 резко выросла важность коммуникационных скилов 🤔

В 2015 в вопросах были разные тестовые методики и собственно то, чем занимаются тестировщики, сейчас этого нет, но появились метрики и много про то, куда запихнуть ИИ.

Кстати, недавно обсуждали про TMS и то, что без них "нельзя": в 2015 65% пользовались Excel-ками (+вордом и почтой), как рабочим инструментом. Правда и TMS тоже было достаточно много.

PS но первые отчеты (2013, 2015 мне больше нравились, они больше именно про тестирование что ли).
Сами отчеты будут в комментах. Вдруг кому-то захочется глянуть 🙂

#testing #байки

Технические приемы для переписывания бека, чтобы не отломать фичу на проде:
- для API на чтение просто сравниваем то, что отдает старое и новое (Tap compare testing)
- для API на запись дублируем БД и дальше сравниваем состояние БД через API на чтение

Modernizing Reddit's Comment Backend Infrastructure

А что из этого переписывания получилось можно посмотреть на графиках.

#tech_read #testing