Uygulama Yaşam Döngüsü için Okunulası birkaç kaynak

Uygulama yaşam döngüsü(ALM-Application Lifecycle Management) için faydalı olacağını düşündüğüm bir kaç intrenet kaynağını paylaşmak istedim. http://davidchappellopinari.blogspot.com/2009/04/what-is-application-lifecycle.htmlDavid Chappell ALM tanımı üzerinde durmuş http://www.best-management-practice.com/gempdf/ITILV3_ASL_Sound_Guidance_White_Paper_Jan08.pdfUygulama Servis Kütüphanesi (Application Service Library-ASL) üzerinde durarak Uygulama Yönetimi(Application Management-AM)ve Uygulama Geliştirme(ApplicationDevelopment) sorumluklarını kısaca anlatan güzel bir whitepaper. http://www.tso.co.uk/amdemo/index.htmApplication Management üzerine TSO'nun OGC için hazırlığı kaynak.Linkteki sadece demo versiyonu.

Scrum methodology

Scrum ile proje geliştirme aşamalarını gösteren eğlenceli bir video...İzlemenizi tavsiye ederim. Scrum çalışma ortamını,User Story,Task,BurnDown Chart,Planlama Oyunu vb.güzel bir şekilde gösterilmiş.İyi izlemeler. http://vimeo.com/4587652 Scrum methodology from Soul' on Vimeo.

Scrum in under 10 minutes by Hamid Shojaee

Scrum in under 10 minutes  Learn the SCRUM software development methodology in less than 10 minutes. By the end of this fast-paced video, you'll know about burn-down charts, team roles,product backlogs, sprints, daily scrum... http://www.dailymotion.com/video/xec1mj_scrum-in-under-10-minutes_tech   Great Thanks to Hamid Shojaee

HP ALM - PPM & QC Integration- Simple RFC Video

HP ALM üzerinden PPM & QC Integrasyonunu gösterir. Kısaca Workflow aşağıdaki resimde gösterildiği şekildedir. Simple RFC HP PPM - QC Integration from Yusuf Sahin on Vimeo.    

Konfigurasyon,Değişim ve Sürüm Yönetimi

Sürüm(Release Management) ve konfigurasyon(Configuration Management) yönetimi değişiklikleri yönetmenin(Change Management) ve koordine etmenin anahtarıdır. Etkileşimini inceleyelim; Değişim yönetimi olmadan konfigurasyon bilgileri doğruluğunu hızla kaybeder.Doğru konfigürasyon bilgisi olmaz ise,değişimler için doğru bir etki analizi(impact analysis) yapılamaz. Konfigurasyon ve Değişim bilgileri doğru değil ise doğru bir Sürüm (Release) yönetimi gerçekleştirilemez. Bu durumda Gereksinim belirlemesi ,Geliştirme ve Testler doğru bir şekilde yapılamaz.

HP PPM & QC Integrasyonları

HP PPM(Project & Portfolio Management) ve HP Quality Center arasında iki tip integrasyon mevcut. CM4QC(Center Management for Quality Center) ALM(Application LifeCycle Management)(eski adı MAC(Managing Application Change)) Bu integrasyonların amacı,İş Birimleri ile BT birimleri arasında yakınlaştırma(Business-Development Alignment) sağlamak,IT Servislerini daha yönetilebilir kılmaktır.Bu integrasyonlar sayesinde ayrıca ITIL Servis yaklaşımının Servis Operasyona kadar(Service Operation) 'a kadar ilerletilmesini sağlayabilirsiniz.Operasyondan PPM'e gelmiş RFC'leri (Request for Change)'leri QC'ye aktarabilir ve süreçlendirebilirsiniz. Biraz da integrasyonları ve farklılıklarını inceleyelim. CM4QC ile PPM içinden QC projeleri yaratabilir ve QC kullanıcılarını atayabilirsiniz. PPM 'den QC Projelerindeki durumu grafiksel ve raporlama araçları ile  kolaylıkla görebilirsiniz. MAC Requirement(RFC) Defect bazında integrasyon ve senkranizasyon sağlayabilirsiniz. Uygun süreçler ve düzenlemeler ile strateji ve IT geliştirmelerinizin uzlaşımını kolaylaştırabilir,Risk,Zaman ve Maliyetlerinizi azaltabilirsiniz.

Sürekli Tümleştirme (Continuous Integration)

Sürekli Tümleştirme(Continuous Integration),geliştirilen uygulamada yapılan değişikliklerin etkisini gözlemleyebilmenizi sağlar. Bu sayade kaynak kodunda(source code) yapılan değişikliğin uygulamanın çalışmasına etkisini görebilirsiniz.Unit (Class),Bileşen(Component),Sistem,Fonksiyonel vb. testlerinin otomatizasyonu ve koşumunun sürekliğinin sağlanmasının yanı sıra diğer yardımcı araçlar ile Statik Kod Analizi,Class-Unit Test Covege 'ı da  vb. gözlemlenmesini sağlayabilirsiniz. Bu sayade,entegrasyon sorunlarını azaltabilir ve sürekli çalışır uygulamalar(sürümler) elde etmiş olursunuz.  Martin Fowler 'ın sürekli tümleştirme ile ilgili yazısına buradan ulaşabilirsiniz. Sürekli Tümleştirme Nasıl Çalışır? Yapılan geliştirme ve değişiklikler Kaynak Kodu Merkezine (Source Control Repository)otomasyon testleri ile birlikte gönderilir.En az günde bir defa olmak üzere (genelde 2-4 saatte 1)Kaynak Kodu Merkezinden  bütün kaynak çekilir derlenip,testleri ile birlikte çalıştırılır.Varsa hatalar mail,hata yönetim sistemi vb. yerlere kaydedilir.Bu sayade uygulama üzerinde hatalar gözlemlenir ve düzeltilir. Aşağıda grafiksel olarak sistemleri görebilirsiniz. 

Is agile affecting testing?

This is part 1 of the 5 part Agile Educational Video Series Agile Testing, A Practical Approach with Matt Braley-Berger. In this segment we kick off the series with an overview of Agile Testing and...   http://www.youtube.com/watch?v=yj8E4fhB1F8    

Systematic Testing of Software with Structurally Complex Inputs

 on GoogleTechTalks http://www.youtube.com/watch?v=wHJKiGURgKc Google Tech Talks January, 7 2008 ABSTRACT Modern software pervasively uses structurally complex data, for example web-traversal code operates on graphs that encode web pages, and IDEs manipulat..Home page: http://www-faculty.cs.uiuc.edu/~marinov

SCRUM (Agile) & Testing (V&V)

Bir önceki yazıda Scrum'ın bir geliştirme yaklaşımı(proje yönetim metedolojisi) olduğundan bahsetmiştik. Testing açısından SCRUM 'ı inceleyelim. Testing'in tam ve genel bir tanımı olmamakla birlikte Testing = Verification (Doğrulama) + Validation (Geçerleme) aktivitelerinin bütünü olduğunu belirtelim. Verification (Doğrulama) :Doğru ürünü üretiyor muyuz? (What)sorusunun cevabını Validation (Geçerleme) : Ürünü doğru üretiyor muyuz? (How)sorusunun cevabını verir. Bu iki sorunu sorunu cevabını verebilmek için Static (statik) ve Dynamic (dinamik) testing 'ten faydalanılır. Static Testing     : Gözden Geçirme,inceleme aktiviteisidir.Herhangi bir koşum yapılmaz. (Quality Control) - Verification ile ilgilidir. Dynamic Testing : Script(test) Koşum tabanlı aktivitedir. (Quality Assurance) - Validation ile ilgilidir. Static ve Dynamic testing birbirinin tamamlayan aktivitelerdir. Biraz da test level'larına değinelim. Unit Integration System & Performance User Acceptance(UAT) adımlarından oluşur ve her bir adım için statik ve dinamik testing aktivitelerinde bulunulmalıdır. Şimdi SCRUM 'a geri dönelim. Daily Scrum Meeting, OnSite Customer ,Refactoring,CI (Continues Integration)   verifikasyon ve validasyon yapmanıza yapmanızı sağlayacaktır.Peki bu nasıl olacak? Öncelikle Analiz - Development - Test aktiviteleri ve bunu her Sprint için paralel olarak gerçekleştirildiğini tekrar belirtelim. PO(Product Owner) - müşterinin ihtiyaçlarını(onsite) toplar,gereksinimlerinizi,user story 'lerinizin analizlerini ve yazımınıDeveloperlar ve testerlar birlikte yapar.(statik aktivite-gözden geçirme,inceleme,verifikasyon) Scrum Master - Daily Scrum Meeting 'lere başkanlık eder ve günlük bir gözden geçirme sağlanır.(verifikasyon) Developer'lar Unit ve Integrasyon testleri hazırlar.(validasyon) ve refactoring yaparlar(verifikasyon).Tüm kodlar source kontrol sisteminden(cvs,svn) kısa zaman aralıkları(1-2 saat) ile CI(Continues Integration) tooluna bütün dinamik testleri ile aktarılır.Böylece Kısa zaman aralıklı ve sürekli validasyon sağlanır. Testerlar,Sistem ve Performans testleri için test scriptlerini hazırlar.Burada Click & Record toollardan çokça faydalanılır. Sprint sonlarında müşteriye kısa bir demo(UAT) yapılır ve onayı alınır.Müşteri için doğru ürün doğru bir şekilde üretilmiş mi? bu sorunun cevabı alınır. Bunu 15-30 günlük Her Sprint sonu için gerçekleştirisiniz  

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. Sprinti değerlendirmek içinde bir retrorespectif toplantısı düzenleyerek özeleştiride bulunur,dersler çıkartırsınız. Aşağıdaki resim kısaca süreci açıklar.  

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. 

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.xlsx (9,33 kb)

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  

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> test.html (876,00 bytes)  

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.

Myths about myths in Software Testing

Software testing üzerine myth'ler. http://video.google.com/videoplay?docid=9201358836489565079&ei=5XYpSbH6BI2A2wKuwKH3Bg&q=software+testing

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)

Becoming a Software Testing Expert

Google TechTalks June 13, 2006 James Bach http://video.google.com/videoplay?docid=6852841264192883219

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() { ;     } }