А кто-то у себя использует Zero Bug Policy?
Отличный подход, который позволяет сохранить беклог и голову в порядке. Меньше страданий от постоянно растущего количества багов, которые никто не фиксит, но которые постоянно фигурируют в отчетности, как "показатель зрелости продукта".

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

А ведь там все просто: если баг есть и мы оценили его как критичный - значит мы его берем и чиним, а не маринуем в беклоге. Если некритичный (или кажется таковым в настоящее время) - значит просто фиксируем проблему, обозначаем его как “won’t fix” и забываем про него до того момента, когда его критичность меняется (похожий запрос от клиента, новый сценарий эксплуатации проблемы и тдтп).

Потому что история “баг заводим, складываем в сундучок в надежде на будущие времена, когда появится возможность его фиксить” - это фантазия радужных единорогов.

Статья по этой теме с рекомендациями по переходу на ZBP

#testing #процессы

< "This is hard (or slow) to test" typically also means hard (or slow) to use, learn, interpret, understand, or fix. In other words: a bug. > Michael Bolton
#testing #quality

“Тестирование никогда не покажет того, что ошибок нет. Только то, что они есть.”

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

Поэтому тут без ссылки на автора, вдруг потом мне припишут 🫠
#мысли_вслух #testing

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

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

#классика #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