Блог инженера-тестировщика Getgear

Блог инженера-тестировщика Getgear
Производитель: GetGear
Модель: Блог версии 1.0 :)))
Наличие: Есть в наличии

15.10.2019

От Васи Викинга

 

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

После этого открываю еще один чек и добавляю товарную позицию без каких-либо тегов. Закрываю чек и получаю на выходе испорченные TLV-данные, а именно в операцию, судя по тест драйверу, попал какой-то странный тег «0, НЕИЗВЕСТНЫЙ ТЕГ». Также данный чек неправильно воспринимается ОФД, а именно нет тегов в графе «Предмет расчета». И эта проблема распространяется на ВСЕ следующие документы. Тег 2131 больше не получается добавить, по крайней мере через тест драйвера.

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

 

 

07.10.2019

От Графа Виктора

 

Расскажу несколько багов из собственного опыта тестирования пинпадов. Для тех, кто не знаком в общих чертах с терминологией и работой данных устройств, следует пояснить – по сути, пинпад является просто клавиатурой, предназначенной для более удобного ввода пин-кодов клиентами, использующими в качестве оплаты банковские карты, т.е. пинпад всегда является периферийным устройством для какой-либо кассы/POS-терминала. Некоторые пинпады представляют собой просто клавиатуру, в некоторые можно вставлять карты, а какие-то поддерживают технологию бесконтактных платежей. В любом случае, основные функции устройства от этого не меняются. Лично я тестировал пинпад с поддержкой карт и NFC-модулем. Вот некоторые баги, которые я могу припомнить:

  1. Формирую чек на ККМ. После этого начинаю оплату на пинпаде. Вставляю карту и жду, когда пинпад попросит её удалить. После появления данного сообщения я отсоединяю пинпад от кассы, потом опять его подключаю. В итоге получается ситуация, что ККМ находится в режиме «ПИНПАД», пинпад ждёт команды от ККМ. Если перезагрузить кассу, то чек аннулируется, но возврата денег не будет, слип-чека не будет, оформить возврат не получится.
  2. После формирования чека на ККТ я пробую оплатить чек через пинпад с помощью карты МИР. Карта только с чипом, без NFC-модуля. После ввода пин-кода касса начинает обрабатывать запрос, слать информацию на сервер и ждать ответа. Приходит отказ. Пинпад просит извлечь карту. По того, как карту вынули, касса продолжает печать чека и на половине первого слип-чека останавливается. В это время пинпад выходит из платежного приложения.

 

 

23.09.2019

От Миши Философа

 

На днях я тестировал очередную версию прошивки для ФРов и столкнулся с достаточно смешной ситуацией. Ситуация заключалась вот в чём: работал я спокойно с кассой в штатном режиме, периодически нажимая кнопку прокрутки бумаги, которая находится на корпусе. И спустя несколько десятков нажатий эта кнопка просто взяла и отвалилась :)

Физически на схеме при этом никаких проблем, связанных с кнопкой, не было.

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

 

 

 

16.09.2019

От Васи Викинга

 

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

Это меня, мягко сказать, удивило, о чём я сразу же отписал в нашей системе баг-трекинга Мантисе. Реакция разработчика, видимо, была примерно такой же, поэтому он стал спрашивать, включено ли у меня кодирование в UTF-8, точно ли это не глюк сканера, после чего заявил, что у него проблемы такой вообще нет. Спустя какое-то время в обсуждение включился его коллега, ошибку признал и сказал, что поправит в следующем патче.

Дело оказалось вот в чём: наш кодировщик по какой-то причине считал, что буквосочетание «ме» из слова «изменилось» закодировано в китайской (!!!) кодировке Kanji, из-за чего происходил развал всей строки.

 

 

02.09.2019

От Миши Философа

 

Однажды, во время тестирования очередной прошивки для очередной кассы я столкнулся с презабавнейшим багом. В прошивке кассы можно присвоить наименования отделам, которые будут печататься в чеке (Отдел #1, Отдел #2 и т.д). В таблице с отделами была предусмотрена максимальная длина возможного названия в 8 символов. Решил сразу проверить граничные значения и вбил по 8 символов в первые 4 отдела. Открываю чек, выбираю первый отдел, добавляю позиции. Закрываю чек, начинается печать. Смотрю, а в названии отдела на чеке одно неприлично большое слово!

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

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

 

 

26.08.19

От Васи Викинга

 

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

Касса загрузилась после включения-выключения, я отправляю команду на продолжение печати. Чек печатается. Отлично! Только вот напечатался он без тех дополнительных тегов, которые я в него добавлял. И это уже не отлично, а самый настоящий баг, причем серьезный. Протестировал аналогичную ситуацию, только вместо принудительной перезагрузки я смоделировал окончание чековой ленты. При таких условиях описываемый баг где-то каждый десятый раз, но всё-таки вылезал. В следующей сборке разработчик его поправил, само собой.

 

 

 

19.08.19

От Миши Философа

 

На описываемый мною момент я занимался тестированием прошивки ККТ. Для начала следует сказать, что такое компактный заголовок. Компактный заголовок – это определенный формат чека, в котором некоторые данные группируются немного иначе, чем в стандартном чеке, что позволяет в каком-то смысле сокращать расход чековой ленты. При компактном заголовке на чеке доступны (при отправке команды с определенным тегом) некоторые дополнительные поля, чтобы, например, указывался остаток бонусов клиента по программе лояльности магазина и т.п.

Так вот, тестировал я работу кассы при печати фискальных документов с компактным заголовком. В какой-то момент очередь дошла до проверки корректности печати этих «специальных» полей (их было два), по умолчанию на печать выводилась фраза «Бонусы». Прошивкой было предусмотрено заполнение этих полей текстовыми символами (не более 32-ух). Ну, так как мы всегда должны в первую очередь проверять граничные значения, я вбил слово длиной 32 символа. Вот что получилось на печати при отправке первого тега:

А вот что получилось при отправке второго тега:

Баг был описан мной, фотографии чеков прикреплены. Через несколько дней разработчик выкатил новую прошивку, где якобы эти баги поправлены. Я стал проверять – баги на месте.

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

 

 

 

06.08.19

От Миши Философа

 

Лето, все на отдыхе в отпусках, поэтому небольшой профессиональный анекдот:

 

Заходит однажды тестировщик в бар.
Забегает в бар.
Пролезает в бар.
Танцуя, проникает в бар.
Крадется в бар.
Врывается в бар.
Прыгает в бар

и заказывает:

кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
–1 кружку пива,
qweasd кружек пива.

В итоге один из посетителей вьезжает в бар на тракторе и всё зависает. Виноват опять тестировщик!

Всем хорошего отдыха! :)

 

 

 

19.07.19

От Миши Философа

 

Занимался я тестированием сайта крупного интернет-магазина. Непосредственно база данных была реализована на 1С, сайт же –  на платформе Битрикс. Для начала я, чтобы найти самые серьезные и очевидные баги, стал имитировать действия потенциального клиента. Заполнил все формочки регистрации (ФИО, почта, контактный номер телефона) и, как следствие, зарегистрировался. Потом пошел в каталог, выбрал товарную единицу и сделал заказ, указав опять-таки имя, тип доставки и телефон.

Всё, заказ «клиентом» сделан, далее ему остается только ждать, когда с ним свяжется менеджер. Теперь имитирую действия менеджера. Произвожу синхронизацию сайта с БД и открываю только что сделанный заказ в 1С. В нём на первый взгляд всё нормально и, в принципе, можно его закрывать и заниматься тестированием дальше. Но ведь нужно сымитировать последовательность действий полностью!

Что должно идти дальше? Менеджер должен связаться с клиентом для подтверждения заказа. Смотрю контактные данные клиента, вижу почту. Отлично. А где телефон? Смотрю: поле «Телефон» пустое, то есть при выгрузке заказа номер телефона в базу данных не попал. Баг, причём крайне серьёзный! Описываю его подробно в Мантисе и кидаю разработчикам 1С. Спустя какое-то время получаю ответ, мол, база данных работает исправно, и xml-файл, который приходит в 1С после оформления заказа, вообще не содержит сведений о телефоне. Короче говоря, проблема не по адресу.

Хорошо, я стал пробовать донести данный баг непосредственно до сайтовиков (которые, несмотря на свою обязанность поддержки, на связь выходили очень неохотно). Проблему донёс, но никакого внятного ответа не получил. Спустя несколько дней получаю-таки ответ: «Проблема решена, поле «Телефон» в xml-файл добавлено». Отлично! Но основное правило тестировщика – это НЕ доверяй и проверяй, поэтому опять делаю заказ с сайта, указываю номер телефона и иду смотреть заказ в 1С. Всё работает! Делаю еще один заказ, но указываю другой контактный номер. Смотрю: в базу вместе с этим заказом попал номер из первого заказа. Опять баг и опять серьезный. Через несколько дней получаю ответ, что всё исправили и вот теперь уж точно всё работает корректно.

Вновь начинаю проверять. Делаю заказ и иду открывать его в 1С. Открыл. Увидел следующее:

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

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

 

 

17.07.19

От Эдика Шахматиста

 

О важности логирования.

Работаем вместе с разработчиком с новым оборудованием, под него софта не было, всё с нуля.

Разработчик пишет прогу, мы тестим. Сразу говорю: «Логируй всё что делаешь», разработчик –   сама уверенность, ведь он плохого не напишет.

Ну и естественно в итоге куча багов :) Разработчик не поймёт в чем дело, где ошибка, нам тоже ничего не понятно, лог-то практически пустой.

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

Мораль: не пренебрегайте логированием! :)

 

 

15.07.19

От Эдика Шахматиста

 

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

И вот 2 часа до новогоднего корпоратива, но работа продолжает кипеть:  пишем очередной вопрос-замечание: "Реализован ли автоматический перевод времени на летнее и обратно в терминале?", оформляем в баг-трекинг.

Через 3 часа видим ответ: "Иди нахрен, заколебал."

Всех с Новым Годом!!! :)

 

 

08.07.19

От Василия Викинга.

 

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

Как уже было сказано ранее, у нас самым частым объектом тестирования является кассовая техника. А как известно, в нынешнее время кассовый чек должен строго соответствовать федеральному закону № 54. Одна из частей чека, которая должна обязательно быть в него включена, — QR-код, в котором хранится техническая информация для того, чтобы клиент мог впоследствии его легко найти.

Итак, приходит новый для меня аппарат с новой прошивкой. Каждый раз, когда держишь в руках новый аппарат или получаешь какое-либо ПО, имеешь прекрасную единоразовую возможность провести абсолютно слепое тестирование. Выглядит это примерно так: не читая инструкцию, ничего не слушая, начинаешь тыкать в любую кнопку, какую только находишь. Именно потому, что ты, тестировщик, еще ничего не знаешь про данный продукт, не знаком с его логикой работы, можешь с довольно высокой вероятностью произвести какой-нибудь набор действий, который приведет к какому-нибудь багу. Так вот, я сижу, тыкаю кнопочки на кассе и в какой-то момент вижу, что на чеке нет QR-кода. “Что за фигня?” — подумал я. Повторяю действия – есть QR-код, повторяю еще раз – нет QR-кода. Отлично, походу это баг!

Но вот засада. Подходит в отдел тестирования разработчик. Повторяю свой ритуал… QR-код есть. Еще раз колдую над кассой, опять всё работает как надо! Ну, на третий раз, наверное, получится? А вот нет. Ладно. Берет разработчик аппарат в руки, и у него тут же всплывает ошибка. Посмотрел он на это дело и с непонимающим выражением лица куда-то ушел. Тут следует еще раз напомнить, что сейчас 2019 год на дворе, и все кассы должны передавать чеки через интернет в налоговую. Зачем это нам нужно, спросите вы? Всё очень просто. Как оказалось, wi-fi модуль на данной кассе также занимался формированием QR-кодов. И баг происходил из-за того, что если касса в данный момент времени пытается совершить передачу документа, т.е. wi-fi модуль занят, то QR-код напечатан не будет, так как касса не интересовалась его статусом и считала, что он всегда мог принять команду на его (QR-кода) формирование.

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

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

 

 

02.07.19

От Миши Философа

 

Однажды, при тестировании сайта интернет-магазина, реализованного на системе 1С – Битрикс, я столкнулся с достаточно забавным и в то же время крайне опасным багом.

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

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

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

 

25.06.19

От Дениса Космоса

 

К нам на тестирование попал прайс-чекер ЗНАЙТ Z-Info. Удивительно, но это оказался один из немногих аппаратов, проверка которых не выявила ни одного серьезного бага.

В первую очередь следует сказать: производитель настолько заинтересован в качестве своего продукта, что помимо собственного отдела тестирования привлек еще и сторонних тестировщиков. А это говорит о многом.

Мы не нашли ничего криминального за нашими коллегами из компании Знайт, поэтому и решили написать, что можем смело рекомендовать данный продукт как ОЧЕНЬ качественный!

 

18.06.19

От Графа Виктора.

 

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

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

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

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

Разработчики писали версию одну за другой, ошибки выскакивали то на 300-ой отрезке, то на 100-ой. Вышла прошивка, после которой удалось сделать всю тысячу отрезок, но откатившись на старую прошивку, мы снова поймали описанный баг на 200-ой отрезке. После этого вернулись ещё раз на последнюю прошивку, где баг вылез вновь на 80-ой отрезке.

В конце концов решение было найдено. Вышла прошивка, которая исправляет этот несчастный баг. Мы сделали более тысячи отрезок, и ошибка так и не появилась. Ура, с багом боролись около трёх месяцев, но он был побеждён.

 

10.06.19

От Миши Философа.

 

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

 

03.06.19

От Василия Викинга.

 

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

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

Сначала на кассу посылается команда открытия документа. Затем на неё по очереди, строка за строкой, посылаются команды с информацией, например: строка с текстом, товар (цена, количество, наименование) или просто какие-нибудь дополнительные данные, имеющие строгий формат. После закрытия документа происходит его сохранение на фискальный накопитель, печать, если она включена, и обнуление буфера документа (при этом обнуления буфера происходит только по факту завершения печати, на случай если во время печати что-то произойдёт, например, кончится бумага или случится потеря питания). ФН —это такое внешнее устройство, которое выполняет две вещи: генерирует уникальный номер и хранит в себе все созданные документы (касса, кстати, не должна работать без ФН, кроме крайне редких случаев). Очень важно, чтобы на ФН документ был сохранён правильно, потому что именно с ФНа документ отправляется на хранение в ОФД (это такие компании, которые занимаются обработкой и хранением документов перед последующей отправкой в налоговую).

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

И вот, в очередном апдейте выходит поддержка новых Тегов, утверждённых налоговой. А значит, надо проверить их на соответствие документу, который их описывает. Ну и вообще, что они теперь действительно поддерживаются устройством. Запускаем наше устройство, проверяем, что оно подключено к компьютеру и стартуем тестировочное ПО. Открываем документ, добавляем в него новые теги, и пока ошибок нет. Закрываем документ, всё правильно печатается и правильно сохраняется в электронной форме (в ФН). Повторяем процедуру, на этот раз при попытке добавить один из новых тегов касса возвращает нам ошибку. Пробуем его распечатать, получается. Вся информация, кроме тега, который не получилось добавить, присутствует. Однако, при проверке документа в электронной форме обнаруживается одна очень серьёзная проблема: там откуда-то взялся пустой несуществующий тег. Может быть, это произошло во время получения ошибки от кассы? Надо проверить! Открываем документ, не добавляем в него никакой дополнительной информации, сразу закрываем. При печати опять нет никаких ошибок, однако в электронной форме снова есть этот несуществующий тег. Это не очень хорошо, потому что все документы, в которых есть этот артефакт, могут восприниматься ОФД как недействительные. Также необходимо понять, какое действие сможет вернуть кассу в нормальное состояние. Пробуем перезапустить, новые чеки все ещё содержат этот артефакт. Пробуем поменять ФН, ошибка на месте. Пробуем провести технологическое обнуление… артефакт исчез. Теперь мы почти полностью уверены, что это была программная ошибка. Но при этом не очень понятно, откуда она могла взяться. Ведь добавленный тег хранится в буфере кассы только до тех пор, пока документ не сохранён на ФН и не произведена его печать. Возможно, при его добавлении происходили изменения настроек самого устройства, либо же почему-то ломалось очищение буфера.

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

 

 

27.05.19

От Миши Философа.

 

– Видишь баг?

– Нет

–Вот и я не вижу. А он есть

 

Описываемый случай произошёл, когда я занимался тестированием платформы 1С – Битрикс. Создаю профиль на тестируемом сайте, заполняю все необходимые данные формы – имя, фамилия, электронная почта, телефон и логин, по которому, собственно, и будет осуществляться последующих вход в учётку. После успешного создания профиля произвожу синхронизацию с базой данных, и наш «клиент» после этого попадает в 1С. Вношу непосредственно в базе данных некоторые корректировки нашему «клиенту», а если быть точным,– меняю ему сегмент (проще говоря, чтобы с этой учётки была возможность приобретать товары по цене ниже, чем розничная). Сохраняюсь и вновь произвожу синхронизацию. Забиваю на сайте данные для входа и получаю в ответ: «Неверный логин или пароль».

 

Я не понимаю, что произошло, и пытаюсь войти снова. «Неверный логин или пароль». После некоторого времени, потраченного на перепроверку вводимых данных авторизации, я обнаруживаю,что после синхронизации 1С – Битрикс логин клиента исчез, и на его место встал почтовый адрес. Написал данный критичный момент разработчикам, на что получил ответ, что так мол и так, нет такого бага, воспроизвести его не получилось.

 

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

 

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

 

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

 

 

21.05.19

От Василия Викинга.

 

Чукча не писатель. Чукча — читатель.

Чем больше аппаратуры покрывает ПО, тем проще упустить какую-то мелочь.

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

Любое тестирование новой прошивки всегда начинается с её установки на аппарат. Затем нам необходимо подключиться к компьютеру и запустить тестировочное ПО.
Именно поэтому, казалось бы, проблемы в новой прошивке, если они есть конечно, должны были показаться практически сразу. Однако не всё так просто!
Различных моделей достаточно много, и чем больше моделей ты уже протестировал, тем больше у тебя уверенности в том, что новая версия прошивки не имеет проблем.
Но всё равно, ни в коем случае нельзя пренебрегать каким-либо тесткейсом, даже если он работал на 20 предыдущих моделях, а у тебя на столе лежит последняя, 21ая.
И вот, я уже готов утверждать, что действительно работа по RNDIS стала гораздо лучше и стабильнее, но не тут-то было. Именно последняя модель, за которую я взялся, выявила проблему.
Проблема, которая была специфична только для неё. Аппарат просто отказывался подключаться!
Сразу же был написан баг репорт. На следующий день он был подтвержден разработчиком, и прошивка отправилась на доработку.

Мораль проста. Даже если вам кажется, что с 99% вероятностью никаких проблем нет, всё равно нужно проводить проверку. А лучше несколько раз.

 

17.05.19

От Эдика Шахматиста.

 

Порой приходится быть не просто тестером, а сыщиком, и расследовать -  кто же виноват?

Итак, начнём.

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

Понадобилось с помощью ридера не только производить оплаты проезда по картам Mifare, но ещё и на карты контроллера записывать номера оплативших карт.

И тут загвоздка: почему-то не пишутся номера - ошибка авторизации к карте контроллера.

Пишем разработчику ПО. Тот даёт версию - не помогает. Пишем снова. Разработчик говорит: "Не понимаю! Пытаюсь авторизоваться разными способами, ничего не выходит!"

Снимаем ридер с терминала, подключаем к компу, прогоняем карту - все хорошо читается и пишется. Ставим обратно на терминал - не пишутся номера. Разработчик уже на ридер указывает мол в нём что-то не так, у себя в коде ошибок не видит.

Ищем разработчика ридера, узнаем как можно прослушать работу ридера.

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

На полученной диаграмме видим следующее: зачем-то на карту ?

Метки:
GetGear © 2019