«Мы всегда на стороне пользователя»: кто и зачем ищет ошибки в решениях «1С»

Любое IT-решение в идеале должно быть эффективным и надёжным для пользователей. Если, к примеру, программа по управлению бизнес-процессами раз за разом выдаёт ошибку, компания не может нормально работать, а значит – теряет деньги. О том, как фирма «1С» выявляет возможные ошибки в линейке IT-решений для малого бизнеса и розницы, и как устраняются уже возникшие сложности, порталу Biz360.ru рассказал Дмитрий Кузькин, руководитель группы тестирования.

Наша группа тестирования следит за качеством программ, составляющих линейку решений для малого бизнеса «1С». Мы отвечаем за то, чтобы в работе продуктов «1С:Рабочее место кассира», «1С:Розница», «1С:Управление нашей фирмой» и сопутствующих мобильных приложениях не было ошибок.

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

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

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

Начну с самого интересного в нашей работе – расследований. Да-да, тестировщики проводят расследования. Мы стараемся «поймать» все ошибки на этапе тестирования (о чём расскажу чуть позже), но иногда первыми их находят пользователи и сообщают об этом нам. Мы должны воспроизвести цепочку действий, которые привели к данной ошибке. Ведь пользователи не всегда прикладывают сценарии или описание вроде «Я зашёл в такой раздел, нажал на эту кнопку, загрузил вот этот файл» и так далее. Это и есть расследование.

Расследование ошибок может занимать и 5-10 минут, а может и полдня. С нашими программами работают предприниматели из разных сфер (продажи, услуги, производство и др.) и сценарии, которые они используют, тоже могут сильно друг от друга отличаться. Кто-то с помощью «1С:УНФ» печёт и продаёт хлеб, а кто-то изготавливает мебель. Иногда к ошибкам приводит наличие определённых данных, характерных только для данного вида бизнеса. И не сразу понятно, почему пекарни нормально пользуются нашим продуктом, а на производстве мебели появляется ошибка. Мы видим только часть кода с ошибкой, а потом выясняем, какие действия пользователей к ней привели.

Ошибка глазами пользователя

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

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

Если пользователь обнаруживает ошибку в наших продуктах, то может сообщить нам о ней несколькими способами.

• Написать в специальной форме оповещения об ошибке прямо в программе.

• Обратиться к партнёру 1С, который предоставил данное решение.

• Написать или позвонить в отдел техподдержки.

Мы, со своей стороны, следим за сообщениями пользователей, в том числе, и в специализированных Telegram-каналах. Это тоже позволяет нам оперативно узнавать о возникающих ошибках.

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

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

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

Допустим, готовится новая версия решения «1С:Управление нашей фирмой». И разработчик сделал для неё новый отчёт или документ, которых раньше в программе не было. Он готовит техническое описание проекта – что и как должно работать. Тестировщик получает проект с описанием, после чего составляет план тестирования. Затем он руками, как пользователь, выполняет те или иные операции – заходит в разделы, активирует нужные ему опции, проводит документы, наполняет справочники и так далее.

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

Каждый тестировщик, как и разработчик, отвечает за разные подсистемы программы. А каждая новая масштабная версия включает по 100-150 проектов. И все эти проекты обязательно должны пройти через тестировщика.

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

Ошибка, зарегистрированная по результатам автотеста

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

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

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

Робот провел тестирование и в 94% сценариев не нашел ошибок

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

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

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

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен». 
biz360  biz360