Тестування ПЗ. Рівень 1. 1 місяць.
Теоретичні знання та початковий досвід
В даний час в IT-сфері як ніколи стала актуальною професія тестувальника. Насамперед високий попит на фахівців, які займаються тестуванням програмного забезпечення. Основними обов'язками таких співробітників є виявлення помилок у роботі програм та моделювання різних ситуацій, пов'язаних з їх додатковим навантаженням. Таким чином, виявляючи та описуючи похибки, надсилаючи звіти про них для внесення виправлень у програму, тестувальники постійно взаємодіють із командою розробки. Курс "Тестувальник ПЗ. Рівень 1" від GeekBrains призначений для тих, хто хоче розпочати кар'єру у тестуванні програмних продуктів. У його рамках розглядаються теорія та практика створення тест-кейсів, тест-комплектів, оформлення багів та звітів за результатами тестування. Даний курс - це 8 практичних занять, де Ви отримаєте знання та навички, необхідні для того, щоб легко включитися в роботу над створенням та покращенням IT-проекту.
Урок 1. Основні поняття у тестуванні
Що таке тестування. Як визначити якість ПЗ (стандарти ISO, критерії якості, метрики). Категорії програмних помилок. Термінологія.
Урок 2. Місце тестування у процесі розробки ПЗ
Цикл розробки програмного забезпечення. Цикл тестування ПЗ. Типи тестів у процесі розробки програмного забезпечення. Відповідність тестування методології розробки програмного забезпечення.
Урок 3. Розробка тест-кейсів
Визначення та структура тест-кейсів. Характеристики гарного тесту. Аксіоми тестування. Підтримуваність тест-кейсів. Системи управління якістю. Тест-комплекти. Чек-листи. Підготовка тестових даних.
Урок 4. Класи еквівалентності та граничні умови. Планування та робота з вимогами
Визначення та пошук Класів еквівалентності. Кордони класів еквівалентності. Робота з вимогами до ПЗ. Участь у плануванні релізу ПЗ. Що робити, якщо документації немає.
Урок 5. Робота з багтрекером
Визначення та функції багтрекера. Як правильно формулювати завдання? Життєвий цикл (workflow) помилок. Оперативне відстеження завдань у багтрекері.
Урок 6. Регресійне тестування
Призначення регресійного тестування. У яких випадках необхідно проводити регресійне тестування. Вибір тест-комплектів для регресійного тестування. Приоритизація та оптимізація тест-комплектів.
Урок 7. Організація процесу тестування
Посадова ієрархія у тестуванні. Планування та оцінка термінів на тестування. Критерій початку/завершення тестування. Звітність за результатами тестування. Підготовка робочого місця.
Урок 8. Тестування інтерфейсу користувача
Особливості тестування інтерфейсів GUI і web-додатків.
Тестування ПЗ. Рівень 2. 1 місяць.
Робота з документацією та тестування додатків
Багато хто вважає, що професія тестувальника є нудною та одноманітною. Однак ця думка несправедлива. Професійний тестувальник - це, в першу чергу, людина, яка вміє творчо підійти до вирішення завдань, що стоять перед ним. Досвід, який набуває в рамках цієї професії, може стати ступенем до кар'єри програміста. Важливою особливістю роботи тестувальника є можливість повноцінного аутсорсу та фрілансу. Курс "Тестувальник ПЗ. Рівень 2" від GeekBrains призначений для тих, хто вже знайомий з основами тестування та хоче отримати більш глибокі знання та навички, необхідні для початку кар'єри в IT-сфері. У його рамках розбираються способи дослідження тестованого ПЗ, вивчаються техніки визначення необхідної кількості тестів та способи візуалізації тестованого функціоналу. Даний курс - це 8 практичних занять, після яких Ви зможете проявити себе як експертний користувач програмного забезпечення, що має власне бачення найкращої організації процесу тестування.
Урок 1. Тест-аналіз. Дослідження ПЗ
Типи та цілі дослідження ПЗ. Декомпозиція програми.
Урок 2. Доменне тестування та комбінації параметрів
Урок 3. Тестова комбінаторика
Створення тестового набору. Мінімальні перевірки. Перебір значень. Атомарні перевірки. Pairwise. Метод взаємопов'язаних перевірок.
Урок 4. Тестування станів та переходів
Аналіз ПЗ на можливі стани та переходи. Виявлення життєвих циклів сутностей та комбінація станів. Вибір валідних перевірок.
Урок 5. Тест-аналіз на основі бізнес-логіки
Вибір умов бізнес-вимоги. Створення таблиць рішень. Комбінування тестів з урахуванням таблиці решений.
Урок 6. Тест-аналіз на основі ризиків (передбачення помилок)
Визначення тестованого функціоналу ПЗ. Виявлення потенційних помилок та їх градація. Визначення стратегії.
Урок 7. Стратегія тестування
Цілі та завдання стратегії тестування. Вибір відповідних технік залежно від функціоналу та особливостей. Облік дисфункційного тестування.
Урок 8. Оцінка ефективності тестів
Оцінка тестового покриття. Оцінка ефективності тестів.
Введення в автоматизацію тестування. 1 місяць.
Автоматизоване тестування
Автоматизація - частина загального процесу тестування, вона є важливою складовою під час побудови роботи та відстеження процесу тестування у рамках розробки програмного забезпечення. На курсі ви розберете різноманітні аспекти використання підходів до побудови процесів автоматизованого тестування. Дізнаєтесь, які існують види програмного забезпечення для проведення автотестів. Зрозумієте, як автоматизувати процеси тестування та створіть свої перші автотести.
Урок 1. Введення у автоматизоване тестування
Що таке автоматизоване випробування; які різновиди автоматизованого тестування бувають; проектний вибір: ручне чи автоматизоване; чорний та білий ящик при автоматизації; огляд та вибір інструментарію.
Урок 2. Стратегія автоматизованого тестування. Практичне створення тестів за допомогою Autoit.
Прийняття рішення щодо запровадження автоматизації; проектування автотестів; стратегії автоматизованого тестування; процес розгортання автоматизації; тестове оточення щодо автоматизації; створення автотесту з допомогою Autoit.
Урок 3. Види автоматизованого тестування
Види автоматизованого тестування; автоматизоване функціональне тестування; інструменти юзабіліті тестування; автоматизоване тестування навантаження.
Урок 4. Проект Selenium та його складові.
Цілі, завдання, особливості Selenium. Selenium WebDriver. Selenium RC. Selenium Server. Selenium Grid. Приклад використання Selenium IDE практично.
Урок 5. Автоматизоване тестування навантаження на прикладі Apache Jmeter
Тестування навантаження; принципи та практика побудови навантажувальних тестів; огляд інструментів; приклад використання Apache Jmeter
Урок 6. Автоматизоване мобільне тестування
Тестування мобільних програм; автоматизовані інструменти – огляд, вибір; тестування навантаження; мобільні емулятори; мобільних ферм.
Урок 7. Автоматизація процесу тестування
Автоматизація процесу тестування та створення тестів; утиліти для автоматизації процесів тестування; генерація тестів; фреймворки; плагіни.
Урок 8. Робота з вимогами та постановками завдань
Вимоги, завдання; системи роботи з вимогами та постановкою завдань; системи багтрекінгу; налагодження процесів проведення тестування та їх автоматизація та інструментарій.
Основи бази даних. 20 уроків.
Проектування БД та запити SQL
Бази даних (БД) - це системи зберігання та обробки даних, для доступу до яких використовується мова SQL (Structured Query Language). Будь-який сучасний сайт, гра або настільний додаток потребують зберігання даних. На даний момент існує безліч різних систем управління базами даних (СУБД), найпопулярнішою є MySQL. "Основи баз даних" - це 20 інтенсивних відео-уроків (по 10 хвилин), де ми пройдемо всі етапи проектування БД на прикладі інтернет-магазину з використанням мови запитів SQL. Після цього курсу ви зможете використовувати різні бази даних, такі як MS SQL та Postgre Sql, оскільки синтаксис мови SQL для них практично не відрізняється.
Урок 1. Реляційні бази даних
Чим відрізняється БД від СУБД; які бази даних називаються реляційними; огляд сучасних СУБД.
Урок 2. Встановлення СУБД
Установка СУБД MySql та графічної програми Mysql Workbench.
Урок 3. Проектування бази даних, нормальні форми
Проектування даних у Excel; нормальні форми; первинний ключ.
Урок 4. SQL-команда CREATE
Створення таблиць у графічному інтерфейсі MySql Workbench; команда CREATE; типи даних; робота у консолі.
Урок 5. SQL-команда INSERT
Заповнення таблиць даними за допомогою графічного інтерфейсу; команда INSERT; AUTO INCREMENT.
Урок 7. SQL-команди DISTINCT, ORDER BY, LIMIT
Отримання та фільтрація даних за допомогою SQL-команд DISTINCT та LIMIT; Сортування за допомогою команди ORDER BY.
Урок 9. Узгодженість даних
Поняття узгодженості чи консистентності даних.
Урок 10. Зовнішній ключ
Поняття зовнішнього ключа та обмежень на значення стовпців; FOREIGN KEY CONSTRAINTS.
За час своєї роботи у сфері тестування, у мене склалася своя, особлива думка про цю сферу, починаючи з позиції молодшого тестувальника (junior tester) до керівника відділу тестування (test manager). І, загалом, ця думка досить критична з часткою любові та обожнювання до цієї чудової професії.
Як вступ
Я ніколи не збирався ставати тестувальником – мене більше приваблювала розробка. Зі шкільної лави я писав програми, які вже обкатувалися моїми однокласниками, а потім одногрупниками: мені було цікаво вирішувати завдання і пожвавлювати речі, а вже вирішенням проблем і багів, що виникають, я займався після того, як мені про них повідомляли користувачі. До версії я приписував мінорну циферку, і… і в якомусь балансі між функціональністю та якістю програма залишалася назавжди, поступаючись місцем новим проектам та програмам.
Забігаючи наперед, скажу, що частково в цьому криється ключ до успішного ведення проектів – у знаходженні балансу між витратами на розробку продукту та його якістю.Будь-який продукт схожий з біологічним організмом, у формуванні якого беруть участь не одна людина, а багато - прямим або опосередкованим чином. У формуванні хорошого продукту повинні брати участь усі зацікавлені сторони, і кожна з них має робити вагомий внесок у спільну справу. Але, на мій подив, тестувальники в цьому відношенні займають особливу нішу: по-перше, вони є сполучною ланкою в процесі, а по-друге, вони єдині з інженерів мають право вето на випуск версії продукту.
Про все про це я дізнався на першому своєму місці як тестувальник з незгаслими амбіціями розробника. Насамперед мене зачарувала можливість отримання доступу до управління продуктом, влада, на яку я не надто розраховував. Це було чудово, щось особливе, вище за написання чергової функціональності. По-друге, тестувальники в силу особливостей професії мають більше уявлення про процеси та цілі продукту, частково транслюють бізнес мети розробникам, а результат розробників – керівникам. На жаль, у світі і, тим більше, у Росії, уявлення про роль тестувальника дуже сумбурне, і її значення сильно зменшується. А ті компанії, які все-таки перебувають у тренді, намагаються розвинути напрями тестування та управління якістю, хоч і ставлять дещо завищені цілі: «знайти всі помилки, знизити до мінімуму вартість розробки через тестування».
Ця стаття, в першу чергу написана за мотивами спілкування з різними компаніями, є квінтесенцією відповідей на їхні запитання. По-друге, звернена до тестувальників-початківців і тих людей, які хочуть дізнатися про тестування побільше з точки зору внутрішньої кухні. По-третє, базується виключно на моєму (суб'єктивному) досвіді.
Теза №1: Тестувальник - не мавпа
В Android SDK входить чудовий інструмент під назвою MonkeyRunner, який дозволяє автоматизувати процес тестування Android додатків в ідеалі без вихідного коду, без особливих знань мов програмування (лише загального уявлення про скриптові мови достатньо) і, головне - імітувати будь-яку поведінку справжнього користувача. У результаті виходить така собі скриптова мавпа, яка тикає, друкує, читає додаток. Саме те, що можна "віддати на аутсорс" машині. Для мене таке розуміння тестування у порядку речей. Але, на мій подив, коли я шукав роботу вперше після своєї першої посади в ролі тестувальника, з'ясувалося, що на ринку існують (і донині!) дивний поділ на «ручних» та «автоматичних» тестувальників, більше того, сходи грейдів і зовсім настільки змішана і розтягнута, що дивуєшся. Не кажучи вже про те, що від компанії до компанії ті самі посади мають на увазі різні посадові обов'язки, особливо це актуально для старших посад.
До моїх посадових обов'язків входило: складання тест-дизайну, тест-кейсів, стратегії тестування (якщо це був призначений на мене проект), репорт багів, перевірка документації та створення тестової документації. Це було зрозумілим для мене, хоча дещо дивувало, що у західних колег ці обов'язки були розділені. На ринку виявилося, що цілком звичайним явищем вважається, що дизайн пишеться за допомогою CTE/UML (у кращому випадку) Test Lead/Senior Tester/Test Designer. Тест кейси (різноманітні стратегії перевірки кордонів, інтерфейсне тестування, навантажувальне, стендові кейси) - Senior Tester'и. І, нарешті, є нижчі посади «виконавців» - Tester. У деяких компаніях та відділах їх кількість може сягати 20 і більше осіб! Інакше кажучи, у штаті проекту вважалися мавпи, у разі, які мають навичками користувача комп'ютером і якимось продуктом.
Насправді ж це дещо неправильно. Тому що тестувальник не мавпа. Якщо це не так, то або ви, як компанія, випускаєте різні продукти в короткий термін, без подальшої підтримки та якості, проганяючи формальні smoke-тести, або, що ймовірно, ваш менеджер/архітектор - баран.
Витрати автоматизацію тестування окупаються далеко ще не відразу.
Для знайомих з теорією тестування (яких, як показує практика, не так вже й багато), цілком очевидно, що необхідність автоматизації сильно залежить від специфіки проекту (його термінів, підтримки, повторюваності тощо). У деяких випадках куди краще обійтися smoke тестами і користувальницьким бета-тестуванням і виконувати приймання через product owner"a, ніж ускладнювати процеси. Прийняти продукт власнику продукту, в другому можна обмежитися, якщо допускають це вимоги, прийнятною самими інженерами-розробниками з випуском release notes У випадку, коли тестування потрібно все-таки окреме, то набагато простіше і ефективніше мати поставлений менеджментом процес життєвого циклу продукту і людини або команду інженерів, здатних самостійно покрити завдання розгортання та тестування продукту, тобто людей, які апріорі знають область, інструменти та методи, а не стадо мавп, яких повісили на розробників чи одного керівника проекту.
Ремарка №1
Як не дивно, але ця проста теза часто свідомо порушується. Наприклад, для аутсорсингових компаній це добрий спосіб отримати додаткові FTE. У плані бізнесу просто вигідніше продати більше, що має низьку собівартість. У досвіді моєї роботи на Auriga, де замовникам надавалися на погодинну оплату відповідні ресурси у кількості десятків осіб – не поодинокий випадок. Більше того, такий план добре покриває цілі стафування проекту для клієнта за мінімальних витрат. Незважаючи на те, що навантаження на менеджера проектів значно зростає, при грамотному керівництві це нехай до створення «кузні кадрів» за рахунок проекту, прив'язки кадрів до компанії (навчання та зростання навички) при порівняно більшій ціні купівлі спеціаліста з ринку, і подальший перепродаж, ротація персоналу більш вимогливі проекти.
Ще однією причиною такої стратегії є можливість придбання нецільових кадрів для клієнта. Так вже виходить, що вимоги до кадрів ваших роботодавців або клієнтів іноді бувають недалекоглядні (про що мова піде нижче), і меншими витратами для компанії (грошима та часом) є можливість купівлі фіктивних кадрів. Скажімо, купівля такого роду «мавп» на проект із параметром «20 років стажу» (але, можливо, будучи вельми посереднім фахівцем). Це особливо актуально в системі грейдів Junior/Standard/Senior багатьох компаній, особливо за межами Росії, де вимоги до стажу та реалії трохи інші.
Наступною, і, як на мене, головною причиною, є ризики. Постановка завдань на проекті для тестування – це покриття певної функціональності та дій. Найчастіше процеси можна автоматизувати, особливо щодо регулярних активностей, регресійного тестування, тобто в процесі тестування створити ферму, процес та інфраструктуру, що часто масштабується, портується і переноситься на інші продукти та проекти з мінімальними витратами. Скорочення «безпосередньої» роботи на проекті для тестувальника веде до двох наступних наслідків:
- Тестувальник стає тестувальником-автоматизатором або він отримує нові сфери відповідальності та нове навантаження. У такому разі, його ринкова ціна та попит на нього зростають, що викликає ризик його догляду або підвищення зарплатних домагань, а це може бути великою проблемою в рамках одного проекту та неможливістю масштабувати та ротувати у компанії.
- Ризик переходу системи на бік замовника чи аутсорсу. У випадку аутсорсингової компанії – це ризик втрати FTE аж до втрати проекту. Такі ризики рідко вносяться до ризик-планів проектів, хоча непрямим чином керуються через місію компанії та тиск топ-менеджменту.
Тому цю першу тезу варто розглядати як проблему у стратегічній перспективі для будь-якої компанії, проблему ролі тестування та вибудовування інженерних процесів. Дозвіл її, грамотна градація та використання суто інженерних кадрів, є ознакою грамотного керівництва та довгострокового планування в компаніях.
Теза №2: Тестувальник - це інженерна професія
Через мішанину з мавпами у професії тестувальників вистачає людей, далеких від інженерної сфери, які навіть не мають відповідної технічної освіти. Це дійсно сумно і сумно, тому що кваліфікованих ресурсів на ринку тестувальників сьогодні дійсно не вистачає - грамотні фахівці вважають за краще йти в розробку (у кращому випадку близьку до теми аналітика), а ті, що залишаються, мають мізерне уявлення про життєвий цикл ПЗ, тестування та мови програмування.
На мій погляд, будь-який тестувальник повинен мати технічні знання, впевнене володіння і хоча б базові навички адміністрування прикладних програм і популярних ОС. Крім того, тестувальник повинен мати хоча б базове уявлення про мови програмування, вміти читати код хоча б на інтуїтивному рівні, а також швидко адаптуватися до нових мов та програм/середовищ. Взагалі, головні особливості тестувальника – це гнучкість та навченість. Тому, маючи досвід у програмуванні та загальне уявлення про скриптові мови та мови високого рівня, людина зможе навчитися та адаптуватися без особливих проблем. В ідеалі потрібне знання скриптової мови та основ мови розробки, на якій і базується проект.
З цього випливає, що тестувальник зобов'язаний вміти працювати з кодом. Хоча, в ідеалі, хороший процес має виконуватися за моделлю чорної скриньки. Проте в нього, в цей ящик Пандори, тестувальник повинен не боятися зазирнути і допомогти розібратися з проблемою розробнику. Тобто бути як риба у воді в системі не тільки багтрекера, а й контролю версій коду, і бути здатним провести реву коду.
Незважаючи на те, що я в переважній більшості випадків чую думку, що процес реву коду, налагодження (дебаггінг) і юніт-тестування - прерогатива виключно розробників, візьму на себе сміливість стверджувати, що це неправильний підхід. Проблема виходить із недостатньої кваліфікації тестувальників та неправильного управління життєвим циклом ПЗ. Можливо, цей підхід добре працює в маленьких проектах з TDD, але головна сила і можливість забезпечити високу якість продукту - розбити сфери впливу, відповідальності, забезпечити принцип роздільності (dissimilarity). » у розробників, уникнути «трюків» з їхнього боку.
Ремарка №2
У компанії Liebherr Aerospace жорстко вибудовані процеси та ролі у компанії. Точне проходження специфічним для галузі ітеративним моделям. Тим не менш, інженерне крило, інженерні посади називаються для всіх однаково – Software Engineer. Акцент робиться на тому, що співробітник компанії в першу чергу - спеціаліст, інженер в галузі ПЗ. Отже, співробітник має розбиратися в інженерних процесах, процесі розробки, тестування, схемотехніки тощо. Тим не менш, серед інженерів присутній обов'язковий поділ на спеціалізацію: in Test, in Development, in Requirements та ін.
Так як компанія слідує жорстко інженерним процесам з метою дотримання найвищої якості, кожна частина процесу розділена на незалежних учасників. Насправді це означає, кожен рівень вимог пишеться окремою людиною (групою), дизайн іншими, код пишеться третіми, юнит-тестування четвертими, функціональне тестування - п'ятими тощо. При цьому, щоб не дати «занудьгувати» та «ув'язнути» в рутині, людей у проекті намагаються обертати за функціями, і, цілком можливо, навіть на одному проекті, в різних ітераціях інженер, у міру своїх можливостей покриватиме різні обов'язки, і охопить різні етапи розробки ПЗ.
Те, що кожен з етапів і типів розробки та тестування повинен покривати різні люди, випливає з вимог міжнародних стандартів, таких як DO-178B (для авіації), EN 50128 (для залізничного транспорту) або ГОСТ Р МЕК 60880 (для атомних електростанцій), та забезпечує, зрештою високу отказоустойчивость лише на рівні процесів у тому числі у частині тестування ПО.
Теза №3: Метрики - нісенітниця, якщо немає роботи в команді
Під час майже кожної співбесіди на посаду тест менеджера можна почути питання щодо того, як претендент збирається вибудовувати процес тестування і які метрики з проекту він збирається знімати, які метрики використовуватиме до себе. Насправді, варіантів метрик – кількісних та якісних – можна придумати чимало, але особливого сенсу вони не матимуть доти, доки не буде в проекті ефективності в команді. У команді у сенсі слова, т. е. як усередині відділу/команди тестування, і при взаємодії з командою розробників і замовників з бізнесу.
На практиці це означає, що марно вважати кількість розроблених тестів (це метрика прогресу), знайдених багів (у гіршому випадку) показником ефективності команди тестування, навіть рейт регресій, навіть синтетичних метрик на проекті (з використанням критеріїв важливості та трудомісткості), не кажучи вже про ідіотських (але, як і раніше, застосовуваних і для команди тестування KSLOC\hour). Для менеджера проекту, можливо, буде непоганою метрикою CPI/SPI як KPI проекту, яка може базуватися на всіх позначених та зібраних тест-менеджером метриках. Тобто, досить абстрактна та високорівнева оцінка залежно від витрачених зусиль та отриманого результату. Але за умови, що команди працюють як єдиний організм.
Для тестувальників це означає, що вони є сполучним, провідним колесом процесу, яке зробить програмне забезпечення працездатним і відповідним вимогам. У процесі тестування це означає як саме тестування, так і надання тесту повторюваності, документованості, можливих проблем і вирішення проблеми (якщо це видно з боку тестування, якщо вистачає кваліфікації), а також перевіряти тестування (VoV). Іншими словами, завданням тестування є як перепрогін і перевірка всіх можливих станів, так і (у необхідному та достатньому випадку) покриття повної тест-стратегії та тест-плану (принаймні те, що зазначено в Quality Gates), винесення багів та їх дозвіл через розробників ПЗ та специфікації. Т. е., з перевірки та виявлення бага відповідальність у ньому не «перекидається» на розробника, а супроводжується тестувальником до його дозволу. Грубо кажучи, тестувальник відповідає за баги, а розробник – за фічі.
Тут ми підійшли до ключових відмінностей між тестувальником і розробником, які в моїй статті виходять дуже близькі і схожі. Тим не менш, за стилем роботи розробники зазвичай або перфекціоністи, або «фічедели» (які люблять кодувати заради коду, функціональності та алгоритмів); тестувальники ж - або педанти, або автоматизатори (які прагнуть автоматизувати автоматизацію). Тому у проекті тестувальник знає, як правильно зробити, а розробник – як саме.
Виходячи з цього, повторюся, що головне - це результат, що залежить від єдиної команди, а не тільки від метрик в одному прогресі, скажімо, дизайну. І де процес просідає більше - там і криється проблема, там і падають реальні метрики, які вже в контексті працюючого синергічного проекту набувають сенсу. Цілком можливо, що довга розробка тестів не вина дизайнера, а вина аналітика, який транстував вимоги надто складно.
Ремарка №3
Незважаючи на те, що описана мною модель говорить про єдність та взаємопов'язаність усіх етапів процесів, сьогодні тестувальників правильніше класифікувати все-таки на розробників самих тестів (що акцентують сили та знання на методології тестування) та devops інженерів, які обслуговують інфраструктуру. Сегрегація функцій має свої плюси при досить великому розмірі проекту та хорошому фінансуванні, коли розвиток, підтримку та тестування інфраструктури можна рознести між інженерами, в ідеалі між експертами-фахівцями. Важливим моментом є те, що тест-інженер все-таки насамперед інженер, розробник у тестуванні, здатний використовувати різні інструменти для вирішення поставленого завдання. І лише в другу чергу - експерт у якомусь певному інструменті та програмі. Знавців інструментарію, можливостей фреймворків правильніше класифікувати як окремих інженерів, інженерів-інструменталістів (tool engineer).
Теза №4: Тестувальник - центр процесу розробки ПЗ
У V-моделі розробки наочно видно, що тестувальник бере участь на всіх етапах життєвого циклу.
Схожість розробника та тестувальника, розмазаність кордонів області за наявності гарної кваліфікації – головний показник інтересу у роботі тестувальника. Звичайно, можна стверджувати, що причетність до продукту та його якості у разі тестування чорної скриньки є мотиваційним фактором, але, на мій погляд, людина, яка прийшла в технічну, інженерну область зробила це усвідомлено, з бажанням розвиватися та працювати над собою. Тому можливість розширювати свій кругозір, впливати на якість продукту (нехай навіть невеликих речей), проявляти активність, а також накладати вето на випуск продукту у тестувальника, на мою думку, вагоміші аргументи за професію. А раз так, якщо хороший тестувальник - не мавпа, а інженер-дослідник, знавець, що бере участь на майже на всіх етапах життєвого циклу (на відміну від ролей аналітиків, дизайнерів, розробників і технічних письменників), відповідальний за якість продукту (не процесу, це до QA, так що під «якістю продукту» матимемо на увазі відповідність заявленим і затвердженим вимогам і стандартам, чеклістам та інше), то для підвищення якості продукту та розвитку себе, як фахівця, тест-інженер повинен проявляти активну позицію. Він знає, як покращити продукт. Знає, що таке «досить хороший», і як його, продукт чи процес таким зробити, ініціювати рух як інженера-розробника, так і інших команд і навіть компаній. Наприклад, у будь-яких проектах бувають моменти простою, який може бути припустимий з боку керівництва. Зазвичай у цей час співробітники вирішують особисті проблеми чи займаються самоосвітою. Щодо роботи розробник може зайнятися рефакторингом, повивчати алгоритми та перенести на свої проекти. А що робити тестувальнику? Освоювати нові засоби тестування? Він нічого не робить без початкового пакета від розробників/аналітиків. Насправді, він може зайнятися автоматизацією своєї діяльності або покращенням продуктів, що ним використовуються, навіть якщо він далекий від інфраструктури та devops.
Ремарка №3
У Liebherr Aerospace жорсткий процес різко обмежував використання будь-яких інструментів і жорстко формалізував процес розробки та тестування, тобто простору для автоматизації залишалося не так багато – навіть втручання у багтрекер було заборонено. Тим не менш, такий процес, як підготовка документації, був у такі періоди автоматизований, нехай і з використанням VBA для MS Office, що не знаходиться під забороною. А для процесу код ревью можна було покращити статичні аналізатори коду. Вони не зовсім задовольняли стандарти на проекті і породжували зайві повідомлення, які не фільтрувалися навіть елементарним grep. Тим не менш, щоб зменшити час на ручне рев'ю коду, в рамках простою ми працювали на перспективу, покращуючи сторонній продукт, такий як статичний аналізатор, готуючи набір кейсів для імплементації потрібних нам перевірок.
Теза №5: Тестування – не місце для фіксації на ключових словах
Останньою і найдивнішою темою, на мій погляд, є дуже невиразне уявлення про тестування (навіть про теорію, не кажучи про практику). У багатьох компаніях відділи тестування не виправдовують надій, у деяких навіть дискредитували себе і функціонують на малу частину своєї потенційної ефективності за низкою чинників. Проблема виникає як через відсутність школи, так і через некомпетентність менеджменту. Ситуація дуже плачевна у галузях, віддалених від IT, навіть де «гроші – не проблема» – там завдання ставляться за принципом «підвищити якість продукту». Навіть у IT-компаніях, де є загальне уявлення про процеси, є ціла низка проблем, пов'язаних із фіксацією на певних ролях чи інструментах, хоча до тестування, повторюся, такий підхід погано застосовується.
В одному з великих інвестиційних банків, у якому я проходила співбесіду, була схожа вимога на позицію тест-менеджера: «підвищити якість і зменшити шлюб». Будь-яке завдання можна вирішити. Хоча під покровом завдань ховається координація відділів з різних продуктів, складання планів тестування, організація тестування, робота з розробниками, складання бази кейсів та інші. Насправді, відповідальність за якість продуктів у компанії логічно взяти на себе якомусь директорові з якості, воно ж QA Director, а не просто керівнику відділу тестування. Однак тут справа впирається у повноваження, яких на цій позиції немає, і відсутність групи, яка не планувалася зовсім (яка могла б допомогти тому тому). Тобто у компанію потрібна людина-оркестр без команди. Розгадка тут проста: менеджмент шукає за ключовими словами, і рахуючи якість в абревіатурі QA панацеєю від усіх проблем, хоча вона лежить у сфері стратегічного топ-менеджменту та процесів, які потрібно спускати зверху з відповідними повноваженнями та ресурсами.
В ідеалі управління якістю (QA) та тестування дві.
Проблема системна, тому що дуже непогано, коли HR шукають за ключовими словами на кшталт «навантажувальне тестування», «функціональне». Але коли в процесі розгляду робиться акцент не на навички тестування, не на активність і гнучкість кандидата, а на конкретний інструмент - це вже проблема, особливо коли ніякого тестування немає (є мавпування), і не факт, що необхідний інструмент ефективніший за те, який знає претендент. Проблема в тому, що знання дрібного нюансу або інструменту, на освоєння якого піде кілька годин, ставиться на чільне місце, вище знання мов програмування або теорії. В одному з інтерв'ю було досить смішно відповідати на запитання: «назвіть якусь книгу з тестування» і, відповівши про Сема Канера, почути: «ми такого не знаємо, а про життєвий цикл бага щось читали?». Це було б смішно, якби не було так сумно. Сумно, коли HR повідомляє про відмову через відсутність досвіду у кандидата, хоча справа до неправильного розставляння акцентів.
Знайти хорошого тестувальника - велика проблема, тому що інженер-тестувальник - це, в ідеалі, людина, яка вирішує технічні проблеми, пов'язані з розробкою ПЗ, такий собі проблему. Такій людині, крім технічних навичок дуже важливо мати уважність, допитливий розум, бути активним і вміти донести думку і відстояти свою точку зору на будь-якому рівні. Тому в руках інженера-тестувальника легко відомий символ - лупа (лінза), що спостерігає за жучками. Як не можна краще характеризує роботу тестувальника: використовується як за прямим призначенням для виявлення дефектів, так і для «пропалювання дірочок», з її допомогою можна добувати вогонь і навіть, маючи цілу систему лінз, спостерігати за зірками. Головне – вміти це робити.
Ремарка №5
У компанії Intel панує підхід, в якому інструменти вибираються з переваг співробітників на проекті. Це означає, що, загалом, неважливо, який інструмент і мову вибрати на вирішення завдання, головне - її вирішити. Співіснування трьох різних тест інженерів, які пишуть на трьох різних мовах цілком припустимо, якщо проблема вирішується, вирішується ефективно і накладні витрати на підтримку розумні, а процес документується. Крім того, багато використовуваних інструментів є безкоштовними, open-source або власної розробки. На сьогоднішній день існує безліч інструментів, за допомогою яких можна вирішувати різноманітні завдання, і вибір інструментів не повинен обмежувати можливості інженера. Однак, якщо для завдання дійсно потрібно використовувати якийсь інструмент, відмінний від вільно доступного, то за наявності чіткого розуміння та обґрунтування можна купити і використовувати його. Це знову-таки відповідає цілям бізнесу – не забивати цвяхи мікроскопом, не працювати ефективно, вичавлюючи максимум із інструментів, якщо кваліфікація інженерів дозволяє обійтися «малими втратами». Хорошою альтернативою є участь у відкритих проектах та інвестиції в них для подальшого використання для власних потреб. Такий підхід вбиває двох зайців (свої потреби) та завдання та створює інструменти для всього суспільства у вільному використанні.
Замість висновків
Тестувальник – це більше, ніж професія. Це спосіб проактивного життя і прагнення це життя зробити найкращим для всіх посильними та ефективними засобами. Цілі тестувальника щодо продукту найбільш близькі до цілей бізнесу та стратегічної мети компанії щодо цього продукту, і водночас глибокі всередині компанії у ролі дослідника. А якщо так, то головні його якості - це енергія, знання та гнучкість. Але в той же час робота тестувальника – це не загальне знання та відповідальність за якість продукту та якість послуг. У тестування є межі: з одного боку обмежені проектом та вимогами у ньому (менеджмент проекту та встановлений життєвий цикл програми), а з іншого – процесами, за які відповідає QA. Але про відмінність QA від тестування зовсім інша розмова.
Олексій Сьомін
Керівник відділу тестування компанії Globus, яка займається розробкою мобільних додатків та сайтів для великих замовників, таких як "Яндекс", "Лабораторія Касперського", ABBYY, Rutube, "СТС Медіа", HeadHunter, "ТНТ Клуб", "Зв'язковий Тревел", " PPF Страхування життя», VimpelCom та інших. Понад шість років у професії. Пройшов весь шлях від junior-тестувальника до керівника відділу.
Мій шлях тестувальника почався з цікавості. З самого дитинства я займався збиранням комп'ютерів та встановленням ПЗ, під час роботи регулярно виникали питання: «Чому не встановлюється? Чому не працює?". У цей момент я подумав, що хочу стати тестувальником, займатися випуском якісного програмного забезпечення та дізнатися відповіді на всі ці питання.
Нижче я хочу розповісти майбутнім QA-фахівцям про те, що на них чекає на початку кар'єри, і дати кілька порад зі свого досвіду.
Співбесіда
Junior-тестувальнику не дуже складно пройти співбесіду. Від нього не чекають глибокого знання теорії та інструментів для тестування. При співбесіді таких кандидатів ми звертаємо увагу на швидкість та жвавість мислення, свіжий та нестандартний підхід до вирішення завдань.
Наприклад, ставимо незвичайні питання, щоб подивитися, як мислить людина:
- Літак вилітає з точки А о 17:00, а прилітає до точки Б о 19:00. При цьому перебуває у польоті три години. Чому таке може бути?
- Як зробити так, щоб, отримавши оновлений додаток, конкуренти не змогли дізнатися про його нові функції?
Будьте готові і до звичайнісінького завдання - протестувати простий предмет: аркуш паперу, олівець, мережевий фільтр тощо.
Також для співбесіди буде корисно:
- Вивчити види тестування: функціональне та дослідне тестування, автоматизовані тести (включаючи інструменти для нього), навантажувальне та стрес-тестування, smoke-тестування.
- Додатково почитати про приймальне тестування та його критерії.
- Якщо ми говоримо про тестування веб-додатків, то це браузерна консоль та її робота, кількість та версії браузерів, роздільна здатність моніторів, інструменти тестування верстки (pixel perfect).
- Якщо ми говоримо про мобільні програми, це види платформ, емулятори, monkey testing. Не забудьте про планшети.
- Вивчити види баг-трекерів. Найпопулярніші: Jira, BugZilla, RedMine, Mantis. Подивіться, як вони працюють, у чому їхня особливість.
- У перспективі – інструменти Jmeter, Postman, Charles. Вони не надто складні в освоєнні на базовому рівні.
Перший робочий день
Перший робочий день відбувається стандартно: видають комп'ютер, який потрібно налаштувати, встановити робочі програми. Системний адміністратор готує доступи до пошти та корпоративних внутрішніх програм.
Не варто питати, де встановити Skype, використовувати в ньому нік із шкільних часів gangsta_666 або кумедну картинку. Використовуйте в ніке поєднання імені та прізвища, наприклад ivansmirnov чи smirnovivan, поставте свою звичайну фотографію.
Важливим кроком у підготовці до робочого дня є знайомство з баг-трекром, який використовує компанія. Про це варто поцікавитися заздалегідь: вивчіть статті, подивіться навчальні відео. Ви заощадите час колег і самі почуватиметеся впевненіше.
Перше завдання
Вам буде надано перший проект для занурення. Раджу ознайомитись з історією баг-трекера та подивитися, які дефекти вже зустрічалися чи найчастіше зустрічаються. Можете собі сформулювати статистику і розумітимете, на які моменти варто звернути більше уваги.
Виявляйте ініціативу. Якщо вам не дали чек-лист програми, не чекайте, а попросіть його у ментора. Якщо в організації немає чек-листа, ви можете скласти його. У нашій компанії найчастіше чек-лист становлять у «Google Таблицях». Нижче ми навели приклад такого чек-листа – ви зможете складати свої за його прикладом.
Колеги будуть здивовані, якщо складете чек-лист у вигляді , наприклад Xmind.net .
Чек-лист для тестування Pokémon GO
Одним з першочергових видів тестування для QA-фахівця-початківця, можливо, стане проходження по чек-листах, тест-кейсах старших фахівців. Цей етап необхідний швидшого занурення у проект. Для нарощування тестової бази новачок може розширювати цей чек-лист. Junior-тестувальники в рамках навчання написання чек-листів підготували лист для тестування програми Pokémon GO. Тут описано лише позитивні кейси.
Перший баг у трекер
Опис багів у різних компаніях може відрізнятися, але загалом є принципи гарного тону.
Тема
У ньому описують проблему кількома словами. Краще, якщо вона почнеться з заперечення: «не працює», «не відбувається», «неправильно» та інше. Наприклад: "Не відбувається синхронізація з сервером на iPhone 6", "Не працює відтворення відео в Nexus 5".
Сценарій
Покроковий опис відтворення бага. Звертайте увагу на передумову та знаки, які передують багу (наприклад, спалахнула червона кнопка зліва).
Додатково можна додати скріншоти із зазначенням місць, на які варто звернути увагу (можна використовувати програми Joxi, LightShot та інші), для більш складних багів - записати відео. Коли наберетеся досвіду, можете знімати та прикладати логи.
Наприкінці сценарію вказується середовище, в якому проводилося тестування: версія програми, прошивка девайсу (Android 6.0.1, iOS 9.3.2). Якщо ця веб-програма, додатково вкажіть версію браузера.
Призначення бага
Далі потрібно призначити на когось баг. Дізнайтеся у менеджера проекту або ментора, на кого вішати цей баг, хто з розробників за якусь область проекту відповідає. Так ви познайомитеся з командою, щоб у майбутньому самому призначати баги.
Проставлення критичності
Види критичності багів у більшості трекерів представлені наступним списком:
Immediate (Blocker)
Блокуюча помилка. Приводить додаток у неробочий стан, в результаті якого подальша взаємодія з системою, що тестується, або її ключовими функціями стає неможливим.
Crit - Urgent
Критична помилка, порушено ключову бізнес-логіку. Проблема призводить до тимчасового падіння сервера або програми без можливості її вирішення. Усунення проблеми необхідне тестування.
High
Значна помилка, порушена частина основної бізнес-логіки. Помилка не критична, є можливість для роботи з функцією, що тестується, використовуючи інші вхідні точки.
Normal
Незначна помилка. Не порушує бізнес-логіку частини програми, що тестується, очевидна проблема користувальницького інтерфейсу і локалізації.
Low
Тривіальна помилка не стосується бізнес-логіки додатка. Проблема сторонніх бібліотек або сервісів, погано відтворюється, малопомітна через користувальницький інтерфейс.
Самонавчання
Про важливість самонавчання всі чудово знають – мої настанови будуть банальні. Тож одразу до справи.
- «Тестування DOT COM», Роман Савін - дуже корисний посібник, практично настільна книга тестувальника-початківця. Містить у собі левову частку знань для того, щоб почати тестувати та успішно відповідати під час співбесіди на питання, що стосуються техніко-теоретичної частини.
- «Як тестують у Google» - глибша книга, що описує організацію процесів, різні стратегії та підходи до тестування. Книга допомагає зрозуміти, що така якість, як і на яких етапах на неї можна впливати.
- "A Practitioner's Guide to Software Test Design", Lee Copeland - у книзі розписані види тестування як "білим", так і "чорним" ящиком. Перераховані різні техніки тестування, а також те, як ними користуватися та коли краще застосовувати. У книзі можна знайти цікаву статтю про дослідне тестування, яка дуже корисна для тестувальників-початківців.
Колеги, напишіть у коментарях назви цікавих книг для тестувальників. Впевнений, усім буде корисно.
Висновок
На закінчення хочеться додати, що випуск якісного продукту - процес нелегкий і нешвидкий. Потрібно вміти відстоювати свою думку в переговорах, переконувати розробників робити правильно, а не на «милицях», розуміти, як зробити функціональність зручнішою для користувачів.
Це лише частина потрібної інформації для тестувальника-початківця. Решту доведеться в бойових умовах шукати в інтернеті, потім питати у колег. Не треба соромитися ставити питання і годинами гуглити, найчастіше відповідь на одне питання заощадить вам чимало часу в майбутньому.
Тестувальник ПЗ – що це за професія така? У чому полягає її суть? І наскільки вона актуальна у сучасному світі? Всі ці питання цілком доречні, тому що сьогодні професії ІТ-сфери є одними з найоплачуваніших на ринку праці. Не кажучи вже про те, що освоєння таких спеціальностей забезпечує людину стабільним майбутнім.
Тестувальник ПЗ: що це таке
Сьогодні більшість електронних пристроїв працює коректно лише завдяки вбудованим програмам. Їх написанням займаються програмісти всіх мастей та рівня підготовки. І повірте, їхня кількість справді захоплює дух. Так щодня створюється не одна тисяча програм: починаючи з простих калькуляторів і закінчуючи штучним інтелектом для високотехнологічних машин.
І, як у будь-якому виробництві, продукт не можна випустити у широкі маси, заздалегідь не перевіривши його на дефекти. Так от, тестувальник ПЗ (програмного забезпечення) – це людина, яка займається польовим випробуванням програм. При цьому він може бути як штатним співробітником компанії, так працюючим на себе фрілансером.
Навіщо потрібні тестувальники програм
Під час створення програм використовуються різні мови програмування. Це може бути C++, JavaScript, Python і таке інше. Після того, як продукт буде завершено, його насамперед перевіряє сам автор. Але оскільки він є творцем програми, він не завжди може об'єктивно оцінити якість отриманого товару. Не кажучи вже про те, що він може просто не вистачити часу для модуляції всіх можливих способів її застосування.
І саме на цьому етапі до гри входить тестувальник ПЗ. Саме він бере на себе всі операції, пов'язані з перевіркою нової програми. При цьому на відміну від програміста тестер не має доступу до програмного коду. Тобто, він відчуває додаток як простий користувач і лише зрідка наділяється особливими привілеями.
Основні обов'язки тестувальника програм
Тестувальник ПЗ - це професія, яка вимагає ґрунтовного підходу до справи. Тут не можна працювати в півсили, тому що це неодмінно позначиться на репутації фахівця. Що ж до самих обов'язків, то вони складаються з наступних пунктів:
- Створення плану перевірки. Тестувальник ПЗ повинен заздалегідь продумати всі сценарії використання програми та відтворити їх. При цьому чим досвідченіший фахівець, тим швидше він може визначати найбільш небезпечні для роботи програми фактори.
- забезпечення, за допомогою спеціальних автоматизованих інструментів. Як і в будь-якого іншого майстра, тестер має свої пристосування для оптимізації та прискорення роботи. Вони універсальні і тим не менш вимагають попереднього освоєння та практики.
- Грамотний та систематизований опис знайдених проблем та недоробок. Суть у тому, що недостатньо просто виявити помилку. Крім цього, потрібно вміти правильно складати протокол роботи, щоб програміст зміг зрозуміти, через що стався збій і яка частина його програми винна у цьому.
Слід зазначити, що часто тестувальників об'єднують у невеликі групи. Насамперед це потрібно для того, щоб прискорити перевірку або зробити її якіснішою. І тут роботу можуть рівномірно розподілити між усіма фахівцями. Наприклад, одні будуть зайняті інтерфейсом програми, другі шукатимуть помилки у обчисленнях, а треті - моделюватимуть найбільш небезпечні для програми сценарії.
Навчання професії
Тестувальником ПЗ може стати будь-хто, хто добре «дружить» з точними науками. В ідеалі, краще мати освіту програміста або хоча б розумітися на основах написання додатків. Виходячи з цього, ця спеціальність добре підійде тим, хто навчається на ІТ-спеціальності. По-перше, це допоможе набратися досвіду та подивитися на праці інших людей, а по-друге, принесе додатковий дохід, що також непогано.
Проте стати тестувальником ПЗ можна і без спеціалізованої освіти. Так би мовити, навчитися усьому самостійно. Благо, сьогодні це не проблема, тому що в мережі є безліч пізнавальних курсів, здатних наочно продемонструвати всі тонкощі цієї роботи.
До того ж, можна випробувати свою долю і спробувати потрапити на підготовлені семінари, які проводяться в багатьох організаціях, які виробляють ПЗ. Наприклад, компанія GlobalLogic періодично проводить навчальні курси спеціально для випробувачів ПЗ. Більше того, закінчивши їх, людина може стати одним із її співробітників, після чого почати працювати в її штаті або віддалено, як фрілансер.
Якими навичками повинен володіти фахівець, що поважає себе
Тестувальник ПЗ без досвіду може знайти собі роботу, а ось фахівець, який не знає основ – ніколи. Проте, які вони, ази професії? Який же багаж знань повинен мати кожен поважаючий себе тестер?
- По-перше, такий фахівець має бути знайомий із основами програмування, щоб мати можливість конкурувати на ринку праці.
- По-друге, доведеться запам'ятати принципи побудови програмного забезпечення та адміністрування ОС.
- По-третє, навчитися працювати із загальноприйнятими базами даних.
- По-четверте, вивчити особливу мову, без якої сьогодні вже не обійтися.
Крім цього, тестувальник повинен добре володіти англійською мовою, оскільки він є домінантним у світі програмування. Більше того, згодом доведеться довести його рівень до ідеального, а також вивчити всі тонкощі технічного стилю.
Напрацювання практичних навичок
Нехай тестувальник ПЗ без досвіду роботи - це цілком звичне явище, все ж таки на пристойний проект такого фахівця навряд чи візьмуть. Тому, вивчивши основи професії, слід зайнятися напрацюванням практичних навичок та позитивних відгуків.
Для цього необхідно вирушити на один із сайтів, які надають роботу фрілансерам. Щодня там викладається не один десяток пропозицій, пов'язаних із перевіркою працездатності додатків. При цьому є безліч замовлень для новачків, які не потребують досвіду роботи або особливих навичок програмування.
Таким чином, за місяць-другий можна непогано просунутися у своїй справі і заробити деяку репутацію. Єдиним мінусом і те, що подібні замовлення часто погано оплачуються. Але з цим доведеться змиритися, оскільки в майбутньому подібні поневіряння зможуть принести куди більш прибуткові замовлення, що окупить витрачені зусилля з лишком.
Де шукати прибуткову роботу
Отже, скажімо, ви вже досвідчений тестувальник ПЗ: з чого розпочати пошуки перспективної роботи? Що ж, насамперед варто переглянути оголошення на онлайн-біржах праці та форумах програмістів. Періодично там трапляються добрі пропозиції, здатні приносити стабільний дохід.
Однак, не варто розраховувати лише на удачу. Якщо у вас є і непогане резюме, можна подати кілька заявок в ІТ-компанії. Керівництво любить цілеспрямованих фахівців, а тому подібна ініціатива може принести свої плоди. Особливо якщо націлитись на ті компанії, які займаються виробництвом якісного софту.
Якщо ж із постійним місцем на даному етапі не щастить, то можна стати фрілансером. Тестувальник ПЗ, що добре проявив себе, віддалено працює вдома, здатний заробити не менше штатного колеги. Єдина різниця полягає в тому, що замість одного наймача він матиме кілька.
Плюси та мінуси професії
Для тих, хто любить і сучасні технології, ця професія здасться дуже цікавою та цікавою. Адже щодня доведеться стикатися з новим продуктом, який незабаром зможе докорінно змінити світ інформаційних технологій. До того ж робота вважається дуже престижною та виключає будь-які фізичні навантаження.
Також багатьох тішить той факт, що ця професія однаково добре підходить як чоловікам, так і жінкам. Більше того, вона може стати для тих, хто через проблеми зі здоров'ям не може влаштуватися на важчу роботу.
Проте є недоліки. Головним є висока конкуренція, викликана дефіцитом високооплачуваних замовлень. Також слід звернути увагу на той момент, що тестувальник програмного забезпечення дуже багато часу проводить за комп'ютером. При цьому він не просто сидить за ним, а повністю захоплений тим, що відбувається на моніторі. Через це з роками можуть виникнути проблеми із зором, що вкрай неприємно.
Оплата праці
Досить складно вивести середньоарифметичну зарплатню тестувальника ПЗ. Це з тим, що вона залежить від цього, наскільки щасливий спеціаліст. Так можна взяти одне замовлення на 10 тис. рублів і зробити його за тиждень, а можна отримати роботу на 20 тис. рублів і не здолати її за цілий місяць.
І все-таки можна з упевненістю сказати, що дохід тестера-початківця варіюється в межах 10-15 тис. рублів на місяць. Досвідчений фахівець може заробити ці ж гроші вдвічі швидше. А штатний співробітник престижної фірми взагалі отримує близько 40-45 тис. рублів.
Тестувальник ПЗ- людина, яка грає першочергову роль тестуванні програмного забезпечення. Професія має технічний ухил, вона сподобається абітурієнтам, схильним до інформатики та математики. Професія підходить для тих, кого цікавить інформатика (див. вибір професії з інтересу до шкільних предметів).
Короткий опис
Тестувальники програмного забезпечення є одними з найбільш популярних фахівців в IT-індустрії. Вони оцінюють програмне забезпечення з погляду експертів та звичайних користувачів, головна мета їх діяльності - виявлення та усунення помилок ПЗ. Іноді тестувальники формують технічну документацію російською чи іноземною мовою. В обов'язковому порядку вони готують звіти, а також розробляють інструменти та сценарії, які використовуються під час проведення тестування. Умовно їх поділяють на 2 групи:
- Альфа-тестувальники, які працюють з ПЗ, що знаходяться у стадії розробки;
- Бета-тестувальники, які спеціалізуються на готових версіях ПЗ.
Перед тестувальниками програмного забезпечення відкриваються перспективи професійного зростання, адже вони завжди можуть вибрати іншу сферу, яка так чи інакше пов'язана із сегментом IT.
Особливості професії
Тестування програмного забезпечення – захоплюючий процес, що має легкий творчий відтінок. Більшість свого робочого часу тестувальник проводить за комп'ютером або планшетом, смартфоном та іншими видами гаджетів. До обов'язків тестувальника ПЗ входять такі роботи:
- розробка оптимальних методик тестування, створення тест-кейсів, моделювання найпоширеніших поведінкових ситуацій;
- створення графіків та планів, виконання різних видів тестування: для безпеки, навантажувальні, функціональні, автоматизовані, конфігураційні, ігрові, юзабіліті та інші. Універсальний тестувальник може виконувати всі ці види тестування, але найчастіше спеціалізується на 1-2;
- створення баз даних та звітів за результатами проведеного тестування;
- класифікація помилок; глибокий аналіз результатів проведеної роботи;
- надання допомоги команді розробників у питаннях усунення помилок;
- консультації для розробників та замовників, аналіз скарг, що надходять від реальних користувачів.
Всі перераховані вище обов'язки варто розділити на 3 основні етапи: розробка (непряма участь), тестування та аналіз, підготовка технічної звітності та налагодження. Цей вид діяльності вимагає залучення, професія підходить для юнаків та дівчат, які схильні до кропіткої та малорухливої роботи.
Плюси та мінуси професії
Плюси
- Тестувальник ПЗ – престижна професія, яка відкриє шлях до інших IT-спеціальностей, де спостерігається ще більш високий рівень оплати праці.
- У тестувальниках ПЗ зацікавлені багато компаній, що займаються створенням програмних продуктів.
- Тестувальник може працювати в офісі або вдома, що дозволяє поєднувати діяльність з подорожами, хобі або здобуттям освіти.
- Заробітні плати тестувальників високі, сфера відкрита для амбітних людей будь-якого віку.
- Доступ до сучасного програмного забезпечення, ігор та інших цікавих продуктів.
- Можливість вести власний блог або вологу, що дозволяє популяризувати свої послуги та отримувати додатковий дохід.
Мінуси
- Робота тестувальників дуже добре оплачується, що спричиняє високу конкуренцію на ринку праці.
- Для виконання замовлень потрібний досвід, за його відсутності знайти роботу непросто.
- Професійні захворювання характерні для всіх людей, які працюють за комп'ютером.
Важливі особисті якості
Для тестувальника програмного забезпечення важливі такі професійні якості:
- логічне мислення,
- вміння концентрувати увагу,
- багатозадачність,
- моральна гнучкість,
- категоричність,
- підвищена точність,
- професійна відповідальність.
Тестувальник ПЗ спілкується з розробниками та замовниками, тому важливі комунікабельність та вміння правильно формулювати думки, а також грамотність.
Навчання на тестувальника ПЗ
Початківець тестувальник може закінчити ССЗ або отримати необхідні навички на курсах - все залежить від вимог потенційного роботодавця та особистісних навичок. Проте вищу технічну освіту слід розглядати як пріоритетну.Абітурієнт може обрати такі вузівські напрями підготовки, для яких профільним ЄДІ є математика:
- «Прикладна математика та інформатика» (код: 01.04.02);
- «Інформатика та обчислювальна техніка» (код: 09.03.01);
- "Інформаційно-аналітичні системи безпеки" (код: 10.05.04);
- «Інформаційна безпека» (код: 10.03.01) та інші технічні напрями, пов'язані з інформатикою, математикою, захистом цифрової інформації та обчислювальною технікою.
Якщо ви вирішили розпочати свій кар'єрний шлях із ССНУ, то розгляньте напрями «Інформаційні системи та програмування» (код: 09.02.07), «Комп'ютерні мережі» (код: 09.02.02) або «Прикладна інформатика (за галузями)». Почати навчання у вузі можна після 11 класу, до вузу абітурієнт може вступити, закінчивши 9 класів.
Міжнародний навчальний заклад, який спеціалізується на комп'ютерній освіті. Працює з 1999 року. 42 філії у 16 країнах світу. Найбільший авторизований навчальний центр Microsoft, Cisco, Autodesk. Студенти отримують міжнародні сертифікати та міжнародний диплом. Головна мета – працевлаштування кожного випускника.
Освойте одну з найбільш популярних IT-професій під керівництвом особистого наставника і почніть заробляти до завершення курсу. Досвід програмування не потрібен. Ви навчитеся тестувати сайти, мобільні програми та інше ПЗ. Дізнаєтесь, як влаштована робота IT-компаній, та зможете зрозуміти, як ви хочете розвиватися у професії. . Вже джуніори дуже потрібні ринком, а цей курс дозволить досягти middle-рівня.
На навчання запрошуються студенти профільних вузів (3-5 курс), практикуючі тестувальники, які хочуть здобути нові знання та підвищити свій професіоналізм. Навчання проводиться у вечірній час, у групі не більше 10 слухачів, тривалість курсу – 3 місяці. Талановиті випускники можуть отримати вакансію у компанії EPAM.
УЦ "Спеціаліст" при МДТУ ім. Н. Е. Баумана
На сайті навчального центру є великий вибір якісних програм для людей, які вирішили стати тестувальниками ПЗ. Будь-який курс складається з теоретичних та практичних блоків, форма навчання може бути очною або дистанційною. Тривалість навчання складає 16-64 ак. ч., мінімальна вартість - 11850 руб. і вище, що залежить від обраного профілю.