Чи повинен програміст бути самодостатнім?

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

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

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

Примітка

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

Відмінні відповіді на даний момент, продовжуйте їх приймати, якщо вам є що додати чи особистого досвіду поділитися!

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

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

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

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

Так. Якщо вам доведеться , ви зможете протестувати свій код. (Я не говорю про одиничні тести, а про тести прийняття тощо).

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

У вас є багато інших питань. Я відповім лише на одне:

Чи повинен програміст уточнити специфікацію?

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

Те, що вони говорять, та реальність - це, ймовірно, дві різні речі. Швидше за все, це обгрунтування:
"Чому я повинен платити зарплату тестеру, коли я можу просто змусити програміста виконувати подвійний обов'язок?"

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

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

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

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

Досить справедливо.

Чи повинні такі завдання бути моєю відповідальністю?

Це врешті-решт вирішить ваше керівництво.

Я себе суворо бачу як програміста і нічого іншого.

Можливо, ви тоді не в роботі. Дуже багато людей люблять отримувати додаткову відповідальність.

І якщо це моя відповідальність, то в якій мірі?

Якщо керівництво скаже так, так.

Коли проект настільки великий, що для нього потрібні тестери?

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

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

Якщо програміст повинен уточнити специфікацію,

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

турбуйтеся про управління проектом

Якщо потрібно, так.

чи навіть надавати підтримку клієнтам?

Якщо потрібно, так.

Мені це здається, що ти перевантажений роботою і реагуєш на тиск. Це проблема. Але зайняти позицію, що це "не твоя робота робити X, Y, Z", це не допоможе. Кращий план - зрозуміти, що ви можете зробити лише стільки, і вказати, що це, ймовірно, може призвести до пропуску термінів, якості ковзання, поганої підтримки клієнтів тощо. Але все одно зробіть все можливе ... не пошкоджуючи своє здоров'я, стосунки тощо в процесі.

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

1. Вони висококваліфіковані та мають різні навички програмістів.
   1. Вони мають багато досвіду та знань, як робити тестування якості та як перевірити, чи створений код дійсно відповідає як очікуванню користувача, так і фактичній поведінці користувачів.
   2. Вони пережили багато помилок і дуже добре думають про ситуації, які можуть зламати програмне забезпечення.
   3. Вони, як правило, цинічні та систематичні. Я помітив, що програмісти часто набагато більш оптимістичні.
2. Вони забезпечують цінний ранній відгук про зручність використання. Наприклад, нещодавно, коли створювали API REST, області, які тестери якості не змогли зрозуміти легко, були гарною ознакою областей, якими користувач також буде незадоволений.
3. Вони перевіряють фактичне середовище, фактично багато конфігурацій реального обладнання, ОС тощо.
4. Вони знають, як будувати масштабні, реалістичні, тестові ліжка та робити продуктивність, навантаження та стрес-тестування
5. Вони зосереджені на тому, щоб не допустити виходу поганих релізів. Програмісти, як правило, зосереджуються на тому, щоб випустити код. Практично, програміст випустить код за замовчуванням, але тестувальнику якості потрібна причина для його випуску (було показано, що він працює!)

"якби у нас були тестери, ти б взагалі не перевіряв власний код"

" Якби у вашої машини був ремінь безпеки, ви б постійно її ламали! "

Чи повинні такі завдання бути моєю відповідальністю? [...] І якщо це моя відповідальність, то в якій мірі?

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

Коли проект настільки великий, що для нього потрібні тестери?

Це не (цілком) правильне запитання. Вам краще запитати "коли якість товару / іміджу компанії настільки важлива, що для неї потрібні тестери?"

Якщо програміст повинен уточнити специфікацію, [...]

Так, звичайно. У більшості випадків існує велика невідповідність між тим, що потрібно розробнику / реалізатору, і тим, що надають клієнти [як технічні характеристики].

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

[...] турбуєтесь про управління проектом чи навіть надаєте підтримку клієнтів?

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

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

1. Специфікація продукту + випадки використання
   Навіть якщо всі знають (або думають, що вони роблять), що таке функціональність продукту, він повинен бути записаний. Ви не можете перевірити програму без чіткої специфікації. Специфікація визначає, що таке правильна поведінка та що таке помилка.
2. Тестові одиниці, інтеграційні тести
   Випробування внутрішніх пристроїв, які важко перевірити через інтерфейс користувача, виняткові стани застосування. Це обов'язково для кожної більшої системи. Обидва типи тестів мають ще одне цікаве властивість - вони змушують вас знову проходити кожну частину коду, і ви зрозумієте помилки / проблеми архітектури, яких ви ніколи не бачили.
3. Стандарти якості та кодування коду
   Одним із завдань, які повинен виконати QA, є вимірювання складності коду. Код низької складності зменшує можливість помилок (запобігання помилок).
4. Огляди коду
   Коли проект досягає заданого розміру або його використовує багато користувачів, огляд коду є обов'язковим. Інший програміст завжди знаходить проблеми з кодом / помилки, які ви пропустили. Програміст іноді сліпий для очевидних помилок у власному коді.
5. Документація
   Документуйте свій код та його архітектуру, це допоможе вам зрозуміти можливі вади (мій власний досвід).
6. Тестери
   Тестер НЕ мавпа , який просто клацає через призначений для користувача інтерфейс. Тестер приймає випадки специфікації та використання та створює тестові кейси. Потім він / вона перевіряє їх по черзі. Якщо кінцеві користувачі повідомляють про помилку, для цього потрібно додати тестовий випадок.

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

Що програміст може досягти, це 2, 3 і 5.

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

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