Yayım tarihi

Agile Proje Yönetimi & SCRUM

Agile,Kimine göre proje yönetişimbilimi,kimine göre çatı(framework)ler topluluğu.

Kısaca

Agile manifesto özetlenen bir yaklaşım biçimidir. İlk temeli Lean manufacturing (Toyota Production System by Taiichi Ohno)

ile atılmıştır.Yazılım geliştimeye uygulanmış hali Lean software development olarak çıkar.Fakat Agile,bir çok metodoloji ve

farklı pratikler içerir.

Lean SD’dışında  Scrum,bu metodolojilerden biridir.FDD(Feature Driven Development),DSDM(Dynamic Systems Development Method)

bu metodojilere ekleyebiliriz.XP(eXtreme Programming),BDD(Behaviour Driven Development),TDD(Test Driven Development)

CI(Continues Integration)pratikler arasında yeralır.Yani bu tekniklerden faydalarak yazılım geliştirme metodojileri uygulayabilirsiniz.

Biraz Scruma değinelim.

Scrum,adını Rugby oyunundan alır ve toplanarak oyunu başlatmanın yoludur.

Benzer şekilde Scrum Team planma oyunu yapar, roller ve görevler dağıtılarak herkesin aynı hedef için çalışması sağlanır.

Sprint,Product Backlog,Sprint Backlog kavramlarını üzerinden geçelim.

  • Scrum,iteratif ve artan bir yöntemdir.
  • Scrum,Analiz,Geliştime ve Test analizin paralel gitmesini sağlayan bir yöntemdir.

Peki bu nasıl olur?

Product Backlog,müşteri ile anlaştığınız önceliklendirilmiş high level gereksinim listesi olarak düşünebilirsiniz.

Sprint,Genelde 15-30 günlük(Time-Boxed) proje zaman dilimidir.

Ve bir proje 1’den fazla Sprint’ten oluşur.Örnek olarak 3 aylık bir proje,

15 günluk iterasyonlarla ilerleyecekse 6 Sprint’iniz olacak demektir.

Her gün Scrum takımıyla,Scrum Daily Meeting (max 30 dk ve ayakta) düzeleyerek genel durum hakkında

bilgi alırsınız.Günlük bir gözden geçirme yapmış olursunuz.

Herkese 3 soru ile bilgi sabihi olursunuz.Scrum Master üç soru sorar:

  • Dün ne yaptın?
  • Bugün ne yapacaksın?
  • Seni engelleyen ne idi?

Herbir sprintte Product Backlog’tan alacağınız bir veya birkeç  kaç grup işi yapmak için

Analiz,Development ve Test ‘i paralel olarak ilerletirsiniz.

Bir bakıma Product Backlog’un Low Level Gereksiminlerini gerçekleştirmek için

çalışırsınız.User Story oluşturarak ve bunlar üzerine Task’lar  açarak programın feature(özelliklerini) geliştrirsiniz.

Ve herbir sprint sonunda yapılan bu işler doğrultusunda Sprint Backlog’u oluşmuş olur.

Sprint Burndown Chart, ile günlük olarak sprint hedefine ne kadar kaldığınızı görebilirsiniz.

Sprint sonunda müşteriye demo yapılır.Sprint Demo.

Sprint Demo ardından,Sprinti değerlendirmek içinde bir retrorespectif toplantısı düzenleyerek SCRUM takımı özeleştirisini yapar,dersler çıkartır.

Aşağıdaki resim kısaca süreci açıklar.

Source: rss

Yayım tarihi

Uygulama Yaşam Döngüsü & Yazılım Geliştirme Yaşam Döngüsü

Bu iki kavram genelde karıştırılmakta.Biraz açıklık getirelim.

ALM(Application Life Cycle Management) ve SDLC(Software Development Life Cycle)

ALM ,SDLC den daha geniş bir kavramdır.SDLC süreci geliştirme sürecini ele alıp

SDLC=>Scope(initiaition)+Requirment Management+Build or Coding+Testing+Operations and Maintenance

süreçlerinden oluşurken ALM’de  bu süreçlere İş Yönetimi (Business Management)  de dahildir.

ALM = Governance+Development+Operation

ALM, iş yönetimi ile yazılım mühendisliğinin evliliği olarak düşünülebilir. 


Source: rss

Yayım tarihi

FMEA – Hata Modu ve Etki Analizi Tekniği – Severity – Priority – Likelihood – RPN

FMEA(Failure Mode & Effect Analysis) Proje ve Test yönetimi açısından önemlidir.

Öncelikle bir takım kavramların üzerinden geçelim.Kısaca anlatmaya çalışayım.

Risk : İstenmeyen bir olayın veya zararın gerçekleşme olasılığıdır.
Yazılım projeleri için genel olarak iki risk vardır.

Ürün(Yazılım) Riski ve Proje Riski

Ürün(Yazılım) riski,muhtemel risk alanlarınıza göre testlerinizi ve kaynakalrınızı nasıl yöneteciğinizi belirler.

1)ilk adımda kalite risk kategorisini belirleyerek işe başlarsınız.Yazılım projeleri için
Fonksiyonelite,Performans,Yük Kapasite,Operasyon ve Sürdürülebilirlik,Veri Kalitesi,Entegrasyon vb…
alanlara göre risk kategorilerinizi oluşturabilirsiniz.

2)Muhtemel Risk Alanlarının Girilmesi

Aşağıdaki gibi bir cetvel risk alanlarınızı kayıt altına alınmasını ve hesaplanmasını sağlar.

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi
1.002                
…                
2.001 Performans              
2.002                

Şimdi bu alanların üstünden geçelim.

Risk No, adından da anlaşılabileceği gibi risk id’si.

Kalite Risk Kategorisi : 1.Adımda bahsettiğimiz kategoriler.

Muhtemel Hata : İstenmeyen olay veya zarar

3) Derecelendirme yapın 

Severity : Sistem tarafından önemi,sistem derinliği,teknik taraftan değerledirilir

Priority : Müşteri tarafından önceliği,iş derinliği(değeri),iş(business) tarafıdan değerlendirilir

Likelihood : Gerçekleşme olasılığı

Severity & Priority genelde aşağıdaki katsayılar ile değerlendirmeye alınır.

1)Urgent
2)Very High
3)High
4)Medium
5)Low

Likelihood ise

1)Muhtemel(Yüksek)
2)Mümkün(Orta)
3)İhtimal Dahilinde olmayan(düşük)

olasılıklara sahip olur.

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi 2 1 2 AddToCart
1.002                

 

4)Risk Önem Katsayısını hesaplayın

RPN=Severity X Priority X Likelihood ile hesaplanır

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi 2 1 2 4 AddToCart
1.002                

5)Test yoğunluğunu belirleyin

RPN ‘den çıkan değer göre Test yoğunluğunuzu belirleyin.

Katsayı ne kadar küçük çıkarsa o kadar çok test yoğunluğuna sahip olacaktır.
Aralıkları aşağıdaki şekilde belirmek

1-20   : A
21-50 : B
51-65:  C
66-75 : D

Test önceliğiniz kapsam,zaman ve maliyet göz önüne alındığında

A>B>C>D olacaktır.

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi 2 1 2 4 A AddToCart
1.002                

sample

Source: rss

Yayım tarihi

Agile Testing on google TechTalks

Google Tech Talks December 9, 2005 Elisabeth Hendrickson ABSTRACT As more teams are adopting Agile practices such as XP and Scrum, software testing teams are being asked to become “Agile” as well. But what does that mean? Is the Agile label yet another buzzword? Or could it be Agile practices are actually changing the way software is built? In this talk Elisabeth Hendrickson shares her perspective on how test teams can be more Agile based on her experiences working as a tester on Agile teams. Along the way, she’ll provide an overview of how Agile practices differ from traditional practices and discuss what those differences mean for independent test teams

http://video.google.com/videoplay?docid=-3054974855576235846

 


Source: rss

Yayım tarihi

QTP – WebTable 'da Hücrenin içeriğine göre Kontrol kutusunun işaretlenmesi

rowNum=Browser(“AUT”).Page(“AUT”).WebTable(“Check”).GetRowWithCellText(“test data 1”)
Browser(“AUT”).Page(“AUT”).WebTable(“Check”).ChildItem(rowNum,1,”WebCheckBox”,0).Set “ON”

İlk satırda table’ın içeriğine göre satır numarasını bulursunuz.Daha sonra satır nosuna göre de sabit hücredeki
içeriğe göre Kontrol kutunuz işaretleyebilirsiniz.

test.html içeriği

<HTML>
<HEAD><TITLE>AUT</TITLE></HEAD>
<BODY>
<HR><br>

<TABLE border=”2″ cellpadding=”3″ cellspacing=”3″ Align=”center”>
<TR><TH>Chk</TH><TH>Data</TH></TR>
<TR><TD align=”center”><input type=checkbox name=DownloadchkBox value =’k_001′></TD> <TD align=”center”>test data 1</TD></TR>
<TR><TD align=”center”><input type=checkbox name=DownloadchkBox value =’k_002′></TD> <TD align=”center”>test data 2</TD></TR>
<TR><TD align=”center”><input type=checkbox name=DownloadchkBox value =’k_003′></TD> <TD align=”center”>test data 3</TD></TR>
<TR><TD align=”center”><input type=checkbox name=DownloadchkBox value =’k_004′></TD> <TD align=”center”>test data 4</TD></TR>
<TR><TD align=”center”><input type=checkbox name=DownloadchkBox value =’k_005′></TD> <TD align=”center”>test data 5</TD></TR>
</TABLE>

<br><HR>

</BODY>
</HTML>

Source: rss

Yayım tarihi

QTP (Quick Test Professional) nedir? diyenlere

İlgisini çeken yazılım geliştirici arkadaşlardan QTP (Quick Test Professional) nedir? gibi sorular geldi.

Kısaca “Fonksiyonel test yapan kara kutu test aracıdır.” diyebiliriz.

Biraz detaylı bilgiye buradan

http://en.wikipedia.org/wiki/HP_QuickTest_Professional

Demo versiyonunu şuradan

https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-127-24^1352_4000_100__

ulaşabilirsiniz.


Source: rss

Yayım tarihi

Software Testing için okunulası

Okunulası kitaplar.Faydalı olacaktır… 

  • Optimize Quality For Business Outcomes A Practical Approach to Software Testing (Paperback)
    by Golze (Author), Li (Author), Prince (Author)
  • Lessons Learned in Software Testing
    by  CEM KANER,James Bach
  • Test Process Improvement: A step-by-step guide to structured testing (ACM Press) (Hardcover)
    by Tim Koomen (Author), Martin Pol (Author)


Source: rss

Yayım tarihi

JUnit – Basit bir örnek

http://www.ic.sunysb.edu/stu/yosong/cse219/junit.html

import org.junit.*;

public class ExampleTest {

    /**
     * methods annotated with @BeforeClass are
     * called once before the test methods run
     */
    @BeforeClass
    public static void setUpBeforeClass() {
        ;
    }
   
    /**
     * methods annotated with @AfterClass are
     * called once after all test methods run
     */
    @AfterClass
    public static void tearDownAfterClass() {
        ;
    }
   
    /**
     * methods annotated with @Before are
     * called before every test case method
     */
    @Before
    public void setUp() {
;
    }

    /**
     * methods annotated with @After are
     * called after every test case method
     */
    @After
    public void tearDown() {
;
    }
   
    /**
     * methods annotated with @Test are
     * your actual Unit Test methods
     * test using:
     *    Assert.assertEquals
     *    Assert.assertTrue
     *    Assert.assertFalse
     *    Assert.assertNotNull
     *    Assert.assertNull
     *    etc.
     */
    @Test
    public void firstTest() {
;
    }
   
    @Test
    public void secondTest() {
;
    }

    @Test(expected=Exception.class)
    public void checkExceptionTest() {
;
    }
}


Source: rss