Ana içeriğe atla

Yazılımda Test Süreçleri

testing software

Amaç: Dokümanın amacı ve test aktivitelerinin özeti burada tanımlanır.

Arka Plan veya Zemin: Geliştirme evreleri ve süreçler burada tanımlanır. Örneğin hali hazırda kullanılan sistemin hali, istenilen yenilikler tanımlanır ve eski data işlemleri bittikten sonra datanın hangi formata nasıl bir süreç içerisinde dönüştürüleceği belirtilir.
Proje süreçleri, alt yapı ihtiyaçları sürüm numaraları ile numaralandırılmalıdır. Değişen ihtiyaç ve datanın alacağı formatlar da belirtilmelidir. 

Kapsam: Test kapsamı ve testin içerikleri burada tanımlanır.

Test ne saglar


Zamanlama: Yapılacak işlerin zamanlama çizelgesi burada verilir.


Test Maddeleri: Test edilecek maddelerin seviyeleri ile birlikte burada tanımlanır. Ayrıca testin yapılabilmesi (test ortamı) için gerekenlerde belirtilmeli.

İlgili Maddeler veya Dokümanlar:

  • İhtiyaç maddeleri 
  • Tasarım maddeleri 
  • Operasyon kılavuzu 
  • Kurulum kılavuzu

Test Maddelerinin Detaylandırılması


1. Program Kodları: Test edilecek yazılımın modülleri aşağıdaki gibi tespit edilebilir;

Program kodlari

2. Business (İş) Prosedürleri:


Business is prosedurleri

3. Raporlama Prosedürleri:


Raporlama prosedurleri

4. End to End Prosedürleri: Sistem entegrasyonları testi.

5. Çevrim – Göç Prosedürleri: Veritabanının tümünün veya bir bölümünün ve ana veritabanından hazırlanan bir dosyanın başka sistem veya programlar tarafından kullanılabilme maddeleridir.

Cevrim goc prosedurleri

6. Test Edilecek Ana Maddeler: Test edilecek maddeler tablo içerisinde modülleriyle birlikte belirtilir.

test edilecek ana maddeler

7. Test Edilmeyecek Maddeler: Test edilmeyecek maddeler buraya yazılmalıdır. Ancak test kapsamı içerisinde yer alması düşünülen maddelerin birinci derece ilişikleri seçilmelidir.

8. Yaklaşım (İşe Girişim): Bu bölüm tüm test gruplarının layıkıyla yapılmasını sağlamak içindir. Tüm maddeler T1, T2, T3, T4, and T5 olmak üzere 5 etapta yapılır. Etaplar ve etapların kapsamı ve ihtiyaçları excel veya benzeri dokümanlarla takip edilmelidir.
Ayrıca geliştirmeyi yapacak takımın data ve data özelikleriyle zaman çizelgesi kapsamının dokuman olarak oluşturulmasında fayda vardır.

Test Etapları ve İçerikleri

Unite testi: Unite testi T1, T2, ve T3 etap kapsamındadır. Her unite testi için ayrı ayrı test koşulları ve test datası ihtiyacı vardır. Her kodun doğru çalıştığının onayı verilmelidir.

error debug test

Fonksiyon testi: Fonksiyon testi T1, T2, ve T3 etap kapsamındadır. Kodların minimum data ile beklenen fonksiyonları ve işlevi yerine getirdiğinden emin olunması gerekir.

Performans testi: Ana bakış açısı ile performans testi T1, T2, ve T3 etap kapsamındadır fakat tüm etaplarda kullanılma ihtiyacı da doğabilir. Testte zaman ölçümlerinin detaylı tutulması gerekir.

Sistem Entegrasyon testi: Sistem entegrasyon testi T4 kapsamındadır. Sistemlerin veya bileşenlerin entegre çalışabilmesini içeren test koşul ve test datası ile yapılır. Tüm iş akışları ve sonuç raporları alındıktan sonra entegrasyonun doğruluğunu ölçer.

Migration testi: Veri tabanının tümünün veya bir bölümünün ve ana veritabanından hazırlanan bir dosyanın başka sistem veya programlar tarafından doğru kullanılabilmesini ölçer. Gerçek data ve gerçek sistemle test edilir.

Kullanıcı Kabul testi: Kullanıcı Kabul testi T5 etap kapsamındadır. Test koşul ve test datası gereklidir. Bu etapta son kullanıcılar teste dahil olabilir…

Doğrulama testi: Tüm test etapları bittiğinde doğrulama testi tamamlamış olur. Doğrulama testi onayı için tüm test etapları tamamlanmış, tüm test koşulları loglanmış, tüm bulunan hatalar raporlanmış ve düzeltilmiş olması gerekir.
Regresyon testi: Regresyon testi, doğrulama testi içerikleri onaylandıktan sonra çıkan versiyonun tamamının test edilmesini içerir. Amacı yeni versiyondaki beklenmeyen etkilerin tespiti ve ölçümlenmesi içindir.
Genel olarak regresyon testleri bir test programı kullanılarak ilgili ilgisiz tüm test koşullarının çalıştırılması ile yapılması tercih edilir.

Sınırlamalar: Yeterlilik zaman sınırlamaları yazılır.

9. Giriş ve Çıkış Kriterleri: FMEA den gelen giriş ve çıkış kriterleri yazılır.

10. Askıya Alınma Kriteri ve Yeniden Başlama Gereksinimleri:

Askıya alınma kriteri: Testin bir bölümünün veya tamamının durma aşaması kriteri.

Yeniden başlama gereksimleri: Teste tekrar başlayabilme kriterleri. Örneğin regresyon testinden sonra yeni bir versiyon çıkma mecburiyeti varsa tüm regresyonun tekrar test edilmesi gibi…

11. Test Sunumu veya Raporları: Aşağıdaki dokümanlar testten sonra sistem test grubu tarafından konfigurasyon yönetim grubuna teslim edilir.

Test dokümanları: Sistem test planı Sistem test tasarım ayrıntıları Sistem test koşulları ayrıntıları Sistem Test yöntem ayrıntıları Sistem Test Logları Sistem Test olay rapor logları Sistem Test olay raporları Sistem Test özet raporu

Test datası: Test koşuları dokümanına tüm data girişleri, sorgu pencereleri ve cevap pencereleri eklenmelidir. Giriş ve çıktı test dosyaları verilmelidir. Son hatasız çalışan test koşul, girdi ve sonuç çıktısı verilmelidir.

12. Testing Görevleri: Test görev listesi yazılmalıdır.

13. Çevresel İhtiyaçlar:

  • Donanım 
  • Yazılım 
  • İşletim Sistemi 
  • Geliştirme Yazılımı 
  • Güvenlik Test Araçları 
  • Yayınlar

14. Sorumluluklar: Testten sorumlu kişiler yazılır.

  • Sistem Test Grubu 
  • Son Kullanıcılar 
  • Proje Geliştirme Grubu 


15. Personel Kadrosu ve Eğitim İhtiyaçları:



Test grup
Test grup personeli

Son kullanıcı
supervisor

16. Eğitimler: Alınmış ve alınacak eğitimler yazılmalıdır.


17. Zamanlama: Test zaman planı yazılır. Ayrıca buraya hangi zaman veya tarih aralığında, hangi donanım veya yazılımların kullanılacağı da eklenebilir.

18. Riskler ve Beklenmeyen Olaylar: Meydana gelecek riskler ve ön görülmeyen olaylar kapsamı yazılır. Örneğin test datasında bir problem varsa datanın debug işlemi için kim ne kadar bu işe verileceği, test uzmanının yetersizliğinde ekibe kimlerin katılacağı veya donanımsal problemlerde ne yapılacağı yazılır.

19. Onaylamalar:
test sureci onaylamalari

Yalçın ÖZÇELİK | Test ve Eğitim Yöneticisi

Yorumlar

  1. Seni seviyoruz Yalçın abi :)
    Bu arada 18. maddeye eklemek isterim ki riks yoksa kazançta yok :)) ( biliyorum bende riks yazabiliyorum, şaka şaka risk )

    YanıtlaSil
  2. :))) Bizde seni seviyoruz Sayın Ali Kemal... Hep güldürmek zorunda mısın _? :)))

    YanıtlaSil
  3. makale için teşkkürler admin.

    YanıtlaSil
  4. yalçn bey vermiş olduğunuz bilgi için teşekkürler

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara