сообщить о баге что это
Баг-репорт
Баг-репорт (bug report) — это технический документ, который подробно описывает ошибку в работе программы, приложения или другого ПО. Его составляет тестировщик, чтобы разработчикам было понятно, что работает неправильно, насколько дефект критичен и что нужно исправить.
Баг-репорты — часть рабочего процесса. В них фиксируют наличие ошибки, назначают ответственного за исправление. Если сообщить об ошибке в рабочем чате, о ней скорее всего забудут. Каждый член команды подумает, что ошибку исправит другой, и в итоге она так и останется в коде.
Виды багов
Структура баг-репорта
Поля варьируются в зависимости от правил конкретной компании, но чаще всего каждый документ содержит следующие пункты:
Серьезность и приоритет багов
Серьезность — это показатель влияния бага на работу программы, того, может ли она функционировать без исправления или баг ломает всю систему. Выделяют пять уровней серьезности багов:
Приоритет — это срочность выполнения задачи. Всего выделяется три уровня приоритетов:
На курсе вы начнете писать собственные тест-кейсы
и пользоваться баг-трекером. Дополнительная скидка 5% по промокоду BLOG.
Жизненный цикл бага
Статус бага в репорте определяется его «жизненным циклом», который состоит из четырех основных стадий:
Кроме основных есть еще несколько статусов:
Как правильно писать баг-репорт
Баг-репорт относится к технической документации, поэтому он не должен содержать лишних оборотов — только факты, изложенные простым языком.
На что стоит обратить внимание при описании дефекта?
Выявить причину возникновения. Например, если на сайте не получается восстановить пароль, то проблема может быть как в бэкенде, так и во фронтенде. Задача тестировщика — разобраться в ней, так как от этого зависит, кому из разработчиков отдавать баг на исправление.
Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.
Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.
Описать несоответствие ожидаемому результату. Чтобы сопоставить то, как работает программа сейчас, с ожидаемым результатом, начинающим специалистам лучше свериться с технической документацией и техническим заданием, где подробно описано, как все работает в идеале.
Вам необязательно иметь техническое образование и навыки программирования, чтобы начать.
Apple объяснила, как правильно сообщать о багах и проблемах с iPhone и iOS
Apple выпустила инструкцию, в которой рассказывается, как правильно сообщать компании о различных проблемах с айфонами и прошивками.
Всякий раз, когда вы регистрируете новый отчет об ошибке, будьте понятны и показывайте все наглядно. Предоставляете ли вы конкретные отзывы об ошибке, с которой сталкиваетесь, или общие отзывы — опишите вашу проблему подробно.
1. Все начинается с четкого заголовка. Он должен содержать емкое описание проблемы. Например, «события календаря в macOS 10.15.4 отсутствуют после создания быстрого события».
Плохо: «Отсутствуют события в календаре».
2. Если вы разрабатываете приложение, то укажите в описании и заголовке его название и версию сборки.
3. При описании своей проблемы тщательно расписывайте каждый шаг. Часто бывает полезно сделать вид, что тот, кто его читает, никогда не видел приложение или систему, о которой вы сообщаете.
Например, если вы напишете «Когда я создаю событие в Календаре, оно исчезает через мгновение», на экране недостаточно подробностей, чтобы воспроизвести проблему. Вы создаете событие календаря с помощью кнопки «Быстрое событие» или перетаскиваете, чтобы добавить новое событие? Как долго длится момент? Событие исчезло после выхода из многозадачности или вы остались в программе?
Вместо этого подумайте, как можно подробно описать свою проблему. Например:
• Нажмите кнопку «Быстрое событие» в приложении «Календарь».
• Заполните событие с любым названием.
• Нажмите «Создать событие».
Фактический результат: событие появляется в нужном месте календаре, но затем исчезает.
Ожидаемый результат: событие календаря должно появиться и остаться в моем календаре.
После заполнения ваших шагов воспроизведения и ожидаемого результата также стоит рассмотреть дополнительные факторы, которые могут повлиять на проблему.
• Вы вошли в iCloud?
• У вас есть какие-либо настройки специальных возможностей?
• Воспроизводится ли проблема подобным образом в других местах ОС?
4. Воспроизведите проблему и сделайте скриншоты или видеозапись экрана. Последнее особенно полезно, чтобы разработчики могли посмотреть все тщательно и, возможно, обнаружить ошибку, которую вы не заметили.
5. Укажите в баг-репорте логи ошибок. Для этого в сервисе создания отчетов есть специальная клавиша.
Как правильно сообщать о багах, чтобы их быстро исправляли
2017-02-17 13:57:52 2021-09-17 14:03:09
В разгар сосредоточенной деятельности программистов отвлекают вопросы в скайпе. Иногда достаточно ответить, но бывает, выясняется, что на проекте возникла ошибка, требующая исправления, и мы начинаем уточнять детали, создаем задание в багтрекере, согласовываем сроки решения. А возвращаясь к прерванному делу, обнаруживаем, что прошло сорок минут. А потом менеджер спросит: «Вася, почему ты задачу оценил в 7 часов, а выполняешь второй день?»
Уважаемый заказчик! Когда на проекте обнаруживается неполадка, и вы хотите быстрее сообщить о ней в чат, помните следующее.
 | Если изложить суть непонятно или сумбурно, на выяснение деталей уйдёт дополнительное время, которое оплачиваете вы. При этом от текущих дел отрываются один, а то и несколько сотрудников. |
 | Может создаться иллюзия срочности. Например, разработчик попытается воспроизвести указанный дефект, не дождавшись ответов на уточняющие вопросы, и сразу попытается его исправить, что хорошо, если проблема критическая, плохо, если минорная (а есть более важные задания), и очень плохо, если вы вообще не планировали исправление. |
 | Возможна и обратная ситуация: обсуждаемая в скайпе неполадка может там и остаться. Многие сотрудники справедливо полагают, что решение вопроса начинается с заведения задачи в багтрекере. Скайп — лишь инструмент коммуникации, где можно оперативно обсудить текущий проект. В багтрекере же фиксируются задания, комментарии и принятые решения. Разбор спорных ситуаций производится тоже по багтрекеру. Иными словами, если вы собираетесь написать в скайпе что-то вроде «было бы неплохо сделать так. », а потом, спустя неделю, возмущаться, почему до сих пор «так» не реализовано, то, пожалуйста, не надо. |
 | Если вы не заведёте задачу в багтрекере, её заведём мы. Тогда следует проследить, что с ваших слов записано верно. |
Что надо сделать?
Время идёт, проект не готов, а бюджет не резиновый. Есть два варианта.
Первый. Наш сотрудник (тестировщик, специалист службы поддержки или менеджер проекта) воспроизведёт неполадку, уточнит её критичность, занесет информацию в багтрекер, мобилизует программистов и обозначит примерный срок завершения. Такая схема успешно применяется, если бюджет проекта позволяет оплатить участие дополнительного специалиста.
Второй. Вы можете завести задачу самостоятельно. Если хотите, чтобы проблема была решена быстро, она должна быть правильно понята. С этого момента подробнее.
Заголовок
Итак, возникла неполадка, о которой нужно заявить. Первое, что указываем при заведении задачи, — это заголовок, при первом взгляде на который должно быть понятно, что случилось. Заголовок должен отвечать на три вопроса.
«Что?» — что, собственно, произошло?
«Где?» — в каком месте интерфейса вы видите проблему?
«Когда?» — при каких обстоятельствах проявляется проблема?
Приведем примеры, когда заголовок не отвечает ни на один из вышеуказанных вопросов.
Примеры, когда заголовок отвечает только на часть вопросов.
Примеры хороших заголовков, отвечающих на вопросы «Что? Где? Когда?».
Описание
В большинстве случаев, при хорошо составленном заголовке описание проблемы может даже не потребоваться. С другой стороны, качественно заполненное поле «Description» может нивелировать недостатки заголовка, и даже указать на решение. Были случаи, когда ошибка, имеющая детальное описание, исправлялась в течение десяти минут, а без такового — несколько часов. В первом случае разработчик сразу понял, какую строчку кода ему править. Во втором — полдня отлаживал код, прежде чем выяснил причины сбоя.
Что нужно указать в описании задачи.
 | Подробности | Помогающие воспроизвести неполадку и навести разработчика на возможную причину ошибки. Например, когда вы по пунктам описываете, что делаете, и как это приводит к проблеме. Выполняя эти шаги, разработчик воспроизведёт ошибку под отладкой и сможет приступить к её исправлению. |
 | Фактический результат | Напишите, что конкретно происходит. |
 | Ожидаемый результат | Напишите, что должно происходить. Упуская этот пункт, вы вынудите программиста искать ответ в требованиях, что займет время. Если явных требований не задокументировано, изложите собственное мнение, иначе разработчик всё равно обратится к вам и будет ожидать ответа, что отложит решение проблемы. Или исправит, как сочтет нужным, а его видение может отличаться от вашего. |
 | Скриншот | В некоторых случаях заменяет тысячи слов, особенно если замечание касается интерфейса или дизайна. |
Приоритет
Создавая задачу, вы можете определить степень серьёзности, исполняя роль руководителя проекта (ведь вы, по факту, им и являетесь). Градации серьёзности следующие.
Вот основное, что следует знать о заведении отчётов о дефектах в багтрекерах, и чаще всего этого достаточно для эффективного взаимодействия с разработчиками. Ну а если что-то действительно важное, всегда можно сообщить в скайпе: «Ребят, я там баг завёл срочный, вот ссылка на него. Когда исправите?».
10 правил хорошего тона при описании багов
Здравствуйте, меня зовут Наталья, я инженер по тестированию компании Docsvision.
Иногда, когда я просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками, рука машинально тянется к лицу. В голове возникает только одна мысль:
«Что? Что я сейчас прочитала?»
В интернете много информации о том, ЧТО обязательно должно присутствовать в баг-репорте. А я решила поделиться с вами своими мыслями о том, КАК нужно писать баг-репорт, чтобы было понятно, о чём вы пишете.
В первую очередь, я писала это для инженеров по тестированию и инженеров технической поддержки, которые передают нам баги, присланные заказчиками. Также моя статья может помочь сформировать описание возникшей проблемы при обращении пользователя в техподдержку: корректное описание позволяет без дополнительных вопросов быстрее обработать инцидент.
Вообще её может быть полезно почитать всем членам команды разработки ПО, которые фиксируют своё общение в багтрекинговой системе.
Приведу пример, чтобы стало понятно, от чего моя рука летит к лицу со скоростью света:
«В контроле файлов при наличии достаточного числа файлов, имена некоторых не отображаются полностью.
Создаём любой документ УД. На вкладке Регистрация в поле Добавьте файл, правым кликом мышь, и выбираем несколько файлов. Второй вариант, перетащить несколько файлов в данное поле. В резутате, если несколько файлов, названия не помещаются полностью. Только если развернуть карточку на весь экран можно увидеть всё полностью. Строка с файлом должна переноситься на следующую строку в контроле, но этого не происходит.»
(Орфография и пунктуация сохранены).
Какой-то невероятный кусок текста, состоящий из сплошного потока сознания.
Коллеги! Вы же пишете для других людей, у которых совсем другая голова и совсем другой образ мыслей. Вы должны писать понятно!
Вот ТОП-10 правил хорошего тона, которых я придерживаюсь сама и которые рекомендую коллегам:
1) Сначала глагол.
2) Принцип «Что-Где-Когда».
3) Обезличенность.
4) Простые конструкции.
5) Без лишних слов.
6) Сократить очевидное.
7) Упростить описание сложного действия.
8) По пунктам.
9) Однозначность.
10) Перечитать.
1. Сначала глагол
Магистр Йода из «Звёздных войн» говорил так, что его было непросто понять с первого раза. Его речь строилась по принципу «объект-глагол-субъект».
«Когда и тебе 900 лет исполнится, тоже не молодо будешь выглядеть ты».
В нашей речи глагол стоит в начале (если он есть).
Пример:
Плохо – «Скопированную карточку открыть на редактирование».
Хорошо – «Открыть на редактирование скопированную карточку».
2. Принцип «Что-Где-Когда»
Этот принцип общеизвестный – сначала надо написать «что», а уже потом «в каком месте» и «при каких условиях». Лучше всего работает при составлении краткого описания ошибки.
Что происходит? – «Не создаётся карточка», «Выдаётся необработанное исключение», «Не создаётся база данных».
Где происходит? – «В виртуальной папке», «На вкладке История», «В контекстном меню».
Когда происходит? – «По нажатию кнопки», «После смены состояния карточки», «При сохранении изменений».
Пример:
Плохо – «В отчёте при добавлении файла комментария текстовый комментарий стирается».
Хорошо – «Стирается текстовый комментарий в отчёте при добавлении файла комментария».
3. Обезличенность
Описание ошибки – это не летопись ваших действий, а руководство для другого человека. Уберите себя из описания.
Пример:
Плохо – «Нажимаем кнопку», «Открываю страницу».
Хорошо – «Нажать кнопку», «Открыть страницу».
4. Простые конструкции
Сложносочинённые и сложноподчинённые предложения, причастные и деепричастные обороты осложняют восприятие текста. Чем проще будет построено предложение, тем лучше.
Пример:
Плохо – «На панели инструментов есть кнопка с шестерёнкой, открывающая меню из двух пунктов, при наведении на которую не появляется всплывающая подсказка».
Хорошо – «Навести мышку на кнопку с шестерёнкой на панели инструментов – не появилась всплывающая подсказка».
5. Без лишних слов
Когда я смотрю советские фильмы, в которых каждая вторая фраза стала крылатой, я восхищаюсь тем, как тщательно проработана речь персонажей. Ни одного лишнего словечка. Каждое слово на вес золота. Так же нужно составлять и описание ошибок – каждое слово должно что-то значить.
Привычная речь богата эпитетами, местоимениями, предлогами, которые дополнительного смысла не привносят. Если справиться с собственным мозгом очень сложно, запишите весь поток сознания как есть, а потом удалите из текста те слова, которые не несут смысловой нагрузки.
Пример:
Плохо – «По какой-то причине смена значений в поле работает довольно странно – по сути обновление поля происходит через какой-то промежуток времени».
Убрать слова «По какой-то причине», «довольно», «странно», «по сути». Они не содержат ценной информации и могут быть удалены из описания без потери смысла. Словосочетание «какой-то промежуток времени» может быть заменено на более короткий синоним.
Хорошо – «Обновление значений в поле происходит с задержкой».
6. Сократить очевидное
Некоторые действия не являются специфичными для тестируемой системы. Например, сохранение некоторого объекта, закрытие окна, вызов контекстного меню, двойной клик, запуск приложения. Эти действия обычно интуитивно понятны, поэтому при описании ошибки не стоит заострять на них внимание.
Пример:
Плохо – «Найти ярлык приложения на рабочем столе, кликнуть по нему 2 раза левой кнопкой мыши».
Хорошо – «Открыть приложение по ярлыку».
7. Упростить описание сложного действия
Допустим, в тестируемой системе есть некоторая специфичная операция. Новенькие тестировщики или разработчики, которые плохо ориентируются в интерфейсе, могут не знать, как выполнить такую операцию. Поэтому описать выполнение этой задачи можно через описание простых действий, которые помогут её выполнить.
Пример:
Плохо – «Согласовать документ», «Выполнить синхронизацию свойств».
Хорошо – «Нажать кнопку «Согласовано» на панели инструментов карточки документа», «Выбрать команду «Синхронизировать свойства» в контекстном меню объекта».
Да, это увеличивает объём описания. Зато уменьшает время воспроизведения за счёт сокращения количества вопросов типа «А как это сделать?» к автору ошибки.
Важно! То, что очевидно для вас, не всегда очевидно для другого человека.
Лично я использую 2 приёма оценки очевидности своего описания:
1) Представить, что видишь интерфейс впервые;
2) Спрогнозировать вопросы, которые могут появиться у читателя.
8. По пунктам
Хорошая практика – разбить шаги воспроизведения на пункты. Это даёт 2 главных преимущества:
1) Упрощается прохождение шагов воспроизведения.
2) Появляется возможность сослаться на некоторый пункт.
Пример:
1) Открыть справочник категорий.
2) Добавить новую категорию. Сохранить, закрыть справочник.
3) Повторить пункты 1 и 2.
Или
1) Создать карточку документа.
2) Создать карточку документа другого вида.
3) Открыть карточку, созданную на шаге 1.
Сколько действий должен содержать один пункт? Вопрос, на который все тестировщики отвечают по-разному.
Я считаю, что общее количество пунктов должно быть не более 5-6, последующие пункты уже воспринимаются сложнее, первое преимущество теряется.
Один пункт должен содержать набор действий, позволяющий достичь некоторой точки. Такой точкой может быть возникновение системного сообщения, создание некоторого артефакта в системе – всё, на чём можно приостановить воспроизведение.
9. Однозначность
Речь наша богата синонимичными словами и словосочетаниями, одни из них уместны и понятны всем, другие – не очень. Я придерживаюсь следующих трёх принципов.
Первый принцип – избегать жаргонных слов и слов с размытым смыслом.
Пример:
Плохо – «система ругается», «клацнуть в молоко», «окно уезжает за экран», «кансельнуть».
Хорошо – «выдаётся необработанное исключение», «кликнуть в пустое место окна», «окно перемещается за пределы экрана», «отменить».
Второй – использовать принятые в вашей команде слова. Второй принцип иногда может исключать первый. Например, если все поголовно в компании говорят «задизейблено» вместо «неактивно», значит, употребление этого слова будет более понятно остальным членам команды. Никто же не ходит в магазин за гальваническим элементом, все ходят за батарейками.
Важно! Если разные коллеги говорят по-разному (кто-то «хинт», кто-то «подсказка»), для эффективности дальнейшего поиска такой ошибки лучше при описании употребить и то, и другое слово.
Третий – одно из правил, провозглашённых в фильме «Посвященный», — «Правильно употребляй слова». Например, иногда словом «символ» заменяют слово «буква», но это разные входные данные, не следует их путать.
10. Перечитать
После того, как вы написали и откорректировали описание ошибки, обязательно перечитайте от начала и до конца. Возможно, вы найдёте опечатку, нечаянный повтор слова, лишний символ или что-то в этом духе. Поскольку взгляд замыливается от чтения собственного текста, я использую метод переключения внимания – увожу взгляд буквально на пару секунд на растение в горшке или соседа слева, а потом возвращаюсь к тексту.
Дополнительно я советую почитать книжку Ли Лефевера «Искусство объяснять. Как сделать так, чтобы вас понимали с полуслова».
Учитесь доносить свои мысли грамотно и понятно, чтобы вас было легко и приятно читать. И да пребудет с вами сила!
P.S.: Убийца – дворецкий, а тот «невероятный кусок текста» из начала статьи должен был выглядеть вот так:
«Не помещаются полностью названия файлов в файловом контроле документа при наличии нескольких файлов.
1) Создать любой документ УД. Оставить в режиме окна, не переходить в полноэкранный.
2) Добавить более 1 файла на вкладке Регистрация в файловый контроль (командой контекстного меню или перетаскиванием).
Результат: Названия файлов видны не полностью. Недостаточно места для отображения названий файлов при размере окна по умолчанию.
Ожидаемый результат: Названия файлов должны отображаться полностью.»
Поиск багов как образ жизни
Введение
В повседневной жизни мы уже чаще пользуемся сайтами и мобильными приложениями, чем прикладными программами для компьютера. В этой сфере проектов с открытым исходным кодом очень мало. Большинство проектов – продукты крупных компаний, имеющих несколько линий поддержки. Сообщить о баге через первую линию поддержки — практически бесполезное занятие. Особенно остро проблема стоит с банковскими приложениями. А сайты? Владельцы сайтов часто вообще не имеют команды разработки. А если через сайт предоставляется какая-нибудь услуга, то общение с менеджерами этих сервисов проходит ещё хуже, чем с первой линией поддержки. Самые интересные истории будут ниже. Надеюсь, они помогут компаниям обратить внимание на качество своих программных продуктов.
Баги на сайтах
Телеканал 2×2
Пожалуй, 2×2 — единственный телеканал, который я смотрю. Никакого телевидения у меня не подключено, и я был очень рад, когда на сайте появился прямой эфир. Имея в наличии телевизор с доступом в Интернет, это было идеальным решением для меня – смотреть телеканал онлайн. Но на деле оказалось всё намного сложнее.
Прямой эфир через браузер на телевизоре не работал. Т.к. сообщать о багах разработчикам – часть моей трудовой деятельности, я быстро нашёл контакты на официальном сайте и попытался сообщить о проблеме. Почему попытался? За 2 месяца не удалось получить никаких ответов с двух почтовых адресов. И в группе ВК ничего дельного не ответили (маркетологу, раскручивающему группу в соц. сетях, явно было не до меня с неработающим сайтом).
Но я не отчаялся. Проблема была явно в трансляции и мне удалось её отследить. Она шла с серверов Rutube. Около месяца ушло на попытки связаться с их специалистами. Самое удачное общение произошло с администратором группы Rutube в VK. Мне дали контакты системного администратора. На письмо ему оперативно ответил его коллега, и мы договорились провести подключение, чтобы записать логи. Оказалось, сервер не был настроен для такого подключаемого клиента (телевизор с Tizen). На решение проблемы ушло 2 часа. Спасибо Алексею Лебедеву из Rutube и админу группы в ВК, которые единственные ответственно отнеслись к своей работе во всей этой цепочке «контактов».
Ресторан MaMa Mia
На сайте MaMa Mia нельзя оплатить заказ Online. По крайней мере, это не получилось у меня. А причина, как потом выяснилось, низкое качество кода. Но давайте по порядку.
Когда корзина полностью была сформирована, кнопка «Оформить заказ» не подавала никаких признаков жизни. А потом в почте я обнаружил это:
Каждый клик по «неработающей» кнопке формировал новый заказ. Как видите, я не отказал себе в удовольствии хорошенько протестировать этот баг 😀
На сайте отсутствует форма обратной связи и какие-либо другие контакты, кроме телефона. Там, конечно же, отвечают менеджеры, далёкие от подобных проблем. С группой ВК этого ресторана такая же ситуация. Более-менее релевантные проблеме контакты мне получить не удалось.
На самом деле, это серьёзная проблема для бизнеса, когда некоторые недоработки, особенно с финансами (я ведь хотел оплатить заказ, но не смог), остаются незаметными для руководства. Более того, даже мы сами недавно умудрились попасть в подобную ситуацию, когда на пять дней сломалась форма запроса триального ключа. Мы очень сожалеем о потерянных пользователях 🙁 А в ресторане, видимо, нет.
Не получив никакой отдачи от общения с менеджерами, я открыл консоль браузера и начал смотреть (кстати, в web-разработке я практически не разбираюсь):
Да это же неперехваченное исключение! Какая красота. Вот тут-то точно статический анализатор мог бы помочь.
С помощью пары запросов поисковику удалось выяснить, что это счётчик для Яндекс.Метрики. Интерпретация страницы просто прекращается после отказа любого внешнего компонента. Как говорится, на разработку было выделено много рублей… Так почему же кидается исключение? В моём браузере было установлено расширение Kaspersky Protect. Отключение разного рода маячков и счётчиков, видимо, входит в защиту от отслеживания, включенного по умолчанию. Это было причиной проблемы. Заказ еды я потом сделал на другом, более технически продвинутом сайте.
К сожалению, эта проблема довольно распространена. Только после этого случая я понял непонятное поведение и других сайтов, которые мне встречались. Надеюсь, у web-разработчиков, попавших на эту статью, опыта прибавится.
ЛК Ростелеком
Наверное, у каждого россиянина найдётся история «интересного» общения с представителями Ростелекома. Но моя будет про небольшой баг. В поддержке ответили, что так не считают, но программисты прикол поймут.
Скриншот из моего личного кабинета:
В базе данных хранится значение NULL, представители Ростелекома считают нормальным выводить это значение на экран. По-моему, это совсем ненормально. Возможно, я просто мыслю как C++ программист, и меня настораживает это значение 😀
Мобильные приложения
РЖД Пассажирам
В мобильном приложении РЖД встретилась интересная ошибка.
Скрин из мобильного приложения:
Параграфы документации хранились в массиве и выводились на экран в обратном порядке. Разработчик что-то напутал с сортировкой или счётчиками циклов в коде. В последней версии приложения этот баг исправлен.
ВТБ-Онлайн
Это был прекрасный банк с удобным приложением. Но летом 2019 года, видимо, в команду пришёл «эффективный» менеджер, и приложение испортилось. Самым большим преимуществом для меня была удобная и быстрая поддержка. Но летом 2019 года начались эксперименты с ботом в чате поддержки. Этот бот был очень сильно забагован. Как минимум на протяжении 3-х месяцев в чате поддержки был жёсткий рассинхрон. На сообщения никто не отвечал, чат пустовал, а после перезагрузки приложения выяснялось, что чат наполнен сообщениями бота, но они выводились только после перезагрузи. Но тогда сеанс уже закрывался, и со следующим сообщением повторялся тот же самый баг. По электронной почте поддержка ВТБ всегда быстро реагировала, но ничего не делала по существу.
Последней каплей для меня стал ещё один баг в чате поддержки, который до сих пор не исправлен:
Приложение тупо не загружает скриншоты с телефона, на котором работает приложение. Это Epic Fail. Я отказался от карт банка и свёл оставшиеся активности в банке к минимуму.
Сбербанк Онлайн
Возможно, самый забагованный банк в России. Среднее время исправления подтверждённого бага по моей многолетней практике – 1 год.
Вот самый вопиющий, на мой взгляд, случай.
При передаче показаний приборов учёта для оплаты жилищно-коммунальных услуг (далее ЖКУ) вас ждёт неприятный сюрприз:
Поясню дополнительно: показания ПУ принимаются с точкой, а для ввода на клавиатуре есть только символ «запятая».
Этот баг откровенно мешал пользоваться приложением, и я часто обращался в поддержку за его исправлением. С момента обнаружения баг просуществовал 6 месяцев (февраль-июнь). После чего, в июльском обновлении, его исправили, включив стандартную клавиатуру. Но это не конец истории! В следующем же месяце (август) в очередном обновлении приложения вернули клавиатуру без нужного символа! Я не знаю, что могло произойти в команде разработки, что пришлось делать такой откат изменений, но банком я пользоваться перестал. Это был один из многочисленных багов, и они практически не исправляются.
Связь с поиском ошибок в коде
Появление описанных проблем и ошибок имеет определённые причины. Это недочёты в процессе разработки программ, а также в организации работы сотрудников в целом. От написания кода до доставки приложения пользователю проходит несколько этапов.
Выявленные проблемы – это, в первую очередь, допущение отделов тестирования. В крупных компаниях это обычно большие команды, занимающиеся только тестированием. Но их эффективность может страдать от разных факторов.
Один из важных факторов, ухудшающий работу тестировщиков, – ошибки, которые можно было исправить ещё на этапе написания кода. Обработка найденных багов отнимает время нескольких людей. Но некоторые из них могли бы и не дойти до тестировщиков, что, в свою очередь, сэкономило время тестировщиков. Они бы потратили его на более продуктивное и высокоуровневое тестирование.
Так, наша команда разработчиков анализатора кода PVS-Studio продвигает методологию статического анализа. Это этап разработки программного обеспечения, который стоит перед передачей приложения в отдел тестирования. По нашему опыту, большинство ошибок являются недочётами этапа разработки. И их можно исправить на раннем этапе, сэкономив время и деньги.
К сожалению, в отличие от программ с открытым исходным кодом, тут у меня нет возможности самостоятельно проверить код на наличие ошибок. Но если код написан на C, C++, C# или Java, то этим командам было бы полезно зайти на сайт и прогнать анализатор на своём коде. Для программ с открытым исходным кодом делается очень большой вклад этим инструментом.
Заключение
Замечать баги в используемом программном обеспечении я уже не перестану. Наверное, это не самое страшное, что могло произойти. У меня есть знакомые, которые работают в кинематографе (мультипликация). Так вот они замечают баги при просмотре мультиков, и это доставляет неудобство. По-моему, это даже хуже. Программы хотя бы можно доработать, в отличие от отснятого материала.
Как вы заметили, с поддержкой пользователей совсем всё плохо. Причём это характерно именно для крупных компаний. Им практически невозможно что-то сообщить и поделиться своим опытом. Некоторого успеха я достиг при посещении конференций для разработчиков. Там часто и присутствуют крупные компании, и некоторые вопросы реально можно обсудить и решить.
Если вам понравится новый формат обзоров багов и историй с ними, то я продолжу в том же духе.