пятница, 24 июля 2015 г.

Классы эквивалентности: будни Золушки

Позор тебе! — кричит начальник, найдя в приложении баг. Даже если не кричит, все равно стыдно: как я могла пропустить такое? Это же так очевидно, почему же не учла? Потому что не подумала об этом классе эквивалентности.


Искать классы эквивалентности сложно даже мне, тестировщику с 7+1-летним опытом — что говорить о моих студентах. В книгах и на лекциях ребятам все понятно. Но как только доходит до практики, начинается ступор. Как же их искать, классы эти? Я придумала аналогию с диснеевской героиней — Золушкой. Ребята говорят, лекция стала понятнее.


Будни Золушки



Мачеха рассыпала на полу гречку и овес, перемешала и сказала — «Разбирай!». Золушка три часа раскладывала кучки. Итог мучений — гречка к гречке, овес к овсу.


mixed-groats-image.jpg  mixed-groats-macro-17517869.jpg
                           ↓
Рисунок4.jpg
В каждом мешке своя крупа  — свой класс эквивалентности


В тестировании то же самое: выделяем классы эквивалентности (крупу), ищем исключения, перепроверяем. Результат — ошибки находят тестировщики, а не начальство.

Поздравляем Александра с новой работой!

Минутка success-story от моих выпускников (smile)
Вчера вечером в чатике выпускников появился Александр с радостной новостью^

Всем привет!

Хочу поделиться радостной новостью - меня взяли в компанию Х (party) 

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



Я попросила поделиться подробностями и рассказать, какую роль тут сыграл интенсив:

Интенсив дает понимание в общем и уверенность в себе. 

Также спрашивают, какой практический опыт работы есть, какие проекты. Одно дело, когда ты приходишь и говоришь, что почитал книжки и посмотрел видео. Другое дело, когда говоришь «Я целую неделю по 10-12 часов в день тестировал web сайт проекта серьезной российской компании... И вот моя state & transition diagram by the way...»

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

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

Могу выделить два основных момента, на мой взгляд:
1) Статус в резюме (пусть и короткий, но серьезный проект).
2) Этот курс дает возможность «переварить» всю теорию, которую смотрел и читал, разложить все по полочкам, иначе в голове каша.

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

Такая вот история! И отличный кейс — я то советую своим ученикам давать чек-лист как пример своей работы, а Александр показал ДЗ8 — state & transition diagram. Тоже вариант, почему бы и нет (smile)

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

PS — Пополнила этой статьей историю развития курса, приходите к нам 3 августа!

четверг, 23 июля 2015 г.

Музейный тур. The Museum Tour

Входит в «Туры по историческим районам», Tours Through the Historical District

Вольный перевод статьи Виттакера из книги Exploratory Software testing. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!

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


Legacy code — антиквариат разработчиков

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

четверг, 16 июля 2015 г.

Баги повсюду. Сборная солянка

Новички всегда спрашивают — где получать опыт? Где искать баги?
А опытные, блин, на эти баги напарываются чуть ли не на каждом шагу. Да и новички напарываются, просто забывают.

Я хочу показать, как можно замечать проблемы в повседневных вещах. И не просто замечать, а попробовать локализовать, докопаться до сути. Как «красиво» описать баг разработчикам, используя шаблон — чтобы это была не стена мыслей, а простые и понятные шаги для воспроизведения. Какими тестами можно было найти эту проблему — это самая интересная часть! Ведь даже если конкретный баг вам неактуален, чек-лист по поиску может навести на мысли Wink ;)

Я создала лейблы «баги повсюду» и «панбагон» (когда он восстал из пепла в виде группы на фб) и с этих слов начинаю все описания багов, найденных в повседневных вещах. Плюс создала этот пост, агрегирующий все найденные проблемы вместе =)

Тут нет и врядли будут баги по защищенности. Хотя бы потому, что я не эксперт Smile :)
Но я хочу показать, что баги — они действиетльно повсюду. И в приложениях, и в игрушках, и в интернет-магазинах... Ищите, и найдете =)

Кейсы по локализации


Баги


Баги в письмах


Web

Кинотеатр
Тестируем регистрацию на сайте Люксор
NaN при выборе сеанса Перегрин на 10.10 в 16:45
Как кинотеатр зажал мои билеты
Nginx error при просмотре программы лояльности
Не работает фильтр «4DX» по русскому фильму

Интернет магазин Wilberries
Поехала верстка в фотках и это закешировалось
Сообщения об ошибках — тоже документация, тестируйте их!
Смайлики криво логируются в ленте новостей
Не user-friedly сообщение об ошибке при загрузке файла
Найди некорректное сообщение по тексту ошибки
Идеально работает по ТЗ ≠ правильно
Ошибка входных данных, если выбрано 0
Вам не хватает «минус 4 тыс» на балансе
В мобильной версии дата ожидания товара — месяц назад

Другие интернет магазины
Декатлон. Фамилия вводится КАПСОМ
Ошибка 400 при сбросе пароля в партнерке OZON

среда, 15 июля 2015 г.

Тур по плохому району. The Bad-Neighborhood Tour

Входит в «Туры по историческим районам», Tours Through the Historical District

Вольный перевод статьи Виттакера из книги Exploratory Software testing. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!

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

CjlR2Ru0dM4.jpg
Некоторые места лучше обходить стороной… Но не в коде!


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

Используйте баг-трекер для анализа. Посмотрите — в каком компоненте больше всего ошибок? Там и ищите!

111.jpg
Баги общительны…


funny-homer-simpson-chasing-spider-box-animated-gif-pics.gif
Где один, там их много =)


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


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


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

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

В этот раз примера не будет по понятным причинам =)



PS: студентам моего курса по тестированию во время обучения эта статья не поможет, но вот выпускникам во время реальной работы — очень даже!

PPS: статья сохранена на Testbase, чтобы не потерялась ссылка.

понедельник, 13 июля 2015 г.

Тест-кейс VS чек-лист в картинках.

Чем же они различаются?

Официальная часть
Вроде все понятно:

тест-кейсы — подробно;
чек-листы — кратенько.

Но моим студентам все равно тяжело. Зачем в тест-кейсе писать, что именно за файл создается, как его загружать в систему (на какие кнопки нажимать, какие действия выполнять)?

Идея 1


Я предложила им такое пояснение:

Тест-кейсы тупые до невозможности, словно ребенка на работу привели и показываем, "Вот мамочка сейчас файл обработает. Нажимаем кнопочку А, потом кнопочку Б, потом...", а не просто "Ну вот загрузили и все получилось".


Ну а чек-листы — это когда не нужны все эти подробности, как именно мы загружаем файлы, на какие кнопочки нажимаем. Нужна просто напоминалка — «Проверить загрузку Excel, CSV, JPG...»



Ребятам пояснение очень понравилось Smile :)
Сказали, что так понятнее, так что заносим в теорию в картинках!

Идея 2


Вы делали ремонт? Покупали шкафы, собирали их? А я делала и отсюда у меня вторая ассоциация.

Мы купили комод в ИКЕА. Он небольшой и простой в сборке. Но инструкция выглядит как талмуд — все настолько подробно. Каждое действие, каждый шаг. Каждый винтик — все в новом пункте на пол-листа А4, максильно доступно. Такой комод соберет даже полный профан. Потому что ребята не считают нужным пропускать этапы как «Ну это же очевидно, куда ввинчивать этот шуруп». Очень напоминает «Ну это же очевидно, на какую кнопочку нажимать, чтобы загрузить файл» Smile :)


А вот диванчик в коридор мы купили в другом месте. Он тоже небольшой и не сильно сложный в сборке — кубик шкафчика собрать и прицепить к самому диванчику. Но инструкция — полный швах. На ней ровно одна картинка — уже собранный диванчик, все детали чуть на расстоянии друг от друга. Ну это же очевидно, как его собрать!


Мы, кстати, не осилили, оставили мастеру Smile :)

Но разница «Простая инструкция — инструкция из ИКЕА» === «Чек-листы — Тест-кейсы». Когда будете писать тест-кейс, помните об этом и о том, что очевидное вам — темный лес для кого-то другого...

PS — блог-пост добавлен на Testbase в раздел «Теория в картинках», где вы всегда его сможете найти! :-)

Развитие интенсива-14.


С момента прошлых хвастов прошло 2,5 месяца — 2 коротких курса и 2 длинных. Что мы сделали для студентов за это время:

Багред

http://bugred.ru/ — сервис для проверки названий багов.

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

Инструмент полезен в первую очередь мне и моим студентам. Но и не только. Именно поэтому я решила «расшарить знания» на всех и сделала Багред доступным обществу Smile :)

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

Перевод туров

The FedEx Tour.
Интеллектуальный тур. The Intellectual Tour.
— Внеурочный тур. The After-Hour Tour.
— Сборщик мусора. The Garbage Collector Tour.

Статьи

— Ошибка, дефект, сбой
— Как стать тестировщиком, с чего начать
— Сообщения об ошибках — тоже документация, тестируйте их!
— Публичная подсказка к ДЗ6 Smile :)

Все больше материалов! С одной стороны — круто! Проще изучать темы. С другой — тяжко, столько всего надо перечитать! Wink ;) Посмотрим на отзывы ребят...




четверг, 9 июля 2015 г.

Лайфхак. Оформление автотестов в confluence, основная страница

У нас есть пачка автотестов на основной функционал системы. Тесты разделены по разделам, вот тесты на сервисы, вот на задачи...

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

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

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

Тесты на регистрацию — register 
Редактирование профиля в личном кабинете — edit

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

А как удобно? Мне пока больше всего нравится такое решение:

1. На основной странице (у меня это «Unit тесты») делаем простой Children Display, выставив ему галочку «Include Excerts»




Если вы не знаете, где взять Children Display, то см пояснялку в пункте 2. Children Display — такой же макрос, как Excerpt.

2. В дочерних:
  • Название страницы — название папки в коде.
  • Заголовок внутри Excerpt — фраза на русском языке с пояснением, что именно тут проверятся.

То есть нажимаем «Create», стоя на основной странице тестов, в списке выбираем «Blank Page» → у нас создается страница, дочерняя к «Unit тесты».

Нажимаем «+ Insert — Other macros»


Выбираем макрос Excerpt.



Пишем внутри него описание, можно оставить текст параграфом, но мне нравится в виде заголовка. Меняется тип текста на панели инструментов. 



3. Профит! Smile :)
На главной страничке мы сразу видим структуру кода с пояснениями. Страницу не надо редактировать при добавлении или изменении дочерних


вторник, 7 июля 2015 г.

Буквы в телефоне — баг?

Покупала я тут недавно сертификат на «Ужин в темноте».

Выбираешь сертификат, нажимаешь «Заказать» — отображается корзина.
Проверяешь, все ли правильно, нажимаешь «Оформить заказ».

И видишь такую формочку

Форма ввода данных

Ее заполнение вызвало у меня небольшой диссонанс Smile :)

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

Форма говорит, что имя корректное, ура!


Начинаю набирать телефон и смотрю на экран — смогу ли я ввести свой номер как мне удобно или тут маска ввода зашита?

Поясню, мой номер выглядит примерно так: 8 (926) 22-33-456.
Именно так я его и помню, так всегда и называю, когда просят мой номер. И когда меня просят его проверить и называют 8 (926) 223-34-56, это немного коробит. Непривычно, приходится в уме прикидывать, он или не он.

Поле ввода может быть простым текстом, может быть маской. Так что я смотрю на экран, что мне покажется там?

Начинаю ввод и...

Минуточку... Телефон корректный?

Минуточку! Какая галочка? Я еще ничего не ввела!
Почему один символ считаем корректным вводом?

Во мне тут же проснулся тестировщик и попробовал ввести одну букву — тоже работает!

И этот корректный???

Бегом оформлять баг? Wink ;)

Нет уж, давайте разберемся.
Откуда у меня диссонанс — я работаю с данными. Мы умеем проверять качество введенных данных и по Дадате моя картина мира:

  • Зеленая галочка — данные корректные;
  • Красный восклицательный знак — данные плохие;

Зеленая галочка = корректно, в моей картине мира

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

Но давайте посмотрим с точки зрения простого пользователя. Мы не любим запретов, они нас бесят. Ведь зачем все эти ограничения? Чтобы типа помочь «не ошибиться». Но вот только если мне помощь не нужна, я найду способ ее обойти. Вот, допустим, телефон. Ах, вы мне запретили вводить что-то кроме маски? Ну и звоните по общему телефону в нашу компанию, перебьетесь без добавочного.

В Дадате была форма с вводом имени и номером телефона. А куда писать доп инфо? В телефон! Так и пишем: «8 800 2223344, звонить после 11:00» или «8 (495) 222-33-44, доб 4455, звонить до 18:00». Сможем мы перезвонить человеку? Сможем! И не нужны никакие маски. И не нужно ограничивать возможности ввода.

Но как же так? А вдруг пользователь ошибется и введет 10 или 12 цифр вместо 11? И не заметит! О ужас и кошмар, мы ему не перезвоним, пользователь обидится и затаит кровную месть. Встречный вопрос — а если он введет 11 цифр, но ошибется в одной? Все равно ведь мы этому пользователю не дозвонимся, а как система такую ошибку найдет?

Никогда не запрещайте. Система может подсказывать пользователю информацию в его мире. Может помогать не ошибаться. Например, если мы «принимаем» только мобильные телефоны в России, то можно и маску на поле повесить. Но всегда стоит задуматься, а действительно ли эта информация нам жизненно необходима? Может, сделать поле необязательным? Или расшифровать — зачем собираем информацию. Вот как выше на картинке, поле с id в ВК необязательно, но, заполнив его, получаешь плюшку! Вот это я понимаю, стимул для заполнения Smile :)

В случае же ввода телефона в «Ужине в темноте» бага нет. У них есть несколько полей. Я могу ввести только свое имя и адрес доставки и не оставлять телефон и email. Им он и не нужен, это нужно мне, если я хочу, чтобы курьер мне отзвонился. А если не хочу, то и ничего и не ввожу или пытаюсь обмануть лишние проверки.

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

Pretty roses — пользователи не любят запретов

PASSWORD EXPIRED 

"Sorry, your password has been in use for 30 days and has expired – 
You must register a new one." 

roses 

"Sorry, too few characters." 

pretty roses 

"Sorry, you must use at least one numerical character." 

1 pretty rose 

"Sorry, you cannot use blank spaces." 

1prettyrose 

"Sorry, you must use at least 10 different characters." 

1fuckingprettyrose 

"Sorry, you must use at least one upper case character." 

1FUCKINGprettyrose 

"Sorry, you cannot use more than one upper case character consecutively." 

1FuckingPrettyRose 

"Sorry, you must use no fewer than 20 total characters." 

1FuckingPrettyRoseShovedUpYourAssIfYouDon'tGiveMeAccessRightFuckingNow! 

"Sorry, you cannot use punctuation." 

1FuckingPrettyRoseShovedUpYourAssIfYouDontGiveMeAccessRightFuckingNow 

"Sorry, that password is already in use. 

© Исходного автора не знаю, так как шутка давно гуляет по интернету Smile :)



среда, 1 июля 2015 г.

Сборщик мусора. The Garbage Collector Tour

Входит в «Туры по бизнес-району», Tours of the Business District

Вольный перевод статьи Виттакера из книги Exploratory Software testing. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!

ShowImage.jpg


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

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

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

Баги повсюду. Отображается неактуальный бонус в планете самоцветов

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

Написала письмо в саппорт, меня сразу спросили про версию игры и версию ipad, я посыпала голову пеплом и добавила эту важную информацию в блог-пост. Потом саппорт попросил меня дать id и ВК, чтобы «вернуть вам ресурсы». Сначала я хотела отказаться, так как писала не ради ресурсов, а через ВК я в игру не заходила.Но жадность взяла свое — а вдруг мне самоцветов за баг дадут? Авторизовалась через ВК, написала свой id и получила от создателей 2 жизни.

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

Нажала «Настройки» (символ щестеренки в правом нижнем углу основного экрана) и кнопку «VK выйти». И что же я увидела? Предложение снова войти и... получить бонус 10 самоцветов!

Повторный бонус?

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

Заводим баг:

****************************************************************************

Игра предлагает получить уже неактуальный бонус за вход через ВК


Шаги для воспроизведения
  1. Запустить игру (прим. автора — считается, что в баг-трекере есть отдельный проект «Планета самоцветов», поэтому название указывать не надо
  2. Нажать кнопку «Настройки»
  3. Нажать «VK Войти»
  4. Авторизоваться через ВК (авторизация должна быть впервые, можно использовать email aaa, пароль bbb, но эту запись надо предварительно удалить из БД) — получаем бонус, 10 самоцветов.
  5. Нажать кнопку «Настройки»
  6. Нажать «VK Выйти»
  7. Нажать кнопку «Настройки»
Результат

Около кнопки «VK Войти» видим зазывалочку «нажми на меня и получишь 10 самоцветов», см рис «VK Войти.jpg». Хотя никаких самоцветов ты больше не получишь, это единоразовая акция.

Ожидаемый результат

Когда бонус уже получен, обещаний самоцветов нет, даже если человек разлогинился из ВК.
Убрать зазывалки из настроек + при загрузке игре, см рис «Загрузка игры.jpg» 

Загрузка игры.jpg

Устройство — mini ipad + ios 8.3
Версия игры — 2.3

****************************************************************************

А найти такой баг очень просто — моим любимым exploratory-туром «Отмененный из-за дождя». Если действие можно отменить — отмените! И попробуйте повторить. Вот такие чудеса иногда случаются Smile :)

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

Здесь мы видим, что проблемы особой нет, баг минорный. Да и служба поддержки у ребят на высоте — я не просила и не требовала возврата моих жизней, а мне вернули. Мелочь, а приятно Smile :)

Но в любом случае, искать и находить такие баги — надо уметь! Ведь главное — предоставить информацию, как оно сейчас работает.

PS — добавила пост в общую копилку багов.