Чи вірите Ви, що інженерам-програмістам це гарна ідея, щоб певний період часу працювали інженерами із забезпечення якості? [зачинено]

Я вважаю, що так. Чому?

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

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

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

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

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

Що ви все думаєте?

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

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

Інженери програмного забезпечення можуть зосередитись на певному аспекті життєвого циклу - вимоги інженерія, архітектура та дизайн, будівництво, тестування та обслуговування. Однак, незалежно від вашої уваги (як робота, чи на поточній фазі проекту), важливо пам’ятати про якість.

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

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

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

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

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

"Повне" можна виміряти лише відповідно до вимог. Або вимоги задоволені, і проект закінчений, або є неповні вимоги, і проект не є завершеним. Будь-яка інша міра повного є марною.

Переконайтесь у тому, щоб програмісти відповідали за свій код та вимагали від них виправлення власних помилок. Це і втрата премії та / або робота.

Не те, що цей досвід не допоможе, але як далеко ви можете піти з такої лінії мислення? Технічна підтримка, продаж, бета-користувач, очистіть туалети (це було б приниженням).

"... доведеться працювати інженерами з якості QA ..."? Ви зробите це суперечливим або покаранням.

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

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

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

Взагалі, варіанти, які ви представляєте, звучать дуже змагально, і не дивуйтесь, чи були у вас справді погані враження з деякими жахливими розробниками. На мій погляд, розробник повинен ЗАВЖДИ бути обізнаний з питаннями якості та тестування, і повинен бути достатньо гордий своєю роботою, щоб вони не вважали її закінченою, поки вона не пройде як жорсткі тести у своєму блоковому тестуванні, як те, що використовуватиме офіційний відділ контролю якості. Якби я мав однолітків, або був технічним керівником у команді і мав розробника, який виявив будь-який "твіт" до QA, він знайшов би мене витягувати за виправлення ставлення. Якщо обидві сторони монети з доставки програмного забезпечення не можуть співпрацювати та діяти як команда, існує справжня проблема культури. Я не хотів би працювати там, і HR, разом із керівництвом, потрібно було б вводити.

Примусити програмістів працювати інженерами із забезпечення якості - це рецепт втратити кращих розробників. Програмування та КЯ вимагають різних наборів навичок та процесів мислення.

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

QA роблять тестування з точки зору користувача. Мислення QA як такі, що користуються різними типами користувачів, придумувати дивні випадкові випадки та створювати незрозумілі проблеми.

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

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

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

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

Ось кілька можливих проблем, які я бачу з вашою пропозицією:

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

2) Бути дуже тесним тестером деякий час не обов’язково навчить їх нічого цінного. Але згодом це може зробити їх нездійсненними, тому що вони будуть вважати, що вони знають все про тестування зараз, оскільки вони провели 6 тижнів у тестовому відділі один раз.

3) Враховуючи, що вони, очевидно, будуть там лише ненадовго, і відділ з питань якості буде знати це, ймовірно, що їм будуть надані лише відносно невимогливі, прості завдання, які потребують невеликого нагляду чи розуміння, але які не дають їм працювати. . Це лише підсилить 1 і 2.

4) Якщо ви хочете уникнути 1, 2 і 3, як ви переконаєте свій тестовий відділ, що варто вкласти величезну кількість енергії у викладання та нагляд за тим, хто навіть не зацікавлений у тестуванні? (Я можу вам сказати, для роботи з тим, хто, згадаймо, не був обраний за тестування на тестування, потрібна страшна кількість часу та енергії . Ви не пропонуєте тестовій команді додатковий ресурс протягом декількох тижнів, ви просимо їх втратити одного з найдосвідченіших людей на кілька тижнів, поки вони навчають новачків).

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

Якщо ви все ще зацікавлені у тому, щоб програмісти не мали змоги в QA - ось пропозиція: наведіть приклад. Іди собі спочатку. Можливо, зробіть це тим, що члени вашої команди мають робити, коли вони вже хороші, і хочуть отримати це додаткове перевагу, проводячи щотижня трохи часу з іншими командами, які спеціалізуються на перекриваються областях - тест, DBA та ін. Якщо ви представите це так, тоді у вас буде більше шансів на успіх.

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

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