Не критичные ошибки это какие

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

Программная ошибка: что это и почему возникает

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

Ошибка в программировании — это зачастую ошибки разработчиков, которые находят тестировщики. Запускают разные тесты и отладку, чтобы определить источники проблемы.

Научитесь находить ошибки в приложениях и на сайтах до того, как ими начнут пользоваться клиенты. Для этого освойте профессию «Инженер по тестированию». Изучать язык программирования необязательно. Тестировщик работает с готовыми сайтами, приложениями, сервисами, а не с кодом. В программе от Skypro: четыре проекта для портфолио, практика с обратной связью, все основные инструменты тестировщика.

Ошибки часто называют багами, но подразумевают под ними разное, например:

❗ Ворнинги, или предупреждения. Возникают, когда программа начинает вести себя не так, как задумывалось. Не являются критичными ошибками. Программа с ворнингами работает, но с аномалиями.

❗ Исключения. Это не ошибки, а особые ситуации, которые нужно обработать.

❗ Синтаксические ошибки. Это ошибка в программе, связанная с написанием кода. Пример: программист забыл поставить точку или неверно написал название оператора. Если не исправить, код программы не запустится, а останется просто текстом.

Классификация багов

У багов есть два атрибута — серьезности (Severity) и приоритета (Priority). Серьезность касается технической стороны, а приоритет — организационной.

🚨 По серьезности. Атрибут показывает, как сильно ошибка влияет на общую функциональность программы. Чем выше значение атрибута, тем хуже.

По серьезности баги классифицируют так:

• Blocker — блокирующий баг. Программа запускается, но спустя время баг останавливает ее выполнение. Чтобы снова пользоваться программой, блокирующую ошибку в коде устраняют.
• Critical — критический баг. Нарушает функциональность программы. Появляется в разных частях кода, из-за этого основные функции не выполняются.
• Major — существенный баг. Не нарушает, но затрудняет работу основного функционала программы либо не дает функциям выполняться так, как задумано.
• Minor — незначительный баг. Слабо влияет на функционал программы, но может нарушать работу некоторых дополнительных функций.
• Trivial — тривиальный баг. На работу программы не влияет, но ухудшает общее впечатление. Например, на экране появляются посторонние символы или всё рябит.

🚦 По приоритету. Атрибут показывает, как быстро баг необходимо исправить, пока он не нанес программе приличный ущерб. Бывает таким:

• Top — наивысший. Такой баг — суперсерьезный, потому что может обвалить всю программу. Его устраняют в первую очередь.
• High — высокий. Может затруднить работу программы или ее функций, устраняют как можно скорее.
• Normal — обычный. Баг программу не ломает, просто где-то что-то будет работать не совсем верно. Устраняют в штатном порядке.
• Low — низкий. Баг не влияет на программу. Исправляют, только если у команды есть на это время.

Типы ошибок в программе

🧨 Логические. Приводят к тому, что программа зависает, работает не так, как надо, или выдает неожиданные результаты — например, не записывает файл, а стирает.
Логические ошибки коварны: их трудно обнаружить. Программа выглядит так, будто в ней всё правильно, но при этом работает некорректно. Чтобы победить логические ошибки, специалист должен хорошо ориентироваться в коде программы.

🧨 Синтаксические. Это опечатки в названиях операторов, пропущенные запятые или кавычки. Безобидные ошибки: их обнаруживают и подсвечивают в коде компиляторы, а программисту остается исправить.

🧨 Взаимодействия. Это ошибка в участке кода, который отвечает за взаимодействие с аппаратным или программным окружением. Такая ошибка возникает, например, если неправильно использовать веб-протоколы. Исправляется элементарно: разработчик переписывает нужный кусок кода.

🧨 Компиляционные. Любая программа — это текст. Чтобы он заработал как программа, используют компилятор. Он преобразует программный код в машинный, но одновременно может вызывать ошибки.

Компиляционные баги появляются, если что-то не так с компилятором или в коде есть синтаксические ошибки. Компилятор будто ругается: «Не понимаю, что тут написано. Не знаю, как обработать».

🧨 Ошибки среды выполнения. Возникают, когда программа скомпилирована и уже выглядит как файл — жми и работай. Юзер запускает файл, а программа тормозит и виснет. Причина — нехватка ресурсов, например памяти или буфера.

Такой баг — ошибка разработчика. Он не предвидел реальные условия развертывания программы. Теперь ему надо вернуться в исходный код и поправить фрагмент.

🧨 Арифметические. Бывает, в коде есть числовые переменные и математические формулы. Если где-то проблема — не указаны константы или округление сработало не так, возникает баг. Надо лезть в код и проверять математику.

Что такое исключения в программах

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

Как это происходит:

1. Когда программист кодит, то продумывает, в какой части программы может вылезти ошибка.
2. В этой части пишет специальный фрагмент, который предупредит компьютер, что ошибка — вполне ожидаемое явление и резко обрывать программу не нужно.
3. Когда юзер запустит программу и появится ошибка, компьютер увидит заранее подготовленное предупреждение программиста. Продолжит выполнять алгоритм так, словно никакого бага и не было.

Исключения бывают программными и аппаратными:

• Аппаратные создает процессор. К ним относят деление на ноль, выход за границы массива, обращение к невыделенной памяти.

• Программные создает операционка и приложения. Возникают, когда программа их инициирует: аномальная ситуация возникла — программа создала исключение.

Как контролировать баги в программе

🔧 Следите за компилятором. Когда компилятор преобразует текст программы в машинный код, то подсвечивает в нём сомнительные участки, которые способны вызывать баги. Некоторые предупреждения не обозначают баг как таковой, а только говорят: «Тут что-то подозрительное». Всё подозрительное надо изучать и прорабатывать, чтобы не было проблемы в будущем.

🔧 Используйте отладчик. Это программа, которая без участия айтишника проверяет, исправно ли работает алгоритм. В случае чего сообщает об ошибках. Например, отладчик используют для построчного выполнения программы. Вместе с тем проверяют значения переменных: фактические сравнивают с ожидаемыми. Если что-то не сходится, ищут баги и исправляют.

🔧 Проводите юнит-тесты. Это когда разработчик или тестировщик описывает ситуации для каждого компонента и указывает, к какому результату должна привести программа. Потом запускает проверку. Если результат не совпадает с ожидаемым, появляется предупреждение. Дальше программисты находят и устраняют проблему.

Ключевое: что такое ошибки в программировании

• Ошибка в программировании — это дефект кода, баг, который может вызывать в программе сбои и неожиданное поведение.
• По серьезности баги делятся на блокирующие, критические, существенные, незначительные, тривиальные. По приоритету — на наивысший, высокий, обычный, низкий.
• Ошибки в коде могут быть разными, например связанные с логикой программы. Или с математическими вычислениями — логические. Еще бывают синтаксические, ошибки взаимодействия, компиляционные и ошибки среды выполнения.
• Некоторые ошибки помогают ловить обработчики исключений.
• Чтобы находить ошибки в коде, тестировщики используют компиляторы, отладчики и пишут юнит-тесты.

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

Для начала рассмотрим каждый атрибут в отдельности.

Серьезность

Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.

Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).

• S1 – Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее функциями становится невозможна.
• S2 – Критическая (Critical). Критическая ошибка, неправильно работающая бизнес-логика, проблема, приводящая в нерабочее состояние некоторую часть системы, но есть возможность для работы с тестируемой функцией, используя другие входные точки.
• S3 – Значительная (Major). Значительная ошибка, часть бизнес-логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
• S4 – Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
• S5 – Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес-логики приложения, плохо воспроизводимая проблема, малозаметная по средствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Из описания видно, что с помощью Серьезности мы указываем как найденная ошибка влияет на тестируемое приложение. Если из-за ошибки приложение полностью не работает, то Серьезность высокая. Если найденный дефект мало влияет на функционал и больше относится к визуальной части (например, опечатка в слове), то Серьезность низкая.

Давайте рассмотрим несколько примеров проблем и попробуем правильно определить их Серьезность. Чтобы было понятно, представим, что мы тестируем приложение по заказу такси.

1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.

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

У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.

Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.

Остаются Критическая и Блокирующая серьезности. В нашем случае Блокирующая подходит больше, так как часть функционала не работает и нет других возможностей найти такси. Следовательно, мы выставляем Блокирующую Серьезность.

2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.

Как вы могли понять, Серьезность относится к технической части приложения и указывает на то, как сильно ошибка влияет на работоспособность приложения.

Приоритет

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

Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.

• P1 – Высокий (High) – требуется исправить в первую очередь.
• P2 – Средний (Medium) – требуется исправить во вторую очередь, когда нет дефектов с высоким приоритетом.
• P3 – Низкий (Low) – исправляется в последнюю очередь, когда все дефекты с более высоким приоритетом уже исправлены.

С помощью приоритета менеджер проекта говорит, когда стоит исправить найденную проблему.

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

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

Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:

Теперь, когда мы разобрались что означает каждый атрибут, давайте посмотрим в чем их различие:

________________________________
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.
________________________________

Предыдущие статьи по оформлению баг-репорта:
Назначение отчета https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-naznachenie/
Шаблон отчета об ошибке https://sedtest-school.ru/testovaya-dokumentacziya/otchety-o-defektah-shablon-otcheta-ob-oshibke/

Исключения в программировании (exceptions) — это механизм, который позволяет программе обрабатывать нетипичную ситуацию и при этом не прекращать работу. Благодаря этому механизму разработчик может описать в коде реакцию программы на такие ситуации.

Простой пример: в программе-калькуляторе исключением может стать ситуация, когда пользователь решит поделить на ноль. Это не должно стать ошибкой, из-за которой рушится вся программа, но чтобы ситуация не застопорила исполнение остального кода, нужно ее правильно обработать. Для этого необходимы обработчики исключений. Они позволяют «сказать» программе, что ей делать, если такое случится.

Механизм обработки исключений существует в большинстве языков программирования. Он может быть реализован немного по-разному, но общая суть схожа: это всегда какие-то особые случаи, которые надо обработать отдельно. Мы при описании будем отталкиваться от особенностей исключений в Java, но встретить их можно и в других языках: JavaScript, PHP, Python, C++ и так далее.

Зачем нужны исключения

Механизм обработки исключений может понадобиться любому разработчику. Если не отслеживать исключительные ситуации, может возникнуть незаметная ошибка, которая нарушит работу всего кода, или программа может «зависнуть» либо «упасть» — потому что сложный момент не был обработан как надо.

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

Какими бывают исключения

Исключения делятся на две большие группы, которые пересекаются друг с другом: синхронные и асинхронные. Синхронные могут возникнуть только в конкретном месте программы или при выполнении определенной операции: открытие файла, деление и так далее. Асинхронные могут возникнуть когда и где угодно. Их «ловят» по-разному, чтобы успешно отслеживать и те, и другие.

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

Как происходит работа с исключениями

• Разработчик пишет код и понимает, что в какой-то момент в том или ином месте может возникнуть нештатная ситуация. Бывает, что исключения добавляют в уже написанный код — например, нештатную ситуацию обнаружили при тестировании.
• В этом месте пишется особый блок кода — обработчик. Он говорит программе: здесь может возникнуть особая ситуация, если она случится, выполни вот это.
• Внутри обработчика — функция, которая выполнится, если программа столкнется с описанной ситуацией. Она или исправит ситуацию, или скорректирует дальнейшее выполнение программы.

Бывают исключения, которые нельзя предусмотреть. Разработчики обрабатывают не все возможные нештатные ситуации, а только самые очевидные, чтобы не перегружать код. Это справедливо для большинства сфер разработки, кроме тех, где слишком высока цена ошибки.

Как устроена обработка исключений

Существуют разные виды обработки: структурная и неструктурная, с возвратом и без возврата. Они различаются механизмом действия, но общая суть одна: это функция, которая запускается, если в коде случилась та или иная исключительная ситуация. Тут можно использовать условный оператор if или специальные синтаксические конструкции.

В примере с делением на ноль обработчик может отменить попытку деления и сказать пользователю, что на ноль делить нельзя, — но это самый простой пример. В реальности все сложнее.

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

Вот пример: не запустился скрипт, необходимый для работы следующего скрипта. Следующий скрипт заметил это, зафиксировал исключение и обратился к обработчику, который запустил нужный скрипт «вручную». После этого все может работать, как и было задумано.

Обработка без возврата — вид обработки, когда проблема не ликвидируется, а участок кода, который не получается выполнить, пропускается. В примере со скриптами обработка «переключила» бы выполнение кода на момент, где уже не понадобится незаработавший скрипт.

Структурная и неструктурная обработка. Это два способа подключить обработчики. В первом случае они встраиваются в код, а когда генерируется исключение, для него выбирается тот или иной обработчик в зависимости от ситуации. Во втором случае обработчики существуют отдельно и «подключаются» к конкретным видам исключений с помощью специальных команд. Способ выбирается в зависимости от вида исключения, особенностей кода и языка.

Обычно асинхронные исключения обрабатывают неструктурно, а синхронные — структурно.

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

Исключения и ошибки: разница

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

• ошибка означает, что программа «упала», что ее работу нельзя продолжить и она должна быть завершена. Ошибку невозможно исправить — только сообщить о ней пользователю, записать в лог и прекратить исполнение кода;
• исключение — это нештатная ситуация, которую тем не менее можно попробовать починить «на ходу», не закрывая программу. В этом есть смысл, в отличие от ситуации с ошибкой.

Это действительно похожие понятия. В Java, например, сущности исключений и ошибок наследуются от общего предка — интерфейса Throwable. Но ошибка — это явление, когда что-то сделать принципиально не получается. А исключение — ситуация, когда программа просто не знает, что делать, если не указать на это дополнительно.

Можно провести аналогию. Мама послала дочь в магазин за покупками и сказала ей купить батон хлеба. Если хлеба в магазине не оказалось, девочка не сможет его купить. Это ошибка. А если в магазине есть три вида батонов, или все батоны вчерашние, а девочка не знает, нужен ли маме только свежий хлеб, или батон есть, но только из ржаной муки, — это исключения.

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

Когда пользоваться исключениями, а когда — ошибками

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

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

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

Как начать пользоваться исключениями

В большинстве языков механизм обработки исключений есть по умолчанию — это популярная функция. Но приступать к работе с ними рекомендуют после изучения базовых возможностей языка. Мы советуем идти от простого к сложному: начать с основ и затем переходить к комплексным темам. Конкретно обработка исключений обычно изучается перед тем, как человек переходит к практическим проектам, потому что любая более-менее сложная программа может столкнуться с исключениями в ходе работы.

• Серьезность
• Приоритет
• Глобальный приоритет
• Высокий приоритет и низкая серьезность
• Высокая серьезность и низкий приоритет

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

Поэтому баги, внесенные в системы отслеживания (bug-tracking системы), дифференцируются.

Каждый баг имеет атрибуты серьезности (Severity) и приоритета (Priority). На первый взгляд может показаться, что разницы между этими понятиями нет, но она все же есть. Серьезность больше касается технической стороны дела, а приоритет — организационной.

Серьезность (Severity) бага

Severity — это атрибут, характеризующий влияние бага на общую функциональность тестируемого продукта.

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

Пример классификации серьезности багов:

• Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
• Critical. Критическая ошибка. Нарушает работу основного функционала. Баг проявляется постоянно и делает невозможным использование основных функций программы.
• Major. Существенный баг. Затрудняет работу основного функционала или делает невозможным использование дополнительных функций.
• Minor. Незначительный баг. На функционал системы влияет относительно мало, затрудняет использование  дополнительных функций. Для обхода этого бага могут быть очевидные пути.
• Trivial. Тривиальный баг. Не влияет на функционал проекта, но ухудшает общее впечатление от работы с продуктом.

Приоритет (Priority) бага

Приоритет — атрибут, определяющий скорость устранения бага.

Приоритет бага сперва определяет инициатор, но в дальнейшем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.

Виды приоритетов:

• Top. Наивысший приоритет. Назначается экстренным ситуациям, которые очень отрицательно влияют на продукт или даже бизнес компании. Такие баги нужно устранять немедленно.
• High. Высокий приоритет. Назначается багам, которые должны быть устранены в первую очередь.
• Normal. Обычный приоритет, назначается по умолчанию. Эти баги устраняются во вторую очередь, в штатном порядке.
• Low. Низкий приоритет. Назначается багам, не влияющим на функционал. Исправление таких багов происходит в последнюю очередь, если есть время и ресурсы.

Также нужно упомянуть о частоте проявления бага.

Частота (Frequency) — это показатель количества пользователей, которые сталкиваются с ошибкой. Определяется при анализе алгоритмов.

Частота бывает:

• High. Высокая: с багом сталкиваются больше 80% пользователей.
• Medium. Средняя: баг обнаружат от 30% до 80% пользователей.
• Low. Низкая: баг проявляется у 10-30% пользователей.
• Very low. Незначительная: такой баг встретится меньше чем 10% пользователей.

Глобальный приоритет бага (Global Severity)

Для определения глобального приоритета необходимо определить частоту проявления бага. Частота влияет на приоритет, а приоритет и серьезность влияют на глобальный приоритет бага.

Таким образом, для определения глобального приоритета бага нужно:

1. Определить серьезность бага.
2. Отдельно от серьезности определить приоритет.
3. Определить частоту (независимо от серьезности и приоритета).
4. Рассчитать влияние частоты на изначально определенный приоритет.

Если частота у бага высокая, приоритет возрастает на одну позицию. Скажем, если изначально приоритет был Normal, но частота высокая, приоритет определяется как High.

Средняя частота бага меняет приоритет только с низкого на обычный.

Низкая или незначительная частота вообще не меняет приоритет бага.

Для определения глобального приоритета можно пользоваться следующей таблицей:

Приоритет/Серьезность	Blocker	Critical	Minor	Trivial
High	Critical	Critical	Minor	Trivial
Medium	Critical	Critical	Minor	Trivial
Low	—	—	Trivial	Trivial

Если глобальный приоритет — Critical, значит, баг нужно непременно исправить. Баги с приоритетом Minor тоже желательно исправить до релиза, хотя некоторое количество таких дефектов может остаться в проекте. Баги с приоритетом Trivial могут вообще не исправляться.

Высокий приоритет и низкая серьезность

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

Вот пара примеров:

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

Высокая серьезность и низкий приоритет

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

Примеры:

1. Домашняя страница сайта ужасно выглядит в старых браузерах. Перекрывается текст, не загружается логотип. Это мешает пользоваться продуктом, поэтому серьезность бага высокая. Но так как очень мало пользователей открывают сайт при помощи устаревшего браузера, такой баг получает низкий приоритет.
2. Допустим, у нас есть приложение для банкинга. Оно правильно рассчитывает ежедневный, ежемесячный и ежеквартальный отчет, но при расчете годового возникают проблемы. Этот баг имеет высокую степень серьезности. Но если сейчас формирование годовой отчетности не актуально, такой дефект имеет низкий приоритет: его можно исправить в следующем релизе.

Итоги

Приоритет и серьезность багов — ключевые атрибуты, в соответствии с которыми определяется очередность исправления. Если неверно присвоить багу приоритет и серьезность, эффективность исправления ошибки сильно снизится. Это может нанести вред бизнесу и привести к финансовым потерям. Поэтому очень важно, чтобы и тестировщики, и разработчики понимали суть этих терминов и пользовались ими правильно.

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

В статье нет теории. На реальных примерах разбираем типичные ошибки, которые видны уже при первичном анализе сайта. Если эти ошибки не исправить:

— все другие действия по SEO продвижению будут бессмысленны;

— контекстная реклама будет неэффективна. По объявлениям придут люди, но не обратятся в компанию.

Поиск ошибок сайта с помощью Яндекс Метрики и Google Analytics

Первое, что мы оцениваем — трафик. Смотрим:

— прирост посетителей за период по каждому источнику;

— откуда переходы: социальные и демографические параметры, устройства, поисковые системы и запросы, какие страницы приносят трафик.

Главное правило: любая аномалия — это подозрительно. Поэтому, задача — найти аномалии.

Аномалией может быть:

— резкий скачок общего и поискового трафика и потом падение;

— разница трафика в Яндекс и Google;

— трафик со сторонних сайтов. Не должно быть внезапных взлетов и падений.

Аномалия может означать:

— санкции от поисковиков;

— накрутку трафика со стороны другого исполнителя или клиента;

— взлом сайта и создание «мусорных» страниц.

Пример:

К нам пришел производитель высокоточного лазерного оборудования. Его сайт продвигал SEO-специалист и показывал результат — рост трафика из поисковых систем. Но этот трафик не приносил лидов, поэтому клиент остался недоволен работой подрядчика.

У нас возникло подозрение на «нагоняемый» трафик. Чтобы проверить, мы сравнили линии поискового трафика Яндекс и Google. В Яндексе виден хороший рост с началом отношений с предыдущим SEO-специалистом. Но в Google вираж кривой не повторяется.

Виражи кривых поискового трафика Яндекс и Google должны быть синхронными. Без резких падений.

В Яндексе видим резкое падение трафика при разрыве отношений с подрядчиком. Так быть не должно. При прекращении работ по SEO, трафик обычно держится на достигнутом уровне до полугода, затем постепенно снижается.

Поиск причин — всегда немного детективное расследование. В данном случае у нас было 2 гипотезы:

Санкции Яндекса. Мы сделали проверку и явных санкций не обнаружили.

Искусственная накрутка трафика:

— роботами;

— людьми, не относящимися к целевой аудитории. Последние за плату заходят на сайт и совершают целевые действия.

Накрутку трафика делает недобросовестный SEO-шник чтобы заработать. Для клиента эти действия:

— бесполезны, потому что такой трафик не приносит обращений и доходов;

— чреваты санкциями поисковиков из-за резких скачков и понижений траста.

Подтвердилась гипотеза 2 с накруткой трафика.

Подобные скачки трафика могут быть связаны и с другими причинами:

1. Переезд на новый сайт, который оказался неудачным. Например, у ресурса плохой дизайн или медленная загрузка. В результате посетитель сразу уходит.

Или при переезде на новый ресурс не были скреплены старые и новые адреса. В итоге при переходе из поиска люди попадают на ошибку 404.

2. Взлом сайта.

Пример:

В нашей практике был случай, когда взломали сайт строителя дач. Взломщики сделали несколько тысяч страниц сайта, каждая из которых перекидывала на онлайн-казино. Ссылки на страницы сайта злоумышленники закинули в описание фотографий на Яндекс Фото. В результате новые страницы были проиндексированы за 4-5 дней.

Сайт строителя попал под санкции «дорвейные страницы» и около 8 месяцев не получал трафик из Яндекса, невзирая на то, что страницы с сайта удалили сразу. Из индекса их изгнать было крайне трудно.

Определить такую ошибку поможет отчет Яндекса «страницы входа».

Яндекс.Вебмастер и Google Search Console — инструменты вебмастеров для анализа ошибок сайта

Вебмастер — это специальная панель, из которой SEO-специалист получает информацию о технических особенностях и ошибках сайта.

Информацию об основных проблемах сайта найдете в Яндекс Справке и в Google Справке. А здесь разберем типичные проблемы на примерах.

Пример 1:

На сайте производителя трубопроводной и запорной арматуры Вебмастер показал критичные и возможные проблемы.

Проблема страниц-дублей с GET-параметрами чревата понижением позиций ресурса в поисковой выдаче. Для решения проблемы нужно объявить все копии страниц неканоническими относительно основной страницы.

Понимаем, что абзац выше написан «птичьим языком» и скорее всего вам не понятен. Это нормальная ситуация, ваша задача просто понять что на сайте есть критическая ошибка, и дать возможность SEO-специалисту ее решить.

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

Пример 2:

На сайте производителя металлопроката обнаружены фатальные ошибки.

Главная страница недоступна для робота — такая ошибка возможна, если:

— сайт недоступен, его не видит пользователь;

— сайт недоступен роботам поисковика — так бывает, когда в файле robots.txt весь ресурс закрыт для индексации.

Пример 3:

На сайте компании, оказывающей услуги продюсирования маркетинга, показана возможная проблема.

Главное зеркало сайта не использует HTTPS-протокол. Этот протокол важен для безопасности сайта и защиты данных. Он виден в адресной строке перед названием сайта. Если есть проблема, вместо «https» вы увидите «http».

Если отсутствует HTTPS-протокол, возможны 2 варианта:

— протокол никогда не был установлен на сайт. В этом случае посетитель увидит страницу сайта. Но вебмастер укажет отсутствие протокола как ошибку.

— HTTPS-протокол отсутствует, хотя ранее был установлен. В этом случае Яндекс или Google при переходе на сайт предупредит посетителя об опасности.

Пример 4:

Сайт поставщика трубного металлопроката имеет критичные ошибки.

Долгий ответ сервера — ошибка означает, что сайт очень сильно тормозит, пользователь может не дождаться загрузки страницы и уйти с нее. Если столкнулись с подобным, обратитесь за помощью к программисту.

Технические ошибки из анализа специализированными программами

Вариантов технических ошибок может быть много. Рассмотрим некоторые наиболее типичные на примерах.

Пример 1:

У производственно-промышленного холдинга обнаружили:

1. Битые ссылки. Это недоступные для пользователей и поисковых систем URL.

Когда на сайте много ссылок на битые страницы, поисковые системы могут посчитать его некачественным и понизить позиции в результатах поиска. Люди также, попадая на битую ссылку, могут посчитать сайт некачественным и уйти с него.

2. Ошибки в настройке канонических страниц. Канонический URL страницы — это адрес, который будет индексироваться при наличии страниц-дублей. На момент аудита в качестве канонических страниц заданы страницы с http, а не с https.

Пример 2:

У сайта компании по добыче и обработке натурального камня обнаружены технические ошибки:

1. Неполная индексация. При полной индексации поисковые системы знают обо всех страницах сайта. В данном случае у Яндекс и Google показатель не совпадает.

Для решения проблемы нужно найти «потерянные» Google страницы и добиться их индексации при помощи Google Search Console.

2. Отсутствие микроразметки. Разметка помогает сделать интернет более понятным, структурированным. Поисковые роботы с помощью разметки обрабатывают информацию для показов в поиске. Решение вопроса позволит увеличить CTR сниппета в поисковой выдаче и поисковые позиции.

Пример 3:

Сайт компании-экспортера имеет технические проблемы:

1. Ошибки в Robots.txt. Файл нужен для корректной индексации ресурса поисковиками: в нем указываются страницы, которые должны или не должны попасть в поиск. Решение проблем с Robots.txt позволит добиться корректной, а значит, более быстрой индексации.

2. Низкая скорость загрузки сайта. Медленная загрузка страницы раздражает пользователя и может ухудшить рекламные и поисковые рейтинги. На момент аудита, почти треть ресурса долго грузится.

Решить проблему поможет:

— оптимизация кода страницы;

— оптимизация размера изображений;

— настройка кеширования со стороны сервера и браузера.

В результате:

— уменьшится количество отказов;

— увеличится конверсия сайта;

— сайт будет лучше воспринят поисковиками.

3. «Висячие» узлы. Это страницы, на которые ведут ссылки, но с этой страницы нет ссылок на другие. Это страницы-тупики.

Чтобы исправить «висячие» узлы, нужно добавить на них ссылки. Это улучшит видимость ресурса поисковыми роботами и снизит количество отказов.

4. Внешние ссылки без атрибута nofollow. Атрибут rel=»nofollow» рекомендуется использовать для ссылок на сторонних ресурсах или для рекламных внешних ссылок, чтобы не передавать ссылочный вес таким страницам (вес — один из ключевых факторов ранжирования). Найдены 253 такие ссылки.

Это не критичная ошибка. В некоторых случаях Google спокойно относится к ситуации, когда на свой сайт ставим ссылку на трастовый источник.

Для решения проблемы нужно:

— проверить все внешние ссылки на «адекватность»;

— закрыть их тегом или наоборот убрать лишние теги;

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

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

Ошибки с оптимизацией (метатеги)

Метатеги — это специальные теги разметки, размещенные на странице. Содержат ее описание, ключевые слова, основное заглавие каждой страницы для поиска. Они должны быть уникальными в пределах сайта. Оптимизация метатегов напрямую влияет на ранжирование ресурса.

В метатегах может быть много вариантов ошибок. Наиболее типичные рассмотрим на примерах.

Пример 1:

Сайт компании-экспортера имеет ошибки в метатегах:

1. Дубликаты H1, title и description.

Title — это заголовок для поиска, а H1 — для сайта. Первый должен быть рекламно привлекательным и содержать основной запрос страницы, а второй — внятно доносить содержание страницы до клиента и поискового робота. Description используется в качестве описания страницы в результатах поиска, чтобы пользователи лучше могли понять суть страницы.

Поисковым роботы понизят страницы с дублями в метатегах в поиске.

2. На 6 страницах отсутствуют title. Это может сильно понизить страницы в выдаче.

Пример 2:

Ошибки в сайте компании по добыче и обработке натурального камня:

1. Одинаковые title и H1. Найдено 135 страниц с дублированием. Поисковик негативно реагирует на эту ошибку. Считает сайт некачественным.

2. Короткий title и description. Title и description — важные элементы поисковой оптимизации. Их содержание часто показано в результатах поиска. На скрине ниже title выделен красным, description — синим.

Если title короткий, поисковым роботам сложнее определить содержимое страницы и оценить насколько она подходит под поисковый запрос. В этом случае робот может сам сформировать заголовок из текста страниц. Такой заголовок может быть некорректным. С description аналогичная ситуация.

3. Слишком длинный title. В результатах поиска отображается около 70 первых символов тега title, остальной текст не видно. Обрезанный title может стать некорректным, ресурс лишится части трафика.

Ошибки юзабилити

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

Пример 1:

Чтобы просмотреть блок с результатами, нужно сделать 5 скроллов, в то время как информации там содержится на 5 коротких предложений. Посетителю может надоесть листать.

На новом сайте блок с результатами выглядит компактно.

Пример 2:

В старом кейсе структура сайта занимала 3 скролла. В новом — 1,5. Она стала более наглядной. Вложенность очевиднее.

Пример 3:

На странице услуги SEO, блок «Что мы делаем?» ранее был растянут вниз и занимал 6-7 скроллов (на скрине показан только верх блока).

Сейчас блок компактен и занимает 1 скролл. В нём легко переходить от одного этапа к другому.

Пример 4:

Первый экран — самая горячая зона сайта. На нём размещают УТП, цифры, ключевые мысли. Эта информация относится к коммерческим факторам ранжирования. Посмотрите на первый экран старого сайта, страница услуги SEO.

А теперь сравните с новым вариантом. Он более информативный с очевидным позиционированием.

Хотим заметить, у старого сайта «уставший» дизайн. Но он всё равно наполнен смыслами и вполне хорош. Грубых ошибок в нем нет. Таких, например, когда попадаешь на страницу и не понимаешь, где очутился, что тебе предлагают и как найти нужную информацию.

Контент

Контент — информация, которую пользователь получает на сайте: текст, картинки, видео.

Чтобы Яндекс и Google лучше ранжировали сайт, контент должен быть:

— уникальным;

— с нужным количеством ключей;

— лаконичным, в то же время содержащим полный ответ на вопрос пользователя;

— фото и видео-контент должен быть качественным. Картинки четкие, но оптимизированные по размеру, чтобы грузились быстрее.

Посмотрим на примере, как влияет контент на продвижение сайта.

Пример:

Хозяйка Ателье фотографировала каждое изделие и выкладывала на страницу сайта. Она создала на сайте разделы по каждому типу изделий: платья, юбки, брюки и т.п. В каждый раздел добавила более 100 уникальных фотографий.

В результате поисковик быстро проиндексировал сайт и вывел его в топ-10.

Для пользователя тоже важен визуал. Например, товары с картинками покупают лучше, чем просто с текстовым описанием. Продать сложный высокотехнологичный товар, например, оборудование, поможет видео обзор. Покажите в нем сам товар и особенности его использования.

Ссылочное продвижение

В ссылочном продвижении мы используем 3 стратегии:

1. Регистрируемся на отраслевых площадках, крупных агрегаторах сайтов и организаций.

2. Покупаем ссылки. Пример на скрине — статья Сайткрафт в блоге Callibri ссылается на сайт нашей компании.

3. Ставим ссылки на сайт в корпоративных соцсетях. На сайте, напротив, ссылаемся на свои соцсети.

Вывод

Первичный SEO-аудит помогает увидеть проблемы ресурса:

— технические ошибки;

— некачественный контент;

— проблемы оптимизации и юзабилити;

— проблемы вследствие недобросовестных действий подрядчиков.

Найденные ошибки — это точки роста ресурса и компании в целом. Исправьте их и ваш сайт выше оценят пользователи и поисковые системы. Сайт получит больше целевых посетителей и даст вам больше обращений. В конечном итоге увеличится ваш доход и прибыль.

Если хотите получить SEO-аудит от специалистов Сайткрафт, запишитесь на консультацию и укажите в форме заявки адрес сайта. Наш специалист свяжется с вами в ближайший рабочий день для согласования даты консультации.