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

Итак, баг-репорт – это запись о найденом дефекте в программе. Вещь очень нужная для всех: разработчикам понятно что не так с приложухой, а мне баг-репорт нужен чтобы через неделю я смог вспомнить что тут вообще происходило. Для менеджеров на первый взгляд баг-репорты не важны, но это не так. Они им тоже нужны чтобы владеть информацией об актуальном качестве продукта и дальше менеджерить исходя из этих данных.
Перечислю поля, которые сам считаю важными.
• ID – номер бага в вашем баг-трекере. Почти везеде (JIRA, RedMine, YouTrack) он присваивается автоматически при создании любой новой задачи в трекере;
• Автор – имя того, кто багу завёл (=нашел). Тоже присвается автоматом;
• Дата – имя поля говорит само за себя;
• Название проекта – название проекта, в котором эта бага обнаружена. Тоже присвается автоматом;
• Версия билда. Почти наверняка вы разрабатваете спринтами. И что бы точно знать имя билда где этот баг 100% присутствует надо это поле заполнить.
• Описание. В этом поле надо подробно по шагам описать сценарий воспроизведения бага. Уделите этому пункту своё внимание. Когда проект большой или у вас несколько проектов, то вы точно забудете что это за баг вообще и как его воспроизводить тем более. То что записано уже не забудется.
• Ожидаемый результат и Фактический результат. Думаю, тут понятно что нужно писать в каждом из полей. Не ленитесь описывать эти поля. Потому что требования могут изменяться и вам в будущем будет проще доказывать свою правоту перед коллегами, когда у вас будет такой аргумент.

Дальше я выделил необязательные поля, но каждое из них может быть очень нужно для какой-то конкретной баги или даже проекта целиком:
• Тестовая среда. Напрмер, название браузера или его версии, название почтового клиента, разрешение экрана, модель ОС или название БД к которой вы цепляетесь;
• Приоритет. То на сколько заказчику важен функционал, в котором есть эта бага.
• Критичность. То на сколько рушит эта бага ваше приложение. Не путайте приоритет и критичность.
• И последнее: скриншоты и видео-пруфы.

И ещё небольшой чек-лист по оформлению багов, который я выработал для себя за время работы:
1) воспроизвожу найденную багу дважды, а не один раз
2) перед тем как завести багу в баг-трекере ищу дубликаты
3) воспроизведение баги в соседних билдах (и релизе, если такой есть)
4) пишу сценарий и попутно его воспроизвожу полностью отключив мозг. То есть делаю только то, что написано
5) сделал скриншоты
6) заполнил в баг-трекере поля: автор, ответственный, версия билда, дата обнаружения, приоритет, критичность
7) ПИШУ ЛАКОНИЧНОЕ НАЗВАНИЕ БАГА. Да, это лучше делать в самом конце. Когда уже сам хорошо понимаешь природу бага и его место.

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

Не знаю, правильно это или нет, но я постарался привязаться к самой распространенной модели жц разработки:
1. Анализ требований
2. Дизайн
3. Разработка
4. Тестирование
5. Эксплуатация
И к каждому этапу я, можно сказать, прилепил своё тестирование руководствуясь девизом: чем раньше начать тестирование, тем лучше.

Этап 1. Анализ требований. Надо врываться в этот этап чтобы понимать функциональные и нефункциональные требования. Общайтесь с заказчиком чтобы понимать ожидания заказчика.

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

Этап 3. Разработка. Тут всё более-менее понятно: модульное тестирование, интеграционное и затем системное.

Этап 4. Тестирование. Это основная наша работа – тестируем всё: регрессионное, функциональное тестирование, тестирование UI/UX. Сложность этого этапа в том, что для нас этот этап считается последним, то есть после него мы уже не сможем ничего менять и цена пропущенных багов может быть огромной. Не сложный этап, но большой и ответственный.

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

Вот и получается, что жц тестирования неотделим от каждого этапа разработки.

Сети – это скучно. Даже разработчики особо не вникают как работает сеть, воспринимая её как существующий факт. Конечно, разработчики понимают важнейшие основы: что есть роутер, зачем DNS, VPN, стек TCP/IP, в чем суть UDP, как работает NAT и т.д.
Может, кто-то начнёт пердеть с моего мнения, но нам, тестировщикам, стоит не меньше разработчиков понимать как работает сеть. Не знание основ работы сети вредно для карьеры любого уважающего себя инженера IT.
Можно привести несколько примеров когда знания сетей пригодится тестировщику, но, думаю, вы сами понимаете на сколько это важно на сегодняшний день в нашей работе.
Итак, мне надо научиться в сети. Что делать? Ну ессно гуглить и читать всякое тематическое. Материала даже на русском хоть попой ешь.
Но не было бы этого поста, если бы у меня для вас не было кой-чего годного
🔥 это самая годная серия статей про сети, из всего что я нашел в рунете. Серьезно. Хотя бы по диагноли, но прочитайте и добавьте в закладки. Сначала нихрена не понятно (потом тоже), но прочитайте.
https://habrahabr.ru/post/134892/

Есть ещё мощнейшая книга В. Олифер Н. Олифер. «Компьютерные сети. Принципы, технологии, протоколы». Но она уже для тех, кому нужно нормально так разобраться, а не по верхам пройтись. Скажу честно, из-за отсутствия конкретной задачи, у меня не хватило мотивации дочитать её до конца. Я сдулся где-то на 1/3.

Тут подвезли довольно крупное аналитическое исследование рынка тестирования ПО в России.

Цитата: Компания Перфоманс Лаб представляет второй выпуск Russia Quality Report. На сегодняшний день это единственное аналитическое исследование индустрии тестирования программного обеспечения в различных сегментах рынка Российской Федерации. В ходе исследования было опрошено 360 респондентов уровня ИТ-директоров и Руководителей отделов тестирования. Были выявлены основные изменения, которые прошли в отрасли за последние два года. Найдено множество интересных инсайтов. Отчет рекомендуется для широкой аудитории ИТ-специалистов, заинтересованных в повышении качества программных продуктов.

Ключевые выводы:
• QA специалисты осваивают новые компетенции
• Agile на пике популярности, однако, есть сложности
• Количество центров компетенций по тестированию растёт
• Банковский сектор — лидер отрасли
• Государственный сектор не спешит проводить импортозамещение в области инструментария тестирования

Как справедливо подметил один коллега в чатике 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 (что в общем-то логично), пользователь онлайн-редактора испытает неудобства, а вы не можете ему помочь, так как находитесь в естественных границах технологии. Но, как и в случае с багами в компонентах, здесь есть оптимистичный сценарий. Проблема, которая не может быть решена в рамках конкретного продукта, может решиться сама по себе по мере развития технологии. Да, сейчас браузеры не интегрированы с системой достаточно тесно и поэтому не имеют доступа ко многим системным ресурсам, но кто возьмет на себя смелость сказать, что так будет всегда?