Son 10 senedir yazılım projelerinde çalışarak edindiğim deneyim sonucu diyebilirim ki, bir proje ekibinin günlük performansını en çok olumsuz etkileyen faktör, çalışanın kısa süreli aralıklarla bölünmesidir.
Yüksek bir seviyede odaklanma gerektiren diğer işlerde de olduğu gibi, özellikle yazılım geliştirme (kodlama) ve test (doğrulama ve geçerleme) aktiviteleri de yoğun bir konsantrasyon gerektirmektedir.
Her 3-5 dakikada bir çalışması bölünen kişinin gün içindeki performansı aşırı derecede düşmesi de kaçınılmazdır. Bu performans kaybının hem üretkenliği hem çalışan memnuniyetini hem de nihai ürünün kalitesini olumsuz etkilediğini rahatlıkla söyleyebilirim.
Friday, September 28, 2012
Yazılımda Bulunan Hata, Kimin Hatası?
Bir ürünü geliştiren kişi yeterli bilgiye sahip olmayabilir, dikkatsiz davranmış olabilir, önemsememiş olabilir, ..., en nihayetinde üründe bir hataya sebebiyet verilmiş olabilir.
Evet, ürünü geliştiren kişinin bu hatada payı vardı, fakat bulunan hata gerçekten de sadece geliştirene mi aittir?
Nihai bir yazılım ürününde bulunan bir hatayı sadece o uygulama kodunu geliştiren kişiye atfedebilir miyiz?
Hayır !
Çünkü, her ne kadar geliştirme/yazma işini yapan kişinin gözünden bu hata kaçmışsa da, o yazılım kodunu gözden geçirmekle, birim testlerini yapmakla, fonksiyonel testlerini yapmakla, gerekli kaynakları sağlamakla sorumlu kişiler de bu hatayı kaçırmış demektir !
Dolayısıyla, (daha önceden de yazdığım gibi) üründe yapılmış olan hata, sadece ilgili kod parçasını yazan kişinin değil, proje ekibinindir.
Ve eğer proje ekibi, üründe bulunan hatalara bu bakış açısıyla yaklaşırsa, kimseyi rencide etmeden, ekibin motivasyon ve performansını olumsuz etkilemeden süreci yönetmiş olacaktır.
Evet, ürünü geliştiren kişinin bu hatada payı vardı, fakat bulunan hata gerçekten de sadece geliştirene mi aittir?
Nihai bir yazılım ürününde bulunan bir hatayı sadece o uygulama kodunu geliştiren kişiye atfedebilir miyiz?
Hayır !
Çünkü, her ne kadar geliştirme/yazma işini yapan kişinin gözünden bu hata kaçmışsa da, o yazılım kodunu gözden geçirmekle, birim testlerini yapmakla, fonksiyonel testlerini yapmakla, gerekli kaynakları sağlamakla sorumlu kişiler de bu hatayı kaçırmış demektir !
Dolayısıyla, (daha önceden de yazdığım gibi) üründe yapılmış olan hata, sadece ilgili kod parçasını yazan kişinin değil, proje ekibinindir.
Ve eğer proje ekibi, üründe bulunan hatalara bu bakış açısıyla yaklaşırsa, kimseyi rencide etmeden, ekibin motivasyon ve performansını olumsuz etkilemeden süreci yönetmiş olacaktır.
Yazılım Testinde İletişim Ne Kadar Önemli?
Sosyal olma ve kolay iletişim kurabilme bir yazılım test uzmanı için hayati öneme sahiptir; özellikle de müşterili projelerde...
Test uzmanları şirket içinde projenin müşterisi rolünü üstlenirler. Bu rol sebebiyle tam olarak nihai müşterinin istediği ürünün teslim edildiğine ikna olana kadar ürünleri sorgulamak durumundadırlar.
Test uzmanı, geliştirilen projeyi nihai müşteriye kabul ettirecek kişidir. Bu sebeple, kabul testlerinde herhangi bir sorun / aksama olmaması için, şirket içindeki testlerde gereksinimlerin tam olarak karşılandığından ve üründe (bilinen) herhangi bir hata olmadığından emin olmak zorundadır; aksi halde ürünün teslimatı gecikecek ve hem şirket hem de müşteri zarara uğrayacaktır.
Bu sorgulama süreci, yazılım geliştirme ekibi ile sürtüşmelere sebep olabilir; özellikle uygulamada bulunan bir uygunsuzluğun hata olarak değerlendirilip değerlendirilemeyeceği konusunda...
Test uzmanları şirket içinde projenin müşterisi rolünü üstlenirler. Bu rol sebebiyle tam olarak nihai müşterinin istediği ürünün teslim edildiğine ikna olana kadar ürünleri sorgulamak durumundadırlar.
Test uzmanı, geliştirilen projeyi nihai müşteriye kabul ettirecek kişidir. Bu sebeple, kabul testlerinde herhangi bir sorun / aksama olmaması için, şirket içindeki testlerde gereksinimlerin tam olarak karşılandığından ve üründe (bilinen) herhangi bir hata olmadığından emin olmak zorundadır; aksi halde ürünün teslimatı gecikecek ve hem şirket hem de müşteri zarara uğrayacaktır.
Bu sorgulama süreci, yazılım geliştirme ekibi ile sürtüşmelere sebep olabilir; özellikle uygulamada bulunan bir uygunsuzluğun hata olarak değerlendirilip değerlendirilemeyeceği konusunda...
Gerek şirket içerisinde gerekse de müşteri ile olan iletişimde esas önemli olan empati kurabilmektir.
Projelerde yazılım geliştirme ekipleri, bir ürünün analizi, tasarımı, kodlaması, birim testi, dokümantasyonu, hataların giderilmesi gibi pek çok konuda yoğun ve stresli bir şekilde çalışmak durumda kalabilirler; özellikle kısa takvime sahip projelerde...
Böyle stresli durumlarda iletişim kurulan kişilerin bu durumlarını da göz önünde bulundurarak, üzerinde konuşulan konu ne ise, karşı tarafı suçlamadan ve çözüm odaklı bir şekilde müşteri isteğinin karşılanması esastır.
Bu noktada bir test uzmanına düşen görev, bildirdiği uygunsuzluğun içeriği, gerekli veri setleri, uygulama çıktıları, ekran görüntüleri ve müşteri isteğinin ne olduğu, sistemin hangi özelliğini veya özelliklerini etkilediğini anlaşılır bir şekilde yazılım ekibine iletmektir; bildirilen uygunsuzluk ne kadar anlaşılır tanımlanmış ise ilgili geliştirici de uygunsuzluğu o kadar hızlı tespit edip, düzeltecektir.
Uygulamada bulunan hatayı herhangi bir çalışana adreslemek (senin hatan izlenimini vermek) yanlıştır. Gerçekte de, hata bir kişinin değil, proje ekibinindir.
Nihai müşteri tarafında ise test uzmanı ürünü müşteriye kabul ettiren kişidir; şüphesiz ki proje yöneticisi, lider yazılım geliştirme uzmanı, kalite güven uzmanı da kabul sürecinde yer alır, ancak kabule esas teşkil edecek testlerin gerçekleştirilmesi ve başarılı olması test uzmanının sorumluluğundadır.
Peki test uzmanı test dokümanlarını kullanarak bir kabul testini gerçekleştirirken müşteri ile ilişkilerinin kabulde ne gibi bir etkisi vardır?
Aynı şirket içerisindeki ekiple iletişim kurduğu gibi müşteri ile de iletişiminde empati kurabilmelidir. Müşteri, belli bir ücret karşılığında şirketinin/kurumunun işlerinde kullanmak üzere bir yazılım sipariş etmiştir ve verdiği paranın tam karşılığını aldığından emin olmak istemektedir.
Test uzmanı nihai müşteri ile sadece kabul testlerinde değil, sözleşmenin imzalanmasından itibaren analiz, ekran tasarımları, prototiplerin kullanımı, ilerleme toplantıları gibi pek çok proje aktivitesinde yakın bir şekilde çalışma imkanı bulur. Bu süreçte sözleşme, konsept dokümanları, analiz dokümanlarında belirtilenlerden öte müşterinin uygulamayı hangi amaçla kullanacağını, müşteri için nelerin kritik olduğunu, hangi tür iş adımlarını daha sık yaptıklarını, uygulamayı kullanacak nihai kullanıcının deneyim ve bilgi seviyesini mümkün olduğunca irdeleyip, "müşterinin ruhu"nu yakalamaya çalışmalıdır.
Böylece, kendisini müşteri yerine koyup, şirket içindeki testlerde, tabii ki gereksinimlere uygun olarak, fakat gereksinimlerde belirtilmemiş kullanım alışkanlıkları, iş adımlarında sık tekrarlanan ve kritik olan özelliklere daha da önem vererek testlerini hazırlaması ve koşturması önemlidir. Çünkü en nihayetinde bir yazılım ürünü kullanıcı gereksinimlerini bire bir karşılıyor olsa da "müşterinin ruhu"nu yakalayamıyorsa, kabul aşamasında sorunlar yaşanması kaçınılmazdır.
Bu nedenlerle bir test uzmanının empati kurarak, müşterinin ruhuna uygun ürünü teslim edebilmek için, hem proje ekibi hem de müşteri ile iyi, yakın ve çözüm odaklı ilişkiler kurması önemlidir.
Thursday, September 27, 2012
Yazılım Testi ve Kalite Güvence Dergisi (İngilizce)
Uzun zamandır takip ettiğim ve çok da başarılı bulduğum bir dergiyi paylaşıyorum.
Software Test and Quality Assurance (Eski adı Software Test and Performance idi):
http://www.softwaretestpro.com/Publication/p/STPM/2012
Geçmiş yıllara ait sayıları da okumanızı öneririm, zira bazı konseptler çok da hızlı değişmiyor.
Ücretsiz üyelik seçeneği de var.
Software Test and Quality Assurance (Eski adı Software Test and Performance idi):
http://www.softwaretestpro.com/Publication/p/STPM/2012
Geçmiş yıllara ait sayıları da okumanızı öneririm, zira bazı konseptler çok da hızlı değişmiyor.
Ücretsiz üyelik seçeneği de var.
Yazılım Testi Terimler Sözlüğü
Yazılım Testine ait terimlerin (ki yazılım teknolojileri ilerledikçe yeni terimler literatüre giriyor) listesini buraya yazmaktansa iki adet güvenilir (İngilizce) bağlantı paylaşıyorum:
Software Testing Glossary (by ApTest): http://www.aptest.com/glossary.html
ISTQB Glossary of Testing Terms: http://istqb.org/downloads/finish/20/14.html
Software Testing Glossary (by ApTest): http://www.aptest.com/glossary.html
ISTQB Glossary of Testing Terms: http://istqb.org/downloads/finish/20/14.html
Tuesday, July 10, 2012
1012-2004 IEEE Standard for Software Verification & Validation
IEEE'in Yazılım Geçerleme ve Doğrulama Standartı'nın mevcut güncel versiyonu IEEE 1012-2004.
Bunu IEEE'nin sitesinden ücreti karşılığında satın alabilirsiniz (şirketinize aldırabilirsiniz).
http://standards.ieee.org/findstds/standard/1012-2004.html
(Yasal olmayan bir şekilde bazı sitelere de yüklenmiş; kişisel kullanımda sorun olacağını sanmam ama şirketinize bu tür yasal olmayan standartları sokmanızı tavsiye etmem.)
Bunu IEEE'nin sitesinden ücreti karşılığında satın alabilirsiniz (şirketinize aldırabilirsiniz).
http://standards.ieee.org/findstds/standard/1012-2004.html
(Yasal olmayan bir şekilde bazı sitelere de yüklenmiş; kişisel kullanımda sorun olacağını sanmam ama şirketinize bu tür yasal olmayan standartları sokmanızı tavsiye etmem.)
IEEE Standards Errata Page / IEEE Standartları Hata Sayfası
For errata of IEEE standards, check the link periodically:
IEEE Standartlarında tespit edilen hata/eksiklikler için aşağıdaki bağlantıyı kontrol edin:
http://standards.ieee.org/findstds/errata/index.html
IEEE Standartlarında tespit edilen hata/eksiklikler için aşağıdaki bağlantıyı kontrol edin:
http://standards.ieee.org/findstds/errata/index.html
Yazılım Testi - Kendimi Geliştirmem Gerekiyor
Bana e-posta ile danışan arkadaşlara yazdığım cevapları blogumda (bazı yerlerini kırparak) paylaşıyorum.
Diğer test uzmanı ve adaylarına faydası olur umarım.
Soru: "Yazılım test mühendisliği sunumunuzu inceledim fakat benim bu konuda kendimi daha fazla geliştirmem gerekiyor nereden başlamalıyım nasıl bir yol izlemeliyim tavsiyeleriniz nelerdir beni bu konuda biraz daha aydınlatabilir misiniz?"
Cevap: "Konu ile ilgili çok fazla doküman var fakat çoğunluğu ingilizce; eğer
ingilizce biliyorsan işin daha kolay.
Blogumda konu ile ilgili 2 tane yazı var:
http://serdartorun.blogspot.
Onları bi okuyun önce, sonrasında tekrar konuşalım."
Soru: "Size sıkıntımı açık açık belirteyim. ... öğrencisiyim ve bir ... firmasında hem kendimi geliştirmek hemde cep harçlığımı çıkartmak amacıyla çalışıyorum. ... üretilen cihazların testlerini yapıyorum gerek simülatörler ile gerekse yeterli donanımlar ile bu işi yaptım.
Kendi iş sistemimizde bir bug ya da iş açılır. Yazılımcı işe başlar, belirli bir sürede bitirir ve işi bana bırakır bende işin diğer etkileyebilecekleri vs. gibi tüm durumları göz önünde tutarak test ederim.
Ancak artık firma artı bu konuda kendimi dahada geliştirmemi istiyor. Buna ek olarak kendi düşüncem her test için adımları dökümanlayıp detaylarını çıkartma her işin detaylarını rapor halinde tamamlanmış işlerin altına eklemek bunu yapmam bir derece daha iyi olur düşüncesindeyim fakat buna ek olarak yapabileceğim şeyler olabilir düşüncesiyle bir uzman görüşü almak istiyorum.
Benim sizden rica ettiğim Bu sistemimi geliştirmek için bir öneriniz var mı? Bu öneriniz geliştirme ekleme adına olabilir adımları düzenleme adına olabilir her türlü görüşe açığım."
Cevap: "Güzel, zaten belli başlı aktivitleri gerçekleştirmişsin ve daha sistematik, süreçlere dayalı bir iş akışı tanımlamak istiyorsun. Gerçekten güzel.
Şimdi:
Mil-STD-498 isimli eski bir askeri standart vardır. Bu standart yazılım geliştirme sürecini sistematik olarak inceler; ilgili kısımları ekte gönderdim.
Özellikle DID dokümanlarını okumanı tavsiye ederim; diğerlerine de ihtiyaç oldukça bakarsın.
Plan dokümanında testleri nerede, nasıl, neleri kullanarak yapacağını anlatırsın.
Test Description dokümanında adım adım Yapılacak İşlem - Beklenen Sonuç adımlarını anlatırsın.
Test report'ta da testin bitiminde hazırlanıp o testte neler olduğunu anlatılır (fakat bu kadar detaylı bir rapor hazırlaman da gerekmez, 1-2 sayfalık özet bir rapor da işini görür).
DID dokümanlarını okuduğunda pekçok sorunun cevabını bulacaksın. Sonrasında ISTQB'nin dokümanlarını ve CMMI dokümanlarını okumanı tavsiye edeceğim; ama önce DID'ler.
Hata takibi için ne kullanıyorsunuz bilmiyorum. Eğer bir aracınız yoksa Mantis'i (http://www.mantisbt.org/) tavsiye ederim; ücretsizdir, kullanışlıdır, iyidir.
Yaptığın testlerin takibi için bir tane excel dosyası işini görür, orada çok otomasyona geçmene gerek yok bence.
Testin Adı - Başlama Zamanı - Bitiş Zamanı - (Eğer varsa) Bulunan Hatanın Numarası - Testin Sonucu (Geçti - Kaldı gibi) bu bilgiler yeterli olur bence.
Öneriler:
Test edilen yazılımın mutlaka revizyonlanması yapılsın; böylece hangi revizyonda hangi hata çıktı takibi yapılabilir. Bir hata hangi revizyonda çıkmıştı, hangisinde kapandı? önemli bir bilgidir.
Test planlaması -> Test Adımlarının yazılması -> Testlerin yapılması
sırasını her zaman takip etmeni öneririm; çünkü planlama yapmadan doğrudan işe geçersen, tam testi yaptığın sırada şu eksikmiş bu eksikmiş diye bir çok kez kestiye uğrarsın.
Bir test "neyi test ediyor", "önkoşulları neler", "testin sonucunda ne bekleniyor" bilgileri mutlaka olmalı.
Test durumlarında da (yani test adımlarının olduğu kısım) 2 farkllı yol izleyebilirsin:
1) Test adımlarını, o yazılımı hayatında hiç görmemiş birinin bile sadece senin dokümanına bakarak test edebileceği detayda yazmak,
2) Test adımlarını daha genel ve daha kısa tutmak.
1. yolda çok efor harcarsın fakat doğrusu budur.
2. yolda, eğer uygulama sık sık değişiyorsa veya henüz olgunlaşmamışsa, tercih edilir.
Tavsiye şu olur: eğer bir Yazılım Geliştirme Döngüsü kullanmıyorsanız (Spiral, Incremental, Waterfall,...), yazılımın analiz ve tasarım aşamaları olması gerektiği gibi detaylı yapılmıyor demektir. Ve bu durumda yazılımda sürekli olarak arayüz, etiket, fonksiyon değişecek demektir. Eğer böyle bir durum varsa ve adımları çok detaylı yazarsan, her seferinde yüzlerce sayfalık bir dokümanı güncellemek zorunda kalırsın ve test yapacak zamanın olmaz.
Anladığım kadarıyla gömülü sistem cihazların testini yapıyorsun, bu tür sistemlerle ben çok çalışmadım; o yüzden net bir şey söylemem bu konuda.
Konu çok derin, eğer bu verdiğim bilgiler tatmin edici değilse, bunları zaten biliyor / yaptıysan, soru cevap şeklinde takıldığın konulara bakabiliriz."
Yazılım Testi - Entegrasyon Testi
Bana e-posta ile danışan arkadaşlara yazdığım cevapları blogumda (bazı yerlerini kırparak) paylaşıyorum.
Diğer test uzmanı ve adaylarına faydası olur umarım.
Soru: "ben sizin hazirladiginiz slayti internetteki arastimalarim sirasinda buldum. bir sistem gelistiren X kisilik bir grubumuz var. test kismi ile ben ilgileniyorum. entegrasyon testlerinin tam olarak nasil ve hangi toolla yapildigini aciklayan birseyler bulamadim. bu konuda bana yardimci olursaniz cok sevinirim."
Cevap: "Entegrasyon testleri size ne çağrıştırıyor? Araç kısmını boşverin şimdilik. Yöntem olarak neyi çağrıştırıyor? Bir de hangi seviyede test yapıyorsunuz? Birim mi yazılım mı? (Unit / CSCI / System / ...)"
Soru: "hazirladigimiz projenin gerekliligi olarak once unit test ardindan component test sonra integration test ve son olarak sistem testyapacagim. internetten ogrendigim kadariyla integration testleri birbirinden bagimsiz calisan komponentlerin birlikte dogru calisip calismadigini kontrol ediyor. ama acikcasi su anda herhangi birseyi cagristirmiyor :) daha evvel yalnizca unit test yaptim. "
Cevap: "V-cycle'ı biliyorsunuzdur. Her geliştirme seviyesine bir test karşılık geliyor.
Birim testini sonuçta Software Design'a göre yapıyorsunuz.
Birim entegrasyon testini Interface Design maddelerine göre yapıyorsunuz.
Bileşen testini Software Requirements'a göre,
Sistem entegrasyon testini Interface Requirements'a göre (SRS veya SSS içindeki arayüz gereksinimleri) yapıyorsunuz.
Burada amaç nedir?
Kendi başına (gerektiğinde mock-up'la , simülatörle, ... desteklenerek) çalıştığını gördüğümüz bileşenleri, System Integration Verification Plan'da hangi sırada entegre edileceğini belirledikten sonra, entegrasyon sırasına göre bu bileşenleri "gereksinimlerine göre" test etmek.
Örnek: 4 tane bileşen olsun (1-2-3-4). Bunları bottom-up, top-down, big-bang gibi yöntemlerle entegre edebiliriz (ki genelde maliyeti düşürmek için big-bang yaparlar). Önce 1 ile 2, sonra 3 ile 4, sonra 12 - 34'ü entegre edebiliriz.
Ya da, Önce 2-3, sonra 1-23, sonra da 123-4'ü entegre edebiliriz...
Sıra ne olursa olsun, sonuçta bu entegre edilen bileşenler birbirlerinden bir bilgi alacak veya dışarıya bir bilgi vereceklerdir.
Entegrasyon testinde yapılan da bu giden-gelen bilginin doğru aktarılıp aktarılmadığını görmek, ki sistem seviyesi testte hem bu detayda teste zaman olmaz (gerek de olmaz). Bir diğer yararı da entegrasyon sebebiyle ortaya çıkacak hatalar daha erkenden tespit edilebilir..."
Yazılım Testi - İş Değiştirmeli Miyim?
Bana e-posta ile danışan arkadaşlara yazdığım cevapları blogumda (bazı yerlerini kırparak) paylaşıyorum.
Diğer test uzmanı ve adaylarına faydası olur umarım.
Soru: "... bilgisayar mühendisiyim ve mezun olduktan sonra ... 6 ay çalıştım.Ardından başka bir şirkette test uzmanı olarak göreve başladım. hala aynı yerde devam etmekteyim.
... yoğundum ve o kadar çok işe yaradığımı düşünüyordum ki,buraya gelince test uzmanı olarak sanki bana ihtiyaç yokmuş.Fazladan gidermiş gibi hissetmeye başladım kendimi. Aslında karakter olarak test uzmanlığına çok yatkın birisiyim.İşimi iyi yaptığım söyleniyor. Fakat bazen okadar boş oluyorumki.
...
Fakat yazılımcıları beklemekten başka çare yok:(
Acaba iş yerinden ayrılmalı mıyım diye düşünmekteyim.Ama çok sık iş değiştirmek iyi değil diye ne yapacağımı bilemiyorum. ..."
Cevap: Tabii şirketten şirkete göre değişir senin durumun. Bazı şirketlerin süreçleri test aktivitelerini tüm projeye yararlar, böyle olunca boş vaktin hiç kalmaz; bazıları ise daha kesik kesik gider, bir dönem insanlar boş kalabilir.
Ben sorunun sende olduğunu sanmıyorum; kendini kötü hissetmeni gerektirecek bir durum da yok bence.
Eğer şirketin işleri çok değilse, nedenlerden biri bu olabilir.
Şirket teste önem vermiyorsa, sadece son kullanıcı testini yeterli görüyorsa, neden bu da olabilir...
...
Ben sorunun sende olduğunu sanmıyorum; kendini kötü hissetmeni gerektirecek bir durum da yok bence.
Eğer şirketin işleri çok değilse, nedenlerden biri bu olabilir.
Şirket teste önem vermiyorsa, sadece son kullanıcı testini yeterli görüyorsa, neden bu da olabilir...
...
Yani özetle bence sende bir sorun yok. Kaldı ki boşta kaldığı için bunu kendine dert edecek kadar bilinçli bir çalışan her firmanın başına :)
Hangi testleri yapıyorsun orada? Sadece fonksiyonel son kullanıcı testi mi?
Belki diğer test türlerini de uygularsan hem kendini geliştirirsin hem de boş kalmamış olursun: performans (yük ve stres) testi, web servis testi, (belki) birim test, (farklı sistemlere) uyumluluk testi, (standartlara) uygunluk testi, gibi.
Eğer şirkette bu konuda bir süreç yoksa, süreç geliştirme faaliyetlerine de başlayabilirsin; eminim şirketin de oldukça işine yarayacak ve hoşuna gidecektir (tabii şirketin bakış açısı bu yöndeyse :) ).
"Yazılımcıları beklemekten başka çare yok" dediğin için şunu anlıyorum; o şirkette analiz sonrasında tasarım pek yapılmıyor ve sen de test dokümanı yazmak ve test yapmak için beklemek zorunda kalıyorsun; ki aslında tasarımı yapıyor olsalar, sen onlara ihtiyaç duymadan testlerini yazabilirsin.
Eğer şirket agile yöntemle geliştirme yapıyorsa, şu şekilde boşta kalmazsın; sana iterasyonlar halinde release yaparlar, sen de bunları 1-2 haftalık periyotlarla test edersin (yani spiral yöntemdeki gibi).
Sık iş değiştirmek, evet, pek hoşlanılan bir şey değildir. Sanıyorum ki yeni mezunsun.
Fakat yeni başvuracağın yere derdini iyi anlatırsan çok da bir sorun olacağını sanmıyorum. Hani 10 senedir çalışıyor olsaydın ve 1-2 senede bir yer değiştiriyor olsaydın, yeni şirkete verdiğin mesaj şu olacaktı: "1-2 sene içinde sizden de ayrılacağım!".
İş değiştirmek istemenin tek nedeni boşlukta kalmaksa, bence bu boşluğu yukarıda anlattıklarımı yaparak doldurabilirsin.
Hangi testleri yapıyorsun orada? Sadece fonksiyonel son kullanıcı testi mi?
Belki diğer test türlerini de uygularsan hem kendini geliştirirsin hem de boş kalmamış olursun: performans (yük ve stres) testi, web servis testi, (belki) birim test, (farklı sistemlere) uyumluluk testi, (standartlara) uygunluk testi, gibi.
Eğer şirkette bu konuda bir süreç yoksa, süreç geliştirme faaliyetlerine de başlayabilirsin; eminim şirketin de oldukça işine yarayacak ve hoşuna gidecektir (tabii şirketin bakış açısı bu yöndeyse :) ).
"Yazılımcıları beklemekten başka çare yok" dediğin için şunu anlıyorum; o şirkette analiz sonrasında tasarım pek yapılmıyor ve sen de test dokümanı yazmak ve test yapmak için beklemek zorunda kalıyorsun; ki aslında tasarımı yapıyor olsalar, sen onlara ihtiyaç duymadan testlerini yazabilirsin.
Eğer şirket agile yöntemle geliştirme yapıyorsa, şu şekilde boşta kalmazsın; sana iterasyonlar halinde release yaparlar, sen de bunları 1-2 haftalık periyotlarla test edersin (yani spiral yöntemdeki gibi).
Sık iş değiştirmek, evet, pek hoşlanılan bir şey değildir. Sanıyorum ki yeni mezunsun.
Fakat yeni başvuracağın yere derdini iyi anlatırsan çok da bir sorun olacağını sanmıyorum. Hani 10 senedir çalışıyor olsaydın ve 1-2 senede bir yer değiştiriyor olsaydın, yeni şirkete verdiğin mesaj şu olacaktı: "1-2 sene içinde sizden de ayrılacağım!".
İş değiştirmek istemenin tek nedeni boşlukta kalmaksa, bence bu boşluğu yukarıda anlattıklarımı yaparak doldurabilirsin.
Firmalar "geliştir-sat" döngüsüne odaklandığı için genelde süreçleri göz ardı ederler. Özellikle mikro / küçük ölçekli firmaların zaten genelde ya haberi yoktur ya da buna ayıracak kaynakları.
Madem ki müdürün destek oluyor sana, bence bir yol haritası hazırla, SDLC'lere göre nerede ne yapılması gerekiyor ve bu süreçlerin her biri için ne tür test aktiviteleri yapılacak, hangi dokümanlar çıkacak, ... sonra bunu detaylandırırsın:
standartlara uygun doküman şablonları, teknik terimler sözlüğü, test süreci prosedürü (ne zaman kim ne yapacak), testlere input olacak doküman / süreçler hangileri, test sürecinin çıktıları neler, hata takip süreci nasıl olacak,... gibi aslında 100lerce konu var.
Tüm bunları baştan sona yapıp, uyguladığın zaman hem iyi bir test developer hem de test manager olabilirsin.
Sana yardımı dokunacak keywordler:
CMMI, TMMI, ISO, IEEE, ISTQB, http://www.sqaforums.com,
http://www.
Madem ki müdürün destek oluyor sana, bence bir yol haritası hazırla, SDLC'lere göre nerede ne yapılması gerekiyor ve bu süreçlerin her biri için ne tür test aktiviteleri yapılacak, hangi dokümanlar çıkacak, ... sonra bunu detaylandırırsın:
standartlara uygun doküman şablonları, teknik terimler sözlüğü, test süreci prosedürü (ne zaman kim ne yapacak), testlere input olacak doküman / süreçler hangileri, test sürecinin çıktıları neler, hata takip süreci nasıl olacak,... gibi aslında 100lerce konu var.
Tüm bunları baştan sona yapıp, uyguladığın zaman hem iyi bir test developer hem de test manager olabilirsin.
Sana yardımı dokunacak keywordler:
CMMI, TMMI, ISO, IEEE, ISTQB, http://www.sqaforums.com,
http://www.
Thursday, April 19, 2012
Yazılım Sektörü Açısından İki Temel Sorun
Ülkede sorun çok; sorunun çok olduğu yerde aslında iş fırsatları da çok olur. Tabii, "fırsat temelli girişimcilik" anlayışı varsa...
Sorunlardan ilki standartlarımız yok.
Kamu web sitelerinin her biri diğerinden farklı; içeriği, tasarımı, çalışma hızı,... hepsi farklı.
Hatta bir kurumun kendi il ve ilçe müdürlüklerinin web siteleri bile birbirinden farklı.
Semboloji standartı yok; TSE'de de bulamadım.
Bu konuda talep aslında özel sektörden gelmeli. Kamu politikalarını şekillendiren üç etmenden birisi "baskı grupları"dır ve özel sektör de bu baskı grubunun içinde yer alır. Eğer firmalar bir komisyon oluşturup (örneğin TÜSİAD veya TOBB içinde) devleti en erken zamanda (kendi sektörleri ile ilgili konularda) standart belirlemeye teşvik ederse, bu hem ürünler arasındaki uyumsuzluğu ciddi derecede azaltır, hem gerek firmaların gerekse de devletin maliyetlerini azaltır, hem de sektöre yeni giren firmaların kalitelerini artırır. İkincil derecede faydaları üzerine bir miktar düşünüldüğünde konunun önemi ortaya çıkar.
(Uluslararası standartlara uygunluk tabii ki önemlidir. Fakat şu da unutulmamalı ki, bazı standartlar her ne kadar "uluslararası" diye anılsa da, aslında standartı ortaya çıkaran ülkenin ekonomik gücü ile orantılı olarak kendi standartının küresel ölçekte geçerli bir standart haline gelmesi için gerekli baskıları yapmaktadır. Konu ile ilgili olarak TCP/IP'nin neden ve nasıl bir internet standartı haline geldiğini araştırabilirsiniz.)
İkinci ve daha da büyük olan sorun ise "firmalar arası işbirliği" eksikliği.
Kamu-Üniversite-Özel Sektör işbirlikleri üzerine pekçok makale ve kitap var. Firmalar arasındaki işbirlikler ile ilgili literatür de oldukça geniş (kümeleşme, iş ağları, rekabet öncesi işbirlikleri)... Hatta devletin bu konuda teşvikleri bile var (bakınız KOSGEB).
Fakat her firma bir diğerini rakip olarak (hatta rakip tanımı az bile kalıyor) görme eğiliminde. Evet, kapitalist ekonominin dinamikleri ve inovasyonun yarattığı ekstra baskı yüzünden firmalar hayatta kalmak için diğerleri ile sürekli rekabet halindeler ve bu gayet de doğal bir durum.
Fakat yine aynı doğallıkla, yerli firmaların sektörü büyütmek, yabancı firmaların monopolcü baskılarına direnmek ve bunu bertaraf etmek, özümseme ve inovasyon kapasitelerini artırmak, ihracatlarını artırmak, ... için işbirliklerine şiddetle ihtiyaçları vardır.
Teknoloji Geliştirme Bölgeleri her ne kadar firmaları (biraz zoraki bir şekilde) bir araya getirse de, bu bir arada bulunma yeterli derecede kümeleşmeye ve iş ağları kurmaya dönüşmüyor.
Sorunlardan ilki standartlarımız yok.
Kamu web sitelerinin her biri diğerinden farklı; içeriği, tasarımı, çalışma hızı,... hepsi farklı.
Hatta bir kurumun kendi il ve ilçe müdürlüklerinin web siteleri bile birbirinden farklı.
Semboloji standartı yok; TSE'de de bulamadım.
Bu konuda talep aslında özel sektörden gelmeli. Kamu politikalarını şekillendiren üç etmenden birisi "baskı grupları"dır ve özel sektör de bu baskı grubunun içinde yer alır. Eğer firmalar bir komisyon oluşturup (örneğin TÜSİAD veya TOBB içinde) devleti en erken zamanda (kendi sektörleri ile ilgili konularda) standart belirlemeye teşvik ederse, bu hem ürünler arasındaki uyumsuzluğu ciddi derecede azaltır, hem gerek firmaların gerekse de devletin maliyetlerini azaltır, hem de sektöre yeni giren firmaların kalitelerini artırır. İkincil derecede faydaları üzerine bir miktar düşünüldüğünde konunun önemi ortaya çıkar.
(Uluslararası standartlara uygunluk tabii ki önemlidir. Fakat şu da unutulmamalı ki, bazı standartlar her ne kadar "uluslararası" diye anılsa da, aslında standartı ortaya çıkaran ülkenin ekonomik gücü ile orantılı olarak kendi standartının küresel ölçekte geçerli bir standart haline gelmesi için gerekli baskıları yapmaktadır. Konu ile ilgili olarak TCP/IP'nin neden ve nasıl bir internet standartı haline geldiğini araştırabilirsiniz.)
İkinci ve daha da büyük olan sorun ise "firmalar arası işbirliği" eksikliği.
Kamu-Üniversite-Özel Sektör işbirlikleri üzerine pekçok makale ve kitap var. Firmalar arasındaki işbirlikler ile ilgili literatür de oldukça geniş (kümeleşme, iş ağları, rekabet öncesi işbirlikleri)... Hatta devletin bu konuda teşvikleri bile var (bakınız KOSGEB).
Fakat her firma bir diğerini rakip olarak (hatta rakip tanımı az bile kalıyor) görme eğiliminde. Evet, kapitalist ekonominin dinamikleri ve inovasyonun yarattığı ekstra baskı yüzünden firmalar hayatta kalmak için diğerleri ile sürekli rekabet halindeler ve bu gayet de doğal bir durum.
Fakat yine aynı doğallıkla, yerli firmaların sektörü büyütmek, yabancı firmaların monopolcü baskılarına direnmek ve bunu bertaraf etmek, özümseme ve inovasyon kapasitelerini artırmak, ihracatlarını artırmak, ... için işbirliklerine şiddetle ihtiyaçları vardır.
Teknoloji Geliştirme Bölgeleri her ne kadar firmaları (biraz zoraki bir şekilde) bir araya getirse de, bu bir arada bulunma yeterli derecede kümeleşmeye ve iş ağları kurmaya dönüşmüyor.
Subscribe to:
Posts (Atom)