вівторок, 19 вересня 2017 р.

6 речей, що б повчити тестувальнику в 2017



Якщо ви досить довго перебуваєте в ІТ-спільноті, то Ви, безумовно, помітили нещодавній рекрутерський бум. "Сіньйорам" це здається цілком звичайним "білим шумом", але зараз не тільки в Україні, але й у всьому світі, зростає попит на мідл, і навіть на молодших програмістів, тестувальників та всіх інших людей, які тямлять у розробці програмного забезпеченні.
І це не дивно. Автоматичні виробничі лінії та 3D-друк зробили товари дешевими та доступними на стільки, що вони такими ще ніколи не були. Тож чим менше людей задіяні у виробництві товарів, тим більше людей готує для цього програмне забезпечення.Але зростаючий попит викликає конкуренцію всередині ІТ-ринку праці. Вже ходять легенди про бонуси, що найбільші компанії платять інженерним командам, щоб ті продовжували працювати над продукцією компанії, а не на власний старт-ап. ІТ-фахівці часто відчувають себе (навіть своїми гаманцями) як рок-зірки! Щоб взяти участь у цих перегонах за долари та славу, требатпостійно вивчати та оновлювати свої знання про нові технології та інструменти. Нижче перераховані деякі штуки, які, на мою думку, можуть зробити привабливим Ваше резюме, а професійні рішення - відповідними останнім тенденціям.


    Мережеві протоколи

        Кожен продукт в 2017 році намагається позиціонувати себе на ринку як "IoT-ready". З технічної точки зору це означає кінець епохи "Тестування чорної скриньки", оскільки на столі з'являється щонайменше пара "чорних ящиків": клієнт та сервер. І протоколи та архітектури обміну даними можуть бути набагато більш кольоровими, ніж старий хороший "клієнт-сервер через HTTP". Малі пристрої, що працюють від батарей, публікують топіки по MQTT через WebSockets. Віддалені камери та датчики надсилають відео потоки один до одного через WebRTC. Кожен з них може мати декілька механізмів резервування та відновлення. Кожен з цих протоколів має власні способи і інструменти для налагодження та зневадження. Дізнайтеся, які обмеження мають налаштування мережевого протоколу для вашого продукту, і, можливо, стратегія тестування наступної задачі дозволить Вам ненав'язливо знайти крітікал!

    Автоматизуйте лише потрібне. Не автоматизуйте непотрібне.

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

    Будьте "поліглотом" програмування

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

    DevOps

        Вміння налаштовувати процес розробки, щоб зробити його більш чітким та прозорим - це велика перевага для будь-якого тестера. Зараз розробники часто не є "пірнальниками на глибину", повністю покладаючись на IDE, CI-сервери та інші сторонні рішення для підготовки коду. Навіть якщо на проекті є окрема особа DevOps, він, без сумніву, не має стільки ж контексту, що тестувальник, і він точно оцінить допомогу в роботі з конфігурацією, розповсюдженням та розгортанням системи. Розглядайте девопса як іншого розробника, який, як і всі розробники, може неправильно трактувати завдання, може не пам'ятати про всі вимоги і, нарешті, може помилятися. DevOps - це лише додатковий компонент системи, який достойний такої ж уваги тестера, що й інші. До того ж, хто може знати, де який модуль має як працювати краще, ніж тестер?

    Docker (знову цей Docker...)

        Віртуалізація вже давно під боком, але вона ніколи не була такою легкою і орієнтованою на розробника, як із Docker. Турбота про багаторівневу мережеву систему з безліччю залежностей на кожному рівні звучить складно, і це є так. Але це перетворюється на жах, якщо ви раптом попросите, щоб погратися, нове тестове середовище. Звичайно, докер не вирішує всіх проблем, але він значно їх спрощує. З його додатком docker-compose, конфігурація середовища виявляється не складнішою, за звичайну девелоперську задачу, що дозволяє описати всю складну розгалужену інфраструктуру в одному файлі під системою керування версій! Забудьте про сторінки Confluence зі списком «Необхідні сторонні бібліотеки для встановлення». Задокеруй всі речі!

    Ваш продукт для людей

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


Дізнавайтеся щось (корисне для професійного росту) щодня. Немає меж досконалості!
І побачимось на QAfest!

Немає коментарів: