Чи повинні розробники нести відповідальність за тести, окрім одиничних тестів, якщо так, то які найпоширеніші?

Зараз я працюю над досить великим проектом, і я використовував JUnit та EasyMock для досить широкого функціонування тестових функцій. Мене зараз цікавить, які ще типи тестування мені слід хвилювати. Як розробник, чи є моя відповідальність турбуватися про такі речі, як функціональне чи регресійне тестування? Чи є хороший спосіб інтегрувати їх корисним способом у такі інструменти, як Maven / Ant / Gradle? Чи краще вони підходять для тестера чи бакалавра? Чи є інші корисні види тестування, які мені не вистачає?

Ви зобов’язані поставити код без дефектів. Вам слід написати, допомогти в написанні або забезпечити написання або виконання тестів, щоб дати вам впевненість у наданому вами коді.

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

Якщо це означає, що ви особисто несете відповідальність за функціональні та регресійні тести, це головним чином функція організації вашої компанії. Усі найвідоміші програмісти, яких я знаю, не запитують себе: "це моя відповідальність писати тести типу X?". Натомість вони запитують себе "що мені робити, щоб переконатися, що мій код перевірений належним чином?". Відповідь може полягати в написанні одиничних тестів або додати тести до регресії, а це може означати поговорити з фахівцем з якості та допомогти зрозуміти, які тести потрібно писати. Однак у всіх випадках це означає, що вони достатньо дбають про код, який вони пишуть, щоб переконатися, що він перевірений належним чином.

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

Це може допомогти вам:

Q1 написані розробниками.

Q2 автоматизовані розробниками та записуються у співпраці з бізнесом та / або тестерами.

Чи є інші корисні види тестування, які мені не вистачає?

Існує тестування прийняття, для якого я рекомендую рамки в стилі BDD, які використовують мову Gherkin : JBehave (Java), огірок (Ruby), Behat (PHP) тощо. Цей тип тестування має деякі переваги перед одиничними тестами:

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

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

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

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

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

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

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

Але це робота команди, не тільки твоєї.

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

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

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

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

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

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

Одне питання - це ефективне використання часу розробників.

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

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

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

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

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

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

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