Yazılım testi bir projenin Development aşaması kadar önemli ve hayati bir süreçtir. Daha kaliteli yazılımın çıkması ve kabul edilebilir düzeyde hatasız olabilen, öngörülmüş maliyet ile bitirilip beklentileri karşılayan ürün iyi bir test sürecinden geçerek oluşur. Buradaki kalite anlayışı müşteriye göre değişebilir. Bu kalite kimine göre tasarım iken kimine göre daha az hatta hiç Bug olmayan yazılımlardır.
Yazılım süreçleri genelde planlama-tasarım, analiz, kodlama ve test şeklinde ilerlemektedir. Scrum çalışma metodolojisi ile bu yöntem aynı şekilde devam etse de pratikte işler biraz daha hızlanmış ve iç içe geçmiştir. Testçi genelde test senaryolarını analiz dokümanından çıkarır. Fakat uzun analiz dokümanları Scrum sürecinde pek bakılamıyor çünkü iki haftalık Sprintler koşulduğu için buna ayıracak pek vakit kalmıyor. Bu doğrultuda kodcu veya analist genelde o Sprint için yapılacak PBI'ların analizini analist yaparken, PBI için yapılacak Development değişikliği için teknik analizini Developer yapmaya başlıyor. Bu dokümanlar maksimum üç veya dört sayfalık bir dosyadır.
Burada net bir şekilde Developer ilgili PBI için ne gibi değişiklikler yapacağını, varsa analiz dokümanındaki görselini ekliyor. Siz testçi olarak hem bu teknik analize hemde Developer'ın o PBI için ne yapacağını ve genel akışı beraber konuşarak test senaryolarınızı hazırlamaya başlıyorsunuz. Scrum'ın bize kazandırdığı en önemli artılardan biri analist, kodcu ve testçinin bir arada ve koordineli çalışmasıdır. Waterfall çalışma biçiminde bu pek mümkün olmuyor ve yazılım süreçleri uzuyordu.
Tabi yukarıdaki çalışma biçimi dışında analist ve test işlerini aynı kişide yapabilir. Bu sayede o PBI'ın sadece o PBI'lık kapsamı için yapılan analiz sonra aynı kişi tarafından senaryoları yazılarak test edilebilir.
Test Senaryolarını hazırlama aşamasına gelecek olursak; PBI için hazırladığınız Test Senaryoları çok uzun olmamalıdır ama az da kabul edilemez. İlgili PBI için gerekli ve ihtiyaç senaryo maddelerini girmeniz yeterli olacaktır. Senaryo koşma işleminden sonra Scrum için en önemli süreçlerden biri olan ve DoD(Definition of Done) maddelerinde de bulunan Test Review işlemidir. Test Review sürecindeki amaç; Tester'ın koştuğu senaryolar ve o PBI'da ne yapılmak istenildiği, genel akış Developer ve Tester ile üzerinden geçilmesi ve kontrol edilmesidir. Bu işlem hem test işlerini hızlandırıyor hemde bulgu bulma veya hatayı azaltma işlemini artırıyor.
Scrum veya başka bir yazılım geliştirme metodolojisi olsun Test Senaryoları test sürecindeki en önemli dokümandır. Bu süreçleri ne kadar ayrıntılı ve açıklayıcı tutarsanız hem izlediğiniz akışa geri dönüp tekrar bakma şansınız olur hemde Test kütüphanenizi geliştirmiş olursunuz.
Scrum içinde uygulanan başka test süreci ise bulgu(Bug) bulma ve bulunan bulgunun fixlenme aşamasıdır. Bu süreç Developer ve Tester arasında ne kadar hızlı olursa çeviklik o zaman daha net ortaya çıkacaktır. Tester bir bulguyu kodlama öncesi bile bulsa bunu Developer ile hemen paylaşmalıdır. Kodlama ve test senaryoları bitiminden sonra dinamik test sürecinin başlamasını daha sonra bulgu evresi ve testin sonlandırılması aşamasına girilirse tüm süreç yine Waterfall çalışma biçimine döner ve o Sprint için PBI'ların Done olması zorlaşır.
Scrum'da yapılan yanlış ise Developer'ın kendi kodlamasını tek başına test etmesidir. Code Review dışında (Bu süreç bile tek yapılmaz) kendi yazılımınızı test etmeniz zordur. Çünkü başka bir bakış açısından sizin yazdığınız koda bakılması gereklidir. Sadece IDE üzerinde Runnable edip bu tamamdır ve arayüzde de böyledir demek pek tavsiye edilen bir test şekli değildir. Aynı şey analiz içinde geçerlidir. Fakat Scrum'da analist, kodcu ve testçi bir PBI'da tüm süreçlere çapraz şekilde bakarlarsa aslında tüm süreçleri hepsi kendi bakış açısından test etmiş olur ve bu sayede hem konular üzerinizdeki yetkinliğiniz artarken hemde yazılım kalitesi daha da yukarı çıkar. Bu koordineli ve iç içe çalışma biçimini Scrum bize kazandırıyor.
Sprint sonu Done olan PBI'lar için uygulama müşteri testine açılır (Kullanıcı Kabul Testi) ve Product Owner'ın bulduğu hata veya değişmesi istediği bir madde varsa tekrar kodlama sonrası test ekibinin kontrolüne sunulur. Bu kontrolden geçen ürün sonrasında da Production ortamına alınır. Böylelikle yazılım test süreci sona erdirilerek, yazılım geliştirme sürecinin son basamağına geçilmiş olunur.
Dinamik Test Süreçleri
Tester'ın kodlama sonrası yaptığı dinamik test süreçlerini açıklayacak olursak;
Kara Kutu Testi (Black Box Testing): Birçok test ekibi tarafından kullanılan, kodun derlenmiş yani Executable hale geldikten sonra yapılan test sürecidir. Bu test sürecinde yazılımın arayüzü, tabları, menüleri, butonları kısacası görseli test edilebilir. Yazılımın genel akışı, programatik yapısı, Request–response servis çağrıları ve Database ile arayüzdeki Datanın doğrulu testi yapılır. Yazılımın gereksinimine duyulan şeylere yanıt verip veremediği ve işlevselliği sınanmaktadır. Bu test süreci uygulanırken kodlama tekniği hakkında herhangi bir bilgi olması gerekli değildir.
Beyaz Kutu Testi (White Box Testing): Kısacası kod testi olarak bilinen beyaz kutu testi veya diğer adı ile Open Box Testing yazılımın kaynak kod - source code dediğimiz ham kodun incelenmesidir. Bu test sürecinde testçi kod içerisindeki akış denetimini, parametrelerin doğru kullanımı, kötü yapılandırılmış koşulları, yazılım kaynaklı güvenlik açıkları, gereksiz kod yığını, Beklenen output değerlerinin doğruluğunu test eder.
Kullanıcı Kabul Testi KKT (User Acceptance Testing): Müşteri veya Product Owner'a dayanan son test sürecidir. Yazılım müşteri tarafından kabul edilmeden önce son defa istenilen talep yazılım tarafından sağlanıyor mu? Product Owner tarafından talep edilen gereksinimlerini ne ölçüde karşılayıp karşılamadığını belirleyip, geri dönüş yapabileceği testlerdir.
Diğer Test Süreçleri;
* Birim Testi (Unit Testing)
* Integration Testing
* Memory Leak Testing (Bellek Sızıntısı Testi)
* Penetrasyon Güvenlik Testleri
* Regresyon Testi (Regression Testing)
* Performans Testi (Performance Testing)
Burak AVCI