Yusuf Şahin

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.

Quality Center, Testing PPM, HP, ALM

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.

Agile, ITIL, Testing test management, IT Servis Yönetimi, ITSM, alm, sdlc, scrum, risk analizi

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.

Quality Center, Testing ppm, IT Servis Yönetimi, sdlc, test management, testing

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. 

Agile, Testing test management, testing, alm, scrum, sdlc

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

Agile, Testing scrum, testing, test management

 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

Testing testing

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, Testing test management, testing, scrum, static, dynamic

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.

Agile, Genel, Testing alm, sdlc, test management, scrum, product backlog, sprint backlog, sprint, risk analizi

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. 

Genel, Testing alm, sdlc

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.

Ş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.

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

RPN=Severity X Priority X Likelihood ile hesaplanır

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.

sample.xlsx (9,33 kb)

Quality Center, QTP, Testing risk analizi, testing

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

Agile, Testing

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, Testing

İ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.

Testing

Software testing üzerine myth'ler.

http://video.google.com/videoplay?docid=9201358836489565079&ei=5XYpSbH6BI2A2wKuwKH3Bg&q=software+testing

Testing

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)

Testing

Google TechTalks June 13, 2006 James Bach

http://video.google.com/videoplay?docid=6852841264192883219

Testing

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

Testing, Java

ABSTRACT

The extensive use of automated testing has been a breakthrough practice in improving the quality of software produced by developers. By now, many companies ha...

Testing

Uzun zaman önce linki verilmeliydi belki ama yeni aklıma geldi.
Aşağıdaki linklerden International Software Testing Qualifications Board(ISTQB)
syllabuslarına ulabilirsiniz.

Foundation Level : ISTQB Syllabus Foundation Level V2007, 12th April 2007
Advanced Level : Syllabus Advanced Level 2007 (official release)

ISTQB Standard Glossary of Terms used in Software Testing V.2.0, Dec, 2nd 2007

Internatinal Link : www.istqb.org
ABD : http://www.astqb.org/
Turkiyede bu misyonu üstlenen : www.turkishtestingboard.org

Testing