Загадки QA

В одном из радиоэфиров как-то разгадывали профессию дозвонившегося слушателя. По десяти коротким описаниям ведущие должны были назвать не только отрасль, но и специализацию. За каждый неверный ответ радиостанция выкладывала приличное денежное вознаграждение игроку. Мне эта идея понравилась, и ниже перечислю свои загадки о профессии "специалиста по тестированию программного обеспечения" (далее - СТПО). Их у меня получилось больше десятка. К каждой загадке буду давать пояснения.

1. Этой профессии уже не мало лет, хотя признали её совсем недавно.

Программированием, а значит и тестированием, занимаются официально в мире с середины ХХ столетия. Должность СТПО включена в государственный реестр весной 2014 года.

2. До недавних пор этим делом занимались в основном представительницы женского пола, но современность привлекла и мужское население.

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

3. Многие считают эту профессию самым лёгким путём для начала карьеры.

Поскольку операторы ПК превратились в просто-пользователей, а тестировщиков считают юзерами альфа-версий, то и желающие "войти в IT" полагают, что освоив профессию QA, они быстрее станут одним из членов престижного клана по созданию информационных технологий.

4. Прежде чем занять свою нишу в производственной сфере, необходимо изучить и опробовать не только нижние ступени, но и хорошо знать верхние, а также уметь заменить любого в параллели. Профессия из числа ИТРиС (инженерно-технические работники и специалисты), но в ВУЗах специализированных факультетов до сих пор нет. На сегодня специальность можно освоить самостоятельно, либо по спец.курсам.

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

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

Исследовательское тестирование чаще других может "повесить" или "убить" приложение. Хакерские секреты используются как принципы проверки безопасности.

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

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

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

Тестировщика часто называют специалистом по обеспечению (QA инженер) и поддержке качества продукта, а оно имеет три параметра: скорость поставки, цена, удовлетворённость функционалом. Их совокупность каждый пользователь определяет сам.

8. В наши обязанности входит подробное чтение документации.

Есть даже особый раздел про проверку требований к продукту, инструкций пользователя.

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

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

10. У истоков профессии было насекомое.

Ошибки программирования называются "багами", потому что первой причиной проблемы ПО был мотылёк, а по-английски bug - жучок.

11. День красоты - профессиональный праздник.

Первую ошибку зарегистрировали в журнале проблем ПО 9 сентября 1947 года. В этот же день с 1995 года чествуют всех причастных к красоте в международных рамках. 

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

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

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

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

14. Наш основной стиль работы - объективность. Нам нельзя рекламировать и продавать товар, не смотря на то, что мы о нём знаем всё лучше всех.

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

15. Сталкиваясь с вирусом мы кричим "Ура!" и, не боясь заразы, несём его на "лечение".

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

16. Эта профессия подвластна всем - среди нас не мало "желторотых" студентов и седых пенсионеров.

Юниоры входят в IT в основном через тестирование ПО.

17. Мы практику превращаем в теорию.

На основе наших проб пишутся инструкции пользователя.

18. На работе мы можем играть в игрушки целый день, и никто не будет против.

Есть особое направление Game-Dev или Test-Game. Программным обеспечением может быть игра. Но даже в серьёзном продукте элементы игры весьма хорошо применимы при тестировании. 

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

Поздравляю соратников с Днём Тестировщика!

Профориентация IT

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

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

Пирамида группы разработки ПО

Схему штата должностей команды по разработке и сопровождению программного обеспечения начну описывать сверху. На вершине пирамиды сразу два человека - Инвестор (Финансовый Директор, Меценат, Finance Producer = FP) и Владелец (или Идеолог, Product Owner = PO) продукта. Если у вас есть идея, то вы - РО. Если у вас есть деньги, то вы - FP, мечтающий о прибыли. Да, продукт иногда можно создать без финансовых вливаний, то есть когда у PO достаточно знаний в предметной области, программировании и рынок открыт для любых проектов. Но если ваша идея настолько велика, что нужна помощь специалистов уровня предметной области, разработки и последующего выхода на рынок, то без помощи FP вам не обойтись. FP может абсолютно не владеть знаниями и умениями ни в предметной области, ни в разработке, ни даже в маркетинге (что весьма редкий случай), но его воздушные замки о скором доходе могут лопнуть уже по окончании первого цикла разработки. Производство ПО может показаться быстрым процессом, но это лишь иллюзии. РО без группы разработки и сопровождения может создать лишь товар-однодневку для малого количества потребителей. Да, это быстро и прибыльно, но одномоментно, потому что в мире более семи миллиардов разных людей, и у каждого из них свой взгляд на мир, то есть одно решение от одного РО однозначно не удовлетворит других. Мечты РО о покорении мира разрушатся. Если же он скооперируется с FP, то это не сильно поможет проекту, хоть это по теории вероятности и увеличит аудиторию в несколько раз. Когда вы решите стать FP, то оцените себя по шкале: объём денежных средств (которые не жалко потерять), знания рынка, наличие связей в целевой аудитории, знания предметной области продукта. Когда вы пожелаете стать вершиной пирамиды в качестве РО, то оцените себя по шкале: профессиональность в программировании, знание предметной области, наличие целевой аудитории, связи вертикальные в профессиональной сфере и горизонтальные в предметной. В качестве РО сам-на-сам мне не единожды случалось быть с самых первых моих шагов в карьере ИТ-эксперта. Первым пробным шагом был закодированный в школьные годы психологический тест на Фокале в 1986 году для научно-технической конференции среди студентов технического института. Не буду считать множество программулек для личного пользования, доход от которых не измерить, разве что экономией времени. А вот автоматизация хит-парада на музыкальном радио "с нуля и под ключ" считаю своей гордостью. Оплата за ту программу исчислялась тоже не в материальном выражении, а в личном отношении всей радиостанции. То есть FP во мне был уровня меценатства, а РО - полного цикла. Любая компьютерная программа не может жить сама по себе, то есть ей нужно как минимум "железо" и платформа, которые имеют реальную цену, в отличие от языка программирования, являющегося в любых вариациях бесплатным. Хочу подчеркнуть, что даже если вы считаете себя РО и владеете языком кодирования, то вам по-любому придётся вложиться сначала в комп и систему для себя, а потом за счёт потребителя или на свои средства обеспечить пользователя местом для вашего продукта.

Средний и самый большой пласт пирамиды составляют Программисты (Разработчики, Кодеры железа, Developer = D), Аналитики (Постановщики задач, Бизнес и Системные Аналитики = А), Тестировщики (Инженеры по Качеству, QC, QA = Т), Сервисные инженеры (Администраторы Сети, Базы, Системы = S). Если ваша команда создаёт серьёзный продукт, то экспертиза из любой этих четырёх групп одинаково важна. На плечи D до недавних пор ложился основной груз работы: обследование предметной области, формулирование бизнес-задач, кодирование, проверка готового продукта на стороне разработки, внедрение и сопровождение ПО на стороне пользователя, выявление и решение проблем интеграции. Всё это мне приходилось совмещать, будучи программистом отдела АСУП на заводе. С расширением проектов для перечисленных ролей группу разработки усиливают специалистами соответствующей квалификации. В большинстве случаев считается, что при каскадном (Waterfall) типе производства обязательно наличие всех должностей, а при гибком (Agile) все роли объединяются в единого сотрудника. Тем не менее, если вы решили выбрать себе сферу информационных технологий в качестве заработка, то начинать самообразование следует со школьной парты. В первую очередь нужны фундаментальные знания в языках общения (например, русский и английский) для единого понимания целей продукта. На второе место ставлю математику, которая не только является основой всех наук, но и способствует развитию логического мышления, столь необходимого при генерации идей и планов. Таким наукам как биология, физика и химия в личном плане развития стоит определить равнозначно много места, поскольку всегда они были и останутся основой знаний предметных областей. Даже если вы станете МОИРом пылесоса, то без понимания механики веника, абсорбции половой тряпки, структуры человеческого скелета, процесса образования пыли, вы не сможете передать технике исходные условия. В последующую ступень знаний включаю все прочие предметы, изучаемые в школе, в том числе и ИТ. Да, не удивляйтесь, но даже профильный предмет не является первоочередным для компьютерщика. На обучение конкретной профессии достаточно курсов в пару лет, а фундаментальные науки можно изучать все десять лет школы, но так и не постигнуть в достаточной мере. Предвижу вопрос о географии, астрономии, истории, психологии и философии. Объём знаний о нашей планете и галактике, об обществе причисляю тоже к третьей группе даже не смотря на то, что Искусственный Интеллект сейчас лидирует в сфере инфо-технологий.

Поскольку моя статья имеет цель профориентации, то хотя бы вкратце опишу спектр обязанностей каждой из четырёх ролей основной ступени в порядке их причастности к конечному продукту. Сначала A берёт идею у РО, опрашивает потенциального пользователя и наблюдает за его текущими действиями. По результатам этого обследования A формирует объём задач на программирование для D, список условий готовности продукта для T, требования к окружению для S.  На втором этапе D кодирует всё то, что придумал A, и передаёт вариант продукта T. T проверяет продукт на соответствие идеи от РО, условиям готовности от A, возможностям окружений от S. S подбирает, устанавливает, связывает окружение (операционная система, база данных, дополнительное "железо") с продуктом на стороне разработки и составляет список артефактов для поставки продукта пользователям. От любого из четырёх производителей продукт может вернуться на любую из четырёх стадий. Таких итераций может быть несколько, пока T не подтвердит, что продукт соответствует продажному качеству. Только тогда D с S и T совместно перекладывают продукт из своих мест для кодирования и тестирования в рыночную область: выкладывают в онлайн-магазин, встраивают ПО в технику или передают продуктовый пакет интеграторам, передают версию ПО в тираж. Если посмотреть на процентное соотношение знаний предметной области и чисто профессиональных навыков для каждой из четырёх ролей, то в моём понимании, основанном на долгосрочном опыте (почти 35 лет) распределяю так: A и T - 40%предмет+60%проф, D - 20%предмет+80%проф, S - 10%предмет+90%проф. 

Далее в процесс включаются Мерчендайзеры (Маркетологи, Рекламщики, Продавцы = М), Внедренцы (Сопровождение, Тех.Поддержка = П), кому-то требуются дополнительно Тех.Писатели (Copywriter = C), МОИРы (Учитель пользователя, Коучер инструмента, Тренер = У), Операторы (Экспертные Пользователи = O). Более лёгким вход в ИТ возможен именно через эту прослойку. Для всех них на 30% ценится знание предметной области, на 20% информационных технологий и самого продукта, на 50% их конкретные профессиональные навыки. Привязка их профессиональной деятельности к ИТ-продуктам обретается в процессе короткого обучения. М не только продаёт продукт, но и собирает статистику для A, РО, FP о значимости ПО для покупателей, от A и T получает информацию для продвижения ПО на рынке. C описывает продукт для М, формирует инструкцию пользователя для O, D, S по информации от A и T, помогает и контролирует грамотность с языковой и технической точек зрения для П, М, У, ему в большинстве случаев приходится составлять и следить за внутренней документацией команды. У, также как и П, способствует освоению продукта пользователем. В разряд O переходит любой пользователь после курсов от У и П. Если в конце прошлого века про М, C, У не задумывались, а O ценился на уровне сегодняшних T, то спустя двадцать лет можно с уверенностью сказать, что все эти роли сегодня сливаются в одну должность, а порой даже их обязанности перекладывают на A или T.

Схема отношений ролей в группе разработки ПО

Для тех, кто лучше воспринимает не графику, а таблицы:

Связи Ролей
От	Что	Кому
FP	деньги	PO
PO	задачи	A
		D
		T
		S
		M
		C
		П
		У
		O
A	работа	D
		T
		S
	зачем использовать	M
	описание	C
D	работа	A
		T
		S
T	работа	A
		D
		S
	тех.состояние	PO
	тех.пояснения	C
	как использовать	M
S	работа	A
		D
		T
M	доход	FP
	потребность	PO
	как используется	A
C	текст	M
	инструкция	O
		D
		S
	грамотность	П
		M
		У
П	освоение	O
У	освоение	O

Соотношение знаний и умений по ролям

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

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

DB IDE

26 апреля 2002 года на общем собрании Кольчугинского филиала компании "Real System for Corp." (RSC) было объявлено о самостоятельном направлении в развитии продукта "Table Magic", который начал своё существование ещё на базе отдела АСУП при заводе "Электрокабель" (ЭКЗ), а затем в 2000 году вместе с "родителем" исходники перекочевали в маленькую компанию разработчиков. В мае 2002 года на московской конференции продуктом, состоящим из "умного грида данных" и редактора хранимых подпрограмм, заинтересовался австрийский бизнесмен, поэтому в июле команду укрепили вторым программистом. Поскольку на тот момент мне приходилось тестировать смежный продукт этой же компании, то мои знания "Table Magic" сначала помогли "подчистить" презентацию и впоследствии привели на место тестировщика. Европейский аналитик порекомендовал множество идей, в том числе переименование в "DatabaseVoyager" (DV) и формирование американской компании "Conquest Software Solutions" (ConquestSS). К началу моей деятельности в августе 2003 года навигатор объектов насчитывал около полутора десятка типов объектов, которые и надо было мне тестировать. Каждый из объектов, добавляемый в список поддерживаемых, имел свой мастер по обработке и некоторые функции в отдельных модулях DV. Постоянно прибавляясь к 2017 году их накопилось более шести десятков. И только спустя пятнадцать лет у владельца продукта единожды возник вопрос о том, как проводится тестирование к тому времени уже давно переименованного продукта SQLDetective (SD).

Как вы понимаете, изначально никакого процесса тестирования в RSC не существовало, поэтому мне пришлось искать варианты самостоятельно. К тому же, руководитель проекта ставил программистов на несколько ступеней выше меня и не позволял вытягивать знания из них, а вместо этого отсылал все мои вопросы к самостоятельному изучению документации базы данных Oracle, собственно говоря для которой и создавался интерфейсный продукт, конкурирующий с TOAD от Quest Software. Итак, знания о новом объекте существенно отличались у программиста и тестировщика, а все задачи на разработку и тестирование были весьма краткие: "добавить поддержку объекта NN". В понимании программиста это зачастую ограничивалось созданием мастера объекта, поскольку он опирался лишь на статьи по его созданию (CREATE), редактированию (ALTER) и удалению (DROP). Но взгляд тестировщика на термин "поддержка объекта в продукте" более широк и рассматривает все операции (GRANT, REVOKE, ANALYZE, PURGE, ...) над объектом, доступные в базе данных. Эти мои обширные знания вынуждали формировать лишь на этапе тестирования, а не в процессе планирования, множество заданий на доработку.

Итак, первым шагом в тестировании нового поддерживаемого объекта было изучение документации. На это в моём плане по тестированию отводился целый день, поскольку в SD поддерживалось несколько версий базы. Сначала для последней версии базы распечатывались статьи по созданию (CREATE), редактированию (ALTER) и удалению (DROP) объекта. Затем тексты сравнивались с каждой предыдущей версией и в распечатке делались пометки о новшествах и утилизациях опций. Документация по объектам Oracle довольно хорошо структурирована, поэтому легко вычленялись необходимые статьи, в которых достаточно было сравнить лишь схемы DDL. Со временем в помощь разработчикам и тестировщикам в SD появился модуль "Oracle Documentation Browser", в котором можно было проиндексировать сразу все пять (на тот момент - 7.3, 8.0, 8.1, 9.0, 9.2, а позже к ним добавлялись 10.1, 10.2, 11.1, 11.2, 12) версий базы. Поиск в этом модуле позволил расширять тестирование статьями про иную (GRANT, REVOKE, ANALYZE, PURGE, ...) обработку объектов и связи, зависимости с другими объектами (точки восстановления с архивами, логи м/в и группы м/в, таблицы и их индексы, триггеры, констрейнты). Но некоторые (POLICY, MV GROUP, RESOURCE PLAN, ...) объекты БД Oracle регулируются не самостоятельными командами, а системными (DBMS_RLS, DBMS_REFRESH, DBMS_RESOURCE_MANAGER, ...) пакетами. Для их тестирования достаточно одной статьи, в которой пакетными процедурами и функциями описаны все действия над объектом, что немного упрощало дело. К концу первого дня у меня получался распечатанный план тестирования в разрезе версий БД и по операциям над объектом, по объёму которых можно было определить необходимое время на все последующие проверки. Так, на "большие" объекты (таблицы, шедулеры) минимально требовалось от пяти дней, а на самые "маленькие" (последовательности, операторы) - до двух дней.
Второй шаг - основное тестирование функциональности - проверяет корректность создания, редактирования и удаления объекта средствами нового интерфейса. Все эти операции в минимальном объёме выполняются на каждой из поддерживаемых версий БД. Следующим проходом по версиям базы тестируются различия схем DDL. И самое сложное, оставленное на закуску, заключается в детальной проверке всех опций DDL, которые в большинстве случаев достаточно посмотреть на последней версии базы.
На третьем шаге тестирования поддержки нового объекта в SD проверяется возможность выдачи и отъёма привилегий на объект через мастер привилегий, если таковые предусмотрены документацией Oracle. Здесь же рассматривается принадлежность объекта юзерской схеме или его системное положение. Не стоит забывать и про версионность базы данных.
Четвёртый шаг рассматривает взаимосвязи объектов через их мастера и панели выгрузки DDL. Например, мастер триггера вызывается из мастера таблицы, а индексный кластер можно создать в базе только после создания индекса. Тестирование SD расширяется модулями Schema Extractor, Compare DB и другими, где как-то фигурирует DDL нового объекта. Очень серьёзно здесь стоит приглядываться к различиям в версиях БД.

Заключительным пятым шагом проверяются всевозможные операции над новым объектом в различных утилитах SD. Например, релокацией партиций занимается "Storage Manager", перекомпиляция хранимой подпрограммы автоматически происходит при её открытии в "Stored Program Editor", для анализа вьювера существуют самостоятельные интерфейсы в рамках одного объекта или целой схемы. Как уже ранее говорилось, именно этот шаг даёт максимальный прирост задач программисту на доработку.

Тесты доступности, удобства, производительности и безопасности лучше проводить не самостоятельным шагом, а в рамках каждого из описанных. Набив руку на первом десятке объектов, у меня сформировалось устойчивое понимание, что только комплексное тестирование может сократить время на проверки, предусмотренные шагами со второго по пятый. К сожалению, владелец продукта никогда не жаловал процесс тестирования, поэтому ни при waterfall, ни при agile не был приверженцем декомпозиции задач и детального планирования, даже совмещая роль скрам-мастера. Менеджер продукта и первый программист откосили в своё время от армии, поэтому и не стремились к порядку, не умеют и до сих пор чётко следовать правилам и сдерживать данные обещания, как это принято у честных бизнесменов.  Очевидно поэтому вопрос РМ-а о вышеописанном стал чисто риторическим с его стороны, а ответ оформился в статью только спустя ровно семнадцать лет после оформления моего первого бага по SD, но уже не для команды ConquestSS, а для вас - простых тестировщиков.

теле2-портация

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

Входные данные.
В телефоне-звонилке работает симка с тарифом только для звонков и сообщений (назовём её ТЗС=ТарифЗвонковСообщений), все услуги по выходу в Интернет отключены, да и сам аппарат не поддерживает выход в Сеть. Фирменный модем-свисток со специальным тарифом (назовём его ТИ=ТарифИнтернета) подключает к Интернету компьютер.
Проблема.
Рано утром меня разбудили пришедшие на ТЗС два сообщения: о подключенной услуге развлечений и тутже факт самой забавы. Это кто ж меня подключил во время сна? Подозревая неладное, открываю через ТИ личный кабинет ТЗС-а и обнаруживаю в блоке Расходы, что с меня сняли 15 рублей за выход в Интернет и 10 рублей за подписку развлечений. 

Провайдерские кражи

Как так? Без моего ведома кто-то распоряжается моими счетами? Да ещё в то время пока сплю! Какой-то нонсенс. При том, что аппарат лежит в соседней комнате, то есть довольно далеко от кровати спящего владельца.

Разбирательство и устранение проблем.
В блоке Услуг личного кабинета ТЗС-а обнаружена подключенная услуга развлечений, которую немедленно отключаю. Для поиска подробностей о том, кто и когда мог мне её подключить, а также о якобы выходе в Интернет делаю запрос Деталей Расходов. Но поскольку в такой отчёт включаются данные только с четырёхчасовой задержкой, то обнаруживаю лишь запись об Интернете. Какого же было моё удивление от времени якобы-связи: 00 часов 52 минуты текущих суток. Припоминаю, что примерно в это время был окончен сеанс Интернета, но не по ТЗС-у, а совсем по иной симке - ТИ. Да, вчера пользование телефонным аппаратом с ТЗС-а было завершено в 21:00, да и то, не связью, а лишь прослушиванием записей с карты памяти. В общем, к аппарату никто не прикасался более, никаких входящих или исходящих контактов не осуществлялось. Далее, то есть с 21:00, был включен комп для просмотра видео через связь по ТИ.

Кстати, если видеопроигрыватели на порталах поддерживают настройку "Качество=Низкое", а тариф интернета мерный, то за 10-14 часов просмотра видео без сторонних скачиваний (реклама, обновления системы и приложений) потратите лишь около двух гигабайт. Соглашусь, что перед сном лучше книжку почитать, а не в монитор глазеть, но наше поколение экран быстрее приводит в сонное состояние.

Мой сеанс по ТИ завершился в 00:50. И вот оно - совпадение! Отключенный Интернет и выключенный комп всю ночь провели в несколько-метровой удалённости друг от друга. Но почему-то в детальном отчёте расходов завершение сеанса по ТИ было отмечено как коннект по ТЗС. Да, обе симки оформлены с одинаковыми персональными данными, но ведь база коннектов для подсчёта трафиков должна связываться по уникальным идентификаторам симок, а не их владельцев. Так что, с высокой колокольни тестировщика могу предположить, что в это время заливалось очередное обновление системы, которое дало такой типа-странный сбой. 

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

Ответы чат-бота

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

Вторым подтверждением глючного апдейта теле2 можно считать навязанную подписку развлечений, подключенную без участия абонента. Конечно, я понимаю яростное желание компании в наживе, но зачем же так грубо теле2 пытается надуть своих клиентов? Почему использую такие жёсткие эпитеты? Это легко объяснимо. Следующим шагом был мой звонок в сервисную службу по номеру 611, где с оператором мне удалось поговорить лишь после прослушивания информации про подписки. На мой рассказ о подключенной без моего ведома подписке и снятой суммы за непользованый Интернет сразу последовала "лояльность" в виде возврата десяти рублей за подписку, но пятнадцать рублей за килобайт интернета вернуть отказались. 

Льстивый возврат

Моя длительная практика в роли специалиста техподдержки даёт мне основания заявлять, что обычный оператор сервисного центра не уполномочен раздавать всем подряд какие-либо скидки и "программы лояльности". Решение о возврате денежных средств даже в мелкой организации принимается владельцем продукта или маркетологом, но никак не сотрудником нижнего уровня, в данном случае - отдела сервисного обслуживания. Скорее всего, название "программа лояльности" - это лишь красивое прикрытие неправомерных действий теле2 по автоподписке клиентов на платные услуги. То есть, сначала их триггер автоматом включает услугу без ведома клиента, а потом, если мы замечаем такие не наши действия, то нам возвращают снятые с нашего счёта рубли. Но, поскольку не все абоненты регулярно перепроверяют свои трафики, то теле2 наживается на нас без нашего согласия. Хоть и по десяточке, а с множества абонентов получаются миллионы лёгкой прибыли. Да и в Сети вы сами можете найти не мало случаев, когда за несанкционированную подписку возвращали моментально средства. 

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

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

Бесплатное подключение и использование, но не на всех тарифах

Решение задачи завершено. Ответ.

Из всего вышеизложенного более у меня нет никаких сомнений, что теле2 намеренно (или случайно из-за низкого профессионализма программистов и тестировщиков) отнимает денежные средства у своих клиентов без нашего ведома, участия и согласия, то есть теле2 - мошенники в прямом смысле слова. К сожалению, детализированный расход ТИ не фиксирует время окончания сеансов, поэтому у меня нет фактов для доказательства провайдеру его ошибок программирования. Маленькая сумма (по 15 руб. пару раз) отъёма у меня денег и частичное (10 руб.) возмещение ущерба не даёт мне повода для обращения в суд или иные правоохранительные и надзорные инстанции, но если с вами произошла аналогичная ситуация, то совместное обращение к власть-имущим возможно прекратит такое издевательство над честными гражданами и предотвратит нахальное превышение полномочий.   

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

СУТ

Стратегия утилизационного тестирования ("сут" в переводе с казахского - молоко, если нет попаданий в цель, то это синоним аутов) в период кризиса выходит на первый план. Текущее время - самое подходящее для разворота направления работ отдела тестирования в сторону сворачивания бизнеса, помогая руководителю проекта оставить продукт пользователям в наилучшем состоянии для очистки совести ответственных за качество.
По результатам моих исследований нижеследующий чит-лист ни единожды спасал компанию от излишних расходов на поддержку производства после расторжения договоров.
1.  Изучить лицензионное соглашение юзера и выделить параметры:
1.1. период действия купленного продукта. Опираться на него при планировании фиксов;
1.2. период техподдержки. Выполнять работы только для оплаченных сервисов и пользователей;
1.3. объём работ по тех.поддержке: править баги, искать обходные пути, предоставлять обновления билдов и версий. Ограничить план тестирования только теми задачами, которые имеют юридическую силу
2. Вычленить из BTS мега-критичные баги (регрессия, нагрузка, обновление внешних систем) для срочной правки. Предоставить по ним отчёт руководителю проекта для согласования тест-плана.
3. Закрыть магазин и продажи для новых покупателей без остановки форумов, сообществ, мест обратной связи:
3.1. уведомить весь список дилеров об ограничении продаж;
3.2. личный кабинет пользователя ограничить доступной версией;
3.3. фильтровать рассылку писем пользователям по доступности продаж.
4. Контролировать публикацию инфы в открытых источниках о возможностях продукта (сайты компании и дилеров, хелп продукта).
5. При приёме заявок от актуальных пользователей критичность и важность входящих багов определять по массовости использования модуля.
6. Прекратить приём и оформление предложений по усовершенствованию продукта.
7. Работа тестировщика продолжается вплоть до завершения периода техподдержки, если лицензионным соглашением определено исправление критичных багов и поставка обновлений.

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