Yazılım Testi nedir?
Yazılım testi temel olarak elde edilen ürünün beklenen kalitede olduğunu belirlemek , değilse istenilen kaliteye ulastirilmasini sağlamak icin kullanilan bir sürectir. Kalite düzeyi muşteri tarafindan maliyet analizi goz onune alinarak belirlenir. Bilgisayar sistemleri hatalar barindirir. Bu hatalar insan(developer, analist vb.) ve donanim kaynakli olabilir hatalar maddi ve/veya prestij kayiplara neden olabilir. Yazılım test surecinin proje dongusune katilmasiyla bu kayiplar en aza indirebilir. Burada unutulmamasi gereken sey mukemmel program olmadiği ve bir yazılımin asla 100% test edilemiyecegidir. Bunun disinda risk bulunmayan projelerde yazılım testine gerek olmayabilir. Bu karar maaliyet analizi goz onunde bulundurularak alinmalidir.
Yazılım Testi.com içinde Hızlı Arama yapmak için anahtar kelimeyi girin:
Yazılım Test cesitleri nelerdir?
| o Kara Kutu testi (Black box testing) |
o Beyaz Kutu testi (White box testing) |
| o Birim testi (unit testing) |
o Artan Entegrasyon/Bütünleşme testi (incremental integration testing) |
| o Entegrasyon/Bütünleşme testi (integration testing) |
o Fonksiyon/I.şlevsel test (functional testing) |
| o Sistem testi (system testing) |
o Baştan sona test (end-to-end testing) |
| o Tekrar Testi ( regression testing) |
o Yüzeysel test (sanity testing or smoke testing) |
| o Yükleme testi ( load testing) |
o Kabul Etme / Onaylama Testi (acceptance testing) |
| o Stres Testi (stress testing) |
o Performans Testi ( performance testing) |
| o Kullanılabilirlik testi (usability testing) |
o Kurma / Kaldirma testi (install/uninstall testing) |
| o Telafi/Düzelme Testi (recovery testing) |
o failover testing |
| o Guvenlik Testi (Security testing) |
o compatability testing |
| o Keşif Testi (Exploratory Testing [E.T]) |
o ad-hoc testing |
| o context-driven testing |
o Kullanıcı Teslim Alma Testi (user acceptance testing) |
| o comparison testing |
o mutation testing |
| o alpha testing |
o beta testing |
Yazılım Test Teknikleri
Kalite kontrol uzmanı veya kısaca testci ne iş yaparı Yazılım testleri nerede yapılırı Testler neye benzerı Bu soruların cevapları seçilen yazılım testi tekniğine gore değişir. Ana başlıklarıyla bazı yazılım testi teknikleri :
1. Temelinde insan olan, testi kimin yapacağina bağlı teknikler
2. Kapsam bazlı, neyin test edileceğine bağlı teknikler
3. Problem temelli, yazılımın neden veya neye karsı test edildiğini bağlı teknikler
4. Aktivite tabanlı, yazılımın nasıl test eğildiğine bağlı teknikler
5. Değerlendirmeye bağli olan, testin geçer veya kalır not aldığını saplayan teknikler
Hangi tekniğin kullanılacak olması, tekniği kullanacak kişinin test hakkındaki düşüncesine bağlı olup aynı anda birçok teknik de beraberce kullanılabilinir.
Test safhasına gelindiğinde aşağıdaki 5 soru yardımıyla hangi tekniği kullanacağınızı saplayabilirsniz:
1. Testi kim uygulayacakı
2. Yazılımın hangi durumları test edilecekı
3. Ne tür sorunlar bulmayı umuyorsunuzı
4. Testci hangi aktiviteleri test etmekden sorumlu olacakı
5. Bir testin geçtiğini veya kaldığını nerden anlayacaksınızı
Size uygun tekniği seçmede ve müşterinize sıfır (0) hatalı yazılımlar sunmada iyi sanşlar.
Kalite Kontrol Analistlerinin Haklari
· Kalite ve proses (surec) ile ilgili sorunlardan bahsetmeye heran hakki vardir.
· Musteri ve/veya programciya soru sormaya ve zamaninda cevap almaya hakki vardir.
· Proje takimindaki iclerinde programcilar, mudurler ve musterilerinde oldugu herhangi birisinden yardim isteye hakki vardir.
· Kalite kontrolu ilgilendiren zaman tahminlerinin yapilmasinda ve guncellestirmesi isleminde hakki vardir.
· Çalistiginda isini daha iyi yapabilecegine inandigi test araçlarinin zamaninda kendine saglanmasina hakki vardir.
· Sadece Kalite Kontrol Analizti'nin degil, butun proje takiminin yazılımin kalitesinden sorumlu oldugunu bilmesine hakki vardir.
Yazılım Testine Neden Ihtiyac Duyulur?
Yazılımlar neden test edilirı Sirketler neden Yazılım testi icin eleman alir iseı Yazılım testi sektorunde calisan herkeş bunlar ve/veya bunlara benzeyen sorularla devamli karsilasirlar. Size cok kisa bir sekilde cevap vermeye calisayim. Sunumdan Sonra Ortaya Cikabilecek Hatalarin, Pahalli Tamir Maliyetlerini Dusurmek / Azaltmak Icin Yazılım hatalarinin tamiri cok ucuz maliyetlerden cok pahalliya hatta bazi durumlarda can kaybina kadar gidebilir. Basit/Kucuk yazılım hatalarinin buyuk bilgisayar sistemlerinin yerle bir olmasina sebep oldugunu anlatan yuzlerce hikaye vardir. Bu sistemlerin çokmesinin bir cok nedeni olmasina ragmen, "yetersiz test" bu nedenlerin en basinda gelmektedir. Bu gercek hikayeler, gerektigi kadar test yapilmasi halinde sirketlerin çok buyuk tamir paralari harcamamalarina yardimci olmasi icin paylasilmaktadir. Asagida bunlardan ucunu okuyacaksiniz: · Pepsi Cola'nin $42 Milyar Dolarlik Hatasi · Cahoot, Abbey Ulusal Bankasi Website Hatasi · Kimya Bankasi Sonuc olarak, yukarida okudugunuz butun bu hatalari gerekli miktarda Yazılım testi yaparak onleyebilmek mumkundu. Demek ki yazılım testin amaci, pahalli tamir maliyetlerini onlemek veya en aza indirmeye calismak. |
Test Dokumanlari Nelerdir?
Sirketden sirkete, kullanilan test methoduna hatta testi yoneten kisiye gore degisik isimli test dokumanlari karsiniza cikabilir. Bu dokumanlardan en fazla karsiniza cikabilecek olanlari:
- Test Strateji Dokumani
- Test Plan Dokumani
- Test Kapanis Rapuru
- I.zlenebilirlik Matrisi (tracebility matrix) [ÖRNEK]
- Test Data Dokumani
IEEE 829-1998 , 829 Yazılım Testi Standartlari Dokumasyon kurallarina gore ise test dokumanlari 3 evreye ayrilir:
1. Test Planlama
- Test Plani
- Test Dizayn Detaylari
- Test Durum Detaylari
- Test Yontem Detaylari
2. Test Uygulama (infaz)
- Test Seyir Raporu
- Test Hadise/Durum Raporu
3. Test Raporlama
- Test Ozet Raporu
Yazılımlar Neden Hata Icerirler
o Iletişim eksikliği
o Programlama hataları
o Ihtiyac değişikliği
o Zaman baskısı
o Dökümantasyon eksikliği
o Geliştirme araçları eksikliği
o Donanım hataları
|
İzlenebilirlik Matriksi Nedir?
İzlenebilirlik matriksinin üç önemli amaci var:
1. Herbir müşteri isteginin, en azindan (min.) bir test senaryosu tarafindan kapsandiginin/test edilip edilmediginin takibini saglar.
2. Zamanla degişen veya gelişen müşteri isteklerinin takibine yardimci olur.
3. Regresyon senaryolarinin belirlenmesinde, olmazsa olmaz denilen müşteri beklentilerinin hangileri oldugunun saplanmasında etkin bir pay oynar.
İzlenebilirlik matriksleri çesitli müşteri istek yonetimi aracları, veritabanları, excel veya word dökümanları kullanılarak yaratınılabilirler. Bu araclardan en çok kullanılanlar:
* Rational RequisitePro
* Mercury QualityCenter
|
Yazılımcılar ile Uyumlu şekilde Çalışmanın Kilit Noktaları
Yazılımcılarla kuracağınız ilişkinin baslangıç noktası, çogu zaman buldugunuz ve rapor ettiginiz hata olacaktır.
Bildiginiz gibi yazılımcı ve kalite kontrol elemanları arasında bu bulunan hatalara bağlı olarak yüksek tansiyon olusabilir. Bu tansiyonun yükselmemesi için karşılıklı saygıya dayali bir ilişki kurulması şarttır. Eger bu saygı ortamı oluşturulamazsa, birçok zaman yazılımcılar kalite kontrol elemanlarına kötü davranmayı secerler. Sonuçta kimse hatasını yüzene vuran/ gösteren insanı sevmez. Eger bu durum (kötü davranma) oluşursa, kalite kontrol uzmanı bu tavrı sineye çekmemeli ve gerektiği gibi karşı çıkmalıdır.
Yazılımcının kodunu resmi olarak eleştirirken, yani test ederken, aşağıdaki saygı kurallarına uymak şarttır:
- hassaslık / duyarlılık,
- beğenme / takdir,
- diploması.
Güzel bir kod gördügünüzde çığlık atıp, "mükemmel olmuş" demek zorunda değilsiniz ama yazılımcıya beğendiğinizi soyleyip kodunu takdir etmekle ilerde oluşabilecek bir sorunu daha baslamadan çözmüs olabilirsiniz. Diğer taraftanda eğer çok kötü bir kod uygulamasıda görürseniz, çok abartmadan, yazılımcıyı rencide etmeden bildirmenin yolunu secmelisiniz.
Aslında, yazılımcılarla iyi bir ilişki kurmanın en iyi, güzel, kolay ve doğru yolu her konuda acık ve doğrucu olmaktan geciyor.
Asağıdaki basit kuralları uygulayarak uyumlu bir ilişkiye ilk adımları atabilirsiniz:
1. Nasıl düşündügünü anlamaya calışın.
2. Doğru hataları, duyarlı bir şekilde bildirip güvenini kazanın
3. Yapabileceginiz birşey varsa, yardım teklif edin
4. Dürüstlüğunuz ve kabiliyetiniz size saygı duyulmasını sağlayacaktır
5. Kişiye (yazılımcıya) değil, işe odaklanın
6. Yazılımcılar kodları, yaptıkları işler hakkında konuşmaya bayılırlar. Onlara soru sormakdan kacınmayın.
Hadi daha ne bekliyor sunuzı Hemen gidip yazılımcılarla iyi bir ilişki kurmanın yollarını test edin… iyi sanşlar…
Kaynak: Lessons Learned in Software Testing by C.Kaner, J.Bach, B.PettichordKK sürecini onaylamak
Kalite Güvencesi vs. Kalite Kontrol
| Kalite Güvencesi |
Kalite Kontrol |
 |
| Sorun veya hataların oluşumunu engeller. |
Ürünün önceden belirlenmiş standartlara uygun olmadığını doğrular bir etkinlik. |
| Süreçlerinin kurulmasına yardımcı olur. |
Hataları algılar, raporlar ve düzeltir. |
| Süreçleri değerlendirmek için, ölçüm programları kurar. |
Süreci uygular. |
| Süreçlerin zayıflıklarını belirler ve onları iyileştirir. |
Belirli bir ürün veya hizmet ile ilgilidir. |
| Bir yönetim sorumluluğu olmasına karşın sık sık bir personel fonksiyonu tarafından gerçekleştirilir. |
Belirli özelliklerin var olup olmadigini doğrular. |
| Süreç tarafından üretilecek bütün ürünlerin hepsi ile ilgilidir. |
Birinci amaci kusurların düzeltilmesi için kusurları tanımlamaktır.
|
| Kalite Kontrol'un işleyip işlemedigini değerlendirdiği için bazen Kalite Kontrol'un Kalite Kontrolu'de denir. |
|
| KG personeli KK sürecini onaylamak dışında hiçbir zaman kalite kontrol yapmamalıdır. |
|
Hata (defect) vs. Geliştirme (enhancement)
Coğu zaman, Hata (defect) ile Geliştirme (enhancement) birbirine karıştırilır. Bu iki terim, aslında hem surec bakımından hem de anlam bakımında buyuk değişiklikler tasıyan terimlerdir. Geliştirme temelde, müşterinin / kullanıcının, yazılıma yeni bir işlevsellik eklenmesini istediği zamanlarda yapılır. Geliştirme Talebi, kullanıcının beklentilerinin yazılım tarafından karşılanmaması durumlarında kullanılır. Öte yandan hata, tanım itibariyle, müşteri ile mutabık kalınmış isteklerden (requirements) sapmanın saplanmasıdır. Bir başka değişle, hata, mutabık kalınmış isteklerin yazılım tarafından yerine getirilemiyor olmasıdır. Her Geliştirme Talebi, mutabık kalınan istekler, dizayn, uygulama ve kalite kontrol sureclerine ihtiyac duyar.
Yazılım icerisince gorunen bir sorunun, Hata mı yoksa Geliştirme mi olarak takip edilmesi gerektiğini anlamak icin asagıdaki basit Evet/Hayir sorusunun cevabına bakılır:
Soru:
Karşılasılan sorun, ekibin şimdiye kadar uyguladığı ve müşteri tarafından kabul edilen isteklerin bir ihlali mi?
Cevap:
Evet. O zaman bu sorun Hata kategorisinde takip edilmelildir.
Hayır. Bu durumda ise Geliştirme Talebi olarak takip edilip, müşteri istekleri toplanıp, yeni dizayn, geliştirme ve kalite kontrol surecleri baslatılmalıdır.
Tolun S. Ozarslan
ISTQB Certified Tester - Advanced Level Test Manager (CTAL-TM)
|
