Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

QA Engineer в ІТ-продукті: як шукати першу роботу і які навички розвивати, щоб будувати кар’єру

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

Вітаю, товариство! Мене звати Олександр, я працюю QA Engineer у продуктовій IT-компанії Quarks. Я влаштувався до компанії, маючи лише дев’ять місяців комерційного досвіду, й успішно продовжую кар’єрний шлях уже 3 роки.

Напрям QA я обрав у доволі зрілому віці. До цього понад 6 років обіймав менеджерські посади, але з часом зрозумів, що трохи втомився від управління, й розвиватися далі стало нецікаво. Деякий технічний бекґраунд я здобув ще під час навчання в університеті за спеціальністю «Телекомунікації» — там познайомився з базами даних, версткою, основами програмування. Це й досі допомагає мені в роботі.

Про те, чим саме займається QA Engineer, ви й так знаєте з інших джерел. У цій статті я б хотів поділитися своїм досвідом та думками, на що звернути увагу під час пошуку першої роботи, які хард- та софт-скіли варто розвивати, як побудувати процеси в тестуванні. Текст може зацікавити тих, хто думає над кар’єрою в QA, а також початківців у сфері.

Як обрати першу компанію

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

Для свого карʼєрного розвитку я обирав саме продуктову компанію. Основними критеріями були:

  • наявність інформації про підходи до розробки;
  • довгостроковість підтримки продукту;
  • ставлення до якості;
  • відгуки від людей, яким можна довіряти.

Перша компанія, де я працював, спеціалізувалася на big data. Команда допомагала будувати бізнеси та покращувати продукти, збираючи інформацію про дії користувачів на ресурсі. Серед клієнтів були компанії зі світовим імʼям, тож їхні завдання часто потребували індивідуального підходу. До фахівців висували справді високі вимоги, й мені пощастило здобувати свій перший досвід із сильною командою розробки.

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

Однією з моїх перших задач була саме така — міграція на нові кластери з оптимізацією коду та структури бази даних. Це об’ємне й шаблонне завдання, однак завдяки йому я покращив незакріплені знання після курсів, ближче ознайомився з технологіями вебзастосунків та попрактикувався працювати з ними.

Важливо розібратися, як взаємодіють між собою клієнт та сервер, сервер та БД, які є підходи до зберігання даних, а також зрозуміти, які принципи та технології використовують для вибору архітектури застосунку. Саме це допомогло успішно впоратися із завданням, а також швидше адаптуватися на новому місці роботи.

Які навички потрібні QA Engineer

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

Хард-скіли

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

Вміння працювати з інструментами для тестування. Наприклад, Postman, Fiddler, Charles. Вони потрібні, щоб налагоджувати та тестувати взаємодію клієнтської частини застосунку з серверною, а також можуть використовуватися для автоматизації API-тестів.

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

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

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

Окремо ми відстежуємо час відповіді на запити, реквести з розбивкою на статус-коди тощо. Особливу увагу звертаємо на 400-ті та 500-ті.

Робота з системами управління тестуванням дозволяє виробити системний підхід до тестування, написання документації, оцінки тестового покриття, надання тестових звітів і багато чого іншого. З найпопулярніших можна виділити TestRail та TestOps. Вони дуже легко інтегруються з баг-трекінговими системами, системами CI/CD та вашим тестовим фреймворком.

Робота з системами налагодження (DevTools). Набагато простіше пояснити розробнику проблему, надавши console log або вказавши, в якому з файлів проблема.

Робота з баг-трекінговими системами. Думаю, не потрібно пояснювати, наскільки такі системи корисні в менеджменті задач. Можна, звісно, просто поговорити з розробником та домовитися про «швидкий фікс». Але все ж краще оформити баг в Jira або Trello, й уже там відстежувати статус виправлення помилки.

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

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

Загальне розуміння технологій вашого продукту. З часом варто дізнатися, для чого вони призначені, та як мають працювати. Детально ознайомтеся з мовами програмування, якими написано проєкт, розберіться з CI/CD, зрозумійте, як працює система контролю версій, які брокери повідомлень використовуються, які є системи управління базами даних та чому обрали саме їх, як відбувається моніторинг та управління ресурсами тощо. Якщо маєте справу з вебзастосунком — розберіться у верстці, почніть з основ HTML, CSS.

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

Софт-скіли

Ось який вигляд має список потрібних навичок.

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

Толерантність до монотонної роботи. На жаль, вона часто йде поруч з QA: однакові перевірки, написання чи оновлення документації. З монотонністю в написанні документації доведеться змиритися, а ось перевірки краще автоматизувати.

Комунікативні навички. Це один з найважливіших скілів. Фахівець спілкується з усіма членами процесу розробки — постановником задачі, дизайнером, девелопером, аналітиком, членами інших команд, а іноді — ще й із замовниками та користувачами. Також QA надає звіти про тестування, й вони не завжди приємні. Розробники часто сприймають недоліки реалізації на свій рахунок, тому треба навчитися толерантно доносити цю інформацію.

Гнучкість та готовність до конфронтації. До гарного QA можна застосувати вираз «один у полі воїн» — він вміє відстоювати свою думку. Важливо пам’ятати, що бачення має бути об’єктивним та супроводжуватися аргументами. Водночас не варто забувати, що справді гарна пропозиція не завжди буде корисна бізнесу. Фахівець має відчувати цю межу, і, якщо потрібно, вчасно відмовлятися від рішення на користь компромісного.

Здатність ухвалювати рішення. Саме QA — це остання інстанція перед передачею фічі до кінцевого користувача, тож готуйтеся ухвалювати рішення та нести за них відповідальність. Однак не варто ставитися до цього, як до чогось суто негативного. Краще сприймати це як досвід та робити висновки, щоб не наступити на ті ж граблі.

Організованість та вміння керувати своїм ресурсом. QA має найкраще знати свій проєкт, тож витрачає багато часу на збір необхідної інформації, й ще більше — на те, щоби ділитися експертизою. Додайте до цього написання документації, тестування задач, зустрічі, проведення співбесід — і стане зрозуміло, що в добі занадто мало годин, щоб це все встигнути. А треба вписатися в межі робочого дня. Тут вам можуть допомогти різного роду застосунки для таск- та тайм-менеджменту — календарі, Trello, Todoist тощо.

Здатність та бажання розвиватися й навчатися. Це одні з найважливіших навичок. Технології постійно розвиваються, з’являються нові практики та підходи, тож, якщо хочете досягти успіху в цій сфері, потрібно завжди тримати руку на пульсі інновацій. Так ви завжди будете в контексті того, що робить команда, й полегшите собі роботу завдяки найкращим практикам. Розвиток має стати невіддільною частиною вашого життя.

Який вигляд має процес роботи QA

Дехто думає, що QA Engineer — це просто співробітник з не дуже сильною технічною підготовкою. Сподіваюся, під час читання статті ті, хто так вважає, змінили свою думку. QA — це не тільки про тестування, а й про відповідність виконаного до поставлених вимог. Тому фахівець має хоча б базово розумітися на різних продуктових напрямах: програмуванні, аналітиці, дизайні й т.д. Втім, це все — лише частина обов’язків, тому далі пропоную розібратися у процесі роботи QA над проєктом, який я проілюструю реальними задачами з власної практики. Думаю, так у кожного буде цілісне враження про те, чим тестувальник має займатися щодня, аби підтримувати високу якість продукту.

1. Визначаємося з вимогами до тестування

Насамперед треба вивчити аудиторію продукту, визначити, хто та як буде ним користуватися. Дізнатися про найпопулярніші платформи, девайси, розміри екранів, операційні системи для користувачів, на яких розрахований застосунок. Тут допомагають статистичні ресурси, як-от Statcounter. Базуючись на цьому, можна будувати стратегію тестування різних сегментів користувачів.

Після запуску продукту обов’язково потрібно налаштувати аналітику. Вже з даними щодо користувачів саме вашого застосунку точно визначте платформи, пристрої, екрани, операційні системи, якими користуються юзери. Потім усе задокументуйте, погодьте мінімальні вимоги до девайсів користувачів та переходьте до кросбраузерного та кросплатформного тестування. У нас частину даних дає власний трекінг, з іншим допомагає Google Analytics.

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

Графік використання ресурсів одного із сервісів, що витрачаються при обробці запитів. Вказано найпопулярніші запити в конкретний момент часу, час обробки кожного та кількість використаної памʼяті з розбивкою за окремими ендпоінтами.

Графіки моніторингу навантаження системи в реальному часі

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

Крім того, визначте, чи варто вам автоматизувати на даному етапі. Коли я прийшов до компанії, продукт уже був доволі складним і великим, тому без автоматизації було важко.

2. Підготовка до тестування

QA підключається на ранньому етапі життєвого циклу задачі. Він оцінює ідею, її опис, переконується, що вимоги завдання не суперечать одна одній, а також уже реалізованому функціоналу. Ми для цього проводимо грумінги, де оцінюємо складність задачі, нюанси її реалізації та визначаємо, чи потрібно її взагалі робити на даному етапі.

На основі вже зібраних даних можна починати будувати вимоги до тестування та писати тестову документацію: тестові сценарії, чеклісти тощо. Для себе ми виділили за обовʼязкове написання тест-кейсів. Вони одні покривають усі механіки, навіть ті, які за якихось причин неможливо протестувати мануально або автотестами. До речі, процес написання тестової документації теж бажано зафіксувати. У нас є окремий документ, де описано всі деталі: в якому вигляді треба передавати задачі на тестування, за якими критеріями визначати їхню готовність, що саме має зробити QA перед тим, як результат потрапить до кінцевого користувача.

3. Безпосередньо тестування

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

  1. Після закінчення розробки девелопер пересвідчується, що виконав усе, чого вимагала задача, зміни, які її не стосуються, не вносили, а якщо він зачепив суміжний функціонал, то інформація про це є в описі завдання. Також він пересвідчується, що в гілку задачі стягнули всі актуальні зміни.
  2. Розробник ініціює збірку тестового середовища. Далі стартують автотести з мінімальним набором перевірок — щоби підтвердити, що дефектів в основному функціоналі продукту немає. Цей процес автоматизований, тож якщо з проєктом усе добре, і тестове середовище розгорнуто успішно, то на останньому кроці в pipeline відбувається відправка webhook на CI для запуску автотестів. Після їхнього проходження формується посилання на репорт, яке відправляється в задачу та додатково публікується в окремому Slack-каналі.
  3. Якщо щось пішло не за сценарієм, то розробник має це виправити. Інакше задача вважається не готовою до тестування, тобто не виконується умова DOR (у нас є і Definition of Ready, і Definition of Done задач для тестування).
  4. Задачу бере в роботу QA. За необхідності, він актуалізує тестову документацію, доповнює сʼюти, які почав описувати на етапі планування тестування задачі (якщо щось пропустив або не врахував на етапі підготовки).
  5. Паралельно починається процес автоматизації. Що раніше ви автоматизуєте, то менше доведеться мануально ретестити один і той же функціонал. У нашій команді Manual та Automation QA донедавна були, можна сказати, окремими командами. Manual QA писав тест-кейси, а Automation QA покривав продукт автотестами відповідно до них. Зараз ми йдемо до того, щоб розмити кордони між цими командами, аби Manual QA більше закривали свої потреби в автоматизації, тобто перетворювалися вже на General QA.
  6. З sanity-тестування починається безпосередньо мануальне тестування, адже smoke вже провели автотестами, які запускав девелопер. Залежно від результатів перевірки, задача повертається на доопрацювання або QA переходить до тестування суміжного функціоналу та регресійного тестування.
  7. Фахівець пересвідчується, що задача відповідає виставленим DOD. Після цього відбувається деплой до основної гілки, де новий чи оновлений функціонал буде доступним кінцевому користувачу.
  8. Завершується процес ретестом задачі та проходженням регресії на продакшені. Для когось це може виглядати зайвим, адже лише нещодавно перевіряли все на тестовому середовищі. Але оскільки архітектура передбачає, що стейджинг клієнтської частини застосунку звертається до стейджингу сервісної частини, то в роботі задеплоїного функціоналу можливі відмінності на продакшені. Наприклад, клієнтська частина не так обробляє відправлені дані або навпаки, сервер ще не повертає ті дані, на які вже орієнтується клієнт.

    4. Підтримка

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

    Впевненість, що з реалізованим функціоналом нічого не станеться, в тому числі через причини, які не залежать від вас чи розробника. Тут допоможуть автотести (їх можна запускати по крону як healthchecks), логування помилок та періодичний аналіз логів, моніторинг продуктових метрик, Ad-hoc тестування. На продуктові та сервісні метрики бажано налаштувати сповіщення — так ви оперативно зможете відреагувати на просадки в ефективності, збільшення кількості помилок на продукті або інші аномальні показники.

    Обробка запитів користувачів. Запити діляться на два типи: користувачу не зрозумілий функціонал або він зіштовхнувся з багом. У першому випадку варто зробити функціонал більш user friendly, а другому — пофіксити баг та мінімізувати ризик повторення цього в майбутньому.

    Періодичне проведення ad-hoc та дослідницького тестування. Цей етап дуже важливий та часто дає змогу помітити те, що раніше пропустили або не покрили сповіщеннями.

    Можливості росту

    Який напрям розвитку обрати вам, ви зможете зрозуміти лише на певних етапах кар’єри. Спектр можливостей для розвитку QA Engineer доволі широкий. Серед найпоширеніших — менеджмент, розробка, аналітика, автоматизація. Є шлях до позицій Automation QA, Security QA, Product/Project Manager, Developer, а також можливості вирости до тимліда чи до техліда.

    Я обрав розвиток у напрямі General QA. Зараз я займаюся і мануальним тестуванням, й автоматизацією, і налагоджуванням процесів. Такий набір робочих обов’язків дозволяє відволікатися від одного конкретного напряму, урізноманітнити буденні задачі та не ретестити одні й ті ж механіки, бо цей процес уже автоматизований.

    Якщо у вас залишилися запитання щодо інших аспектів роботи QA — я з радістю відповім на них у коментарях.

    Корисні ресурси

    • «Тестування. Фундаментальна теорія» — стаття на DOU у двох частинах (ось перша, а ось друга) з теорії тестування. В них ви зможете ознайомитися з теорією тестування, принципами та підходами до процесу.
    • HTTP and everything you need to know about it — стаття про http-протокол. Доволі легка для сприйняття. Автор розповідає про структуру запиту, описує переваги https над http та перелічує основні http-методи, а також групи статус-кодів. Додатково рекомендую ознайомитися із загальними властивостями методів.
    • W3Schools — ресурс, щоби заглибитися в основи мов програмування, взаємодії з базами даних, верстки та інше, що може знадобитись QA Engineer.
    • Q & A — навчальний ресурс для інженера-початківця. Тут зібраний набір лекцій і практичних завдань, які можуть допомогти на старті кар’єри.
    • Udemy — онлайн-ресурс для проходження курсів з різних напрямків. Залежно від потреб, ви можете обрати курс для себе. Наприклад, коли у нас на проєкті вирішили спробувати інтегрувати навантажувальне тестування, саме на цьому ресурсі я знайшов курс, де гарно описано весь процес — починаючи від написання тестів, закінчуючи їх візуалізацією та віддаленим запуском.
    • How Google Tests Software — книга авторства Джеймса Віттакера та Джеффа Каролла, де описано процес тестування в Google, чим займаються QA Engineer в компанії та причини, чому все побудовано саме так. Книга радше для ознайомлення з цікавою практикою, ніж рекомендація до інтегрування у своїй команді.
    • Head First Design Patterns: A Brain-Friendly Guide — книга авторства Еріка Фрімена, Елізабет Робсон, Кеті Сьєрра та Берта Бейтса розкаже, що таке патерни програмування, для чого, й у який момент їх потрібно застосовувати. Після прочитання, ви краще зрозумієте структуру проєкту, і, як наслідок, зможете спростити весь процес тестування й уніфікувати тести.
    • Telegram-канал Security QA — канал, де публікують книги, інструменти хакінгу, відео з конференцій та інші матеріали, що стосуються тестування безпеки.
    👍ПодобаєтьсяСподобалось20
    До обраногоВ обраному14
    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
    Як ви вже зрозуміли з наявності цього блоку, я вважаю вибір компанії, де ви будете здобувати перший досвід роботи, дуже важливим.

    Як автор пропонує реалізовувати вибір першої компанії при конкуренції 50 (DOU) — 600 (Djinni) кандидатів на місце?

    Пруфи:
    jobs.dou.ua/...​ends/?category=QA&exp=0-1
    public.tableau.com/...​iz/ItJobMarket/Dashboard1

    Вітаю!
    Дякую за відгук.
    Так, пошук першої роботи може бути нелегким, як і в будь-якій іншій сфері. Але в цьому матеріалі викладена субʼєктивна думка з особистими прикладами і що стосується розділу про працевлаштування — якщо Вас влаштовує компанія і Ви готові прийняти від неї оффер, то чому б так не зробити)
    Для себе я обрав саме той шлях, який описав. На щастя, проблеми з працевлаштуванням особисто у мене не було. Були звісно і співбесіди, які я відверто провалював, але головне зробити з цього відповідні висновки, бути обʼєктивним і чесним перед собою, закрити прогалини в знаннях, і бути наполегливим в пошуку.
    Як спеціаліст, який пройшов не одну співбесіду і провів їх в багато разів більше, можу сказати, що якщо Ви впевнені в собі і в своїх знаннях, Ваші знання відповідають вимогам вакансії, і особливо, якщо Вам є що запропонувати компанії окрім того, що вимагається в описі до конкретної вакансії — Ви однозначно можете розраховувати на оффер.
    Так, на жаль ринок перенасичений, але і багато спеціалістів елементарно не відповідають вимогам. Особисто моя думка, це може бути повʼязано з хибною впевненістю в отриманих знаннях на курсах/відео-уроках, які в свою чергу можуть запевняти про «легкий вхід» з мінімальними знаннями. Часто так і є, отримані там знання є поверхневими і їх обʼєм є мінімально достатнім для проходження співбесіди. Але якщо окрім того, що Вам викладають, Ви будет постійно прокачувати себе, як спеціаліст і не забудете вказати це в своєму CV — Ви вже зможете привернути до себе увагу рекрутера, який запропонує Вам співбесіду.
    Перед співбесідою дійзнайтесь про стек технологій, що використовується на проекті і ознайомтесь з ним. Якщо Ви будете впевнено і розкрито відповідати на поставлені питання, що стосуються конкретної вакансії і того, що Ви вказали в резюме, то знайти роботу не складе проблеми.

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

    Коли я шукав роботу QA 15+ років тому, впевненості в собі також було достатньо. Але тоді рекрутерам не доводилося перегортати по 600 відгуків на вакансію. Здається, зараз фізично неможливо знайти роботу QA без досвіду — бо таку кількість резюме люди не переглядають.

    Приходить начальник, йому передають пачку резюме. Він з середини витягає випадкових 10 штук, а інші викидає до смітника. Рекрутерка дивиться великими очима. Лід відповідає: «А нащо мені невдахи?».

    Не можу повністю погодитись, адже підходи до пошуку в різних компанія відрізняються.
    Знову ж таки на своєму прикладі, в ході пошуку кандидатів переглядав і відверто «пусті» резюме. І так, вони не проходили до етапу співбесіди, але тому що не відповідали вимогам вакансії, в основному через відсутність необхідного стеку знань, рандомної вибірки не застосовуємо) До того ж, з останніх кількох наймів в команду QA на проект, один кандидат був без досвіду роботи, двоє інших мали мінімальний комерційний досвід, один і шість місяців, випробувальний термін закрили всі.
    Ваш приклад теж має місце бути, але так далеко не в усіх компаніях. І якщо резюме кандидата було відхилено, то він має повне право запитати причину відмови і заповнити прогалини в знаннях чи резюме.

    він має повне право запитати причину відмови

    Ніби рекрутери відповідають

    Дякую за статтю та лінки. Як раз «How Google Tests Software» нещодавно обговорювали. Таки треба виділити час та прочитати.

    Ніколи не розумів для чого писати і публікувати такі статті.
    З пустого в порожнє.Трава зелена, небо голубе. Кому потрібна ця вся теоретично-безсенсовна інформація, крмі автора який це все написав ?
    Жодного реального практичного кейсу або корисної інформації. І так 80% статей на ДОУ (((

    Чому? Багатьом тестувальникам, котрі засиділись на одному місці, буде корисно. Все в цьому світі йде по спіралі — технічні та навколо-технічні статті не виключення.

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