...

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

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

Термин же "стратегия", вот уже лет пятьдесят как, часто употребляется в смысле, который в него вкладывает теория игр (см. Стратегия).
В применении к тест-менеджменту, стратегия - это дефиниция того, что надо делать (планировать) при наступлении тех или иных обстоятельств, вероятность которых заранее неизвестна. Стратегия отражает неопределённые аспекты планирования, которые на ту же диаграмму Ганта не ложатся. В этом смысле, приоритезация рисков - это способ определения стратегии. На русский язык термин переведён точно - стратегия не эквивалентна плану. Для проверки можно попытаться, например, мысленно назвать Стратегию развития металлургической промышленности Российской Федерации на период до 2015 года планом. :) Заодно можно обратить внимание на обилие количественных показателей и элементы неопределённости (впрочем, довольно слабо прописанные) в этом документе. Это именно то, что отличает её от плана.

Что же касается James Lyndsay, то он, видимо, просто забыл поставить в свою фразу оговорку under various circumstances, потому что она для него очевидна. Понятие стратегии - это просто часть его (и, возможно, его читателей) математической культуры.

любите вы переливать из пустого в порожнее.

Решил сделать небольшой follow-up в рамках рекламной компании SWEBOK:


5.5.1.2. Test guides

The testing phases could be guided by various aims, for example: in risk-based testing, which uses the product risks to prioritize and focus the test strategy; or in scenario-based testing, in which test cases are defined based on specified software scenarios.

Хочется выстроить понимание, что все мы работаем не для себя, не для абстрактного идола под названием Качество - мы работаем в IT, мы работаем для бизнеса.

О как.

-------------------------------------------------------------------
Даже если отвлечься от госзаказов, "бизнес" - это всего-лишь одно из средств организации улучшения качества жизни, но никак не самоцель.

..и вообще..нет такого понятия как "младший" тестировщик, есть QA-engineer и Senior QA-engineer ...

Это Вы по своей компании судите? Количество позиций и их название зависят от штатного расписания. В каждой компании оно свое.

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

Когда-нибудь Вы столкнетесь с темой мотивации.

Ну а чего тянуть-то? Может быть прямо сейчас и столкнёте? Чтобы я, значит, не прозябал в глупости.

Это Вы по своей компании судите? Количество позиций и их название зависят от штатного расписания. В каждой компании оно свое.

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

Для мелких и средних фирм и команд - выпендреж.
Когда в проектной команде будет более - менее приличное число человек, ну скажем 150, такая градация может иметь смысл.

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

Если что-то вызывает у Вас волну неконтролируемого смеха, то извольте - объяснитесь.

А можно нарисовать чартер всей затеи? На уровне цели, решаемые проблемы, бенефициары.

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

А попадает меж тем всё кучнее.
Решится ли кто-то на рассуждения о том, благодаря чему из роли тестировщика (которую, конечно же, разработчик может играть по отношению к результатам деятельности другого разработчика) получилась профессия тестировщика?

Праздник заканчивается, так что не буду на всё отвечать. Надеюсь я не слишком оффтопил по теме "Как найти готовых сотрудников, которых не надо учить [и которые всё будут делать сами]". :)

a66at: Позволю себе вопрос, чтобы прояснить для себя вашу точку зрения, окончательно. Из какой роли в отрасли тестирования и QA вы в последнее время извлекаете прибыль?

PS
А что за дядьки такие "Джонатан Льюис" и "Брюс Эккелль"? Можно ФИО в оригинале чтобы я не гадал на гугле?

Инженер по нагрузочному тестированию. Правда в свете последних обсуждений не совсем понятно QA это или не QA. Кворум телеком как я прочитал на их сайте тоже хочет этим заниматься, так что мои чувства к ним не праздны. :) На самом деле, я хоть и не Jonatan Lewis или там Bruce Eckel, но тоже есть в гугле.

С другими описаниями сравнивать пробовали?

Пробовал. Два раза выходил на новую работу, пока Ваше объявление тут висит. Один раз в Белл, кстати, по объявлению в этом форуме.

Или мне опус написать на 5 страниц текста? А просто прийти пообщаться и выяснить все на практике уже в лом?

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

Вы похоже так и не поняли, что не в описаниях дело. Case верно отмечает
текущую ситуацию на рынке.

Я ситуацию на рынке рассматриваю с другой стороны. И у меня сложилось впечатление, что тестировщиком найти хорошую по моим меркам работу очень сложно. Уж точно требует больших усилий чем читать объявы на форумах и "ходить общаться". Когда я говорю "хорошую" я деньги как таковые в виду не имею, но если вернуться к Вашей вакансии, то разница в расценках в ней и в Вашем резюме наглядно отражает типичную систему ценностей нанимателей, а она мне не нравится. Ожидания у меня возможно и завышенные, но я по крайней мере не называю это кризисом. Просто осознаю что лично я не нужен. Рекомендую Вам тоже проделать это ментальное упражнение. Вместе с Case-ом.

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

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

Если взять мою вакансию: она по требованиям и зп в Москве уже неадекватна?

Я вот не понимаю, зачем париться по поводу каких-то там "кризисов", когда можно не париться?
Та вакансия вообще противоречивая. Написано много-много каких-то требований пусть даже и несложных, но вместе с ними в комплекте идёт уже обычно кое-какое критическое мышление. Обязанности не описаны, проекты не описаны, на сайте какие-то общие слова - род деятельности компании неопределён, о месте в ней сотрудника остаётся только догадываться. Т.е. получается по дефолту: отмывать сортир в студенческой общаге и не забывать петь гимны процессному подходу к работе. :) Ясен красен на неё не особо отзываются.

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

Странно у вас как-то получается Вакансия как вакансия, обычные требования к человеку в компанию, а не в проект. Я когда по рынку искал людей примерно также искал - ибо нет чётких заморочек "j2ee два ода минимум", ну нет - так что ж теперь делать? У нас вакансии ещё интереснее описаны - и приходят люди, и работают.

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

Растолкуйте, пожалуйста, чего вы мне порекомендовали, я не сумел вычленить из текста. Сравнить свою готовность идти на указанные в вакансии деньги и ЗП в резюме Влада? Бр...

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

2 раза сменить работу за 9 месяцев? acute.gif А как же тезис о том, что работодатель предпочитает не иметь дело с перебежчиками?

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

У нас высокотехнологичные проекты, что подтверждается тем ...

Можете даже не сомневаться, что кандидат с нужными Вам опытом и скилами уже поработал в нескольких точно таких же компаниях, не первый раз слышит эту песню, и знает о своих реальных перспективах по только что приобретённому опыту увольнения. Ещё раз попытаюсь объяснить: если бы я её рассматривал, то меня бы интересовало не какие там требования и насколько я им соответствую (ведь если я тот самый кто Вам нужен, то я им уже соответствую), а чем я буду заниматься и зачем именно я со своими знаниями и опытом там вообще нужен. Потому что если я не нужен, то меня всё равно ничего хорошего не ждёт. Без этого ничего не получится, будь я хоть Джонатаном Льюисом, Брюсом Эккелем и <кто уж там самый крутой в функциональном тестировании>. Иногда нужность действительно вскрывается только на собеседовании. Но раз до собеседования никто не доходит, то я бы рекомендовал совершить какой-нибудь подвиг или хотя бы развить какую-нибудь слабость, которую может легко восполнить нужный кандидат, а не поднимать одну и ту же тему на форуме. Чтобы вам нанять какого-нибудь гражданина, который стартует с места и может тягаться с разработчиками, аналитиками, админами, нужно ему показать, что он точно не подписывается на то чтобы какую-нибудь студенческую поделку перекладывать с места на место и портить друг другу нервы с её единственным разработчиком, что его скилы будут востребованы.

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

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

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

Может и не доведёт. Хотел бы я знать, что доведёт.

На мой взгляд Вам просто не нужна работа. ... Приходите познакомимся :)

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

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

Ну т.е. стратегия это всё-таки проектный, а не процессный артефакт. :) Я согласен, процесс тестирования не нужен для выбора стратегии.

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

Я Вам ещё раз говорю, нет таких програмных систем

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

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

Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.

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

Но как вы без дополнительных средств расчитаете время отклика системы на определенные операции при определенной нагрузке?

По логам и audit trail-ам. Тулы этого кстати не делают, и интеграция с ними по этому поводу бывает сложной.

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

Возьму свой любимый gray box тест и запущу с нужной интенсивностью в некоторое количество потоков - это несколько десятков строк кода дополнительно.

Ну это уже не вручную же Это уже автоматика.

Ну ещё одна иллюстрация к утверждению, что нельзя автоматизировать то, чего нет. :)

И как это кореллирует с утверждением, что нельзя автоматизировать то, чего нет?

Я так понимаю что Вы подразумеваете, что для автоматизации тестирования нужно чтобы существовало не само тестирование, а процесс тестирования и спрашиваю, зачем конкретно это нужно.

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

А теперь, если немного абстрагироваться, то получится, что и для нагрузочного тестирования и для регрессионного нужно вначале подтянуть ресурсы, инструментальные средства, подготовить среду, заготовить тесты или выявить правила формирования тестов (например в модульном тестировании тест соответствует некоторой функции) и уже потом автоматизировать тесты. То есть в данном случае подход один и тот же независимо от вида тестирования. Но главное то, что автоматизация уже делается тогда, уже есть основа, когда есть чего автоматизировать.

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

Можно вы тут пока сами? Вернусь на той неделе.

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

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

Мне показалось, что Вы хотели поспорить про приоритеты видов автоматизированного тестирования с точки зрения приносимой пользы вне контекста своей статьи, т.к. компонентное тестирование в ней не рассматривается. Я что-то путаю?

Про то что в первую очередь, а что во вторую я бы поспорил.

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

По моему это попытка определить множество через множество. Что такое логическая единица кода?

Это так важно?
Короче, динамическое тестирование такой сущности - это модульное тестирование

UNIT unit1;INTERFACE    PROCEDURE Proc1;IMPLEMENTATIONPROCEDURE Proc1;    BEGIN         ...    END;END;

А такой - компонентное:

class Motto {  public static void main(String[] args) {    System.out.println("Java rules!");    }}

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

Про то что в первую очередь, а что во вторую я бы поспорил.

Ну давайте, спорьте. SALar, видимо имел в виду, что в современных системах дефекты GUI самые дешёвые в исправлении, поэтому не стоит на них концентрироваться слишком сильно. Не говоря уже о централизованных системах со всякими интеллектуальными терминалами (банкоматами там, мобильными телефонами), в которых, может статься бизнес логику не получится вообще через GUI протестировать. SOA он тоже, кажется, упоминал.

Unit это вообще не к тестерам

Интересно даже стало. Это отражение нежелания или неспособности?

это holy war, пока никто не возьмётся что-то подсчитать в цифрах

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

Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.

Повторю - это должно делаться разработчиками.

Про тестирование на уровне бизнес-модулей.
Основная или базовая функциональность (то что замыкает бизнес-цикл: закрытие периода, перерасчёты, выставление НН, пени и прочей лабуды) зачастую тестировалась внутренней разработкой. Мы делали свои фреймворки, которые дёргали через удалённые вызовы торчащие методы, заменяя по сути вызовы клиента и интерфейсов в другие системы. Отчёты не парсили (ну его нафиг этот "кристалл"), а собирали из базы по опорным точкам на основе бизнес-правил: банально, чтобы например внутри сети электроенергия не возникала.

Unit-тестами этот слой - я бы назвал это тестированием бизнес логики - не покрывается. Средствами record-playback зачастую тоже в основном из-за сложности проверок получаемого состояния. Либо руками, либо создаваемыми отдельно для тестовых нужд приложениями (фреймворками).

Теперь моя очередь пришла тупить и притворяться пеньком. Это что, была аргументация в пользу утверждения "да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся"?
Вообще, у меня к этому отрывку замечаний нет, я со всем согласен, но хотел бы обратить Ваше внимание на следующие обстоятельства:
1. Оказывается что в Ваших прошлых проектах кто-то ведь делал часть работы по обеспечению качества продукта ("это должно делаться разработчиками", "зачастую тестировалась внутренней разработкой"). Причём, Вы не умеете определить этот вклад количественно. Вы как-то учитываете это теперь, когда стали "дорогим консалтером" и вроде бы собираетесь нести ответственность за весь спектр? Хочу напомнить, что тестирование и автотестирование - это не самоцель.
2. Вообще говоря, в процитированном отрывке описана автоматизация того, чего не существует. По крайней мере, можно себе представить (лично я могу вспомнить) случаи, когда это справедливо.
3. Рискну предположить что дохлые лошади именно так и получаются - делается ставка на тестирование через GUI, когда критические с точки зрения качества продукта участки кода доступны только синтетически, люди чувствуют что занимаются фуфлом и перестают работать. При том подходе, который вы описали в процитированном отрывке, я могу понять как лошадь может получиться и как - не получиться, но как она может получиться дохлой - нет.
4. Всё что вы описали не обязательно делать в процессе разработки, всё то же самое может понадобиться проделать при приёмочном тестировании (если понадобится, и unit test тоже). Т.е. непонятно, что может объективно помешать этому, кроме слепой веры в то что "так не делается". Разумеется, делать это должны квалифицированние люди - "разработчики".
5. Непонятно также, при чём здесь процессы? Вот представьте самую плохую ситуацию (кошмар KaNoN-а): вы - аутсорсер, приходите к заказчику, вам дают стенд и какие-то доки, можно спрашивать у разработки, и надо автоматизированно протестировать какую-то функциональность (неважно даже, доступна она через GUI или нет). Какие после это Вам ещё нужны процессы чтобы были у этого заказчика? Можно список, в нём плюсиками отметить те, становление которых Вы случайно можете разрушить неверным движением, внедряя автоматизацию, и звёздочкой - такие, что Вы без них откажетесь работать, а будете требовать, чтобы владельцы бизнеса немедленно взяли под свой личный контроль их внедрение.

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

Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.

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

Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Статью попробую опубликовать в ближайшее время. Были бы силы.

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