Как справедливо подметил один коллега в чатике QA juniors, это первая статья про "Как я стал тестировщиком" без упоминания Савина и Куликова

https://habrahabr.ru/company/yamoney/blog/344784/

​Нактнулся на интересный mindmap с виденьем будущего индустрии тестирования ПО.

Для начинающих тестировщиков эта проблема особенно актуальна. Мне тоже пришлось пройти через неё. На вопрос "на сколько детальным должно быть тестирование" нет правильного ответа, но можно и нужно найти некоторый баланс между "слишком глубоко" и "слишком поверхностно".
Вся соль понимания этого баланса заключается в том, на сколько хорошо ты чувствуешь внешние индикаторы: сообщения от заказчиков/клиентов, мнение команды и мнение менеджера.
Да, всегда стоит стремиться к отсутствию багов в продакшене. Всем, кроме заказчиков, понятно, что это невозможно. Дело в том, что исправление некоторых багов требует больших трудовых затрат, и не имеет никакого экономического смысла. Хотя, если у вас какой-то медицинский или банковский продукт, то вы просто обязаны копать глубоко, особенно по сравнению с каким-нибудь, например, веб-приложением. В индикаторе Сообщения от заказчиков/клиентов действует примерно такое правило: ты нашел много багов, но их никто особо не фиксит или пользователи не сообщают о проблемах, то ты сильно закопался. Если нашел мало багов, а с продакшена баги заводят вагонами, то, очевидно, стоит сильнее углубиться.
Мнение команды. Если коллеги разработчики тестируют продукт самостоятельно или на стендапах ставят вопросы о качесвте тестирования, то тестирование слишком поверхностное. С другой стороны, если команда спрашивает есть ли у тебя более важные задачи или пытается как-то ограничить тестирование,то ты слишком глубоко закопался.
От менеджера. Как правило, менеджер человек не молчаливый и сразу тебе скажет о том, что у тебя проблемы с подходом к тестировании: мало - добавить, много - ограничить и дать более важные таски.
Это всё не правила, но сигналы чтобы сделать выводы о своей работе, о своём подходе. Всё зависит от контекста, от заказчика и от продукта. И по-хорошему, наша задача добиться такого баланса, при котором мы будет тестировать чуть глубже, чем требуется на проекте. Так мы с одной стороны сохраним свои силы и время для более важных задач. С другой – наша команда, менеджер и заказчик/клиенты будут довольны отсутствием багов и ожидаемым поведением продукта.

​Поделитесь этим котиком с друзьями, если вам нравится мой канал @protesting

У меня есть гугл табличка, в которой я собираю полезные ссылки по теме тестирования программного обеспечения. Немного привел её в порядок, и хочу поделиться с вами.
Она не идеальная, особенно в плане моей оценки "полезности" статьи. Но, мне кажется, многим на старте карьеры она будет полезна.
🚧 Ещё я буду очень благодарен, если у вас есть закладках полезные ссылки и вы скините её мне. Я её сразу добавлю в табличку.

https://docs.google.com/spreadsheets/d/1T1rbCNwSpE6yXgIa6pUcu0VyyQGvZ92Iog2zU3SUl5U/edit?usp=sharing

​Если вам однажды понадобится скачать чьи-нибудь Stories из Instagram, вот отличное расширение для Chrome:

https://goo.gl/Yb9mok

Когда уже мы разделим календарный год от финансового!?
Каждый раз под конец года начинается этот ахтунг с дедлайнами. Одной рукой проект сдаешь, другой в очереди за мандаринами стоишь. Доколе🔥
За эту неделю у меня накопилось более 700 непрочитанных сообщений в телеграме: чаты и каналы. Будет чем заняться 2го числа 😅

Надеюсь вы, как и я, напрягали булки не зря и ваши проекты сданы, а заказчики довольны 🎄🎁

В конце декабря на хабре вышла, на мой взягляд, очень интересная статья о том, как человек решил проверить секурность крипто-кошельков. Статься длинная, минут на 12-15, но оно того стоит, так как там описан реальный UX, а не домыслы.
Короче, если вам хоть немного интересны темы криптовалют или безопасности web-сервисов обязательно стоит прочитать

https://habrahabr.ru/post/343152/

Если вам нечем заняться на выходных, то посмотрите отличный новый сериал https://www.kinopoisk.ru/film/tma-2017-1032606/, который хоть и похож на Stranger Things завязкой истории (мухосранск, пропавший пиздюк, СВЕРЗХЗХЗЪЪЕСТЕСТВЕННОЕ), но на деле по атмосфере, сюжету и временным петлям гораздо круче.

Один только саундрек из эмбиента, немецкого и скандинавского попа с вкраплениями Lorde, Apparat и alt-J чего стоит.

На http://quality-lab.ru вышла очередная крутая статья про баги, которые никогда не будут исправлени и как с этим жить. Дело в том, что все продукты получаются неидеальными. То есть с багами! Некоторые из них никогда не будут поправлены. Произнесите это слово по слогам, чтобы почувствовать всю обреченность и окончательность этого вердикта: ни-ког-да!

Тип 1. Баги, связанные с устаревшими устройствами и программами.
Если вы делаете продукт в 2018 году, нет смысла добавлять специальную верстку для Internet Explorer 6 или подстраиваться под iPhone 4. Конечно, это почти абсурдные примеры, но человек в здравом уме вряд ли будет поддерживать старое устройство или древнюю версию браузера, так как их аудитория уменьшается с каждым днем и однажды просто исчезнет. Здесь стоит сделать оговорку: все же не стоит отсекать идею пофиксить подобный баг сразу. Все нужно соотносить с полезностью для пользователей и вашими затратами. Например, если вы потратите на фикс 10 минут, а «спасибо» вам при этом скажут десятки тысяч человек, нужно браться за работу. А вот тратить 20 часов для одного пользователя бесплатной версии, который отписался под одним из ваших постов на Хабре годичной давности, – это непродуктивное решение.


Тип 2. Баги в сторонних компонентах.
У программиста может не быть компетенций для исправления ошибки, если в его решении используется сторонний компонент. Зачастую это классическая проблема «черного ящика»: три дырки на входе и три дырки на выходе, код закрыт, лицензия проприетарная. Но даже открытый исходный код не гарантирует того, что проблему в принципе можно решить. Например, разработчики ПО на основе OpenOffice не правят баги в OpenOffice, потому что знают, что просто не смогут потом его собрать. Впрочем, все это, как правило, относится к компонентам, у которых закончилась поддержка. Другой вариант – отсутствие компетентных людей в команде. Баг в компоненте – это не приговор, если у вас есть возможность связаться с разработчиком, и при этом четко определены границы зоны ответственности между тестировщиками и программистами.


Тип 2 и 3/4 . Баги, связанные с технологией.
Представим ситуацию: создавая веб-приложение, вы имеете дело с ограничениями, которые накладывает браузер (например, с неспособностью распознать текущую раскладку клавиатуры). Вот реальная ситуация: в текстовом процессоре Microsoft Word язык проверки орфографии меняется в зависимости от того, в какой раскладке вы набираете текст, в то время как в онлайн-редакторе вам придется задать язык проверки орфографии вручную. Таким образом, пытаясь вести себя как пользователь Microsoft Word (что в общем-то логично), пользователь онлайн-редактора испытает неудобства, а вы не можете ему помочь, так как находитесь в естественных границах технологии. Но, как и в случае с багами в компонентах, здесь есть оптимистичный сценарий. Проблема, которая не может быть решена в рамках конкретного продукта, может решиться сама по себе по мере развития технологии. Да, сейчас браузеры не интегрированы с системой достаточно тесно и поэтому не имеют доступа ко многим системным ресурсам, но кто возьмет на себя смелость сказать, что так будет всегда?

Как с этим жить?
Продуктов без багов не бывает, бывает лишь различная степень толерантности к ним. Последняя зависит от сферы, в которой функционирует ваше ПО. Например, если вы пишете код для бортового компьютера космического корабля, логично предположить, что толерантность к багам будет нулевой. Тем не менее, когда на гитхабе опубликовали исходный код программы для бортового управляющего компьютера «Аполлона-11», пользователи сервиса нашли места, которые можно было поправить. Пусть это были баги уровня опечатки (и расширения для спасения Мэтта Деймона, но их мы в расчет не берем), но они присутствовали.

Наличие незакрытых тикетов в багтрекере – это не свидетельство некомпетентности и не трагедия. Да, здесь автор немного драматизирует, прочитав на stackexchage трэд о том, как стать zero-bug programmer (ответ: не писать код или найти себе плохих тестировщиков).

Более того, если у вас много неисправленных багов, вы знаете о них и приняли осознанное решение не вносить правку – это здорово! Вы знаете ваш продукт и готовы ко всему!


Судьба бага
Этика и профессиональная гордость подсказывают нам, что необходимо фиксить все баги, которые мы можем найти, но реальность оказывается сложнее. Есть два типа багов:
• баги, которые нельзя не поправить;
• все остальные.

Во втором случае вам всегда придется принимать бизнес-решение, руководствуясь как минимум двумя вещами – здравым смыслом и собственной выгодой.

В эссе основателя Source Gear Эрика Синка My life as a Сode Economist автор предлагает задавать себе по поводу каждого бага четыре вопроса:

1. Степень критичности: когда этот баг повторяется, каков его негативный эффект и насколько он критичен для системы?
2. Частота: как часто он повторяется?
3. Цена: сколько усилий и ресурсов нам потребуется, чтобы поправить этот баг (пока мы правим баги, мы не делаем что-то новое)?
4. Риск: чем мы рискуем, когда правим этот баг (любое изменение кода – это риск)?

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

Привет,
этот канал я создал, чтобы рассказать о своём профессиональном опыте в тестировании, об интересном и полезном. Не то чтобы я рассказал всё, что знал. Нет. Но и писать сейчас об этом почему-то желания нет. Возможно, я вернусь к теме этого канала позже, но не сейчас. Извините, если не оправдал ваших ожиданий.

Несколько месяцев назад я сделал другой канал. Тема нового канала шире и, главное, проще для меня – пишу и делаю репосты вообще всего, что меня заинтересовало. Пока канал больше похож на мою личную записную книжку, но вы можете подписаться. Буду рад каждому, но не обещаю радовать регулярностью. Зато досаждать частыми уведомлениями тоже не буду :)

Ссылка вот: https://tttttt.me/iwannasaysmth

Так уж вышло, что я решил сосредоточиться на неразвитии и теперь просто скидываю мемы в своём микро-канале:
https://tttttt.me/another_meme_channel ❤️

и нет, это не скам. Я реально пытаюсь привлечь больше подпищеков )