IV - TEST DOKÜMANLARI

Test süreçlerinin kalitesini arttırmak amacıyla hazırlanan 3 doküman bulunmaktadır:

1. Test Policy: Şirket üst yönetimi tarafından belirlenen ve kurumun test felsefesini temsilen, test departmanının uyması ve izlemesi gereken kuralları belirlemektir. Yazılımın kalitesini arttırmak için kullanılan test sürecini tanımlar ve hedeflere ulaşırken testin etkinlik ve verimliliğinin nasıl ölçüleceğini belirtir.

2. Test Strategy: Test stratejisi yazılım test yaşam döngüsüne bir yaklaşım tanımlamaya yönelik bir plandır. QA ekiplerine test kapsamını tanımlamaları için rehberlik eder.

- Kapsam: Belgeyi kim gözden geçirecek; kim onaylayacak; Zaman çizelgeleriyle gerçekleştirilen yazılım test faaliyetleri nelerdir.

- Test Yaklaşımı: Test süreci; Test seviyeleri; Ekip üyelerinin rol ve sorumlulukları; Test türleri; Test yaklaşımı ve varsa otomasyon aracı; Yeni hatalar ekleme, yeniden test etme, hata triyajı, regresyon testi, vs

- Test Ortamı: Her ortam için gerekli olan gereksinim ve kurulum sayısının tanımlanması; Test verilerinin yedeklenmesinin tanımlanması

- Test Araçları: Testin yürütülmesi için gerekli olan otomasyon ve test yönetim araçları

- Release Kontrolü: İlgili sürümdeki tüm değişiklikler için test koşumunu sağlayacak uygun sürüm gemişine sahip sürüm yönetim planı

- Risk Analizi: Tahmin edilebilen tüm riskler listelenir; Riskleri azaltmak için net bir plan ve ayrıca bir acil durum planı hazırlanır

- Review & Approvals: Tüm faaliyetler iş ekibi, proje yönetimi, geliştirme ekibi vs tarafından gözden geçirilir ve imzalanır

3. Test Plan: Ürünlerin nasıl test edileceğini, test uzmanları arasındaki test tipi dağılımı, proje süresince kullanılacak test ortamı ve test araçlarını, testlerden sorumlu kişi ve sorumluluklarını, test seviyelerini ve test türlerini, test çalışmaları için planlanan test programını, hataların yönetim ve raporlama ilkelerini içerir. Test yöneticisi tarafından hazırlanır ve ekiple paylaşılır.

V - TEST CASE HAZIRLAMA

1. Test Case Hazırlama: Test Senaryosu, bir yazılım uygulamasının müşterinin gereksinimlerine göre çalışıp çalışmadığının belirlendiği bir koşullar grubudur. Test Case yazmanın temel amacı bir uygulamanın test kapsamının belirlenmesidir.

2. Test Case için Gerekli Dokümanlar: İş süreci; Kullanıcı profilleri; Kullanıcı ortamı; Diğer sistemlerle etkileşimler; Mevcut sistemlerin değiştirilmesi

- User Requirements Document: işlevsel gereksinimler; işlevsel olmayan gereksinimler; lisanslama ve kurulum gereksinimleri; performans gereksinimleri; güvenlik gereksinimleri; kullanılabilirlik ve eşzamanlı gereksinimler

- Business Use Case Document: Sistemin gereksinimler altındaki iş akışının iş aktörlerini, hedefleri, önkoşulları, son koşulları, temel akışı, alternatif akışı, seçenekleri ve istisnaları kapsar.

- Functional Requirements Document: Gereksinimler kapsamındaki sistem için her özelliğin işlevsel gereksinimlerinin ayrıntılarını verir.

- Software Project Plan: Proje planı -> hedefler, öncelikler, kilometre taşları, faaliyetler, organizasyon yapısı, strateji, ilerleme izleme, risk analizi, varsayımlar, bağımlılıklar, kısıtlamalar, eğitim gereksinimleri, müşteri sorumlulukları, proje takvimi vs ayrıntıları içerir.

- Test Plan: Test edilecek özellikler, test edilemeyecek özellikler, test ekibi niteliği, kaynak gereksinimleri, test kapsamı, test çıktıları, test yürütme için koşullar, raporlama ve izleme mekanizması, test ölçümleri içerir.

3. Test Case Nasıl Yazılmalı

- Use a strong title: Uzun başlık yerine anlamlı ve tanımlayıcı başlık

- Include a strong description: Açıklama, test eden kişiye neyi test edeceğini söylemeli. Bazen test ortamı, test verileri, önkoşullar vs gibi detaylar içerebilir.

- Include assumptions and predictions: Test icin geçerli olan tüm varsayımlar ve test yürütülmeden önce karşılanması gereken tüm koşullar eklenmelidir.

- Keep the test steps clear and concise: Test senaryoları basit olmalı, testin nasıl başlayacağı ve aşamaları gibi bilgileri içermeli.

- Include expected result: Test adımları sonucunda ne elde edilmesi gerektiği açıklanmalı. Böylece uzman test durumunun success veya fail olduğuna karar verebilir.

- Make it reusable: İyi bir test senaryosu yeniden kullanılabilir olmalıdır. Böylece bir sonraki sefer zamandan tasarruf edilebilir.

- Atomic scenario: Bir test case sadece bir durumu test etmelidir (ör. successful login). Bir case içerisinde birden fazla condition bulunmamalıdır.

4. Test Case Parameters

- Test Case ID: Her test case kendine ait bir ID'ye sahip olmalıdır.

- Test Case Description: Her case kısa ve net bir ifadeyle tanımlanmalıdır.

- Pre-Conditions: Her case'de karşılanması gereken koşullar ifade edilmelidir.

- Test Steps: Tüm test aşamaları ayrıntılı olarak ve son kullanıcının anlayacağı şekilde anlatılmalı

- Test Data: Test adımlarını koşmak icin uygun test verilerine ihtiyaç vardır. Test öncesinde ihtiyaç duyulan test dataları toplanmalı veya oluşturulmalıdır.

- Expected Result: Test koşumlarından beklenilen sonuç ifade edilmelidir.

- Actual Result - Post Condition: Test senaryosu yürütüldüğünde sistemin gösterdiği sonuç.

- Status: Actual Result ve Expected Result'a göre sonuç success veya fail olarak işaretle.

- Diğer Parametreler: Project Name, Module Name, Date of Creation, Created By, Date of Review, Executed By, Execution Date, Release, Version

5. Dikkat Edilmesi Gerekenler:

- Anlaması ve yürütmesi kolay: Benzersiz test durumu tanımlayıcıları kullanılmalı; Önkoşullar listelenmeli; Test verilerin tanımlanmalı; Test senaryosu açıklaması kısa olmalı; Test adımları ayrıntılı ve anlaşılır olmalı; Beklenen sonuç belirtilmeli; Pozisyon durumu listelenmeli; Test durumları ayırdedici olmalı; Test senaryosu senaryo tasarım teknikleri takip edilerek yazılmalı; test senaryosu anlaşılır olmalı; Senaryolar yeniden kullanılabilir ve bakımı yapılabilir olmalı; Proje zaman çizelgelerine göre uygulamanın risk faktörleri belirlenmeli ve test senaryoları önceliklendirilmeli; Senaryolar listelenmeli ve iş senaryosu ve işlevselliğe göre sınıflandırılmalı; Test senaryoları modüler ve ayrıntılı olmalı; Test senaryoları başkalarının kolayca anlayabileceği şekilde yazılmalı ve gerekirse değiştirilebilir olmalı;

- Check List: Hangi modüller test edildi; Koşulan ortalama test senaryosu sayısı; Kaç modül ve fonksiyon güvenilir olduğunu kanıtladı; Her modülde bulunan hata miktarına göre hangi modüllere daha fazla dikkat edilmesi gerekiyor; Test case'lerde kontrol edilen ve korunan uygun sayıda veri mevcut mu; Kullanıcı uygulamayı doğru kullanmıyorsa doğru hata mesajları gönderiliyor mu; Uygulama mobil cihazlarda, farklı tarayıcı ve platformlarda uyumluluk açısından test edildi mi; Kullanıcı arayüzü gereksinimlere uygun mu

VI - HATA RAPORLAMA

Hatanın sebebi ve sonucu detaylıca anlatılmalı: Hangi durumlarda, ne tip bir hata oluşuyor, beklenen sonuçtan nasıl bir sapma gerçekleşiyor.

- Rapor başına bir hata:

- Hata oluştuğunda yazılımın neresindeydiniz: Hatanın bulunduğu sayfa, form veya satır

- Hata oluştuğunda yazılımda ne yapıyordunuz: Hatayı tetikleyen işlem

- Ne olmasını bekliyordunuz: Hata olmaması durumunda beklenen sonuç

- Hata ekran görüntüsü ve ekran kaydı:

- Teknik bilgileri kaydedin: işletim sistemi, web sayfa ve uygulamaları, hangi tarayıcı, masaüstü/mobil vs teknik bilgiler

- Alınan hata mesaj ve kodları:

- Sorun tekrarlanabilir mi: Aynı işlem her defasında aynı hataya mı yol açıyor

- Kendiniz düzeltmeyi denediniz mi? Sayfa yenilenmesi veya sistemin yeniden başlatılması sorunu çözüyor mu

- İşinizi ne kadar etkiliyor: Bir hatanın yürümesi gereken işleri ne kadar etkilediği bilgisi hata çözülme sırasını etkilemektedir.