Як виходити з QA, як можна одержати першу роботу з розвитку? [зачинено]

Я вже 10 років в QA, намагаюся вступити в розвиток близько 5 з них. Я брав заняття на C ++, Java та C #. Я зміг написати деякі інструменти та одиничні тести на C # на моїй теперішній роботі і (за всіма рахунками) зробив це добре.

Однак 8 місяців тому мій роботодавець поклав на мене відповідальність за створення нової групи з контролю якості. Зараз я роблю ручне тестування та розгортання, не обіцяючи повернутися до розробки. Я переглянув дошки робочих місць і є багато завдань для веб-розробників, і що я ще можу зробити, щоб отримати її? Я взяв кілька книг про Ruby on Rails, над якими планую працювати над Mac на дому, але не впевнений, що роботодавців цікавить би щось, окрім комерційної веб-розробки.

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

Чи говорили ви з вашим поточним роботодавцем про бажання стати забудовником? Почніть з цього, і якщо вони не зобов’язують, час шукати в іншому місці.

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

Ви обов'язково повинні використовувати свій досвід QA, оскільки досвід дійсно важливий.

Розробники QA часто пильнують, і це часто невиправдано.

Однак упередженість існує, і ви не можете точно викреслити QA зі свого резюме.

Ось моя пропозиція: замість того, щоб робити перехід безпосередньо до dev, зробіть перехід до "ролі на півдорозі". Термін (принаймні в США) називають "інженером автоматизації". Він поєднує навички QA з навичками програмування і зазвичай передбачає дуже мало ручного тестування або традиційного QA. Ваш досвід роботи з одиничними тестами та фокус TDD роблять це досить приємним становищем. Я займав цю посаду протягом року (хоча я прийшов з розробленого і пізніше повернувся до дев) і можу сказати вам, що було зроблено багато інженерних програм.

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

Також спробуйте проворні магазини. Вони мають тенденцію менше спостерігати межі qa / dev.

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

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

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

Моє перше завдання як молодший розробник після 1,5 років QA (і 3 роки на підтримку під час літа) було виправити проблеми розмітки та css. Через кілька тижнів я виправляв прості дефекти коду, перш ніж брати на себе відповідальність за сфери роботи та врешті-решт проекти.

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

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

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

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

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

Якби я був SDET (і слава богу, що я ні), я би проявив свою здатність до інженерії програмного забезпечення, впровадивши цінний внутрішній інструмент для компанії, і я би використовував C ++ / Java / C # для демонстрації своїх навичок. Причина, з якою я працював би над внутрішнім інструментом, полягає в тому, що, швидше за все, мені не дали б можливості написати код, орієнтований на клієнта, як SDET, тому внутрішній інструмент - це єдиний шлях.

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

А коли ви будуєте, застосовуйте міцні навички програмного забезпечення:

• написати ремонтопридатний код
• додати багато коментарів
• впроваджуйте його для ефективності, масштабованості та надійності
• встановити цілі та графік випуску
• написати читаний проектний документ.

На початку багатьох робіт мені сказали, що місяцями я не торкаюся живого коду. Це триває близько двох тижнів. Потім хтось кидає новий проект у вже завалену групу розвитку. Здогадайтесь, хто доступний?