Shift Left: шифтуємо вліво на реальних прикладах

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Одна з моїх перших статей на DOU, написана більше трьох років тому, про TestOps. Я тоді знайшов трохи часу, щоб порефлексувати і відповісти собі на питання: хто я? Що я роблю? Як класифікувати свою роботу?

І дійшов висновку, що роблю багато речей, які не притаманні типовим активностям QA-інженера чи Test Lead. Натомість займаюсь розробкою, налаштуванням пайплайнів, конфігурацією середовищ, моніторингом... тобто типовими активностями DevOps.

І сам собою у мене в голові виник термін TestOps — методологія, спрямована на пришвидшення процесів розробки й тестування за рахунок щільної взаємодії QA з Dev та Ops, і за нагоди, виконання їхніх активностей, якщо це є bottleneck.

Я погуглив, і, на диво, такий термін в інтернеті траплявся не те щоб часто. Зате ми з Михайлом Чубом накопали статей з Shift Left та Shift Right тестуванню — активності, які чудово вписуються в концепцію TestOps! І нам дуже закортіло популяризувати термін і підхід загалом. У своєму резюме я серед основних навичок, до речі, маю TestOps 🙂

У коментарях багато писали типу «Гей, нащо новий термін? QA і так мають забезпечувати якість на всіх етапах життєвого циклу!». Тільки от етапів стало стільки, що одна людина фізично може все не вивезти, тож настає питання про розділення праці.

Я дуже рекомендую ознайомитись з оригінальною статтею, але сьогодні маю натхнення поговорити про Shift Left. Багато хто пише, що це зміщення фокусу тестування на ранні етапи розробки ПЗ. Але це лише концепція — як її використати на практиці? Я знову знайшов у собі трохи сил на рефлексію і вирішив написати низку практичних порад — що саме треба робити, шифтуючи вліво. Поради ви можете використати вже! Без реєстрації та СМС (цей жарт ще не застарів?).

Підемо просто за водоспадом, бо, як виявилось, тестові активності можна не просто «змістити вліво», а взагалі починати їх якомога раніше на кожному етапі розробки ПЗ.

Планування

Roadmap (дорожня карта) — те, що ви не помічаєте, коли воно є, але дуже помітно, коли його нема. Коли я був просто інженером, у моїй команді завжди працювали досвідчені менеджери, які стежили, щоб у нас був план і ми його дотримувались.

Коли я сам став тест-менеджером, в одному з нових проєктів я побачив, що номінально дорожня карта продукту розписана на три роки вперед, але фактично стейкхолдери не можуть сформулювати конкретні вимоги до компонентів продукту. А тому декілька разів на спринт приходять на мітинги, що видати порцію рандомних побажань в стилі «колись для цієї фічі буде скрин, і я хочу, щоб кнопочки тут були зелені». Тобто фічі нема, прототип не працює, але кнопочки, бляха, зелені! І до того ж демо просять регулярно й дуже дивуються, що ми не можемо показати цілісні фічі, бо «Там же все очевидно» ©.

Тож майже одразу я запропонував інший підхід до роботи: якщо ви самі не маєте загального бачення продукту, то ми, команда розробки, сформуємо власну дорожню карту й беклог і почнемо робити справді робочий прототип. Побачивши його, ви вже зможете визначити, чи це те, що вам треба, і що б ви хотіли покращити? І цей підхід почав працювати.

Це наша задача — спланувати роботу та зробити процес розробки й тестування комфортним. Тож не зволікайте і не думайте, що все налагодиться саме собою. Дійте проактивно!

GTD (Get Things Done) — у вас ніколи такого не було, що в розмові з іншими QA ви чуєте, що вони використовують дуже крутий процес чи інструмент, і думаєте: «От би і нам таке». Але ви не можете це впровадити, бо ваші процеси вже зав’язані на інший стек технологій, тули куплені, купа роботи зроблена, люди звикли і «Ти шо, найрозумніший всьо мінять? Роками працювало — не чіпай».

Пам’ятаю, я розмовляв з одним інженером, який жалівся, що втомився бекапити код в архіви і деплоїти білди на сервер руками за ssh. Я питаю: а як же git? Білд-сервер налаштувати? На що отримав відповідь, що команда таких радикальних змін не сприйме. Та і замовник консервативний і платить за фічі, а не за оновлення процесів.

Або ж інший приклад: наймав я в команду Team Lead замість себе, і він мене питає, чи користуємось ми Teamscale? (не реклама). Я до цього навіть не чув про такий інструмент, а він допомагає мапити тест-кейси напряму на код! Тепер дуже хочу десь його спробувати 😀

Зазвичай люди використовують ті інструменти, до яких звикли у яких мають досвід. Тому першим кроком вліво має стати нетворкінг: саме спілкування з колегами, конференції, мітапи можуть стати для вас джерелом знань про цікаві тули, тренди та підходи. Другий крок — аналіз. Продумайте процес вашої роботи та які інструменти можна використати, щоб допомогти роботу робити: де спілкуватись (так, навіть месенджери важливі), де код писати, де зберігати, де документацію вести і задачі трекати, як все це між собою пов’язати для забезпечення traceability артефактів і чи ви зможете замінити / доповнити якісь інструменти за нагоди (чи є хоч банальний експорт даних)?

І оскільки ми шифтуємо вліво, цей аналіз має відбутися до початку роботи, а не під час, для латання дір на кораблі, що тоне. Якщо вам складно, найміть експерта-консультанта. Це не слабкість, а дорослий і виважений підхід (кажу це як експерт-консультант 😎).

Вимоги

Для кого працюємо? У багатьох інженерів (я не виняток) є проблема сприйняття вимог, яку можна влучно описати виразом «за деревами не бачу лісу». Ми так захоплюємось ідеями, як ми маємо запрограмувати чи протестувати вимоги, що не звертаємо уваги на їхню мету — вирішити проблеми користувачів. Я взяв собі за правило, аналізуючи вимоги, завжди питати: як би я це використав, якби сам працював із застосунком? Чи це буде зручно? Чи це зрозуміло?

В одному з проєктів замовник попросив зробити екран конфігу й розмістити на ньому десь 50 різних інпутів, чекбоксів, дропдаунів і кнопочок зі складною логікою деактивації певних елементів за активації інших, на три екрани. Бо він так бачить. А як я спитав, чи буде користувачам зрозуміло, що відбувається (оскільки я бачив подібний функціонал у вигляді мінімалістичної таблиці на пів екрану), замовник попросив до свого дизайну додати ще один, додатковий екран, де будуть показані результати конфігурації ¯\_(ツ)_/¯ Я б хотів не цього, але вже краще, ніж було.

Пріоритети. Зусилля мають бути адекватні до користі. Якщо замовник ПЗ хоче суперадмінку для налаштування своєї системи з крутим візуальним дизайном, гнучкістю і десятком графічних тем (десь на півроку роботи), а будуть користуватись цією адмінкою півтори людини, я б зекономив час та ресурси і рекомендував робити все простіше, сфокусуватись на більш важливих задачах. А до адмінки можна повернутись, як буде зайвий час.

Будьте експертами. Дуже часто ми робимо будь-яку дичину, яку від нас вимагають, бо «такі вимоги» чи «більшість людей хоче». Так-от, замовник часто не знає, як краще, бо його знання в дизайні застрягли десь у 90-х і тексти в стилі MS WordArt він вважає іконою стилю.

Уявіть ситуацію: приходить людина до лікаря і просить відрізати собі руку. «Але ж чому?» — питає лікар. На що отримує відповідь: «Бо в мене вухо болить і в інтернеті кажуть, що це єдиний спосіб лікування».

Наша задача — не критикувати ідеї замовників, а донести до них всі можливі варіанти рішення їхніх задач, пояснити плюси та мінуси і порадити найкращі (на вашу експертну думку). Щоб замовник ухвалив поінформоване рішення. Вам платять за те, щоб ви були експертами, тож будьте ними! І що раніше почнете, то краще.

А щодо «більшість хоче» — більшість зазвичай помиляється, бо більшість — не експерти і тим паче не візіонери. Свого часу «більшість» не бачила перспектив в смартфонах без клавіатури, але Apple зробила революцію з iPhone; «більшість» вважала комерційну космонавтику нерентабельною; «більшість» голосувала за Зеленського і Слуг Народу 😜

Не забувайте про NFR. За статистикою, більшість вимог до ПЗ — функціональні. Усі думають про те, що має робити продукт. І дуже часто ми забуваємо спитати про нефункціональні вимоги — як має працювати продукт? Як швидко? Як ефективно? Наскільки надійно? На яких пристроях / браузерах / ОС?

І згадують про них тоді, коли продукт уже готовий, але працює не так, як би того хотілося користувачам. І починаються хотфікси, костилі, кранчі. Турбуймося про якість заздалегідь!

Подбайте про майбутні покоління. Який би крутий, незамінний та інноваційний продукт ви не створювали, рано чи пізно його життєвий цикл завершиться і його потрібно буде замінити. Подумайте над тим, що буде потрібно для епічного фінального акорду — може це експорт усіх даних і конфігів в простий і зрозумілий формат? Можливо, саме ви будете розробляти нову версію, і така далекоглядність стане вам у пригоді 😉 Це хоч і не найпріоритетніша задача, але точно варта уваги.

Дизайн

І ось ми вже добрались до архітектури. Чи можна тут шифтувати вліво? Треба!

Робіть усе просто і явно. Мені дуже імпонує концепція Zen of Python. Наче нічого особливого, робіть добре й не робіть погано, але деякі пункти я взяв на озброєння і активно просуваю під час розробки:

  • Будь-який продукт має робити всі дії явно. Ніяких прихованих чи неочевидних рухів. Якщо кнопка називається зберегти дані, вона має тільки зберегти дані. Якщо на додачу ви ще й Email комусь надішлете і відкриєте попап для реєстрації на сторонньому ресурсі, бо «ну ми ж зручніше намагаємось зробити». Про це або має бути повідомлено користувачу, або розбито на декілька дій. Якщо ваша програма щось завантажує, вона не має виснути — додайте хоч якийсь лоадер.
  • Прості рішення кращі за складні. Якщо вам треба інпут з валідацією та автозаповненням і на його роботу потрібно кілька днів, зробіть спочатку просто інпут, щоб протестувати, а валідації й автозаповнення прикручуйте за нагоди.
  • Помилки мають бути оброблені та інформативні, щоб користувачі не просто знали, що помилка сталась, а знали чому і (в ідеалі) що зробити, щоб її виправити.
  • Якщо вам, користувачам, замовникам, аналітикам чи розробникам складно пояснити вимоги чи алгоритм реалізації — значить ми щось робимо не так.

Принципи розробки — в маси! Майже кожен розробник і автотестер може розказати вам про SOLID, DRY, KISS, <badass_principle_name> і як він використовує ці принципи під час написання коду. Але на рівень дизайну системи ці знання чомусь не масштабуються. Наприклад: S в SOLID означає Single responsibility — один клас виконує лише одну задачу. Але якщо ми створюємо мікросервіс, то нехай він робить і перше, і друге, і п’яте. Зрештою маємо не мікро, а таки собі макросервіс, монстр Франкенштейна, який важко підтримувати і тестувати.

Testable by Design. Завжди пам’ятайте: тестери, інженери підтримки й адміністратори — теж користувачі продукту, що розробляється. Продукт має бути зручний і для них. Якщо тестерам на етапі тестування потрібні maintenance API, щоб простіше сетапити дані для тестів — створіть відповідні задачі і реалізуйте. Ми не маємо витрачати десятки годин, щоб просто підготувати дані для пʼятихвилинного тесту. Це має бути ваша ініціатива. Якщо не попросите самі, вам не запропонують.

Якщо користувачі / замовники просять зробити складну функцію — запропонуйте одразу додаткову фічу з її перевірки. Наприклад, відеоредактор: перед тим, як запускати 10-годинний рендер, може згенерувати за запитом 5-секундне відео, щоб показати результат і внести правки, не витрачаючи час на невідомість.

Ну і звісно, логи — мій постійний біль. Або їх мало, або вони неінформативні, або вони дублюються чи мають неправильний рівень. Тест-інженери, якщо ви бачите, що вам не вистачає логів, — заводьте задачі на їхнє додавання. Якщо є зайві — заводьте задачі, щоб їх прибрати. Бо логи — це про підтримку системи, а підтримуваність — одна з восьми характеристик якості ПЗ. Будь-яка програма заслуговує бути якісною з усіх сторін!

Розробка і тестування

Якщо ви думаєте, що на цих етапах вже пізно рухатись вліво, то ніт — це ніколи не пізно 😀

Unit tests. Як тест-інженер і автоматизатор, я взяв за правило допомагати розробникам писати Unit-тести. З них код, з мене — дані. Для генерації даних я навіть сам писав алгоритми згідно з вимогами. І намагався не робити жодних припущень: не розумію на 100%, що мається на увазі — баг вимог і потребує уточнення. Це подвійна робота, зате в такому випадку алгоритм вдвічі краще проаналізований і протестований.

Integration. Типовий блокер багатьох Enterprise-розробок: ви зробили свою частину і чекаєте, поки вам нададуть сторонні сервіси для інтеграції, щоб виявити, що в інших виробників була інша версія вимог і тепер вам потрібно ASAP адаптувати API, щоб встигнути до дедлайнів. Або ви всі неправильно зрозуміли E2E-сценарій і треба все переробити. По-перше, завжди намагайтесь комунікувати з іншими командами (напряму, якщо це дозволено, або ж через замовника), щоб розуміти прогрес інших, що саме вони роблять і за якими вимогами. Просіть надавати вам хоч якісь чорнові версії інших систем для ранньої інтеграції. По-друге, створюйте моки і намагайтесь провести E2E самотужки. Це не панацея, але знали б ви, скільки помилок було виявлено і попереджено через вчасне тестування з моками.

Тестові дані. Дані — наше все! Навіть ідеально написане ПЗ може працювати не так, як хоче користувач, якщо він ввів криві дані, неможливу комбінацію, пропустив поле. Намагайтесь дістати та створити реалістичні й нереалістичні (corner case) тестові дані заздалегідь. І готуйте дані для системи в цілому. Не можу не згадати випадок, коли ми тестували банківську систему на сотнях тисяч даних, а в проді їх створили мільйони, і продуктивність значно просіла, незважаючи навіть на масштабування ресурсів. З тих пір намагаюсь генерувати дані в тестовані системи заздалегідь, щоб наблизити умови до реальних.

Усі ваші тестові наміри мають бути явними. Вимога робити все явно стосується не лише продукту. Пишіть тест-план: декларуйте, що і як будете тестувати, що вам потрібно для тестування, і вимагайте все, що потрібно. Щоб потім не жалітись, що тест-кейси готові, а тестового середовища вам злі DevOps не створюють.

Якщо у вас блокер в тестуванні — не чекайте, що воно якось само мине. Комунікуйте, пишіть листи, збирайте мітинги й контролюйте, чи розвʼязуються після комунікації проблеми. Бо часто буває, що провели десять мітингів, а проблему так ніхто і не розвʼязав.

Якщо ви чогось не знаєте — питайте.

Завжди робіть оцінку — скільки часу вам потрібно на тестування і які можуть виникнути ризики, що вплинуть на час тестування, щоб команда знала, коли можна очікувати результати вашої роботи.

Пишіть інструкції. Є таке поняття — bus factor. Чи зможе команда працювати без вас? Чи всі знають, що ви робили? Записуйте інструкції, в текстовому чи відеоформаті про те, як працює продукт, який ви тестуєте, діліться досвідом. Не чекайте, поки щось станеться чи вас явно попросять задокументувати все.

Summary

Майте здоровий глузд, критичне мислення, будьте проактивними і пам’ятайте, що розробка ПЗ — це командна робота.

Дякую, що дочитали! Якщо вам сподобалась стаття, кидайте копійчину на РЕБ для морпіхів.
Якщо не сподобалась, то теж кидайте 👇
🔗 Посилання на банку

👍ПодобаєтьсяСподобалось18
До обраногоВ обраному6
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мені дуже сподобалась стаття,написано корисно та з душею,зберіг собі👍

Странно что в статье про Shift Left не упоминаются Quality Gates и Continuous Testing — без этих понятий представление о TestOps будет неполным

Если кому то хочется посмотреть разъяснения о том, что это такое перейдите по ссылкам ниже

Continuous Testing — i.postimg.cc/sfLNR5N0/CMMI-CT.png
Quality Gates — i.postimg.cc/...​yPHZx3Z/Quality-Gates.png

не бачу взаємозв’язку — чому QG і Continuous Testing — це зміщення вліво? Можете обґрунтувати?
З моєї точки зору, це як раз самий сок тестування.
А автоматизація тестування — антипод shift left, бо робиться здебільшого задля покриття регресії.
І взагалі я не шанувальник CMMI 😁

Соррі у Вас якесь неправильне уявлення про поняття автоматизації тестування.

Test Automation != Functional Regression of e2e scenario & it’s coverage

автоматизація тестування — антипод shift left

Блін тільки на співбесіді так не кажіть — не треба ганьбитися. Прочитайте тут докладніше www.browserstack.com/...​hat-is-shift-left-testing

Особливо уважно цей параграф — How to Implement Shift Left Testing Approach?

Без introduction Quality Gates для коду неможливо собі уявити Shift Left — не дарма картинку вам скинули — прохання ознайомиться і розібратися в темі

Гарна стаття про shift left — здається, я навіть її читав колись. Але чому ви наводите цю статтю, в якій написано погляд конкретного інженера, як беззаперечну правду? ЇЇ авторка молодець, і ми навіть маємо низку спільних пунктів в параграфі How to Implement Shift Left Testing Approach.
Визначення shift left (дякую пану Wrath) — an approach to software testing and system testing in which testing is performed earlier in the lifecycle.
Я саме так його і сприймаю — зробив фокус на активностях планування, вимог і дизайну, коли ще жодної строки коду може не бути написано.

Без introduction Quality Gates для коду неможливо собі уявити Shift Left...
прохання ознайомиться і розібратися в темі

Тестування різноманітніше, ніж ви можете уявити, і кожен тест інженер може приносити більше користі, ніж думає.
Я розібрався в темі і намагаюсь дивитись на речі ширше 😁

Послухайте мені здається це у Вас дуже однобоке розуміння тестування і Ви свій досвід поширюєте на всіх інших — втім після того, як я побачив картинку на релігійну тематику, потрібно було здогадатися, що автор догматик, який не сприймає критику. Ах так Ви ще й сидите в одній компанії вже 15 років не дивно, що в такому разі Вам вже давно «корона тисне»

Послухайте мені здається це у Вас дуже однобоке розуміння тестування

ви зробили такий висновок, базуючись на...

Ви свій досвід поширюєте на всіх інших

було б дивно у статті, де я ділюсь власним досвідом і best practices, які в мене спрацювали, не ділитись власним досвідом

автор не сприймає критику.

Процитую сам себе з попереднього коментаря:

ЇЇ авторка молодець, і ми навіть маємо низку спільних пунктів в параграфі How to Implement Shift Left Testing Approach.

Я сприймаю конструктивну і обґрунтовану критику

як я побачив картинку на релігійну тематику... Ах так Ви ще й сидите в одній компанії вже 15 років не дивно, що в такому разі Вам вже давно «корона тисне»

коли нема аргументів по суті, переходите на особистості? Дорослий і розумний підхід в дискусії 👍
У мене там ще картинка з котиком на єдинорозі — вперед, можете написати, що я ще й наркоман

Я написав Вам вище що стаття написана слабо і Ви ігноруєте дуже багато важливих аспектів з практик Shift Left та Test Ops

Я на жаль не можу багато витрачати час на суперечки з Вами, так як займаюся реальною роботою і звичайно у мене не так багато вільного часу для написання 100500 статей та топиків на форумі =)

Я написав Вам вище що стаття написана слабо

всім не догодиш ¯\_(ツ)_/¯

Ви ігноруєте дуже багато важливих аспектів з практик Shift Left та Test Ops

покажіть но мені пальцем, де я обіцяв розкрити всі аспекти Shift Left та Test Ops в цій одній статті? Чому ви в статті про шифт лефт взагалі очікували розкриття всіх аспектів тест опс? Люди на цю тему книжки пишуть
Резюмую: ви самі придумали собі завищені очікування незрозуміло чого, а вони не виправдались. Не робіть так 😉

Я на жаль не можу багато витрачати час на суперечки з Вами, так як займаюся реальною роботою і звичайно у мене не так багато вільного часу для написання 100500 статей та топиків на форумі =)

Я на то і експерт, що оптимізував свою роботу так, щоб і робота була зроблена, і час на 100500 статей був 😉

Шановний Олексію, я бачу Ви ніяк не хочете заспокоїться, тому відповім Вам востаннє.

Ось приклад нормальної технічної статті на dou dou.ua/forums/topic/45216

Вона структурована, описує для кого вона призначена, дає введення у тему для новачків, визначає проблему та підхід до її вирішення.

А ось цей Ваш набір думок вголос перемішаний із безглуздими картинками я нормальною технічною статтею назвати не можу і якщо я бачу якісь недоліки я не мовчатиму просто тому, що когось у компанії промоутнули до Head of QA Practice тільки тому що він пропрацював там 15 років. На цю тему до речі є чудовий терм термін en.wikipedia.org/wiki/Peter_principle

The Peter principle is a concept in management developed by Laurence J. Peter which observes that people in a hierarchy tend to rise to «a level of respective incompetence»: employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another

Рустаме, маю зазначити, що стаття опублікована в розділі «Блоги», а не «Технічні статті». Також давайте постараємося розвивати дискусію (за бажання) стосовно тез, викладених в статті, але не переходити на особистості. 🙂

Шановний Олексію, я бачу Ви ніяк не хочете заспокоїться, тому відповім Вам востаннє.

Я не заспокоююсь, бо я люблю жваві дискусії. Більш того, я жадаю від вас критики по суті, бо кожен раз, отримуючи конструктивну критику, я вчусь новому і стаю ще кращим інженером.

Ось приклад нормальної технічної статті на dou

Це не технічна стаття, про це вам навіть редакторка ДОУ пише 👇. Це радше софт скіли. Знову цитую себе.

ви самі придумали собі завищені очікування незрозуміло чого, а вони не виправдались. Не робіть так 😉

Якщо виділяти вашу критику, я зрозумів, що:

  • вам стаття не подобається, тому що не подобається
  • безглузді картинки
і якщо я бачу якісь недоліки я не мовчатиму

так не мовчіть — напишіть про кожен недолік step by step.
Бо поки здається, що мій єдиний недолік — то мій стаж роботи🦕. Чи це не ейджизм часом? 😂

Я просто оставлю здесь ссылку на en.wikipedia.org/wiki/Shift-left_testing

Смотрите Agile/DevOps shift-left testing

І взагалі я не шанувальник CMMI 😁

это у Вас после сдачи ISTQB такая нелюбовь к CMMI? 😁

Дякую за лінку. Чи ви самі читали, що там написано?
Бо я бачу протиріччя між визначенням

...testing is performed earlier in the lifecycle..

і описом

traditional shift-left concentrates on unit testing and integration testing

А Agile/DevOps shift-left testing — лише

a single or small number of V as in the previous two examples of shift-left testing

Бо згідно цієї статті у вікіпедії, раніше unit та integration — тестування нема ¯\_(ツ)_/¯

Ну это вы уже цепляетесь к словам и терминологии — широко известный факт что IT индустрия довольно таки новая сфера по историческим меркам и терминология не устоявшаяся и меняется от компании к компании

Вы не поверите например что я слышал от разных специалистов когда мы говорили с ними о том что собой представляют интеграционные тесты :)

IT индустрия довольно таки новая сфера по историческим меркам и терминология не устоявшаяся и меняется от компании к компании

так і я ж про це 🤝
Мені хочеться, щоб shift left був про будь-які активності, якщо вони є «якомога раніше» в життєвому циклі. Про це і написав. Може колись і цитата мене на вікі потрапить 😂

Вы не поверите например что я слышал от разных специалистов когда мы говорили с ними о том что собой представляют интеграционные тесты :)

жгітє, мені цікаво!

це просто V-модель. як і будь яка модель, вона окреслює напрямок руху, але не розказує, як треба рухатись

Дякую, що дочитали! Якщо сподобалось, кидайте копійчину на РЕБ для морпіхів:
🔗Посилання на банку
send.monobank.ua/jar/4NaJnwrSDS

якщо не сподобалось, теж кидайте

хм. я писав не так

дякую, пофіксив

Самарі — власне запозичення слова Summary, трапляється в українській мові так само, як і багато інших англіцизмів. (Це була редакторська правка).

Підписатись на коментарі