Yazılımcılarla kuracağınız ilişkinin baslangıç noktası, çoğu zaman bulduğunuz ve rapor ettiğiniz hata olacaktır.
Bildiğiniz 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,
- diplomasi.
Güzel bir kod gördüğü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.Pettichord
skip to main |
skip to sidebar
Yazılım Testi
-
Anasayfa
Yazılım Testi Nedir?
Yazılım Test Çeşitleri
Yazılım Testi Niçin Yapılır?
Test dökümanları nelerdir?
Yazılım Test Teknikleri
Test Otomasyon Aracı Nedir?
Makaleler
-
Günün Sorulari ve Cevaplari
Neden yazılımlar hata içerir?
Agile ile Yazılım Testi
İzlenebilirlik Matriksi Nedir? (Traceability Matrix)
Kalite Kontrol Analistlerinin Hakları
Yazılımcılar ile Uyumlu Şekilde Çalışmanın Kilit Noktaları
Türkiye’de yazılım testinin yeri ve önemi
İyi bir yazılım testinin kriterleri nelerdir?
Uluslararası geçerliliği olan test sertifikaları nelerdir?
Fikirlerinizi Paylaşın
Takip Edin
ISTQB @ Dice.com
Takip edenler
5 yorum:
Benim şöyle bir tecrübem olmuştu; Görev verilen arkadaşlar bir türlü kendi işlerine konsantre olamıyorlardı zira sürekli farklı talepler dolayısıyla işleri dağılıyordu.
Genelde ise kendilerini yeterince ifade edemiyorlardı. Tam olarak işi ne zaman yapabilecekleri yada nasıl yapabilecekleri konusunda fikir yada plan sahibi değillerdi. Proje yönetimi yada zaman planlaması eksikliği ve sahip oldukları bilginin kimi zaman yetersizliği ve pratik çözümler oluşturamamaları üzerlerinde baskı oluşturuyordu.
Sadece yazılımcı değil ama genelde teknik personelin içine kapanık olduğunu düşünmek yanlış olmaz. Dolayısıyla mesela bir satışcıdan tamamen farklı bir profildir. Sabırlı ve anlayışlı olmak şarttır. Baskı kurmak yada diktacı olmaktan ziyade işleri ve istekleri daha rafine ve düzenli hale getirmek faydalı olabilir!...
Bir bilişim profesyoneli olarak, yazılım üzerinde bulunan hatanın "insan ilişkileri" içinde "tartışılmasını" gayet anlamsız buluyorum. Öncelikle, yazılım hataları tamamen bilimsel olarak ele alınması gereken şeylerdir. Yani bir satışçının veya pazarlamacının işini yaparken yaptığı bir hata gibi değerlendirilemez, daha çok bir matematik problemi çözülürken yapılan bir hataya benzerler. Bu yüzden hata takibinin ve iletişiminin yazılı olarak yapılması problem içindeki insan unsurunu ortadan kaldırır. Bu yüzden de hata takip yazılımları kullanırız.
Ayrıca burada dikkate değer olan durum, bilişim uzmanı olmayanların yazılım hatalarını "üretici hatası" olarak değerlendirerek konunun tamamen kişiselleştirilmesine neden olması. Kişiselleştirilen hatalar, psikolojik sorunlara neden olduğu için bu şekilde "diplomatik davranın" tipinde anlamsız önerilere neden oluyorlar.
"Mukemmel Bir Dunya"
Onur Bey'in dediklerine 100'de 100 katiliyorum..!
America'daki sirketlerin bilgi islem dalinda herhangi bir departmanin olmasini bile cok gereksiz buluyorum.... Bilgi islemle ilgili her turlu isin, "insan iliskisi" gerektirmeyen, yazili iletisim yoluyla yapildigini varsayarsak, America'da bir calisana, saatine $45-120 arasi para verip bir ofisde oturtup kira vereceklerine, Rusya'da veya Hindistan'da saatine $10-15 vererek, sadece bir requirements (sartlar/gerekler) dokumani "e-mail" yolluyla yollanip hem dizayn, hem yazilimin tamami (test edilmis durumda) gene e-mail yoluyla geri gelmeli... Sonucda hepimiz biliyororuz ki bir Mukemmel bir dunya'da yasiyoruz ve insanlar (yazilimcilar, testciler, PMler, vs...):
1. Cok detayli, hicbir "acabaya" yol acmayan e-mailler atiyorlar birbirlerine...
2. Hata Takip Yazilimlarini tamamen kullanilmasi gerektigi gibi kullaniyorlar.
(Submit > Assign > Open > Resolved > Validate (Reject) > Close)
Calistigim butun projelerde, hicbir bilgi islem "profesyoneline" bu hatanin statusu nedir, kapandi mi, niye daha test edilmedi gibi sorular sormadim bugune kadar...
*************************************
Eger aranizda boyle "Mukemmel" bir dunya'da yasayan ve boyle "Mukemmel" projelerde calisaniniz varsa, bilmenizi isterim ki cok ama cok kiskandim sizleri.....
Not:
1. Requirements yani musterinin istekleri cogu zaman mukemmel birsekilde dokumana yazilmaz. Bu hem yazilimci hem testci tarafindan bilindiginden, testciler bulduklari bazi hatalari yazilimciyle informally konusma ihtiyaci duyarlar. Cunku sonucda yazilimcida testcide ayni dokumani okuyup, anladiklarini yazarlar veya test ederler... ama bazen insanlarin okuduklarin anladiklari farkli hem de cok farkli olabilir. Ornek, testci karsinizda drop-down beklerken, radio buttons goruyor... test senaryosu drop-down icin yazildigindan Fail olmasi gerek ama onun yerine yazilimciyla informallay konusup, neden drop-down yerine radio button kullandigini sormasi ve eger cevap mantikli ise gereginde test scenariosunu degistirmesi daha mantikli....
Eger bu verdigim ornek sadece e-mail yoluyla yapilirsa, cok buyuk bir ihtimalle yazilim ve test gruplari arasinda terslesmeler meydana gelir...
Bu olayi AT&T'de yasadik, Accenture icin calistigim 2 projede de yasadik... Dersimi ogrenip "insan iliskilerini" on plana cikarttigim diger projelerde ise hic ama hic yasamadik...
Onur Bey'in dedigi gercekten de mantik aslinda ama Mukemmel Bir Dunya'da....
Öncelikle ben mükemmel bir dünyadan bahsetmiyorum. Şu an içinde yaşadığımız gerçeklikten bahsediyorum.
Yazılı iletişimin eksik kaldığı durumların olması çok normal. Ancak ben tamamen yazılı bir süreçten bahsetmiyorum. Süreçlerin yazılı olarak sürdürülmesinden bahsediyorum. Süreçler sırasında sözlü iletişimin olmaması gibi bir durum söz konusu olamaz zaten. Sonuçta ne yazılım geliştiriciler, ne proje yöneticileri ne de yazılım testçileri robot değil.
Problemlere yol açan durumların en aza indirilmesi için yazılı süreçler çok önemli.
Ancak yazıda bahsedilen, "diplomatik olunması, yazılımcının duygularına dikkat edilmesi" gibi önerilerin sebebi, yazılım hataların değerlendirilmesi ve aktarılmasında yapılan hataları gizlemek amaçlı. Yani yazılım hatalarının, yazılım geliştiricinin yetersizliğinden kaynaklandığını düşünmek veya o şekilde aktarmak bu tür problemlere neden oluyor. Çok az miktarda durum dışında da yazılım hataları yazılımcının yetenekleri ile ilgili değildir.
Yorum Gönder