Yazılım yaşam döngüsünde hızlı ürün çıkmak için testlerin otomatikleştirilmiş olması ve stabil bir şekilde her ortamda (DEV-TEST-UAT-PREPROD) çalışması istenilen bir durumdur. Test türlerini inceleyecek olursak Test Piramidine göre kod commit olduktan sonra ki ilk test Developer'ın yazdığı Unit Test (Birim Test) olup, bu testen geçen paketler deploy olur ve otomasyon-entegrasyon testleri devreye girer.
Canlı ortama kadar giden bu sıralı pipeline düzeninin çalışmasını ufak ve orta ölçekli kurumlarda çok beklemeyin özellikle Türkiye'deki şirketler de. Bu disiplini büyük kurumlarda olmasını bekleyebilirsiniz. Çünkü oralarda süreçler kurumsal olarak oturduğu için ITIL, TOGAF, COBIT, SDLC (Enterprise Architecture) gibi genel kavramlar en azında var diyebiliriz.
Sıralı bir pipeline örneği aşağıdaki gibi verecek olursak; Build sonrası Developer'ın yazdığı unit testler çalışır sonrasında kod deploy olur. Test otomasyoncuların yazdığı entegrasyon test scriptleri çalışır, kritik bulgu yoksa Build kırılmaz ve Security(Pentest) testlerden sonra paket Release olur.
Commit >> Assemble(Build) >> Unit Test Run >> Deploy >> Test Automation Scripts Run (Entegrasyon Test) >> Security Test >> Release(Production)
Otomatikleştirilmiş test türleri olarak Unit Test ve Test Otomasyon Script'lerini örnek vererek bu yazılım sürecinde aldığım kısa notları sizlerle paylaşacak olursam;
* Her ortam için Merge öncesi Unit Testler çalıştıktan sonra paket Deploy edilir ve Otomasyon Testleri ardından çalıştırılır. Unit Testler ve Otomasyon Test Senaryoları birbirini tamamlayacak şekilde Agile & Scrum süreçte her Sprint paralel gitmektedir.
* Her Sprint hem unit hemde otomasyon testleri task olarak alınır development PBI'ları içinde.
* Sprint planlamalarda WS(Web Servis) ve Servis Entegrasyonları(Rest-Soap) gibi PBI’lar da test taskları direk test otomasyon development taskı olarak alınabilir. Manuel test olarak UI ve İçeriği tam belli olmayan testleri alabilirsiniz.
* Birim Test yazdığın koda içindeki metodu test eder, metodun sonucunda olan işlemin true-false olasılığını test eder. Entegrasyon testi gibi kapsamlı test değildir. Bu yüzden sadece Unit Test'den geçen paket bir işe yaramaz.
* Otomasyon Case’lerin de belli bir olgunluktan sonra ve Development ekibinin Unit Test yazması ile birlikte, Dev ekibinin unit testleri arasında olan bazı Case’leri Otomasyon Scriptleri arasından çıkararak direk High Level Senaryolar otomasyonda tutulması amaçlanmıştır. Test script sayısını çoğaltmak için boş test yazmayın kritik testleri yazın.
* True-False testleri Unit Test bazında tutunuz, Otomasyon testlerinden çıkarınız. Örneğin kimlik numarası ile login işleminin 11 haneli ve deaktif senaryolarının şekilde denenmesini Unit Test kısmında test ediniz fakat Happy Path login senaryosu Test Otomasyon'da olsun.
* Projelerde Unit Test daha çok yazın çünkü otomasyon-entegrasyon testlerine göre maliyeti ve maintance ihtiyacı daha azdır. Unit Test sayısını 1000 ve daha fazla sayılara çıkarabilirsiniz. Run edildiğinde Test Otomasyon testleri gibi çok zaman almaz.
* Production bulgusu olarak tespit edilen her konuyla ilgili detaylı Unit Test yazma prensibi takım ve kurum olarak kabul etmenizi tavsiye ederim.
* Developer takımlarına Unit Test yazdırmak istiyorsanız bu testlerin Coverage bilgisini alıp (SonarQube, Maven JaCoCo gibi araçlar kullanabilirsiniz) en başarılı ve Coverage değeri yüksek birim test yazan Developer'ları kurum içi sıralayabilirsiniz. Bir nevi kalite rekabeti oluşur o kurum içinde. Bu sayede her Developer yazdığı ürünün yanında testininde kod kalitesini yüksek tutmuş olur.
* Unit Test Sayısı ve Coverage bilgisine göre en iyi sonucu alan projedeki Developer kişisini kurum olarak aylık ödüllendirebilir ve Unit Test yazımını bu sayede Developer'lar arasında artırabilirsiniz.
Burak AVCI
Hiç yorum yok:
Yorum Gönder
Makaleye Yorum ve Sorularınızı Bırakabilirsiniz.