Cevap.

Otomatik testlerde teknik borç sorunu, otomasyonun artmasıyla birlikte — test sayısının yüzlerce ve binlerle ölçülmeye başlamasıyla — ilk kez fark edildi; testlerin bakımı çoğunlukla geliştirmenin kendisinden daha pahalı hale geldi ve mimari hatalar çoğaldı.

Konunun Tarihi

Otomasyonun ilk dönemlerinde testler hızlı bir şekilde, genellikle şablonlar olmadan, standartlar olmadan ve sonraki yeniden yapılandırmalar olmadan yazıldı. Sonuç olarak otomatik test repositoları eskiyip, uygulamanın değişimiyle kırılmaya başladı ve bunların bakımı giderek daha fazla çaba gerektirdi.

Sorun

Hızlı bir şekilde "yerinde" yazım, testlerde kaotik bir yapı yaratır.
Yeniden yapılandırma eksikliği, kopyalama ve kötü okunabilirliğe yol açar.
Geliştiricilerin otomatik testlere katılımı azdır.
Geçerliliğini yitirmiş test senaryoları, ürünün güncel gereksinimlerini yansıtmaz.

Çözüm

Testlerde düzenli yeniden yapılandırma uygulamalarının benimsenmesi — kod inceleme, linting, biçim standartları, mimari şablonlar.
Kopyalığın azaltılması — PageObject, Factory, Service Layer ve diğer şablonlar.
Test senaryolarının ürün ekipleriyle sürekli güncellenmesi.
Otomatik analiz araçlarının kullanımı ile kapsama ve eski kodun kontrolü.

Temel özellikler:

Düzenli Test Yeniden Yapılandırma Döngüsü
Otomatik testlerin zorunlu Kod İncelemesi
QA ile geliştirme arasında işbirliği

Taktik Sorular.

Yüksek kod kapsama oranı, teknik borcun olmadığına dair bir gösterge midir?

Hayır, formel kod kaplaması, test tabanının kalitesini ve yaşayabilirliğini garanti etmez: eski veya "gereksiz" testler olabilir.

Tekrar otomatik test şablonlarını yazmak, teknik borcu ortadan kaldırmak için yeterli midir?

Hayır, altyapı ve şablonlar, projenin büyümesine bağlı olarak yeniden gözden geçirilmesi ve geliştirilmesi gerektirir.

Otomatik testler iyi yapılandırılmışsa, tamamen manuel test yapmadan geçinebilir miyiz?

Hayır, her zaman manuel olarak smoke/regression/niche testlerine ihtiyaç olacaktır ve otomatik testler, stabil işlevselliğin düzenli "izlenmesi" için gereklidir.

Tipik hatalar ve anti-şablonlar

Yeniden yapılandırma eksikliği
Aşırı iç içe geçmişlik ve testlerin karmaşıklığı
Eski testler nedeniyle CI boru hatlarının kesintiye uğraması

Hayattan Bir Örnek

Olumsuz Durum

Otomatik testler inceleme olmadan yazıldı, yapı proje boyunca değişti, bazı testler geçerliliğini yitirdi — testlerin %40'ı uygulama değişiklikleri nedeniyle başarısız oldu.

Artılar:

2-3 ay içinde "büyük" kapsama hızlı bir şekilde ulaşma

Eksiler:

Bakım için büyük zaman kaybı
Büyük sahte başarısızlıklar

Olumlu Durum

Ekipte her iki haftada bir otomatik testlerin incelemesi ve yeniden yapılandırılması yapılmakta, mimari kabul edilen standartlara göre korunmakta, testler güncel kullanıcı hikayeleriyle sıkı bir şekilde bağlanmaktadır.