CMMI bir surec iyilestirme yaklasimidir. CMMI-DEV sureclerin oturtulup iyilestirilmesi anlaminda bazi yazilim gelistirme adimlarinin varliginin ve olgunlugunun da seviyelendirmede etkili oldugunu biliyoruz. Lakin soz konusu adimlar bahsettiginizden daha yuksek seviyeli adimlardir. CMMI’in tanimlanmis belirli seviyelerine uygunluk bildirimi ile onurlandirilmis firmalar, kendi ic surecleri icerisinden degerlendirilirler. Yani CMMI birim test yazildiktan sonra boyle bir dokuman yazilir gibi bir recete vermez. Bunun yerine yazilim gelistirme sureclerinizin ne kadar olgunlasmis oldugunun bir olcutudur. Kisacasi CMMI vasitasi ile boyle bir soru elma ile armutu karsilastirmak olacaktir ve temelinde CMMI’in ozune uymayan bir yaklasimdir.

Dokumantasyon konusuna gelirsek durumu soyle ozetlemek mumkundur; yazilim uretimindeki her cikti gibi dokumantasyon da belirli amaclar icin ve birilerinin okumasi icin hazirlanir. Eger bu is icin boylesi bir emek sarfedilmesi dusunuluyor ise bunun sebebi sorgulanmalidir. Eger bu ek surec yazilim gelistirme yasam dongunuzde pozitif anlamda bir katki saglayacak ise zaten bunu yapmaniz sizin icin iyidir. Sizin icin olumlu katkilar saglayacak adimlari atarak is yapma bicimlerinizi iyilestirmek de “isini iyi yapmanin” tanimi dahilindedir.

Sureclerinizi kendiniz icin olusturur ve iyilestirirsiniz, CMMI icin degil. CMMI olcumleri, sizin yazilim gelistirme sureclerinizi tam olarak tanimlanmis hangi olgunluk seviyesinde gerceklestirdiginiz ile ilgilenecektir.

Kaynak kodun dokumantasyonu hususlarinda surdurulebilirlik, standardizasyon ile kaynak planlamada saglanacak kolayliklar, kaynak koda dair ic dinamiklerin denetimi gibi teknik konularin yaninda sirket icinde enformasyon paylasimi, akreditasyon ihtiyaclari gibi yonetimsel konularin irdelenmesini oneririm. Bu tip konularin yazilim testi seminerlerinden ziyade boyle bir platformda tartisilmasi daha saglikli ve amacina uygun olacaktir.

Iyi testler!

Test Mühendisliği’ni kariyer edinmeyi düşünenlere yönelik önerilerinizde size katılıyor ve yazınız için teşekkür ediyorum. Sanırım bu mesleği seçecek arkadaşların kesinlikle unutmamaları gereken şey, test mühendisinin görev ve sorumluluklarının sadece kitaplarda anlatılığı gibi “test sürecini yönetmek ve test yapmak” ile sınırlı kalmadığı… Bu durumun hem avantaj hem dezavantajları var:
Sizin de belirttiğiniz gibi bir test mühendisi, “söyleneneni yapmak” ile “mesleğine katkı sağlamak” arasındaki farkı kavrar ve test sürecine, hatta ölçümler ve kalite çalışmalarına, müşteri ilişkileri, sistem mühendisliği ve entegrasyon ile ilgili çalışmalara katkı sağlamaya çalışır, geliştiricilerle her zaman sıkı bir diyalogta bulunursa kısa sürede kendisini projenin A’dan Z’ye tüm gelişim sürecini, problemlerini ve risklerini biliyor, geliştiricileri arkalarından itekliyor veya önlerine geçip yol gösteriyor durumunda bulur. Ancak henüz test mühendislerine “bilir kişi” olarak bakılmamakla birlikte pek çok şirkette geliştiricilerden daha az söz hakkı verilebilmekte, sizin önceki birkaç yazıda da kısmen değindiğiniz üzere onların fikirlerine danışmak bir yana “hadi bunu test et” yaklaşımıyla onlardan olmayacak işler istenebilmekte… İşte bu durumda psikoloji, felsefe gibi bilimler, sakinlik, sabır gibi kişisel özellikler giriyor işin içine :)
Ama her şeye rağmen, eğer bir kişinin yeni test araçlarını kullanma yeteneğinden de önce “hata bulma / hataları tahmin etme” ve bundan (ince bir) zevk alma özelliği varsa kesinlikle bu işi seçmeli bence :) Yazılım, hayatımızın her alanında daha sık kullanıldıkça, biraz sıradışı veya detaylı düşünerek sürüme çıkmaya hazırlanan bir programda birçok hata bulan kişilere daha çok ihtiyacımız olacak çünkü..
Her geçen gün Türkiye’de de testin önemi daha iyi kavranıyor ve olumsuz örnekler azalıyor elbette ama eğer bu mesleğe atılacak arkadaşlar şirketlerinde bir ilk olacaklarsa; onlara bol şans ve modülünde hata bulmanmasının bir düşmanlık değil kaliteli üretime büyük bir katkı olduğunu kabullenmiş bir ekip diliyorum…