Tuesday, April 2, 2019

High Achievement Tips from The Governor

"The most important thing is that you have a vision !"
Let's learn the rest from The Governor.


Thursday, March 28, 2019

En Çok Vakit Geçirdiğiniz 5 Kişinin Ortalamasısınızdır

Başlıktaki gibi bir teoriyle karşılaştım geçenlerde Youtube'da. Üzerinde düşününce gerçekten de hak verdim.

Eğer vaktinin tamamını kahvehanede, iddia bayisinde geçiren insanlarla vakit geçiriyorsanız, sizden bir tıp doktoru veya başarılı bir iş insanı olmanız beklenmez.

Benzer şekilde eğer web girişimleri, IoT, yapay zeka, ... alanlarında okuyan, çalışan, üretim yapan insanlarla vakit geçirdiğinizde de karşılıklı etkileşim sonucu siz de o alanlara ilgi duymaya başlarsınız.

Bu sebepten dolayı aile bireyleri hariç en çok vakit geçirdiğiniz 5 kişiyi çok iyi seçin; sonuçta bu seçim geleceğinizi şekillendirecek.

Şurada bir de yazı var, okursanız.

Sunday, March 24, 2019

Özet Olarak Yazılım Testi Nedir




Yazılım sistemlerinin hedeflenen kullanım ortamında tam, doğru ve tutarlı olarak müşteri istek ve beklentilerine uygun çalıştığının kontrolüdür.

İhtiyacınız Olan Tek Kişisel Gelişim Eğitimi Burada

Benim görüşüme göre, Brian Tracy gelmiş geçmiş en iyi kişisel gelişim uzmanı. Pek çok kitabını okudum, eğitim videolarını izledim fakat aşağıdaki video benim en çok faydalandığım konuşmasını içeriyor. Kendinizi geliştirme ve (eğer ilgileniyorsanız) zengin olma tekniklerini tek bir konuşmaya toplamış.

Eğer bu konuşmanın size faydası olursa (ki eğer uygularsanız kesinlikle faydasını göreceksiniz) o zaman diğer konuşmalarını da dinler, kitaplarını da okursunuz; ama bence gerek yok, bu konuşma tek başına yeterli.

Videoda şu başlıklarda teknikler anlatılıyor (konuşma İngilizce, İngilizce bilmeyenler altyazıyı açıp, otomatik olarak Türkçe'ye çeviri seçeneğini seçerek izleyebilir):

1.) Büyük Hayaller Kurun 10:43
2.) Sevdiğiniz İşlerle Uğraşın 12:34
3.) Kendinizi Mükemmeliğe Adayın 14:06
4.) Size Özel Olan Yetenekler ve Yetkinlikler Geliştirin 17:31
5.) Kendinizi, kendinizin-patronu olarak görün 18:48
6.) Gittiğiniz istikamet belli olsun 20:41
7.) Başarısızlık Olasılığını Düşünmeyi Reddedin 24:41
8.) Kendinizi Yaşamboyu Öğrenmeye Adayın 27:17
9.) İşkolik Bir Zihniyet Geliştirin 31:36
10.) Doğru İnsanların Çevresinde Olun 34:45
11.) Zirveden Zirveye Tırmanmaya Hazır Olun 36:22
12.) Direnç Geliştirin ve Düşünce Geri Kalkın 37:22
13.) Sarsılmaz Bir İyimser Olun 41:32
14.) Cesaret ve Israrcılık Konularında Gelişin 42:43
15.) Özdisiplin Kalitenizi Artırın 44:00



Saturday, March 23, 2019

The Best and Only Self-Development Training You'll Ever Need

Brian Tracy, from my point view, is the best of best self-development mentor I have ever listened to.

Among his dozens of books and trainings and conferences, the below video is the  most concise and brief one that includes techniques for self-development and (if you are interested) for becoming rich.

It is always fun and informative listening to Brian Tracy, and I hope you'll learn many many techniques after watching this video. Be aware; just watching has no effect, you should apply these techniques !

This video includes information mainly on these topics:

1.) Dream Big Dreams 10:43
2.) Do what you love to do 12:34
3.) Commit to Excellence 14:06
4.) Develop Your Unique Talents and Abilities 17:31
5.) See yourself as self-employed 18:48
6.) Develop a clear sense of direction 20:41
7.) Refuse to consider the possibility of failure 24:41
8.) Dedicate yourself to lifelong learning 27:17
9.) Develop a workaholic mentality 31:36
10.) Get around the right people 34:45
11.) Be prepared to climb from peak to peak 36:22
12.) Develop resilience and bounce back 37:22
13.) Become an unshakable optimist 41:32
14.) Develop the qualities of courage and persistence 42:43
15.) Quality of self-discipline 44:00


Friday, March 22, 2019

Ürünü En Hızlı Şekilde Nasıl Test Edebilirim?

Projelerin doğası gereği bazen regresyon testi kapsamında bazen sistemin canlıya alınmasında bazen de müşteriye yapılacak sunum öncesinde, ürünün beklendiği gibi çalıştığının doğrulamasının yapılması gerekmektedir.

Tabii ki en güvenilir yöntem %100 kapsama oranına sahip testlere sahip olmak ve test otomasyonu kullanarak tüm testleri baştan sona çalıştırmaktır. Fakat çoğu zaman bu rüya-senaryoyu gerçekleştirme imkanı olmaz. 

Böyle bir ihtiyaç varsa şu kararın verilmesi gerekir; ürünün hangi yetenekleri / isterleri daha kritiktir?
Tüm testleri koşturamayacağımıza göre risk temelli test yaklaşımı ile hangi yeteneklere odaklanmamız gerektiğini belirlememiz gerekiyor.

Bankacılık uygulamalarında bu yetenekler farklıyken, stok yönetim yazılımlarda çok daha başka yetenekler önemlidir.

En kritik yetenekler belirlendikten sonra, kritiklik derecesi yüksekten aşağıya doğru sıralanır ve en üstteki yeteneğe en çok zaman ayrılırken, listenin altına doğru inildikçe test süresi de kısaltılır.
Örneğin toplam 10 yetenek varsa ve test için de toplam 20 saat süre ayrılmışsa, 1. yetenek için 3 saat, 2. için 2,5 saat, 3. için 2 saat, ..., 10. için 20 dakika, şeklinde bir planlama yapılabilir.

Burada önemli olan bir diğer konu da testi yapacak kişinin o alandaki bilgisidir. Test altındaki yetenekle ilgili 10 yıl deneyimi olan bir test mühendisinin, 3 yıl deneyimi olan birine göre çok daha etkin test yapacağı da unutulmamalıdır. Test yöneticisinin bu durumu da göze alması önemlidir.

Thursday, March 21, 2019

STANAG Doğrulama

Askeri (çoğunlukla NATO) projelerde sözleşmelerde tanımlı STANAG'lar kullanılarak ürünlerin geliştirilmesi ve doğrulanması gerekmektedir.

STANAG, Standardization Aggrement'in kısaltmasıdır ve tüm listeye buradan ulaşabilirsiniz; fakat çoğuna doğrudan erişim yoktur.

STANAG kullanılarak ürünleri geliştirmenin ve test etmenin güzel tarafı; istenen her yeteneğin detaylı olarak tanımlanmış olması, muğlaklıkların olmamasıdır. 

Zor tarafı ise, kimi STANAG 300-400 sayfa olabilmekte kimi zaman da diğer standartlara referanslar vererek binlerce sayfaya çıkabilmektedir. (Her zaman olduğu gibi) Bu zorluk aynı zamanda bir de fırsat yaratmaktadır. Sektörde bu kadar kalın dokümanları okumaya ve öğrenmeye hevesli çok kimse olmadığı için (bakınız İş Eğitinin Önemi) herhangi bir STANAG ailesini iyi öğrenmeniz durumunda hem yurtiçi savunma sanayinde hem de NATO ve diğer askeri oluşumlara yönelik yazılım yapan yurtdışı firmalarda kolaylıkla iş bulabilirsiniz. Fakat tekrar söyleyeyim; bu dokümanlara hâkim olmak kolay değildir.

STANAG kullanarak doğrulama yaparken dikkat edilmesi gereken konu, hazırlanacak test senaryolarının birebir standarttaki maddelerle eşleştirilmesidir; bir senaryo birden çok maddeyi içerebilir. Ve tabii her zaman olduğu gibi, izlenebilirlik matrisini de doğru ve detaylı hazırlamak önemlidir.

Wednesday, March 20, 2019

İş Etiğinin Önemi

Kabaca bir tarih vermek gerekirse 1990 yılı sonrası doğumlular ile öncesi doğumlular arasında iş bilinci, şirkete bağlılık, otoriteye saygı, çalışma disiplini gibi konularda ciddi farklar var.

Daha özgür, daha çok kaynağa erişerek, istediklerini çok zorlanmadan elde eden, "Google" nesli insanların yoğun araştırma yapmaları gereken, kısa aralıklarla yeni bilgiler edinip bunları ürüne dönüştürmeleri gereken yazılım mühendisliği alanında fazlasıyla zorlandıklarına şahit oluyorum.
Zorlandıkları zaman da genelde iş değiştirme yoluna gidiyorlar, .çünkü mevcut baskıdan-zorlamadan kaçmanın en hızlı yolu iş değiştirmek.

'90 öncesi doğumlularda da bu tarz çalışanlar var ama oran olarak çok daha az. '80 öncesi doğumlular ise çok daha işlerine bağlı, zorluktan kaçmayan çalışanlar oluyor. Gözlemlerim bu yönde.

Burada tabii, yaşın ilerlemesi ile birlikte gelen sorumluluk algısının da artıyor olmasının etkisi vardır. Ancak bu sadece benim gözlemim değil, sektördeki pek çok şirkette çalışan deneyimli personelin ortak görüşü.

Bu duruma bir de sürekli olarak yurtdışına kaptırdığımız iyi yetişmiş ve deneyimli mühendisleri eklediğimizde (sivil ve askeri) yazılım dünyasının gitgide rekabet şansını yitirdiğini görmek zor olmuyor.

Monday, March 18, 2019

Genel Toplantı Kuralları

Proje içi toplantılar bir tarafa, müşterilerin / proje paydaşlarının katıldığı toplantılarda, genel görgü kuralları haricinde dikkat edilmesi gereken birkaç konu var.

  1. Proje ekibi ile karara bağlanmamış, özellikle proje yöneticisinin bilgisi dahilinde olmayan hiçbir konuda müşteri temsilcisine bir teminatta bulunmayın. "Uygulamaya bu özelliği ekleyebiliriz", "Bu özellik basit, herhangi bir eforu / maliyeti yok", ... tarzında söylemlerden özellikle sakınmak gerekir.
  2. Özellikle yabancı (Türkçe bilmeyen) müşteri temsilcileri yanında onların anlamadığı bir dilde konuşmayın. Çünkü toplantılar konuları görüşmek, sorulara cevap bulmak ve karara bağlanmak için yapılıyor. Bu kişilerin anlamadığı bir dilde etraflarında bir şeylerin konuşulması, en başta nezaket kurallarına aykırı.
  3. Yabancı diliniz iyi değilse, çok söz almamak en iyisidir. Mecbur kaldıysanız; heyecan yapmadan, kısa ve net olarak söyleyeceğiniz şeyi söyleyin ve durun :)
  4. Mutlaka ve mutlaka toplantıda konuşulacak konulara (toplantının ajandasına) hazırlanın, gerekli tüm belgeleri hazırda tutun, ağ bağlantısı / çalışır ürün gerekiyorsa bunları hazırlayın.
  5. Ve lütfen toplantı süresince cep telefonunuz ile oynamayın.

Sunday, March 17, 2019

Başlamış bir Projeye Atanma Durumu

Bir test mühendisinin projenin sözleşme aşamasında projeye dahil olması en ideal durumdur. Çünkü, henüz sözleşme aşamasında gereksinimleri inceleyebilecek, gözden geçirip yorum verebilecektir. Böylece projenin sonraki aşamalarında ortaya çıkabilecek eksiklikleri çok daha önceden tespit edebilecektir.

Ancak kimi zaman, projenin ortasından projeye dahil olmak durumunda kaldığımız çok oluyor. Gereksinimlere / ürüne / sürece hızlı bir şekilde hâkim olunabilmesi için gerekli adımları aşağıda listeledim. Bu neden önemli? Çünkü projenin kabul aşaması yaklaştığında, daha henüz sözleşmeyi / gereksinimleri bile okumamış iseniz, (muhtemelen) bir başkasının hazırladığı test senaryolarının geçerliliğinden, tamlığından, doğruluğundan asla emin olamayacaksınız demektir. "Gereksinim İzlenebilirlik Tablosu'na bakarım, her gereksinim en az bir teste atanmışsa, bence testler tamdır, doğrudur" diyemezsiniz. Evet, bu gereklidir ama yeterli şart değildir. Belki testler gereksinimlerde bahsedilen durumları karşılamıyordur? Bu riski almaya gerek yok.

  1. İlk olarak mutlaka sözleşme okuyun. En kapsamlı sözleşme bile 50 sayfayı geçmez. Bir günde okur, 2-3 günde tamamına hâkim olursunuz.
  2. Sözleşmede belirtilen her maddenin (ister yönetimsel ister teknik maddeler olsun) bir proje çıktısı ile karşılandığından emin olun. Örneğin, bir Test ve Değerlendirme Ana Planı ve bir de Yazılım Test Planı istenmişse, sizden önce bunların hazırlanmış olduğundan emin olun. Aylık / haftalık proje ilerlerme raporları isteniyorsa, bunların formatının, içeriklerinin belirlendiğinden emin olun; yoksa hazırlayın.
  3. Sözleşme maddeleri ile Sistem Gereksinimleri arasında izlenebilirlik kurulduğundan, her bir sözleşme maddesinde belirtilen isterin, sistem gereksinim(ler)i tarafından gerçekten karşılandığından emin olun; yoksa sonradan çok sorun çıkacaktır.
  4. Geri kalan dokümantasyon için V döngüsünü uygulayın.
  5. Ürüne en hızlı şekilde adapte olmanın yolu:
    1. Hazır test dokümanları ile sistemi test etmek,
    2. Hazır kullanım dokümanı ile sistemi kullanmaktır.
    3. Ayrıca, (proje ekibine, direktörlere, müşteriye,...) arada bir ürünün tanıtımını yapmak da çok faydalı olacaktır.
  6. Asla varsayım yapmayın: "Nasıl olsa benden öncekiler bunları yapmıştır, dokümanları hazır, gözden geçirme de yapılmış, demek ki bunlar doğrudur" diye düşünmeyin !!!
  7. Kim hazırlamış olursa olsun, kime atanmış olursa olsun, sizin işinizi etkileyen konularda kimseye güvenmeyin. Çünkü onlar da projeden ayrılıp gittiklerinde, aslında bu işlerin kısmen veya tamamen eksik olduğunu görebilirsiniz. Bu durumda da o işleri kim yapacak? :) Evet, bildiniz; siz yapacaksınız.

Monday, March 11, 2019

Kabul Testleri Öncesi Oryantasyon

Projelerin kullanıma alınmadan önceki son test aşaması olan Kabul Testleri'nden önce yapılması gereken ama genelde vakit ayrılmayan önemli bir konu olan Oryantasyon'dan bahsedeceğim.

Test dokümanları genelde oldukça kapsamlı ve aşırı dikkat verilmediği sürece kolaylıkla içinde kaybolabileceğiniz belgelerdir.

Oryantasyonun amacı, testin ilerleyişinin nasıl olacağı, hangi testte hangi yeteneklerin nasıl test edildiği, hiçbir gereksinimin gözden kaçırılmadığı, test sırasında verinin hangi kaynaktan nasıl girileceği, test çıktılarının nasıl toplanacağı ve saklanacağı, testte ortaya çıkan hataların ve isteklerin nasıl yönetileceği konularında test katılımcılarına detaylı bilgi vermektedir.

Bu yüzden, her ne kadar testten önce müşteri test belgelerini gözden geçirmiş olsa bile (ki çoğu zaman detaylı bir gözden geçirme de yap(a)maz müşteri), testin katılımcılarına (gerekirse 1-2 gün boyunca) oryantasyonun verilmesi, hem müşterinin test sürecine olan güveninin artırılmasına, hem test faaliyetine daha çok katkı sağlamasına, hem de ürünün nihai ortamdaki kullanımı sırasında ortaya çıkabilecek hataların çok daha erken farkedilmesine imkan sağlayacaktır.

Thursday, March 7, 2019

Kullanıcı Tanıma Anketi (Sistem Analizi)

Geliştirilmesi planlanan yazılım sistemlerinin amacına uygun, yüksek performanslı, etkinliği yüksek ve müşteri beklentilerinin ötesine geçmesini sağlamanın en kolay yolu detaylı bir sistem analizinin yapılmasıdır.

Sistem Altsistem Tanımları dokümanının Fonksiyonel Gereksinimler kısmında sisteminin "ne yapması" gerektiği belirtilirken "Sistem Karakteristikleri" başlıklarında da yapacağı işi "nasıl yapması" gerektiği belirtilir.

Pek çok projede "Sistem Karakteristikleri" başlıkları bütçe yetersizliği, zaman darlığı veya yeterli uzmanlık olmaması sebepleri ile U/D, N/A, DSB gibi kısaltmalar konularak boş bırakılır.

Sistem kullanıma alındıktan sonra da kullanılabilirlik, erişebilirlik, performans, idame edilebilirlik, gibi konularda ardı ardına sorunlar yaşanmaya başlanır.

Standartlara uygun proje geliştiren şirketler çoğunlukla (kısmen de olsa) "Sistem Karakteristikleri"ni belirlemeye çalışmaktadır. Ancak daha düşük bütçeyle iş yapan şirketlerin bu tarz belgeler oluşturma imkanı olmayabilir.

Bu sebeple, bu tarz şirketlerin kullanımı için, son kullanıcıları tanımaya yönelik soruları aşağıda listeledim. Bu sorulara ek sorular da eklenebilir. Sorulara verilecek cevaplara uygun olarak geliştirilecek yazılım sistemlerinin çok daha az hata içeren ve yüksek müşteri memnuniyeti içeren sistemler haline geleceğine emin olabilirsiniz.

Kullanıcı Beklentileri: 

  • Kullanıcıların sistemden beklentileri nelerdir?
  • Mevcut durumda ne tip işlerde ne tip maliyetler / zararlar oluyor?
  • Kullanıcıların bilgisayar okuryazarlığı hangi seviyededir?
  • Kullanıcılar içinde bedensel / zihinsel engeli olanlar var mı? Ne tür engelleri var?
  • Sistem tek bir yerleşke içinde mi kullanılacak yoksa geniş bir alanda mı?

Kullanıcıları Tanıma:

  • Toplam kaç kullanıcı olacak? Önümüzdeki 5 yılda kullanıcı sayısında tahminen kaç kişilik bir artış olur?
  • Hangi rollerde kullanıcılar olacak? Yönetici, sistem yöneticisi, veri giriş, raporlama / sunum, …
  • Rollere göre kullanıcı sayıları nedir?
  • Rollere göre kullanıcılar hangi gün ve saatlerde sistemi kullanacaklar?
  • Rollere göre hangi kullanıcı sistemi ne kadar süre kullanacak?
  • Rollere göre kullanıcıların en stresli / yoğun / yorucu iş akış(lar)ı nelerdir?
  • Rollere göre kullanıcıların çalışma ortamı kısıtları var mı? Sahada kullanım gibi.
  • Rollere göre kullanıcı için en kritik / beklemeye tahammül edemeyeceği iş akış(lar)ı nelerdir?
  • Kullanıcıların uygulama üzerinden ve/veya dosya sistemi / veritabanı üzerinden girecekleri veri tipleri nelerdir?
  • Kullanıcıların girecekleri veri dosyalarının adet ve/veya boyut sınırı var mıdır?
  • Kullanıcıların sisteme toplu halde girmeleri gereken veriler ve/veya başka bir sistemden aktarılması gereken veriler var mı?
  • İşin zorluklarını ve olası dar boğazlarını anlamak açısından bir müddet çalışma ortamında kullanıcılar ile birlikte vakit geçirmemiz mümkün mü?

Kullanıcı Eğitimi:

  • Kullanıcılara hangi konularda eğitim verilecek?
  • Eğitim hangi ortamda yapılacak?
  • Eğitim sırasında (projenin ilk aşamasında) Kullanabilirlik testi için prototip hazırlanması.
  • Toplamda hangi rolde kaç kullanıcı eğitim alacak?
  • Eğitim materyali nelerden oluşacak?

Donanım/Yazılım Altyapısını Tanıma:

Yazılım:

  • Kullanılan işletim sistem(ler)i nelerdir?
  • Kullanılan internet gezginlerinin isimleri ve versiyonları nedir?
  • İnternet Gezginleri'nde yüklü addon - pluginler var mı?
  • İnternet gezginlerinin / pluginlerin güncellenmesine izin verilmekte midir?
  • Kullanıcı doğrulama için LDAP benzeri bir sistem var mıdır?

Donanım:

  • Sistemin kullanılacağı tesis(ler)in fiziksel altyapısı nedir? Kablosuz iletişim gerekli ise, ortam uygun mudur?
  • Kullanıcıların sistemi kullanacakları donanımın (bilgisayar, tablet, telefon) özellikleri nelerdir? Rollere göre hangi tip donanımlar kullanılacaktır?

Kalite Karakteristikleri:

  • Sistemin herhangi bir çevresel şart kısıtı var mıdır? Sıcaklık, nem, toz, gürültü, sarsıntı, ...
  • Sistemin kullanılacağı tesis(ler)in donanım altyapısı nedir? Ağ hızı, sunucu sayısı, elektrik altyapısı, jeneratör / UPS varlığı, …
  • Sistemin Genişleyebilirlik ihtiyacı var mı? Sınırları nedir?
  • Sistemin Yedekleme ihtiyacı var mı? Nasıl bir süreç düşünülüyor?
  • Sistemin uyması gereken bir Sertifikasyon kısıtı var mı?
  • Sistemin birlikte çalışması gereken (Uyumluluk) başka sistemler var mı? Arayüzler ve veri tipleri nedir?
  • Sistemin Kaynak Kullanım kısıtları var mı? CPU, bellek, disk alanı, ağ kapasitesi kullanım sınırları gibi.
  • Sistemin Afet Kurtarma özelliği ihtiyacı var mı?
  • Sistemin Efficiency (belirli bir yük için kaynak tüketimi) kısıtı var mı?
  • Sistemin Effectiveness (harcanan efor sonrasında elde edilen performans) kısıtı var mı? Bir işlemin en fazla 3 adımda yapılması gibi.
  • Sistemin uyması gereken bir yasal mevzuat / standart var mı? Nedir?
  • Sistemin Performans (tepki süreleri) kısıtı var mı? Hangi yük altında bu süreler nedir?
  • Sistemin Platform Uyumluluk kısıtı var mı? Hangi platformlar?
  • Sistemin veri / bilgi Gizliliği kısıtı var mı? Ne tür veriler, hangi roldeki kullanıcılar?
  • Sistemin Kurtarılabilme (Recovery / recoverability) kısıtı var mı? Ölümcül hata durumunda en geç 5 dakikada sistemin faal hale gelmesi gibi.
  • Sistemin Bakımı için izin verilen gün / saatler nelerdir?
  • Sistem için Hizmet Seviyesi Anlaşma şartları nelerdir?

Kullanıcı Destek:

  • Kullanıcıların eğitim sonrası sorunlarında hangi yöntem ile yardımcı olunacak?
  • Bir Destek Merkezi kurulması ihtiyacı var mı?
  • Destek hangi ortam üzerinden sağlanacak? E-posta, telefon, video konferans, …
  • Soru ve hata bildirimleri nerede kayıt altına alınacak?

Wednesday, March 6, 2019

İş Hayatında Öne Çıkan Yetkinlikler

Uzun yılların birikimi olarak rahatlıkla şunu söyleyebilirim; iş hayatında başarılı olmak için gereken yetkinlikler teknik bilgiden ziyade sosyal yetkinlik ve etik değerlerden oluşuyor.

Aşağıdaki liste tam olmayabilir ama iş hayatında saygı duyulan ve takdir edilen bir çalışan olmak için gerekli özelliklerin bunlardan oluştuğunu düşünüyorum:

  1. İşe erken gelmek, geç çıkmak.
  2. Yöneticilerin isteklerine olumlu cevap vermek.
  3. Zor işlere talip olmak.
  4. İş önceliklendirmesi yapmak; önemsiz işleri sonraya ertelemek, öncelikli işlere daha fazla efor harcamak.
  5. İş saatlerinde sadece ve sadece işle uğraşmak.
  6. Altına imza attığınız, içinde isminiz geçen işleri en iyi şekilde yapmaya çalışmak.
  7. Şirket kaynaklarını özel işleriniz için kullanmamak.
  8. Şirket kaynaklarının israfını engellemek.
  9. Şirket süreçlerini ve kültürünü sürekli iyileştirmek.
  10. Birlikle çalıştığınız kişilerin bireysel gelişimlerini desteklemek.
  11. Kişilerin başarılarını diğer çalışanlarla paylaşmak, hatalı yaptıklarını ise sadece o kişiyle paylaşmak.
  12. Kendinizde eksik gördüğünüz alanlarda sürekli eğitimle gelişim sağlamak.

Saturday, December 1, 2018

Sites to Learn Web Development

Learning nowadays is nearly free and requires only a computer, internet connection and a will to learn.

My latest learning topic is Web Development which includes HTML, CSS, JavaScript, Node.JS, React.JS, Redux and probably some more technologies. I believe that learning web development will help me a lot in my test engineering career.

There are a ton of free and paid sites that helps you learn Web Development.

The free ones, which are my favourites, are:
  1. FreeCodeCamp.Org :This site has courses on the below topics, and it provides text-based lessons and an environment that lets you test out what you learned from the lessons.
    1. Responsive Web Design Certification (300 hours) 
    2. Javascript Algorithms And Data Structures Certification (300 hours) 
    3. Front End Libraries Certification (300 hours)
    4. Data Visualization Certification (300 hours)
    5. Apis And Microservices Certification (300 hours) 
    6. Information Security And Quality Assurance Certification (300 hours) 
    7. Coding Interview Prep (Thousands of hours of challenges)
  2. W3Schools.com : Again, a wonderful site where you can gain in-depth information on HTML, CSS, JavaScript, SQL, PHP, Bootstrap, and JQuery. It also includes tons of examples and quizzes that helps you try  yourself out, and also provides certification for $95 for each topic.
The paid ones are from Udemy. I bought both of these courses and I can say that both of them are quite neat. The good part about these courses are that along the way, you start to build your own web sites / projects and at the end of the courses you will have finished nearly 40 projects which you can include in your resume. You can watch their sample videos after you visit their pages on Udemy.
  1. The Complete Web Development Course - Build 15 Projects:
    1.  HTML, CSS, Javascript, jQuery, Bootstrap, PHP, MySQL, Wordpress, API's (Google , Facebook, Twitter), Mobile All covered!
  2. The Complete Web Developer in 2019: Zero to Mastery
    1. Learn to code and become a web developer in 2019 with HTML, CSS, Javascript, React, Node.js, Machine Learning & more!

Wednesday, November 21, 2018

Mikro ve Küçük Ölçekli Yazılım Firmaları için Test Stratejileri

24.06.2018'de güncellenen KOBİ tanımına göre Mikro Ölçekli firmalar çalışan personel sayısı 10'dan az olan ve Küçük Ölçekli firmalar da çalışan personel sayısı 50'den az olan firmalardır.

Nakit akışı, yüksek ve düzenli kâr bırakan pazarlara erişim, çalışan motivasyonunu yüksek tutamamak gibi yönetim seviyesi zorluklar bir yana, az sayıdaki personelin pek çok farklı faaliyeti yoğun ve fazla mesai yaparak gerçekleştirmeleri sonucu hatalar yapılabilmekte, bu da nihai ürünün toplam kalitesinde zayıflığa ve müşteri memnuniyetsizliğine sebep olabilmektedir.

Bir soru sorarak başlayalım: 
Mikro ve küçük ölçekli yazılım firmalarının nihai müşteri memnuniyetlerini nasıl yükseltebiliriz?
Şunu belirtmekte fayda var: bu firmaların CMMI, SPICE, ISO 12207 gibi ağır metodolojilere uymaya yetecek kaynakları çoğunlukla olmayacaktır. Hatta bazen çevik yöntemleri bile uygulamakta zorlanabilirler.

Tümdengelim yaparsak; 

  • Müşteriler ne kadar az hata ile karşılaşırlarsa o kadar "Düzelt-Test Et-Yayınla" döngüsü işletilir,
  • Ürünün kullanımı ne kadar kolaysa o kadar az eğitim / kullanım desteği verilmesi gerekecektir,
  • Personel teslimat sonrası ne kadar az hata ve destek ile uğraşırsa, bir sonraki ürünü geliştirmek için daha çok zamanı olacaktır.
"Test Mühendisliğinde Olası Riskler ve Alınabilecek Tedbirler" başlıklı yazımda belirttiğim pek çok durum firmanızın işleri zorlaştırıyor olabilir ancak sorunun özü kısıtlı kaynaklar sebebiyle firmaların Test ve dokümantasyona yeterince zaman harcayamamalarıdır.

Aşağıda, bu sorunu çözmeye katkı sağlayabileceğini düşündüğüm maddeleri veriyorum. Firmanızın kaynaklarına ve yapısına en uygun yöntemi yine kendiniz belirleyebilirsiniz. Bunların uygulanması konusunda veya firmanızın yapısına özel sorularınız olursa da yardımcı olmaya çalışırım.




  • PERSONEL:
    1. İmkanınız varsa, mesleği test mühendisliği olan personel istihdam edin. Yazılımı geliştirenler (ve müşteriler) test yapmaktan genelde hoşlanmaz, bazen üstünkörü yaparlar, genelde de sadece "happy path"i test ederler. 1 kişi bile olsa istihdam edeceğiniz test mühendisi, müşteriden dönme ihtimali olan hataları çok büyük oranda azaltacaktır. Eğitim dokümantasyonu, müşteri desteği vermesi de cabası; çünkü sistemin genelini (çoğu zaman) en iyi bilen kişi test mühendisidir. 
    2. Sürekli olarak test mühendisi istihdam edemiyorsanız, stajyer / yarı-zamanlı çalışacak öğrencilere test yaptırabilirsiniz. Fakat bu personelin "test  mühendisi bakış açısı" olmadığından bu konuda eğitim almaları gerekecektir, bir danışmanın vereceği 2 günlük bir eğitim bile çok fark yaratacaktır. Aksi durumda çok fayda sağlanamayabilir. 
    3. Sürekli veya yarı zamanlı personel istihdamı da sizin için mümkün değilse, yine mesleği test mühendisliği olan bir danışman sadece ihtiyaç zamanlarında size destek verebilir.  Bu ihtiyaç zamanları şunlar olabilir:
      • Projenin ilk aşamasında sözleşme / sistem gereksinimlerinin gözden geçirilmesi ve bir ana test planı / stratejisi hazırlanması,
      • Sistem tasarımı sonrasında sistem seviyesi test senaryolarının ("Öncelikli Senaryo") yazılması,
      • Ara teslimat dönemlerinden önce testlerin koşturulması ("Detaylı Senaryo"),
      • Nihai teslimat öncesinde tüm senaryoların koşturulması.
"PERSONEL" konusunu çözüme ulaştırdıysanız;
  • TEST SÜRECİ
    1. Mutlaka gereksinim yönetimi yapılmalı. Böylece hiçbir istek/gereksinim göz kaçamaz.
    2. Müşterinin en çok önem verdiği, olmazsa olmaz dediği, beklemeye tahammül edemeyeceği işlevlerin neler olduğunu listeleyin. Bu işlevler belirlenirken kullanıcı ile empati kurabilmek çok önemlidir.
    3. Risk temelli test yaklaşımı ile bu listedeki maddelerin tamamını üst seviyede test eden bir senaryo oluşturun ("Öncelikli Senaryo").
    4. Her teslimat öncesi "Öncelikli Senaryo"yu mutlaka çalıştırın.
    5. "Öncelikli Senaryo"yu alt parçalara ayırıp detaylı senaryolar hazırlayın ("Detaylı Senaryo").
    6. Geri kalan kısımlar için "İkincil Senaryolar" oluşturun.
    7. Teslimatları ayda bir yaptığınızı varsayarsak, haftada 1 kere "Öncelikli Senaryo", 2 haftada 1 "Detaylı Senaryo", ayda 1 kere de "İkincil Senaryolar"ı koşturabilirsiniz.
      • "Ürün bitsin, testleri sonra yaparız" diye düşünmeyin, böyle bir yaklaşım kaosa davetiye çıkartmaktır.
    8. Eğer resmi bir "Kabul Testi" yapılacaksa, "Kabul Testi Nedir, Nelere Dikkat Etmek Gerekir" başlıklı yazımda belirttiklerim uygulanmalı.
  • HATA YÖNETİMİ:

    1. Proje ilerledikçe hata sayıları da doğal olarak artacaktır.
    2. Eğer müşteriye bir ara ürün / demo ürünü teslimatı yapılmışsa, önem derecesi ne olursa olsun müşteriden gelen hata bildirimlerine öncelik verin ve en kısa zamanda ilk onları çözün ("ÖNCELİK 1").
      • Bizler için önemsiz gibi görünen hatalar, son kullanıcı gözünde çok önemli olabilir.
    3.  "Öncelikli Senaryo" ve "Detaylı Senaryo"dan bulunan hatalara 2. seviye öncelik verin ("ÖNCELİK 2").
    4. "İkincil Senaryo"dan bulunan hatalara 3. seviye öncelik verin ("ÖNCELİK 3").
    5. Firmanıza daha yüksek katma değer sağlayacak ve müşteri memnuniyetini artıracak hata çözüm sırası da doğal olarak ÖNCELİK 1 > ÖNCELİK 2 > ÖNCELİK 3 şeklindedir.
    6. Jira, Mantis veya diğer bir hata yönetim uygulaması kullanmak şarttır. Mümkünse son kullanıcıların da bu sistem üzerinde hata açabilmelerini sağlamak geri bildirim hızınızı artıracaktır. 

  • DOKÜMANTASYON:
    1. Kod içinde mutlaka "comment"ler ile neyin ne iş yaptığını belirtmek, hata düzeltme ve bakım dönemlerinde hayat kurtarıcı olmaktadır.
    2. Müşteriniz eğer formal test dokümantasyonu istiyorsa (örneğin TÜBİTAK), Mil-Std-498'i kullanabilirsiniz, ücretsizdir.
    3. Uygulamanın kurulumu ve kullanımı ile ilgili kısa da bir belgeyi tercihen web sayfası veya uygulamanın içine entegre olarak hazırlamanız, sonrasında kullanımla ilgili gelecek pek çok sorudan kurtaracaktır sizi.
    4. Ürünün kapsamlı eğitimi gerekiyorsa, ürün olgunlaştıktan sonra eğitim videosu hazırlayarak maliyeti azaltabilirsiniz.

  • ARAÇ KULLANIMI:
    1. Eğer ürününüz test otomasyonuna uygunsa, personelinizin bu konuda deneyimi varsa ve en önemlisi otomasyona alınan testlerin çok sık güncellenmesi gerekmeyecekse, test otomasyonu fayda sağlayacaktır. Ancak uyarmam gerekir: bu iş ayrı bir uzmanlık alanıdır ve kimi zaman faydadan çok zarar da verebilir.
    2. Sadece açık kaynaklı test araçlarından faydalanın. Ticari test araçları genelde fazlasıyla pahalıdır, eğitim / destek maliyeti olabilmektedir, alınan araç âtıl kalabilmektedir.
    3. Test verisi hazırlama ve kaynak kodu sık değişmeyecek kısımlar için otomasyon kodu yazılabilir. Bir kere yaparsınız, proje boyunca sizi tekrarlayan işlerden kurtarır.

Tuesday, November 20, 2018

Gençlere Tavsiye: Evet Yeniden

Meslek hayatı boyunca, kendi mesleği ile ilgili bir tane bile kitap okumadan emekli olanların ülkesi burası... 
Mesleğinin ikinci senesinden itibaren yeni bir yetkinlik edinmeden terfi bekleyen, zam bekleyenlerin ülkesi burası...

Sorun ülkede değil, iş ahlâkımızda; uzmanlığa, çalışmaya, alın terine, ... değer vermeyişimizde.
%1 ilkesini daha önce yazmıştım.
Bir tane de kitap önereyim; "The Little Book of Talent".



Her gün, özellikle zorlu bir aşamayı geçtikten hemen sonraki gün daha da fazla pratik yapmanın uzun dönemde ne kadar faydalı olduğunu güzel anlatan bir kitap. Kısa da bir kitap, okunmasında çok fayda var.

Hep şikayet etmek de doğru değil, çözüm de sunmamız gerekiyor.
Özellikle gençler için.

Şöyle bir hesap yapalım, bizi nereye götüreceğini görelim.
Mesleğinizle ilgili olarak haftada 1 kitap ("teknik kitaplar zor, haftada bir tane bitmiyor" diyorsanız, ayda 1 kitap) okuduğunuzda 5 senede 1*52*5=260 kitap ( veya 1*12*5=60 kitap) okumuş olursunuz. Mesleğinizle ilgili bu kadar kitap okuduğunuzda bu sizi nereye getirir?
Ülkedeki, o alandaki, %1 arasına sokar sizi.



Tabî bunun için azim, istek, kararlılık gerek. İzlenecek yüzlerce Netflix dizisi varken, gezip tozmak varken, bunları yapmak zor geliyor.

"Kitap sevmiyorum, başka ne var" diyenlere: youtube videoları var. Aklınıza gelen her konuda eğitim var.  Udemy var, Coursera var, Khan Academy var... Tarihin hiçbir döneminde enformasyona erişim bu kadar kolay olmadı...
İzle, öğren, uygula.
Bu kadar.

Özgeçmişler geliyor bazen karşımıza, inceliyoruz. Boş içleri. 3 paragraf hikaye var ama içleri boş. 
Şunu yap, seni almayacak şirket yok:
- Okuduğun teknik kitaplar için 3er paragraf blog yazısı yaz, 
- İzlediğin eğitim videolarından öğrendiklerini uyguladığını ispatlayan bir site yap, bir yazılım yaz, bir video çek, olmadı bir blog yaz,
- İhtiyacın olmasa da staj yap,
- Para için değil de deneyim için, daha öğrenciyken veya yeni mezunken bir şirkete gir, verilen her işi yap,
- İş ağını geliştir, amirlerinden linkedin'de bir tavsiye yazısı yazmalarını rica et,
- (yazılım mühendisleri için) bir Open Source projede katılımcı ol, kod yaz, test yap,
ve tüm bunları özgeçmişine yaz.
Bir de böyle başvur işe. Kabul etmemelerine imkan yok.
O kadar çok hiçbir şey bilmeyen mezun var ki, tercih edilmemen neredeyse imkansız.

İkinci sorun, işe girdikten sonraki "beleşçilik".
Bilemediği, çözemediği bir sorun olduğunda etrafındaki deneyimli personele Google muamelesi yapanlarla dolu iş yerleri. Terslendiği zaman ağlayan mı istersin, "biraz araştır" dendiğinde prens/prenses kişiliğine hakaret olarak algılayan mı istersin,...

"Kendim araştırayım, zorlansam da kendim çözmeye çalışayım, bi gayret göstereyim" diyenlerin sayısı, özellikle 1990 sonrası doğumlularda, o kadar az ki, sorunu çözemeseniz bile sırf gayret gösterdiğiniz için liderlerinizin yardımını ve takdirini kazanırsınız.
Takdir edilmek de değil buradaki amaç; kimseyi sömürmeden, sorunları kendi başınıza çözme yeteneği kazanmanız.



Son olarak da: sırf işe biraz erken gelip, biraz geç çıkmak, pijama gibi veya sokakta 5 liraya kartpostal satmaya çalışanlar gibi değil de işe uygun giyinerek hem çalışma arkadaşlarınıza hem yöneticilerinize hem hizmet verdiğiniz müşterilere hem de şirketinize olan saygınızı gösterecektir.



Umarım okuyan 100 kişiden biri bunları uygular.


Wednesday, November 14, 2018

Fonksiyonel Olmayan Gereksinimler: Uygunluk

Kullanıcıların, "normal çalışma zamanlarında" sistemin çalışabilir olduğuna güvenme derecesidir. Diğer bir deyişle, kullanıcılar normal çalışma saatlerinde sistemi kullanmak istediklerinde sistemin kullanıcı isteklerine cevap verebiliyor olması gerekmektedir.

Örnekleyecek olursak;

  • Çevrimiçi Ödeme Sistemi saat 06 ile 23 arasında kullanıma uygun olmalıdır.
  • Çevrimiçi Ödeme Sistemi 100 saatlik MTBF (Mean Time Between Failures - Arızalar Arasındaki Ortalama Süre) değerine sahip olması gerekmektedir.
  • Çevrimiçi Ödeme Sistemi, kullanıcıların isteklerinin %95'ine 15 saniye içinde cevap verebilmelidir. Geri kalan zamanlarda 20 saniye içinde cevap verebilmelidir.
  • ATM cihazı hafta içi günlerde saat 06 ile 23 arasında %99 oranında uygun olmalıdır. 
  • Sistemin yeni bir kurulumu, kurulum işlemi başlatıldıktan sonra 24 saat içinde ilk kullanıma hazır olmalıdır.
  • Sistem kullanıma kapatıldıktan sonra sistemin veritabanı yedeği 15 dakika içinde alınabilmelidir.
  • Sisteme kapatma komutu gönderildikten sonra 3 dakika içinde sistem kapanmış olmalıdır.
  • Acil durum veri silme komutu gönderildiğinde 15 saniye içinde her 3 sabit diskteki tüm veri geri kurtarılamaz şekilde silinmelidir. 

Tuesday, November 13, 2018

Fonksiyonel Olmayan Gereksinimler: Hayatta Kalabilirlik

Bir sistem arızası ortaya çıktığında yazılım sisteminin kendini toparlaması ve çalışmaya devam etmesinin ölçüsüdür.

Örnekleyecek olursak;

  • Denetleme yazılımı arıza sonrası kapanırsa kullanıcının sözleşme dosyasında yaptığı değişiklikler kurtarılmalı ve dosya arıza oluşumundan bir dakika öncesindeki duruma gelmeli.

  • Yazılımın güncellenmesi sırasında bir arıza ortaya çıkarsa yapılan tüm veri ve güncellemeler geri alınmalı ve yazılım eski haline dönmelidir.

  • Bir arıza durumu sonrasında işletime devam edilirken kullanıcıya yazılımın "güvenli mod"da çalıştığı ve tüm verinin salt okunur durumda gözden geçirmeye hazır olduğunun bilgisi verilmelidir.

  • Sistem, arızalı olduğu tespit edilen yeteneklere erişimi engellerken diğer tüm yeteneklere erişime izin vermelidir.

  • Montaj hattındaki tüm donanım bileşenleri yedekli olmalıdır, böylece herhangi bir donanım bileşeni arızalandığında montaj hattının durması engellenmelidir.

Monday, November 12, 2018

Testler Ne Zaman Biter?

Yazılım sektöründe bir süre çalışanların çok iyi bildiği gibi, yazılım ve sistem projelerinin karmaşıklık sebebiyle, test edilebilecek patikaların sayısı neredeyse sonsuzdur. Ve proje yöneticilerinin en sık sorduğu sorulardan biri "testler ne zaman biter"dir.

Öncelikle testlerin sayısının neden çok olabileceğini inceleyelim.

Örnek olarak E-Devlet giriş sayfasını kullanabiliriz.



Uygulayabileceğimiz testleri listeleyelim:

  1. T.C. Kimlik No alanı ve e-Devlet Şifresi alanını boş bırak, "Sisteme Giriş Yap" düğmesine tıkla,
  2. T.C. Kimlik No alanına geçerli değer gir ve e-Devlet Şifresi alanını boş bırak, "Sisteme Giriş Yap" düğmesine tıkla,
  3. T.C. Kimlik No alanını boş bırak ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
  4. T.C. Kimlik No alanına boşluk karakteri gir ve e-Devlet Şifresi alanına boşluk karakteri gir, "Sisteme Giriş Yap" düğmesine tıkla,
  5. T.C. Kimlik No alanına geçerli değer gir ve e-Devlet Şifresi alanına boşluk karakteri gir, "Sisteme Giriş Yap" düğmesine tıkla,
  6. T.C. Kimlik No alanına boşluk karakter gir ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
  7. T.C. Kimlik No alanına 500 adet karakter gir ve e-Devlet Şifresi alanına 500 adet karakter gir, "Sisteme Giriş Yap" düğmesine tıkla,
  8. T.C. Kimlik No alanına Kopyala-Yapıştır ile 10 karakterlik değer gir ve e-Devlet Şifresi alanına Kopyala-Yapıştır ile 10 karakterlik değer gir, "Sisteme Giriş Yap" düğmesine tıkla,
  9. 1-8 arasındaki testleri tekrarla, "Sisteme Giriş Yap" düğmesine tıklamak yerine klavyedeki ENTER tuşuna bas,
  10.  T.C. Kimlik No alanına geçerli bir değer gir ve e-Devlet Şifresi alanına geçerli değer gir, "Sisteme Giriş Yap" düğmesine tıkla,

Yukarıda tanımlanan 10 (aslında 17) adet teste daha pek çok test eklenebilir. 
Görüldüğü üzere sadece 2 tane alan için bile bu kadar test tanımlanabiliyorken, yüzlerce ekran ve binlerce veri giriş alanı / kontrol düğmesi içeren, birden fazla yazılım ve donanımın entegre olduğu, yedekli veritabanı sistemleri, yük dengeleyiciler, CBS yazılımları, masaüstü / web / mobil arayüzleri olan devasa bir sistemde, yapılabilecek testlerin sayısı (sonsuz olmasa bile) on binlere ulaşabilir.

Peki soru şu: Testler ne zaman biter?
  1. Atanan efor / süre bittiğinde: Proje takviminde test için ayrılan süre bittiğinde,
  2. Test durumları belirli bir başarı yüzdesine ulaştığında,
  3. Hata oranı belirli bir yüzdenin altına indiğinde,
  4. Tüm gereksinimler %100 doğrulandığında
    • Gereksinimlerin %100 doğrulanmış olmasının, geçilebilecek tüm patikalardan geçildiği anlamına gelmediğini de belirteyim.
Anlaşıldığı üzere, bir sistemi %100 test etmek hem ekonomik değil hem de kimi durumlarda mümkün değildir.
Bunun istisnası, görev-kritik yazılımlardır; hata yapması durumunda insan yaşamına ve ülke güvenliğine ciddi zararları olabilecek yazılımlar için yazılan birim testlerin %100 kapsama oranına sahip olması beklenmektedir.

Peki, madem sistemi %100 test etmek ekonomik / mümkün değil, o zaman "nasıl bir test stratejisi izlersek hem sistemi yeterli derecede test etmiş oluruz hem de hataların büyük kısmını müşteri ortamına kurulum yapılmadan önce tespit etmiş oluruz?".

Bu da bir başka yazının konusu: En Uygun Test Stratejisini Nasıl Belirleriz?

Friday, July 20, 2018

Günde 1 Tanenin Gücü

Hepimizin hayatta amaçları ve hayalleri var. Bu amaçlara ve hayallere ulaşmak için ise çok azımız plan yapıyor, daha da azımız bu planları düzenli bir şekilde uyguluyor.

"Günde 1 Tane" ile kastettiğim şey, bizleri bu amaçlara ulaştıracak plan maddelerini her gün birer birer uygulamak. Bu konuda özlü sözler de var, örneğin, "100 kilometrelik bir yolculuk, her seferinde bir adım atılarak bitirilebilir", "bir pastayı nasıl yersiniz? küçük birer ısırık ile", ... 

"Günde 1 Tane" yaklaşımı ile neleri başarabileceğimize bir bakalım.

  • Günde 1 blog yazısı yazarak bir senede 365 makaleden oluşan bir blog sitemiz olabilir,
  • Günde 1 sayfa yazarak bir senede 365 sayfalık bir kitap yazabiliriz,
  • Günde 1 kelime öğrenerek bir senede 365 yeni kelime öğrenebiliriz,
  • Günde 1 kilometre yürüyerek sağlığımızı koruyabiliriz,
  • Günde 1 yeni kişiyle tanışarak senede 365 yeni insanla tanışmış ve iş ağımızı / çevremizi genişletmiş oluruz,
  • Günde 1 video kaydederek senede 365 videodan oluşan bir Youtube arşivimiz olur (öyle ki, bu videolar zamanla bize reklam geliri ile kazanç sağlar),
  • ...


"Günde 1 Tane" dediğimizde illaki "1" olmak zorunda da değildir, bu rakamı kendiniz belirleyebilirsiniz.

  • Günde 10 TL biriktirerek senede 3650 TL (yani gayet iyi bir tatil parası) biriktirebiliriz,
  • Günde 10 sayfa okuyarak her ay bir yeni kitap bitirebiliriz.


Burada önemli olan 1, 10, 100 olması değil, bu yöntemin her gün uygulanmasıdır.
Düşündüğünüz zaman size kolay gelebilir ama yapacağınız şey her ne olursa olsun, bunu her gün yapmak gerçekten çok zordur.

Fakat zor olması sizi korkutmasın; zor geldiği için pek çok insan amaçları doğrultusunda düzenli çalışmıyor ve sonuçta sizi, diğer insanlardan farklı kılacak şey de onların yapamadığını yapmak olacaktır.

Şöyle düşünelim. Türkiye'de sizinle aynı meslekte, sizinle aynı yaş grubunda bulunan 50.000 kişi olduğunu varsayalım. Eğer,

  • Kendi alanınız ile ilgili olarak, her gün 10 sayfa okursanız, senede 12 yeni kitap bitirirsiniz (kaldı ki çoğu insan kendi alanlarında meslek hayatları boyunca bile 12 kitap okumuyor),
  • Kendi alanınız ile ilgili olarak, her hafta 1 eğitim videosu / konferans kaydı izlerseniz, senede 52 yeni konuda bilgi sahibi olursunuz,
  • Kendi alanınız ile ilgili olarak, her hafta bir blog makalesi yazarsanız, senede 52 adet blog yazınız olur ( bu da sizin konuya olan ilginizi ve konu hakkındaki bilginizi ortaya koyar).

Örnekler çoğaltılabilir. Sadece bu 3 maddeyi sadece 1 sene uygulamanız durumunda bile sizinle aynı alanda çalışan ve dolayısıyla sizin rakibiniz olan akranlarınızın %90'ından daha bilgili, daha tecrübeli hâle gelirsiniz. Bu yöntemi 3 sene boyunca uygulayın, ülkedeki sizin alanınızdaki insanların %99'undan daha iyi olacağınız kesindir.

Sonuç olarak: hayattaki amaçlarınız belli ise, bu amaçları gerçekleştirmek için Günde 1 Tane yöntemini kullanmanız durumunda başarılı olmanız neredeyse kesindir.

Monday, March 19, 2018

Yazılım Testi ile Sistem Testi Arasında Ne Fark Vardır?

Sistem, yazılım ürünleri ile (kimi zaman) donanım ürünlerinin birleşiminden oluşmuş yapıya verilen isimdir.
Yazılım ise sadece yazılım ürünleri ve destekleyici konfigürasyon ve veri dosyalarından oluşan yapıya verilen isimdir.

Eğer geliştirilen ürün, sadece yazılım parçalarından oluşuyorsa, bu bütüne yazılım sistemi adı da verilebilmektedir.

Test açısından bakıldığında yazılım testi ile ifade edilen;

  • yazılım seviyesi gereksinimlerin doğrulandığı,
  • normal girdiler haricinde sınır değerlerin, boş değerlerin, hatalı ve eksik değerlerin de testlere dahil edildiği,
  • testin akışının (test betiği / test durumu) sadece hedeflenen fonksiyonu test ettiği 
yapı anlaşılır.

Sistem testi dendiğinde ise;
  • sistem seviyesi fonksiyonel gereksinimler ile kalite karakteristiklerinin doğrulandığı,
  • (çok büyük çoğunlukla) sadece normal girdilerin testlere dahil edildiği,
    • çünkü yazılım seviyesi testlerde ekranlardaki / servislerdeki sınır değerler vesaireyi zaten test ettik,
  • belirli bir operasyonel konsept senaryosu kullanılarak sistemi baştan sona bir ana akış dahilinde test eden,
  • yazılımın, sistemin diğer bileşenleri olan donanım ürünleri etkileşiminin de test edildiği,
bir yapı anlaşılır.

Yazılım testleri de birer senaryo dahilinde işletilir ama bu senaryolar sadece bir veya birkaç fonksiyonu içerir. 

Saturday, March 3, 2018

Taşınabilirlik Gereksinimi Örnekleri

Yazılım sisteminin bulunduğu mevcut donanımdan veya yazılım ortamından bir başka donanıma / ortama kolay taşınabilmesine yönelik gereksinim türüdür.

Örnekler:

  1. Hesap Hareketleri İşleme Sistemi tarafından kaydedilen tüm zaman damgaları kalıcı depolama birimine yerleştirildiklerinde Evrensel Koordine Zaman yapısında olmalıdır.
  2. Bir zaman değerinin kullanıcıya görüntülendiği her yerde zaman kuşağı belirgin olarak görüntülenmelidir.
  3. Ürünün, önümüzdeki sene Avrupa pazarında satışı hedeflenmektedir.
  4. Ürün, işyeri ofislerinde çalışacak şekilde tasarlanmıştır ancak, üretim montaj fabrikalarında çalışacak olan bir sürüm de amaçlanmaktadır.
  5. Sistem, Microsoft Windows 10 ve Macintosh işletim sistemleri için geliştirilmelidir.
  6. "EvMuhasebesi" yazılımı en az aşağıdaki özelliklerdeki kişisel bilgisayarlar veya iş istasyonlarına taşınabilir olmalıdır:
    1. En az 16-bit renk destekli 15 inç ve üzeri monitör,
    2. Asgari 1GB disk alanı.

Bütünlük Gereksinimi Örnekleri

(Integrity'nin karşılığı olarak Bütünlük - Tamlık kullanılmakta. Bu tanıma Dürüstlük kavramını da eklemek gerekiyor)

Yazılım sistemi tarafından idame ettirilen verinin kesin, tam, gerçek ve doğru olma seviyesine yönelik gereksinim türüdür.

Örnekler:

  1. Tüm mali değerler noktadan sonra 2 haneye kadar doğru olmalıdır.
  2. Depo sıcaklık değerleri artı / eksi 2 santigrat derece kesinliğe sahip olmalıdır.
  3. Proje belgelerinde yapılan değişikliklerin sebebi bir veritabanı veya eşdeğer bir teknoloji ile kayıt altına alınacak ve düzenli olarak yedeklenecektir. Bu işlem, disklerde veri kaybı olması durumunda belgelerde yapılan değişiklikleri belirlemek için gerekmektedir.
  4. Kredi Sorgulama Sistemi, tüm yuvarlama hesaplarını önce noktadan sonra 5 haneye kadar yapmalı, ardından da noktadan sonra 2 haneye kadar yapmalıdır.
  5. Sistem verisinin bütünlüğü, dahili kontrol sistemi tarafından saniyede 2 defa gözden geçirilmelidir; eğer veride tutatsızlık tespit edilirse, sistemin işlem yapmasına izin verilmemelidir.

Wednesday, February 28, 2018

Gizlilik Gereksinimi Örnekleri

Yazılım sisteminin hassas veriyi koruma ve sadece yetkili kullanıcıların erişimine izin verme derecesini belirleyen gereksinim türüdür.

Örnekler:

  1. T.C. Kimlik Numarası'nın sisteme girişi sırasında veya sonrasında hiçbir kısmı görüntülenmeyecektir. Basılı belgeler üzerinde sadece son 4 rakamı görünür olacaktır.
  2. Hasta Verileri Sistemi sadece hastanın ıslak imzalı izni olduğu durumlarda hastanın kayıtlarına erişim izni verecektir.
  3. Sistemde kayıtlı her veri türünün gizlilik dereceleri olacaktır. Her veri türü içindeki tekil veriye farklı seviyelerde gizlilik dereceleri atanabilecektir. Bir kullanıcı sadece kendi yetki seviyesi ve bunun altındaki seviyedeki gizlilik derecesine sahip veriye erişim sağlayabilmelidir.
  4. "Gizli" gizlilik derecesindeki ve daha üst seviyedeki gizlilik derecesindeki veri hiçbir surette harici bir ortama kaydedilemeyecek ve/veya basılı hale getirilemeyecektir.

Kullanılabilirlik Gereksinimi Örnekleri

Kullanıcının, sistem ile etkileşim kurarak öğrenme, işlem yapma, girdileri hazırlama ve çıktıları yorumlamasının kolay olmasına yönelik gereksinim türüdür.

Aşağıdaki gereksinim örnekleri okuduğunuzda göreceksiniz ki Kullanılabilirlik gereksinimlerini sadece yazılım ürünleri için değil hemen hemen tüm ürün ve hzimetler için geçerlidir. Ve bunları doğrulamak için A/B Testi ve daha genel olarak Odak Grubu (Focus Group) çalışmaları yapmak gerekmektedir.

Örnekler:

  1. Ürün, tek el ile erişkin nüfus (18 - 80 yaş) tarafından kolaylıkla kullanılabilmelidir.
  2. Gıda otomatı, herhangi bir eğitim gerektirmeden, erişkin nüfus tarafından kullanılabilmelidir. Otomatı ilk defa gören insanların en az %95'i başarılı bir şekilde alışveriş yapabilmelidir.
  3. Ürünün yeni sürümünün kullanımının, bunu değerlendirecek kullanıcıların en az %90'ı tarafından "eski sürüme göre daha kolay" olarak değerlendirilmelidir.
  4. Deneyimli bir sipariş giriş personeli, tedarikçi kataloğundan seçilen bir ürün için azami 7 dakika ve ortalama olarak 4 dakikada sipariş girebilmelidir.
  5. Türkçe bilmeyen kullanıcılar, herhangi bir eğitim ihtiyacı olmadan, ürünü kullanabilmelidir.
  6. Daha önce ATM cihazı kullanmış olan banka müşterileri, ortalama 2 dakika içinde ATM'den para çekebilmelidir.
  7. Daha önce ATM cihazı kullanmamış olan müşterilerin en az %90'ı ortalama 4 dakika içinde ATM'den para çekebilmelidir.
  8. ATM'den ayda en az 6 defa para çekmiş olan müşteriler ortalama olarak 30 saniyede ATM'den para çekebilmelidir.

Tuesday, February 27, 2018

Emniyet Gereksinimi Örnekleri

Yazılım sisteminin insanlara veya hedef kullanım alanı içindeki ortama zarar vermesini engellemeye yönelik gereksinim türüdür.

Örnekler:

  1. Operatör Koruması "Etkin" durumuna gelmeden Radyasyon Sistemi işlem yapmaya izin vermemelidir.
  2. İlaç İzleme Sistemi, doktor tarafından belirtilmiş azami miktardan daha fazla oranda doz kullanımına izin vermemelidir.
  3. Yiyecek Satış Makinesi, bir soğuk gıda ürününün ısısı 4 derecenin üzerine çıkması durumunda bu ürünün satışına izin vermeyecektir.

Tekrar-Kullanılabilirlik Gereksinimi Örnekleri

Yazılım sisteminin bir parçasının diğer bir sistem tarafından kullanımı için dönüştürülmesine yönelik gereksinim türüdür.

Örnekler:


  1. Elektronik Fon Transferi ödeme seçeneğinin geliştirilmesi öyle yapılmalıdır ki organizasyonun diğer bölümleri tarafından tekrar kullanılabilsin.
  2. İstemci cihaz üzerinde çalışması için geliştirilen tüm yazılımlar, destekleyici bir ortamın indirilmesini gerektirmeden kişisel bir bilgisayar üzerinde çalışacak şekilde geliştirilmelidir.
  3. Devlet arşivlerindeki basılı materyal elektronik hale dönüştürülürken, var olan bilginin farklı maksatlarla kullanılabilmesi için farklı formatlarda sunulabilmesinin sağlanması gerekmektedir. Bilgiye erişim aynı zamanda fikrî mülkiyet yasalarına uygun bilgileri de içermelidir.

Monday, February 26, 2018

Yüksek Seviyede Verimli Test Mühendislerinin 5 Özelliği

Her meslek alanının uygulayıcılarının kendi alanlarında en iyi olabilmeleri için sahip olmaları gereken bazı yetkinlikler vardır.

Yazılım Testi de bu açıdan bir istisna değildir. Sıkı çalışma ve adanmışlık her meslek için önemlidir. Bu yazıda, test mühendislerinin alanlarında en iyi olmaları için kesinlikle kaçınılmaz olan 5 özellik sıralanmıştır. Sizin de önemli gördüğünüz yetkinlikler varsa, bunları yorum olarak ekleyebilirsiniz.

#1) Merak:
Merak, listenin ilk sırasındadır. Bir test mühendisi olarak, kesin olarak belirli olmayan her şeyi sorgulamak durumundayız. "Acaba 'Kaydet' düğmesine ard arda 2 kere tıklarsam ne olur? Veya 3 kere? Veya 'Kaydet'e tıkladıktan hemen sonra 'ESC' tuşuna basarsam ne olacak? Alanları boş bırakıp 'Kaydet'e basarsam ne olacak?" diye merak etmek gerekiyor.

Zaten deneyimli bir test mühendisi iseniz bu tarz bir yaklaşıma çoktan sahip olmuşsunuzdur. Eğer meslekte yeni iseniz, bu yaklaşıma en kısa zamanda sahip olmanızı tavsiye ederim. Eğer soruları siz sormazsanız, ürünün son kullanıcısı soracaktır ve hatalarla karşılaşabilirler. Eğer düşünebildiğiniz tüm senaryoları test etmezseniz, son kullanıcınız edecektir.


#2) Detaylara Gösterilen Dikkat:
Bu madde gerçekten çok önemlidir ama dürüst olmak gerekirse bunun insanın içinden gelmesi gerekir; öğretilebilecek bir yetkinlik değildir. 

Detaylara yeterince dikkat gösteren biriyseniz uygulamadaki en ufak bir kusur / uygunsuzluk gözünüze takılıp sizi rahatsız edecektir.

Bu şekilde çalışarak yaptığınız testlerden memnun kaldınız mı? O halde bunu bir alışkanlık haline getirin. Bu şekilde doğmamış olabilirsiniz ama bu konuda özen gösterirseniz zamanla bu yetkinliğe ulaşabilirsiniz.
#3) Odaklanabilme ve Parçalara Ayırabilme Yeteneği
Kısaca ifade edersek, büyük resimden ayrılmadan zihnimizi en küçük detaylara odaklayabilme yeteneğidir. 

Bir test mühendisi olarak, büyük resmin gözünüzü korkutmasına veya dikkatinizi dağıtmasına izin vermemelisiniz. Sistemin tamamına ayrı gözle bakarken, sistem içindeki birimlere tek tek bakmanız gerekecektir. Bu sayede, o en küçük birimi bile kendi başına ele alıp test edebilirsiniz.

#4) Yapıcı İletişim:
Yapıcı iletişim bir yetkinlikten ziyade bir kişilik özelliğidir. İyi bir iletişim kurabilmek için öncelikle karşıdaki kişiyi dinlemeli, söyleyeceklerimizi tartmalı, uygun bir ton belirlemeliyiz. Kimi insanlarda bu özellik doğal olarak vardır, kimileri de üzerinde çalışarak sonradan geliştirebilirler. Peki bu neden önemli?

Çünkü aslında test mühendisliği teknik bir iş olsa da aslında sosyal bir iştir. İnsanlar tarafından, insanlar için geliştirilen bir ürünü test ettiğimiz için hem kullanıcı/müşteri ile hem de yazılım geliştiren ekip ile yapıcı bir iletişim kurmamız sorunların krize dönmesini engellediği gibi, ürünün çok daha hızlı ve amaca uygun olarak geliştirilmesine katkı sağlar.

Bu konu gerçekten çok önemli olduğu için, test mühendisliğinde iletişim konularda daha önceden yazdığım yazılara da bakmanızı öneririm. "Testin Sosyal Yönü".
#5) Kendini Sürekli Geliştirme
Hemen hemen her meslek alanı zamanla gelişim göstermektedir. Ancak teknoloji yoğun alanlar özellikle de yazılım mühendisliği neredeyse her gün yeni yöntemler ve teknolojiler doğurmaktadır.

Bir test mühendisi olarak gelişmelerden uzak kalmak, meslekte geriye düşmemize sebep olacaktır. Fonksiyonel, performans, güvenlik ve kalite karakteristikleri (güvenilirlik, erişebilirlik, vs.) gibi pek çok farklı test türü ile ilgili kısa aralıklarda yeni ürünler çıktığı gibi Web, mobil ve diğer platformlarda da sürekli yenilikler yapılmakta.

Bu ürün ve yeniliklere çok değil 1 sene uzak kalmak bile sıradanlaşmamıza sebep olacaktır.

Esneklik Gereksinimi Örnekleri

Yazılımın farklı ortamlara, konfigürasyonlara ve kullanıcı beklentilerine kolay uyum sağlamasına yönelik gereksinim türüdür.

Örnekler:
  1. Uygulama, gelecekteki çoklu dil kullanımına uygun olmalıdır. Bu uygunluk şunları içermelidir:
    • Veritabanının yapısı öyle olmalıdır ki çoklu dil desteğini desteklemek için ek bileşenler veya mevcut bileşenlerin değiştirilmesi gerekmemelidir,
    • Kullanıcı, kişisel bilgilerini girerken tercih ettiği dili seçebilmelidir.
  2. Kullanıcıya görüntülenen hiçbir metin, programın kaynak kodu içinde olmamalıdır. Kullanıcının gördüğü her metin, kaynak kodun güncellenmesine gerek olmadan değiştirilebilmelidir. 
  3. Faturalama sistemi birden fazla para biriminde fatura kesme işlemi yapabilmelidir. 
  4. Ders programı yönetim sistemi birden fazla bağımsız dersin birden fazla takvim seçeneğini desteklemelidir. Dersler hakkındaki bilgiler birbirinden bağımsız olmalıdır ve kullanıcılar kayıtlı olmadıkları derslerle ilgili hiçbir bilgiye erişememelidir.
  5. Sistem, kaynak kodunda herhangi bir değişiklik gerektirmeden, yeni bir kullanıcı bildirim yönteminin uygulama içinden tanımlanabilmesine imkan sağlamalıdır.

Sunday, February 25, 2018

Platform Uygunluk Testi

Platform Uygunluk Testi'nin amacı, geliştirilen ürünün hedef işletim sistemlerinin tamamında sorunsuz olarak çalıştığının doğrulanmasıdır. Web ürünlerinin farklı internet gezginlerinde çalışmasına yönelik testler de bu kapsamda değerlendirilebilir.

Normal şartlar altında, kurulum işlemleri hariç olmak üzere, ürünün arayüzünün ve yeteneklerinin her platformda birebir aynı olması beklenmektedir. Ancak, test adımlarında komut ekranı / terminal ekranında yazılması gereken komutlar varsa, Windows ve Linux temelli işletim sistemleri için bu komutlar farklı olduğundan, bu detay test adımlarında belirtilmelidir.

Bu test türünün zorluğu, aynı testlerin her bir platform için tekrarlanması gerekliliğidir. O sebeple, mümkün mertebe test otomasyonu yapılarak harcanacak eforun asgari seviyeye indirilmesi önemlidir [test otomasyonu için harcanacak efor da ayrıca göz önünde bulundurulmalıdır, çünkü kimi durumda otomasyon kodunun yazılması, bakımının yapılması, farklı platformlarda çalışır olduğunun garanti edilmesi çok zor olabilir].

Bu test türünde karşılaşılabilecek bazı sorunlar şunlardır:

  • Kütüphane / eklenti uyumsuzlukları,
  • Konfigürasyon dosyalarındaki dizin adreslerinin gösterim farklılıkları sebebiyle dosyalara erişim sorunu,
  • Performans farkları,
  • Dosya formatlarındaki farklılık sebebiyle gösterim sorunları.

İdame Edilebilirlik Gereksinimi Örnekleri

Yazılım sistemindeki arızaların bulunması ve düzeltilmesine yönelik olan gereksinim türüdür.

Örnekler:

  1. Müşteri hizmetleri çağrı merkezi, sorun raporlarının %95'ini 2 saat içerisinde analiz etmelidir. "Acil" olarak sınıflandırılan arızalardan %98'i 3 iş günü içerisinde düzeltilmelidir.
  2. Uygulama geliştirme süreci, 2 iş günü içinde tüm sistemi tekrar test eden bir regresyon test prosedürü içermelidir.
  3. Bir bakım mühendisi, geliştirme ve test eforu da dahil olmak üzere, yasal mevzuatta yapılan değişiklikleri en geç 24 iş saati içerisinde sisteme yansıtmalıdır.
  4. Sistem, bakım amacıyla 24 saatten daha uzun bir süre kapalı kalmamalıdır.

Saturday, February 24, 2018

Kurulabilirlik Gereksinimi Örnekleri

Yazılım sisteminin, hedef ortama kurulumu, kurulumun kaldırılması veya tekrar kurulmasının kolay ve zahmetsiz olmasını sağlamaya yönelik gereksinim türüdür.

Örnekler:
  1. Sistemin veya 3.parti ürünlerinin detayını bilmeyen ama üzerine kurulum yapılacak işletim sistemi ile ilgili yeterli bilgiye sahip bir sistem yöneticisi tarafından sistemin ana sunucu yazılımının kurulumu mümkün olmalıdır.
  2. Yazılım sistemi hedef işletim sistemi olan Windows 10, Ubuntu Linux ve Redhat Linux işletim sistemleri üzerine kurulum arayüzü üzerinden kurulabilmelidir.
    1. Kurulum arayüzünde belirtilen tüm alanların yanında detay açıklamaları anlaşılabilir bir dilde yazılmalıdır.
    2. Kurulumun yapılacağı hedef işletim sistemi, kurulum dizini, veritabanı bağlantı ayar bilgileri, vekil sunucu ayar bilgileri yine bu arayüz üzerinden girilebilmelidir. Böylece kullanıcı, kurulum sonrasında konfigürasyon dosyalarında değişiklik yapmak zorunda bırakılmamalıdır.
  3. Ana sistemin yeni bir sürümü yayınlandığında, sistemin güncellemesi bu yeni sürüm ile yapılabilmelidir. Bu esnada kullanıcı bilgisayarlarındaki ve/veya tüm sunuculardaki kayıt dosyaları, konfigürasyon ayarları, kullanıcı verileri, veritabanı dosya ve tabloları yapılan bu güncellemeden olumsuz etkilenmemelidir / silinmemeli / kaybolmamalıdır.
  4. Yazılım sisteminin kurulu olduğu ortamdan kaldırılması, Kurulum Kaldırma yazılımı kullanılarak yapılmalıdır. 
    1. Kurulumun kaldırılması esnasında, kaldırılan yazılımın, sistemde yüklü diğer yazılımlar ile ortak kullandığı dosyalar silinmemelidir.
    2. Kurulum Kaldırma yazılımı, sadece yazılımın mı yoksa hem yazılım hem de verilerin mi silinmek istediği bilgisini kullanıcıdan almalıdır ve bu doğrultuda silme işlemini yapmalıdır.
    3. Kurulum Kaldırma yazılımı, yazılım sisteminin kendi oluşturduğu dosya ve kayıtlar ile kullanıcılar tarafından oluşturulmuş kayıtların yedeklenmesine imkan veren bir yetkinliğe sahip olmalıdır.
    4. Yedeklenme işlemi sonrasında, yedeklenen veri ile yedeği oluşturan kaynak veri karşılaştırması yapılarak eksik veri olmadığı doğrulanmalıdır.