У мене є програма PHP, яка дуже велика. Зазвичай це 2-3 розробники, які працюють над цим повний робочий день, і ми доходимо до того, коли ми вносимо зміни та створюємо помилки (функції кашлю!). Програмне забезпечення не є складним, скажімо, просто багато чого відбувається (35 ~ контролерів, приблизно однакові моделі тощо).

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

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

Може, нам потрібна неповна робота Q / A людина?

У когось є якісь пропозиції / думки.

Так, вам потрібен Q / A персонал. Деякі з багатьох причин включають

• Виділений тестер коштує грошей, але часто менше грошей, ніж розробник, тому вигода від невикористання часу більша, ніж додаткові витрати.
• Спеціальний тестер знає, як перевірити речі, зокрема речі, які неможливо автоматизувати. Проведення автоматизованих тестів на взаємодію із системою через браузер - дещо волохата, але налагоджена дисципліна. Якщо ви знайдете когось, хто вже знає, як це зробити, вам не доведеться витрачати ще більше часу, вивчаючи хороші інструменти та налаштування.
• Професійний тестер знає, як насправді знайти дефекти. Вони набагато частіше думають, як подумає користувач програми, а тому здійснюють ті стани в системі, які фактично з’являться у виробництві, а це означає, що ті помилки, які виявляються дуже помітними, як правило, будуть знайдені раніше , економлячи ваші збентеження та витрати на надшвидкі виправлення.
• Узагальнюючи це, тестер не вважає розробника . Важко передати, наскільки це різниця, якщо ви цього не відчували. Свідомо чи ні, розробник не хоче знайти дефекти. Вони знають, як працює система, і, як правило, уникають типових безглуздих (для них) даних або даних, які спричиняють проблеми в реальному житті. Якщо щось працює несподівано, вони знають, як обійти це, і прагнуть взагалі не сприймати це як дефект. Вони ніколизіткнутись із труднощами в розумінні того, що означають відповіді системи, оскільки вони їх написали, хоча це є головною причиною проблем майже у всіх реальних системах. Коротше кажучи: програмісти, як правило, погано відчувають типові проблеми, які виникають у користувачів, тому що вони є висококваліфікованими фахівцями. Тестер має набагато простіший час для виконання найбільш релевантних тестів.

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

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

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

Найміть професійного QA

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

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

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

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

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

Існують інструменти, які можуть деяким чином контролювати покриття тесту. Інструменти охоплення коду для PHP