Чи повинен розробник також діяти як тестер? [зачинено]

Ми - команда scrum з 3 розробників, 1 дизайнера, майстра scrum та власника продукту. Однак у нас немає офіційного тестеру в нашій команді. Проблема, яка завжди є у нас, полягає в тому, що тестування програми та проходження цих тестів та видалення помилок було визначено як один із критеріїв для врахування PBI (Product Backlog Item) як виконаного.

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

В якості засобу ми рекомендували компанії найняти новий тестер. Хтось, хто на роботі буде тестувати, і лише тестувати. Офіційний професійний тестер.

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

Вони праві? Чи повинні ми також розробники (також дизайнери) бути тестерами?

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

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

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

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

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

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

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

Розробники можуть бути тестерами - коду інших розробників.

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

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

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

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

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

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

Тим не менш, журналісти самі проводять перевірку орфографії. Тим не менше, коректор - це окрема і важлива професія.

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

Якщо хтось, окрім розвитку, постійно виконує цю роботу, це просто означає простий факт - він тестувач за сумісництвом.

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

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

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

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

... ми рекомендували компанії найняти нового тестера. Хтось, хто на роботі буде тестувати, і лише тестувати. Офіційний професійний тестер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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