Чому тестери та програмісти не люблять один одного? [зачинено]

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

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

Я думаю, що це грубо над узагальненням та над спрощенням.

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

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

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

редагувати

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

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

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

Чому виникають проблеми?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Також деякі розробники дивляться на QA. І все-таки я набагато скоріше знайду дефект, ніж клієнт ....

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

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

Виходячи з цього питання: Методи тестування програмного забезпечення або категорії, я підозрюю, що вам потрібна корекція ставлення до тестерів і тестування загалом.

Як розробник, я відчув свою частку напруженості з тестерами.

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

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

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

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

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

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

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

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

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

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

Погане жужу.

Це часто виникає з трьох факторів -

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

Мені подобаються тестери, але в двох випадках я виявив конфлікт.

1. При управлінні грають тестери і дияволи одне від одного.

2. Коли проблеми постійно надсилаються, у них не вистачає деталей, тобто "Екран x не працює".

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

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