Ну інших конкретних даних, окрім цієї однієї вибірки, поки що немає. Тому так, ці дані і є для мене актуальними.
Якщо у вас є дані про те, який відсоток кандидатів працевлаштовуються після платних курсів (в порівнянні з загальною клькістю працевлаштованих джуніор/трейні куа) — поділіться, буде цікаво.
Колега сказав, що три роки тому тестував маркер. Вчора людина випустила відос про те, як же тестувати олівець: www.youtube.com/watch?v=qpSEsGEGYg8 .
Порівнювати тестування з авіамоделюванням чи мікробіологією некоректно. Тестування, схоже, не викладають окремим курсом в університетах, кафедр тестування теж не зустрічав.
3. Спробуйте дати визначення слову «якість», спираючись лише на розуміння.
4. Звідки ви знаєте? Продавці до цього часу продають ручки на співбесідах. Замість олівців може бути простий функціонал загальновідомої програми, наприклад.
Чесно кажучи, не знаю, хто і навіщо малює такі діаграми. Я особисто ще не зустрічав людини (включно з senior QA чи Senior Dev), яка б володіла всіма перерахованими навиками.
В коментарях відповідав вже.
класика не старіє. завжди є головні речі і додаткові. за сотнями технологій ми забуваємо головне, а потім дивуємось, чому роботодавці реджектять сертифікованого кандидата.
Вакансії без обов’язкових вимог знань сіквела, хтмл, апі, рест, соап, лінукса, гіта та сніферів:
jobs.dou.ua/...pgame-qa/vacancies/181436
jobs.dou.ua/.../newxel/vacancies/178970
jobs.dou.ua/...ies/p2h/vacancies/183321
jobs.dou.ua/...ologies/vacancies/182728
Звичайно, треба багато вчитися. Але вимоги дуже різні. Що ж вивчати? SQL, MySQL, Oracle, NoSQL, MongoDB, REST API, SOAP, XML, HTML, CSS, Linux, Docker, web-browsers, Agile/Scrum, FW, TestRail, HP ALM, Microsoft Test Manager, JIRA, Git, mobile testing...? Я відкрив лише 4 вакансії на джинні. Потрібні роки, щоб вивчити згадані принципи, технології та інструменти бодай поверхово. Горе в тому, що з всього цього тестувальнику-новачку потрібно, може,
Але якщо ви зосередитесь на лише двох — теорія та англійська — і вже потім, якщо бажаєте, додасте, наприклад, навик роботи з API, ви суттєво виокремите себе серед інших.
В тому, щоб клацати кнопки на фронті, нема нічого поганого. Суть роботи тестувальника: знайти проблему. Клацаєте ви по кнопочкам, запускаєте скрипти чи переглядаєте код — яка різниця, якщо з кожною знайденою вами проблемою ПЗ стає кращим.
Так, якщо без досвіду, то інтернатура чи трейні — найкращий варіант. Але якщо таких кандидатів багато, роботодавець відбирає за принципом найбільш критичних характеристик, а такими якраз і є хороші знання теорії і англійська (якщо це аутсорс, наприклад). Не сертифікати. Перевірка апі — цей мейнстрім, я згоден, і якщо ви цілитесь в цю галузь, і вже є теорія і англійська, накинути зверху практику перевірки апі вже трохи легше.
Чи потрібна мова програмування, залежить від обраного напряму. Якщо автоматизація — так. Для мануала ця вимога не обов’язкова.
Якщо ви добре знатимете теорію тестування і матимете гарну англійську, на трейні вас точно візьмуть. З джуном як пощастить. Але якщо кандидат заходить з іншого боку — вивчає JIRA, Scrum, SQL, і вцілому хоче осягнути все те, що описано у вакансіях — але при цьому забуває про теорію, такий кандидат, імхо, довго шукатиме свою компанію.
11.6 млн результатів на запит «full stack qa engineer». Менше ніж на «General QA», але має право на життя.
Ідею потреби в ручному тестуванні я б сформулював просто: Якщо юзерами є люди, продукт мають перевіряти люди. І залучати для допомоги будь-які інструменти (в т.ч. автотести).
ручное тестирование — это прошлый век
що ж, тоді гугл все ще в минулому столітті
Пропрієтарний Squish справляється.
Згоден, але якщо людина відкриває для себе нові горизонти і йде до них, працювати цікавіше.
вроде Robot его хавает с AutoIt
Не впевнений (хоча заводити не пробував). Але по відгукав виглядає сумнівно, з урахуванням, щоб працювало і на macOS.
йдеться про тест-план
Йдеться про тест-сьют в термінології ISTQB.
все ще є проекти, які роблять релізи раз на 10 місяців з1000-годинним регрешином
Можливо, на тлі зростання кількості мобайл- та веб-проектів частка інших проектів стає меншою, проте такі проекти продовжують бути і приносити прибутки.
Можливо, вартувало б половину із тих 1000 людиногодин потратити, щоб автоматизувати хоча б частину регресійного плану
Слушна думка, ми йдемо в цьому напрямку.
Що ж, можливо. Спасибі. Чесно кажучи, переважно зустрічаю це слово в англомовному написанні (test suite), на автоматі транслітерував у «тест-сьюіт». Втім, «сьюіт» це, чи «сьют», зміст статті від цього не зміниться.
Будь ласка! )