Як ми усі знаємо, Тестування Програмного Забезпечення — надзвичайно цікавий та доволі інноваційний напрямок в ІТ сфері.

     А хто не знає? На початках зародження ІТ, розробники (програмісти) писали код, а потім самостійно здійснювали його перевірку та тестування. Поступово, разом із збільшенням кількості програмного забезпечення і його удосконаленням, виникла необхідність у окремих фахівцях із тестування — тестувальниках. Чому? Бо тестування полягає не тільки в тому, аби переконатися, що код працює без помилок, як очікувалось. Тестування вимог, інтеграційне тестування, функціональне тестування, регресійне тестування, тестування навантаження… список можна продовжувати й продовжувати, оскільки параметрів, які слід враховувати при тестуванні конкретного програмного забезпечення ДУЖЕ багато.

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

 1.Думка, що тестування — це тільки створення і запуск тест-кейсів

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

2. Ігнорування необхідності достатнього розуміння коду

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

3. Неефективна комунікація (Я, твоя, моя нє панімать)

     Ми всі бували у ситуаціях, коли помилку в програмному забезпеченні виявив клієнт. Звісно, кого він звинувачує? — Команду тестувальників. Багато хто в таких випадках сприймає догану на рахунок власного его і починає захищатися, шукати виправдання. Професія тестувальника вимагає терпіння і ефективної комунікації! Крики і спроби переконати всіх, типу “Ви тут ні до чого”, нікуди не приведуть, а ефективна робота над власними помилками й покращенням тестового процесу однозначно допоможуть виправити ситуацію, втримати клієнта.

4. Обмежений вплив кінцевого користувача

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

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

5. Очікування щоб розробник ввів в курс справи

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

6. Відсутність пріоритезації областей для тестування

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

7. Недооцінка автоматизації — там де потрібно застосувати автоматизоване тестування

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

8. Відсутність чітких планів на майбутнє підвищувати професіоналізм у галузі тестування ПЗ

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

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

9. Відсутність сприйняття тестування як професії

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

10.  Неспроможність спланувати стратегію тестування

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

Радимо про себе аналізувати питання:

  • Які інструменти тестування використовувати / вивчити?
  • Які були невдачі при останньому запуску / релізі?
  • Як можна зробити тест-кейси більш ефективними?

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

     Деякі речі приходять з досвідом, а деяким треба наполегливо вчитися. Стати аналітиком із Забезпечення Якості або тестувальником означає піклуватися про якість продукту на усіх рівнях і щиро хотіти його покращити.

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

      Отже, це були мої ТОП 10 підказок Junior qa engineer, котрі заважають стати професійним тестувальником. Надіюсь, вони були для Вас корисними.

Джерело: www.softwaretestingclass.com/10-reasons-why-you-are-not-a-professional-tester

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.