Я випадково знав якогось системного адміністратора, і за його словами, хлопці, які тестують, не дають переваг в організації порівняно з розробниками. Без сумніву, випуски програмного забезпечення неможливі без тестерів, але я ніколи не покладав руки на тестування, тому не дуже знав про це. Жодного правопорушення не передбачалося.
Відповіді:
На мій досвід, на жаль, до них часто ставляться як до службовців другого класу, а ще гірше - легковажної принади для програмістів.
Це пов'язано з низкою речей:
Коли тестери роблять свою роботу правильно, всім легко, але програмістам забути, що вони навіть існують. Так само, як адміністратор мережі, ви помічаєте їх лише тоді, коли вони не виконують свою роботу або роблять їх погано. Тож з точки зору решти організації їх пам’ятають лише за своїми помилками.
Помилково це розглядається як робота початкового рівня для людей, які прагнуть бути програмістами, але ще не кваліфіковані для цієї роботи. Насправді, в одній компанії, в якій я працював, їм присвоювали посади молодшого програміста, незважаючи на їхні прохання отримати посаду з питань Q&A. Навіть той факт, що вони перебувають у відділі контролю якості, був недостатній для того, щоб кадровий персонал зміг просунутися в цьому.
Через №2 передбачається, що всі тестувальники є людьми початкового рівня, і їм слід платити відповідно.
Ніхто не любить, щоб його критикували, і оборонним програмістам занадто часто не подобається тестерів, оскільки їхня робота вимагає, щоб вони цілий день вказували на помилки програміста. Як менеджер, я постійно працював у місії з PR, щоб нагадати програмістам, що команда QA була там, щоб вони виглядали добре, а не роздували їх.
Це, як правило, робота, в яку люди потрапляють випадково, а не вибір, принаймні спочатку. Я не пам’ятаю жодного плану ступеня в жодній із шкіл, в яких я відвідував, яка готувала людей до програмного забезпечення Q&A. Вони існують, але зазвичай у професійно-технічних училищах нижчого класу, що лише сприяє думці, що вони є менш кваліфікованими професіоналами.
Тестові завдання набагато частіше, ніж завдання програмування, що надсилаються за кордон. Принаймні, програмісти можуть стверджувати, що ефективніше спілкуватися з дизайнерськими потребами на місцевому рівні та що цінним є збереження знань про те, як працює флагманський додаток компанії всередині компанії. Проте тестування набагато простіше модулювати і, таким чином, легше передавати аутсорсинг.
З усіх вищезгаданих причин тестери, як правило, бачать написання на стіні та переходять на інші завдання (наприклад, програмування), особливо справді хороші. Це означає, що більшість тестових робочих місць, як правило, укомплектовано більшою кількістю людей початкового рівня, які ще не перегоріли і не перейшли до інших речей, що, на жаль, підкріплює декілька перерахованих вище ідей.
Це залежить від компанії, але зазвичай. Їх часто сприймають як громадян другого класу, і в багатьох компаніях тестування розглядається як позиція початкового рівня, з якої ви потім переходите до справжнього розробника.
Це, звичайно, лайно. Попрацювавши з якимись хорошими тестерами, я можу сказати, що вони є і цінними, і важкими для них. Хтось з розумом, достатньо креативним, щоб знайти не очевидні помилки та достатньо методичний, щоб зробити ретельну роботу.
Хоча один виняток: я знав декількох хлопців з тесту Майкрософт, і чую, що тестери є громадянами першого класу.
Я працював функціональним тестером протягом року над досить великим проектом. Кожна команда з близько 10 членів мала по 2-3 тестери. Треба сказати, що до нас проект ставився так само важливо, як і розробники.
Знайти помилок непросто. По-перше, тестувальники повинні зрозуміти, що передбачається зробити кодом. Це означає читання та розуміння вимог. Ключовим тут є розуміння вимог - якщо тестувальники не можуть зрозуміти вимоги достатньо добре, щоб знати, як писати позитивні тестові випадки, ви повинні турбуватися. Це означає, що розробники написали якийсь код, який робить те, що вони припускали. Чи правильне це припущення? Ви не знаєте, поки не розібраєтесь з вимогами, і можете подякувати вашим тестерам за те, що виявили цю ваду.
По-друге, тестувальникам доводиться писати помилкові тестові випадки, що гарантує, що код не є тим, чого він не повинен робити. Розумним правилом є те, що ви пишете 5-10 помилкових тестових випадків для кожного позитивного тестового випадку. Це означає розуміння вимог ще далі, і часто цеінформація є або, принаймні, була в нашому проекті, заплутаною та неоднозначною. (І це було не через малі зусилля щодо збору вимог - у нас в команді було щось на зразок 13000.) Знову ж, розробники написали свій код, використовуючи свої припущення, або ще гірше, навіть не вважали це взагалі. То що робить код у цих умовах, які не є нормальними? Ви не знаєте, поки не перевірите. Можливо, програма не відповідає; можливо, воно просто розбивається; можливо, це знищує дані; можливо, це дозволяє користувачеві виконувати команди як користувач root. Що б це не робило, ви хочете знати. В іншому випадку ви можете одного дня прочитати наступний заголовок у газеті - БУГ У ВІДКРИТТІ КРЕДИТНОЇ КАРТИ КЛІЕНТІВ ПРОГРАМИ [ІМЕНТУ ВАШОЇ КОМПАНІЇ]
Тож добре поводьтеся зі своїми тестерами. Ставтеся до них добре. Зрештою, саме вони усувають помилки у вашому програмному забезпеченні та полегшують ваше та наше життя.
Хороші тестери, які вміють ефективно аналізувати проблеми та вміють робити гідну автоматизацію тестів, вартують своєї ваги золота, оскільки там так багато ковбойських тестерів (коли опитував одного «тестера», коли він насправді засміявся, коли зрозумів, що ми знаємо, що він робить складати на місці, доки його резюмують у його резюме).
У моїй команді до тестера ставляться як до рівних - що включає відповідальність і зарплату. Якщо ви хочете тестер, який натискає наступний цілий день - передайте їх десь дешево (ми також це робимо).
Оновлення після прочитання інших відповідей: Є багато професіоналів QA, які люблять роботу, яку вони виконують. Просто для того, щоб дати іншу точку зору, якщо ви ще не натрапили на якісь поважні позиції щодо якості, наведений тут приклад: Тестування вбудованих додатків / мобільних додатків для провідних автовиробників. Вони гарантують, що вимоги бізнесу повністю виконані до випуску транспортного засобу на ринок, і жоден користувач не відчуває повільну та невідповідну інформацію приладової панелі автомобіля. Вони тісно співпрацюють з менеджерами та керівництвом вищого рівня, а також розробниками, починаючи з планування процесу забезпечення якості, до практичного тестування на тренажерах у проектному об'єкті. Я не можу подумати про те, що вони малопотужні, вони вирішують величезні обов'язки та право власності, і вони є одними з найкращих інженерів.
тепер моя раніше відповідь, зворотний бік:
Я зауважував, що випускники інженерії ненавидять виділятись на тестувальні підрозділи (контекст: Індія, великі фірми, що надають програмні послуги, де все залежить від "бізнес-вимог"), оскільки вони вважають це нетехнічним робочим середовищем. Їм надаються аркуші видатних таблиць із вказівками на кшталт "натисніть на всі посилання на веб-сторінці та перевірте", змушені працювати з випускниками нетехнічних потоків (науки, мистецтв), які вони вважають приниженням і вважають, що їхні технічні навички не є утилізується. Ці розподіли грунтуються виключно на вимогах організації, і більш свіжий час не має повноважень вести переговори про його кар'єрний шлях. Тож якщо ви шукаєте роботу, націлену на таку велику ІТ-компанію, вас попередили. Ви практично нічого не можете зробити, окрім виходу з компанії в потрібний час.
Якщо немає можливостей вивчити автоматизоване тестування, тестування навантаження / працездатності тощо, кар'єра до певної міри застоюється. Особисто я знаю, що можливості для виконання завдань на місці (= навантаження грошей з точки зору офшорного програміста) більше для тестування в мою організацію, ніж будь-який інший підрозділ. Вони працюють з усіма галузями вертикалі як наповнювач або клей, оскільки тестування неминуче в проектах у всіх областях.
Якщо ви впевнені, що можете керувати своєю кар'єрою так, як вам завгодно, тестування - це ніщо непросте. Маючи 4-5 років досвіду та трохи удачі, ви можете отримати дуже хорошу експозицію, іноді взаємодіючи з діловими користувачами вищого рівня. Ви також можете добре зрозуміти галузь / домен, в якому працюєте (порівняно з розробником, який зосередив би увагу на певній частині системи). У цей момент можна також перейти до ролі бізнес-аналітика.
Я знаю компанії, в яких відповідальна за випуски команда QA. Це означає, що вони мають можливість блокувати випуск через відсутність якості. Якщо повідомляється про проблему в полі, вони є першими в лінії вогню (добре відразу після польового інженера).
Зазвичай вони мають вищі знання про домен. Вони, як правило, краще знають загальну функціональність продукту, тоді як розробники зосереджуються на їх модулі / особливостях.
Також я знаю, з QA-організацій, де вони мають написати свої власні інструменти для тестування. Не кажучи вже про автоматизацію цілого матеріалу. Я розробник і завжди цінував хлопців з якості, які перевіряють мої функції.
Принаймні, в моїй організації QA ставляться однаково до розробників. Я думаю, це через домен (телеком), де знання протоколу та мережевої архітектури однаково цінуються з навичками програмування.
Так. Подобається або залиште, вони однаково важливі, але завжди менш переважні. Можливо, тому, що їх легко замінити.