Yazılım Test Süreci Adımları
1- Test Hazırlık Süreci
Test süreci, SDLC’nin ilk aşamasından, yani gereksinimlerin toplanmasından başlar. Genellikle Agile projelerde iş analistleriyle birlikte test ekibi de gereksinim
toplama sürecine dahil olur. Waterfall gibi geleneksel modellerde, gereksinimler toplandıktan sonra test ekibi devreye girer.
Hazırlanan gereksinim belgesinden sonra gereksinim analizi yapılır. Gereksinimlerin temel özelliklere uygun olup olmadığı kontrol edilir. Temel gereksinim özellikleri;
- Atomik: Gereksinimler daha küçük parçaya bölünemeyecek kadar atomik seviyede olmalıdır. Tanımlanan bir gereksinim kendi içerisinde farklı gereksinimleri içeriyorsa anlamlı olabilecek şekilde parçalara ayrılmalı ve ayrı şekilde tanımlanmalı.
- Açık, Kesin: Gereksinimler tüm paydaşlar tarafından anlaşılacak derecede açık bir şekilde tanımlanmalı, okuyucunun tartışmasına açık olmamalı ve muğlak ifadeler içermemelidir.
- Bütün, Tam: Gereksinimler tüm paydaşlar için yeterli seviyede detay içerecek şekilde tanımlanmalıdır.
- Anlaşılır: Analiz dokümanlarında çoğu zaman kısaltmalar ya da teknik terimler ile gereksinimler tanımlanır. Analiz dokümanlarını farklı bilgi seviyesindeki paydaşlar da okuyacağı için herkesin anlayacağı şekilde gereksinimler tanımlanmalı, çok fazla kısaltma kullanılıyorsa dokümanda bu kısaltmalar ayrı bir bölümde açıklanmalı.
- Tutarlı: Gereksinimler birbirleri ile tutarlı ve iş ihtiyacını karşılıyor olmalı. Farklı paydaşlar ile yapılan görüşmeler sonucunda ortaya çıkan, birbirleri ile çelişen gereksinimlerin netleştirilmesi gerekir.
- Kısa, Öz: Gereksinimler tanımlanırken fazladan olabilecek gereksiz bilgiler verilmemeli, kısa ve basit bir şekilde tanımlanmalı. Uzun cümleler ve bağlaçlar kullanılması analiz dokümanlarının okunmasını ve kolay anlaşılmasını olumsuz yönde etkilemektedir.
- Doğrulanabilir: Tanımlanan gereksinimler doğrulanabilecek şekilde kabul kriterleri içermeli. Böylelikle test aşamasında test yapan kişinin inisiyatifine göre değil tanımlanan kriterlere göre testin başarılı ya da başarısız olduğu kararı verilir.
- Uygulanabilir: Gereksinimler öngörülen sürede, teknik açıdan, iş kuralları, kısıtlar ya da yasal zorunluluklar açısından sorunsuz bir şekilde, belirlenen bütçe ve kaynak ile uygulanabilecek şekilde tanımlanmalı. Sistemsel olarak kolayca uygulanamayacak, ekstra donanım ihtiyacı ve maliyet gerektirecek gereksinimler yerine uygulanabilir çözümler üretilmeli ve gereksinim tanımlaması yapılmalıdır.
- Önceliklendirme: Gereksinimler tanımlanırken mutlaka önceliklendirme yapılmalı, hangi gereksinimin daha öncelikli olduğu tanımlanmalıdır. Ayrıca gereksinimler arası ilişkiler de belirlenmeli, gerçekleşmesi birbirine bağlı gereksinimler varsa açıkça belirtilmelidir.
Gereksinim belgesi, inceleme ve analiz sonucunda tamamlanır. Belgedeki gereksinimlerin hangi doğrulama yöntemi kullanılarak doğrulanacağını gösteren Gereksinim Doğrulama Matrisi oluşturulur. Gereksinim Doğrulama Yöntemi;
- Gösterim (Demonstration)
- Test
- Analiz
- Muayene (Inspection)
- Uygunluk Belgesi (Certificate of Compliance – CoC)
Gerçekleştirilecek test türlerin belirlenmesi, testlerde hangi kısımların öncelikli olacağı ve testin yapılması gereken test ortam ihtiyaçları belirlenir.
2- Test Planı ve Kontrolü
Proje için bir test planı oluşturulur. Test planı;
- Test edilen ürününe ait kısa bir özetten oluşan girişi,
- Hedef ve görevleri,
- Test kapsamını,
- Test stratejini,
- Test programını,
- Kontrol prosedürlerini,
- Test edilip edilemeyecek özellikleri,
- Kaynak,
- Roller ve sorumlulukları,
- Bağımlılıklar,
- Riskler / Varsayımlar,
- Araçları vb. projeye ait bilgilere yer verilir.
3- Test Analizi ve Tasarımı
Mimari, kullanıcı arayüzü, tasarım, test koşulları tanımlama ve önceliklendirme, test verilerinin tanımlanması, test ortamının tasarlanması ve test senaryolarının yer aldığı test prosedürünün hazırlandığı kısımdır.
- Test Prosedürü Test Durumlarından (Test Case), Test caseler Test Adımlarından oluşur.
- Her test adımının bir aksiyon bir de beklenen sonucunun bulunması gerekir. (Input/Output)
- Aynı gereksinim bir veya birden fazla adımda doğrulanabilir.
- Bir adımda birden fazla gereksinim doğrulanabilir.
- Test casede adım sayısı 20 adımı geçmeyecek(mümkünse) şekilde oluşturulmalıdır.
- Bir gereksinim birden fazla test durumunda doğrulanabilir.
Test durumların tamamlanması ile İzlenebilirlik Tablosu oluşturulur. Bu tablo Test Durumu ID ve bu test durumunda doğrulaması sağlanan Gereksinim ID sütunlarından oluşmaktadır.
4- Test Koşumu
Testin yürütülmesi, test edilecek ürünün hazır olması ve teste başlama kriterlerinin sağlanmasıyla başlar.
Testin yürütülmesine başlarken ;
- Test senaryolarını / prosedürlerini içeren dokümanların
- Test yönetimi, konfigürasyon yönetimi ve hata takip araçlarının
- Kullanılıyorsa test otomasyonu araçlarının hazır olması
- Test sonuçlarının nasıl kayıt altına alınacağını ve değerlendirileceğini belirten süreçlerin tanımlanmış olması gereklidir.
Ad-hoc ve keşifsel testler koşulmaya başlanır.
- Ad-hoc Testi: Ad-hoc test, olası kusur ya da hataları mümkün olduğunca erken bir aşamada bulmak için gayri resmi (önceden tanımlanmamış) veya yapılandırılmamış bir yazılım test türüdür. Genellikle yapılacak bütün testlerin sürelerinin belirlenmesini amaçlar. Bu test ekipleri tarafından gerçekleştirilir.
- Keşifsel Test: Keşif testlerinde, testçi kendi deneyim ve tecrübesini kullanarak birim ya da sistemi gayri resmi olarak test etmesidir. Keşif testleri, gereksinimler az ya da yetersiz olduğu durumlarda veya testler üzerinde önemli zaman baskısı olduğunda çok işe yarar.
- Hata açılır – Geliştirici hatayı çözer – Test ortamına deploy olur – Testçi doğrulama yapar – Hatanın çözülmesi üzerine hata kapatılır. (Her deploy sonrasında regrasyon testi koşulur.)
Ad-hoc ve keşifsel testlerin yapılmasının ardından Vasıflandırma sürecine geçilir ve hazırlanan test caseler adım adım koşulur. Testler koşturulduktan sonra ortaya çıkan sonuç ile beklenen sonuç karşılaştırlır. Beklenen sonuç ile ortaya çıkan sonuç farklı olduğunda, hata raporu veya uymazlık raporu olarak sunulur.
5- Ön Koşu
Hatalar yazılımcı tarafından çözülüp testçi tarafından çözümünün doğrulanıp hata fixlendikten sonra Ön Koşu yapılır. Vasıflandırma sürecinin aynısıdır. Ön koşunun vasıflandırmadan tek farkı, kullanıcı ortamında test koşumunun gerçekleştirilmesidir.
6- Çıkış Kriterleri ve Raporlama
Projenin risk değerlendirilmesi göz önünde tutularak, her bir test seviyesi için “Yeterli test” durumunun ortaya çıkacağı bazı bitiş ölçütler oluşturulur. Bu ölçütler projeden projeye değişir ve “exit criteria” olarak da adlandırılır. Çıkış kriterleri;
- Azami sayıdaki testlerin koşumunun yapılması ve yeterli miktarda “Geçti” test sonucunun alınması,
- Hata oranın belirli bir oranın altında kalması,
- Teslimat tarihine gelinmiş olmasını içerir.
Çıkış kriterlerinin değerlendirilmesi, test faaliyetini sona erdirmek için belirlenen hedeflere ulaşılıp ulaşılmadığının değerlendirilmesidir.
Çıkış kriterlerinin değerlendirilmesi ve raporlama, şu aşamaları içerir:
- Test sonuçlarının Test Planı dokümanında belirlenmiş kriterlerle karşılaştırılması (planlanan bütün testler tamamlandı mı, çözülen hatalar için gerekli konfirmasyon ve regresyon testleri yapıldı mı, çözülmeyen kaç hata kaldı, bu hatalar ne kadar önemliler vb.)
- Daha fazla test yapılmasına ya da çıkış kriterlerinin değiştirilmesine gerek olup olmadığının değerlendirilmesi (bu kararların verilmesi diğer paydaşların da onayını gerektirir)
- Diğer proje paydaşlarının da test sonuçlarını görüp değerlendirebilmesi için bir Test Raporu yayınlanması .
7- Kabul
Proje ekibi, kurum ve müşteri ile Test Hazırlık Gözden Geçirme Toplantısı yapılır ve toplantı sonucu kullanıcıdan onay alınırsa kullanıcı tarafından kabul için tarih alınır.
- Kabul: Kullanıcı ortamında yapılan testler sonucu hata çıkmazsa kabul olur. Kabul, modülün hatasız olduğu anlamına gelmemektedir. Kullanıcının isteklerine göre iyileştirmeler olabilir. Uygunsuzluk ve kırmızı kalem düzeltmeleri yapılabilir. Kapanış tutanakları veya geçici kabul tutanağı imzalanır.
- Şartlı Kabul: Kullanıcı ortamında yapılan testler sonucunda çıkan hataların severity oranı 1 veya 2 değilse (hatalar ciddi değilse) şartlı kabul yapılır. Kapanış tutanağı hazırlanır ve geçici kabul tutanağı belirlenen tarihe kadar hatalar çözülür ve doğrulama yapılır.
- Ara Verme: Kullanıcı ortamında müşteri ve kullanıcı tarafından modülün gereksinimlerini karşılamaması ve modülün uygunsuzluğuna karar verilerek ara verme süreci başlar.
8- Canlıya Alma
Kabul edilen proje canlıya alınır.