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
Source: rss
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
Source: rss
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.
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.
“Static Code Analiz” test araçları CI araçları ile entegre edilebilir ve bu sayade code verifikasyon aktivitelerine destek verilir.
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
Source: rss
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.
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:
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
Hp Quality Center 10 yepyeni özellikleri ile bu yılın başında piyasaya sürülmüştü.
Belki biraz geç bir yazı oldu ama yine de ekleyelim.
Cross Project Customization,Version Control,Sharing Libraries,Baselining,Test Resources Modul
ilk etapta göze çarpan ve etkileyici yeni özellikler.
Yeni özellikler hem test üst yöneticilerinin hem de tester’ların işlerini kolaylaştıracak.
Detaylı bilgiyi ekte bulabilirsiniz.
QualityCenter 10 – WhatIsNew.pdf (193,31 kb)
Source: rss
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
Blog’umu güncelledim.Yeni tasarım ve yeni kullanım özellikleri ile karşınızda…
Umarım yeni tasarımı beğenirsiniz.Görüş ve isteklinizi paylaşabilirseniz memnum olurum.
Hem blogun gelişmesi hem hem kendi gelişimim için faydalı olacaktır.
Source: rss
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 |
Source: rss
Aşağıdaki linkten Quality Center 10 – Agile Accelerator ulaşabilirsiniz.
Agile Accelerator ,HP Quality Center 10 ‘na agile metodolojiyi uygulamanızı sağlar.
https://h30406.www3.hp.com/campaigns/2009/wwcampaign/1-7K3IQ/index.php
Source: rss
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