Agile Testing Üzerine Soru ve Cevaplar

Özellikle bir çok firmanın geleneksel yazılım geliştirme methodolojilerinden Agile’a geçiş yapmaları ile birlikte, test alanında da Agile Testing kavramı çok fazla kullanılır oldu. Hatta Agile Testing ile ilgili bir çok kitap ta yazıldı? Peki nedir bu Agile Testing?

Onur: Öncelikle Agile Testing’i (Çevik Test) açıkcası tek cümlede tanımlamak pek kolay değil. Agile Testing, agile yazılım geliştirme süreçlerinize adapte olan bir yazılım test sürecidir diye bunu en özet şekilde ifade edebiliriz. Bu ifadeyi tabiki açmak gerekir. Agile ile birlikte en temel olarak değişen şeyler; periyodik ve kısa zaman aralıklı canlıya bir müsteri için bir değer ifade eden geliştirmelerin çıkılması, kalitenin artık sadece tek kişinin ya da tek grubunun sorumluluğu olmaktan çıkmış olması ve takımın sorumluluğunda olması, değişimlere daha hızlı ve esnek bir şekilde yanıt verebilmek ve adapte olabilmek, ağır dokümantasyon ve proje hazırlık süreçlerinin daha hafifleştirilmesi, daha akıllı, pratik, efektif araçlar ve çözümler kullanarak mesela; Exploratory testing, Pairwise testing, Desk checking, otomasyon, devops pratikleri vb. ile yazılım geliştirme hızının ve verimliliğinin artırılması olarak sıralayabiliriz. Bütün bunlar Agile değerleri olan “kullanıcı etkileşimleri, çalışan yazılım, müşteri işbirliği ve değişime cevap verebilme” ile tam uyumluluk göstermektedir.

Aslına bakılırsa Agile Testing bir mit ya da efsane değil. Eskiden yazılım test süreçlerinde yaptığımız temel şeyleri yine yapmaya devam ediyoruz. Geleneksek yöntemlerde yapılan, uzun ve komplike dokümantasyonlar, proje ve test hazırlık süreçleri ve manual eforlardan uzaklaşmaya çalışıyoruz. Bunun yanı sıra hata bulmaktan ziyade, hataları önlemeye daha fazla odaklanıyoruz. Burada da “early testing” (erken test) devreye giriyor. “Erken Test” için, testin yazılımın en erken safasında devreye girmesi diyebiliriz. Product Discovery (ürün keşfi) aşamalarında, UI-UX süreçlerinde, User Story (kullanıcı hikayesi) oluşturulmasında, refiment toplantılarında test ekibinin geri bildirimler vermesi buna örnek verilebilir. Dokümantasyon noktasında ise gerek test senaryolarını, gerek test raporlarını, ve diğer test ile ilgili dokumanları, mesela planlama, strateji vb. dokumanları olabildiğince sadeleştiriyor hatta bazılarından ise vazgeçebiliyoruz.

Agile ile birlikte test süreleri de kısaldığı için daha kısa zamanda daha etkin bir test süreci oluşturmamız gerekiyor. Buradaki temel amaçlarımız ise hatalardan arınmış bir ürünü canlıya atmak, riskleri minimize etmek, ürüne duyulan güveni yükseltmek, ürünün değerini ve kalitesini artırmaktır. Burada çok çeşitli açıdan ürünün değerini artırabiliriz. Örneğin; kullanılabilirlik, uyumluluk, kurulabilirlik, güncelleştirilebilirlik, performans, güvenlik, gibi testleri yaparak ürün değerini yükseltebiliriz. Agile yazılım yaşam döngüsünde, gereksinimlerin hazırlanma hızı ve bunlara ait geliştirmelerinde hızlanması ile birlikte, bu hıza test açısından da aynı şekilde yanıt vermek gerekiyor. Agile takımlar, iş birimleri ile çok yakın iş birliği içerisinde oldukları için gereksinimleri çok hızlı anlamaları ve bunları önceliklendirmeleri gerekmektedir. Bu süreçte, test uzmanları da, oyunun her anında geri bildirimleri ve yaptıkları çalışmalar ile etkin bir şekilde görev almalıdırlar. Geneleksel yöntemleri uygulamaya çalışan yerlerde olduğu gibi gibi herşey olup bittikten sonra geliştirilen özelliklerden haberdar olmamalıdırlar.

Diğer çok kritik konulardan biri ise “Whole Team Approach” (Tüm Takım Yaklaşımı) adını da verdiğimiz, ekibin bir bütün olarak hareket etmesidir. Agile ile birlikte test uzmanları artık bağımsız bir “Test Takımı”nın bir üyesi olmak yerine, “Agile Development Team” in (Agile Geliştirme Takımı) bir üyesi olmaya başladılar. User Story’nin (Kullanıcı Hikayesi) hazırlanmasından sonraki en temel iki sürecin development (geliştirme) ve test olduğunu söyleyebiliriz. Agile ile birlikte, müşteri açısından bir değere sahip olan bir geliştirmenin (artifact) hayata geçmesi için geçen tüm süreçlerden artık tüm takım sorumlu olmaya başladı. Dolayısı ile artık ürünün kalitesi de tüm takımın sorumluluğu altına girdi. Test uzmanları artık “Quality Police” (Katilte Polisi) ya da “Gate Keeper” (Kapı Bekçisi) gibi görülmemeli ve de böyle davranmamalılardır. Geliştirme hayat döngüsü içerisinde yer alan tüm testler ve test tiplerinden tüm takım sorumludur. Bu iş birliği sürekli ve sabit olarak devam etmelidir. Agile Geliştirme Takımı’nın birbirleri, iş birimleri ve tüm partiler ile mükemmel seviyede bir iletişimi olmalıdır. Developer’lar nasıl daha iyi test yapılacağını öğrenirken, test uzmanları da sistem mimarisi, API’ların detayları, iletişim protokolleri, otomasyon, performans, güvenlik gibi konularda daha fazla kendilerini teknik olarak geliştirerek, developerlar ile aynı lisanı konuşabilmeli ve onlara destek olmalılardır. Tabiki ekipteki her üye farklı seviyede test yapabilme yeteneğine sahiptir ve test uzmanları bu noktada geçmiş deneyimleri, test bakış açıları, hisleri, müşteri odaklı bakış açıları ve sistemleri hataya zorlama yetenekleri ile en iyi test yetkinliklerine sahip takım üyesidirler. Bu nedenle, test uzmanları gereksinimleri sadece GUI seviyesinde test etmemelilerdir. Zaten bunu açıkcası ekipteki bir çok kişi yapabilecek yetkinliktedir. Test uzmanları, ürünü ve sistemi daha da zorlayacak durumları dikkate almalı, alternatif senaryoları çıkarıp denemeli, hataları en erken safada bulmalı ve öngörmelilerdir. Bunların dışında kullanılabilirlik, performans, güvenlik, stabilite, uyumluluk, vb. açılardan da ürünü test etmeleri gerekir. Eğer bu süreçlerde test uzmanları bir bataklığa saplanırsa, tüm ekip test uzmanlarına el verip, onları o bataklıktan çıkarmalı ve ekipçe yollarına devam etmelilerdir. Bu şekilde tüm ekip olarak hareket edilerek, son kullanıcı için değer üretilmiş olunacaktır.

Son olarak değişime adapte olmak ve ona cevap vermek hakkında da birkaç şey söylemek istiyorum. Geliştirme yaşam dögüsü içerisinde gereksinimler, özellikler, mimari tasarımlar, araçlar, riskler, öncelikler değişebilir ve tüm bu değişimlere takım olarak adapte olunmalıdır. Dolayısıyla test uzmanları da “adaptive tester” (adapte olabilen test uzmanı) olmak zorundalar. Mesela, geliştirmelerin ilk safalarında MVP’ye (Minimum Viable Product) odaklanıp, riskleri biraz daha fazla kabul edebilirken, ilerleyen safalarda artık ürün de iyice olgunlaşdığında riskleri, öncelikleri dafa fazla dikkate alarak ilerleyebiliriz.

 

Bazı firmalarda test rolünün olmadığı durumlar da olabiliyor. Agile ile birlikte test uzmanlarına gerek var mı?

Onur: Açıkçası bu görüşte olanlar, gerçekten iyi bir test mühendisi ile çalışmamış, çalıştıkları test uzmanlarının yetkinliklerini kısıtlamış, ya da test uzmanlarının kendilerini geliştirmelerine yardımcı olmamış kişiler ya da kurumlardır. Çünkü iyi bir test uzmanı ile çalıştığınızda, test uzmanının sizlere neler katabileceğini çok daha iyi anlıyorsunuz. Yetkin bir test uzmanı, geliştirmelerin başlangıç aşamalarından canlıya çıkana kadar geçen sürede fonksiyonel, performans, güvenlik, kullanılabilirlik gibi konularda agile geliştirme takımlarına çok değerli katkılar sağlayacaktır. Ayrıca, bizde test uzmanı ya da test rolü yok diyen kuruluşlarda, aslında bal gibi test uzmanı rolü var. Çünkü test ihtiyaçları var ve ürünlerinin testlerini test uzmanları yerine ya developer’lar ya da Product Owner’lar yapıyorlar. Yani yeri geldiğinde development team içerisindeki farklı roller, test uzmanı rolü şapkasını giyip, paşa paşa test yapıyor. Tabiki burada yapılan test, deneyimli bir test uzmanın yapacağı testin yerini tam anlamıyla tutmuyor. Ancak, ekiplerdeki kişiler test anlamında eğitilerek, belli seviyede test bakış açısı kazanabilirler. İyi bir test uzmanı şüpheci, riskleri koklayan, sistemi manipüle etmenin yollarını arayan ve bilen, uç noktları düşünen ve bu durumları gerçekleştirerek testlerini yapan, alternatif senaryoları mutlaka test eden ve bu alternatifleri çoğullayan birisidir. Bunun yanında teknik anlamda da kendini geliştirmiş ise size otomasyon, güvenlik, performans testi gibi oldukça kritik konularda da inanilmaz değer katacaktır. Günümüzde Agile süreçler içerisinde önemli bir yeri olan DevOps kültürünün de en önemli parçalarından birisi otomasyon olduğu için hem test bilgisi hem de teknik anlamda yetkin test uzmanlarını Agile ekiplerde barındırmak, o ekibin gücüne güç katacaktır.

 

Agile olabilmek için kültürel olarak değişim şart mıdır? Ya da şirketlerin kültürleri Agile olmalarını ya da olamamalarını ne kadar etkiler?

Onur: Kesinlikle! Belki de Agile için en önemli olmazsa olmaz olan konu şirket kültürünün Agile ile uyumudur. Herşeyden önce bence Agile bir felsefedir ve bu felsefe; kişilerin birbirleri ile yoğun etkileşim içinde olmalarını, bir takım olarak uyumlu çalışabilmelerini, gereksiz prosedürler ve kurumsal fazlıklardan arınmalarını, değer odaklı olmalarını ve müşterilerine değer katan uygulamalar üretmelerini önerir. Eğer şirket kültürü Agile felsefesi ile uyuşmuyorsa kültürel değişim şarttır. Çünkü bir şirketin ne kadar agile olduğunu, firmanın kültürü çok ciddi olarak etkilemektedir. Bunu performans değerlendirmelerinden, şirketin toplantı kültüründen, insanların birbirlerinin sözlerini kesmeden dinleyip dilememelerinden, teknik borçlara önem verilip verilmemesinden, sürekli iyileştirme ve sürdürebilir mükemmelliğe önem verilip verilmemesinden, tüm birimlerin birbirleri ile olan iş birliği ve etkileşimlerinden, haddinden fazla mesai yapılıp, yapılmamasından vb. bir çok önemli gösterge ile anlayabilir hatta ölçebiliriz. Eğer, bir şirkette Agile kültürününü/felsefesini oturtamazsanız, o şirket Agile konusunda başarısız olacaktır. Burada da bu değişime en tepeden start vermek bence çok önemlidir. Agile kültürünü tepeden tırnağa şirket kültürüne nakşetmek gereklidir.  Bu sayede yukarıdan genel Agile hava dalgası alt kesimleri de etkisi altına alacak ve değişim daha da hızlı gerçekleşecektir.  Emir-komuta zinciri ile işleyen, ben ne dersem o olur zihniyetiyle ilerleyen bir kurumda “Sanal Agile” değişimi olacaktır. Eski dönemlerden miras kalan performans ölçüm sistemleri, bireyleri birbirleri ile yarıştıran taktikler ve ölçümler bir kenara bırakılmalıdır. Hedefler takım olarak verilmeli ve takım bu hedefleri başardığında, maddi ve manevi olarak takdir edilmelidir. Takım her zaman bireylerden daha önemli ve değerlidir. Dolayısı ile takım motivasyonunu sürekli üst seviyede tutmak, üretimi ve verimliliği de beraberinde getirecektir.

 

Peki Agile Tester kimdir? Bir Agile Tester’ın değerleri prensipleri neler olmalıdır?

Onur: Öncelikle bu soruya Lisa Crispin ve Janet Gregory’nin yazmış olduğu Agile Testing kitabından alıntılar yaparak cevap vermek isterim. Agile Testing kitabında bir Agile Tester’ın sahip olması gereken değerler ve prensipler oldukça güzel özetlenmiş. Agile Tester öncelikle değişikliklere adapte olabilen, hem teknik hem de iş birimleri ile son derece başarılı iletişim kurabilen, yazılım testinin temellerini ve özünü oldukça iyi bilen, süreçleri ve yaptığı işleri sadeleştirebilen, kompleks ya da karışık sistemleri analiz edebilen, riskleri koklama ve önleme becerilerine sahip, hataları en erken safada bulabilen, tüm süreçler boyunca sorduğu sorular ve vermiş olduğu geri bildirimlerle kalitenin yükselmesine katkıda bululan, müşterinin bir nevi temsilcisi olup, müşteri bakış açısı ile ürüne değer katan, teknik yetkinlikleri ile de süreçlerdeki üretkenliği maksimum seviyeye taşıyan bir test profesyonelidir. Tüm bunlarla birlikte bir agile tester mutlaka ekip içinde doğru davranışlar sergilemelidir. Bu takım harmonisi ve “whole team approach” tüm takım yaklaşımı için de oldukça kritiktir.

Bir Agile Tester’ın prensipleri neler olmalıdır’a gelecek olursak. Bunları aşağıdaki gibi özetlemek isterim. Bir Agile Tester:

  • Saygılı
  • Profesyonel
  • İstekli
  • Neşeli
  • Hızlı
  • Çabuk Öğrenebilen
  • Cesur
  • İletişim yeteneği üst seviyede olan
  • Keşfetmeyi, araştırmayı seven
  • Müşteri bakış açısına sahip ve müşteri için değer üreten
  • Riskleri azaltan
  • Değişimi kabullenip, kucaklayan
  • Sürekli iyileşmeyi benimsemiş ve bu yolda çalışan
  • Kalitenin yükselmesini destekleyen
  • Yaptığı işleri sadeleştiren ve basitleştiren
  • Takım üyesi olabilen
  • Ve mutlu olan

Bir test profesyoneli olmalıdır.

 

Bir çok test uzmanı ve IT dünyasındaki kişiler manuel testin ileride öleceğini söylüyorlar. Manual Test süreçleri ve test uzmanları gelecekte olmayacaklar mı?

Onur: Aslında yazılım testini bir bütün olarak düşünmek en doğrusu. Bir test uzmanı bence kendini manuel ya da otomasyon test mühendisi olarak ikiye ayırmamalıdır. Test otomasyon mühendisliği yapan bir test uzmanı, bir otomasyon projesine başlamadan önce manual test adımlarından geçmek durumundadır. Senaryoların otomasyon kodlarının yazılmasına başlamadan önce, bu senaryolara ait test tasarımını, test önceliklendirmelerini, test datalarının seçilmesini ve oluşturulmasını, test ortamlarının hazırlanmasını yapmak durumundadır. Bununla birlikte sürekli manuel test yapan bir test uzmanı ise kendini bence teknik olarak ilerletmesi gerekir. Test ile ilgili yetkinliklerine; API testleri yapabilme, browser’ların console’unu iyi kullanabilme, temel seviyede JavaScript bilgisine sahip olma, temel seviyede en azından “record” (kayıt) ederek performans testi senaryoları oluşturabilme, test süreçlerinde kendine kolaylık sağlayabilecek seviyede otomasyon araçlarını kullanabilme ve temel programlama bilgisine sahip olma gibi önemli yetkinlikleri eklemelidir. Bir test uzmanının, sadece manual test yaparak yazılım testinden büyük bir keyif alacağından şüpheliyim. Zaten tecrübelerimde, hem kendimde hem de yönettiğim ekiplerde bana bu durumu göstermiştir. Bunun için olabildiğinde yazılım testini bir bütün olarak düşünerek temel test bilgisi başta olmak üzere otomasyon, performans, güvenlik, kullanılabilirlik ve diğer “ility” testleri (compabitility, installabilitiy, interoperability, stability, etc.) konusunda bilgi ve deneyim sahibi olmak faydalı olacaktır.

 

Agile’da dokümantasyon konusunda kullanılabilecek yöntemler taktikler nelerdir?

Onur: Hangi dokümantasyonu yapıyor olursak olalalım (bu excel ile data analizi, powerpoint ile sunum, word ile bir makale olabilir) yaptığımız dokümantasyonları olabildiğince sadeleştirmeye çalışmalıyız. Zaten dokümanların amacı; bizlere ihtiyaç duyduğumuzda yardımcı, hatırlatıcı ve yol gösterici olmak olmalıdır. Eğer dokümanlar bizi ve diğer paydaşları yoracak düzeydeyse, fayda sağlamaktan çok külfet oluşturmaya başlamışlardır. Dokümantasyon taktiği olarak, bir doküman hazırlamaya başladığımızda ilk olarak dokümanımızın temel amacına odaklanmalıyız. Bu odak doğrultusunda, yazmak istediklerinizin ana başlıklarını çıkararak ilk işe başlayabiliriz. Burada sade bir text file’i ya da mind-map’ler kullanabiliriz. Ana başlıklarımızı belirledikten sonra bunların alt kırılımlarını ya da detaylarını oluşturmaya başlayabiliriz. Zaten ana iskeleti belirledikten sonra detayları oluşturmaya başlamak daha rahat olacaktır. Burada da yine Scrum’daki gibi belirli periyodlarla dokümantasyonunuzu şekillendirebiliriz. İlk olarak ana başlıkları oluşturma, ikinci olarak bunların alt kırılımlarındaki detaylara giriş yapma, sonrasında bu detayları adım adım tamamlama şeklinde ilerleyebiliriz. Bu süreçte yazı yazma, resim bulma, şekil çizme, infografik oluşturma, video ekleme, alıntı yapma, referans bulma vb. gibi alt süreçler olabilir. Bunları da planlayarak adım adım yapmak sağlıklı olacaktır. Bu yöntem, bir seferde oturup, devasa bir doküman hazırlamaktan çok daha etkili olacaktır. Hem bu sayede dokümantasyonun yarattığı can sıkıntısı problemini de minimize edebiliriz. J

 

Kariyer.net’de SCRUM Framework’ü ile yazılım geliştirme süreci nasıl yürütülüyor?

Onur: Bu noktada ekipler mümkün olduğunca bir sprint önden olacak şekilde refinement toplantıları (irdeleme ve analiz toplantıları) yapıyorlar. Genellikle tek refinement toplantısı, bir sonraki sprint’de yapılacaklar işleri detaylı konuşmak için yeterli olmuyor. Bundan ötürü, bir sprint içerisinde birden fazla refinement toplantısı yapabiliyoruz. Bu toplantılarda, üzerinde konuşulan işlerin user-story’si önceden PO tarafından belirli seviyede hazırlanmış oluyor. Bu toplantılara development team (developers & testers) dışında, UI designer ve UX uzmanlarımızda katılıyorlar. Bu sayede işler, tüm ekipce detaylı analiz edilebiliyor. Bu analizler sonucunda; tasarım, UX, backend, frontend, mobil, ana senaryo, alternatif senaryo ve test ihtiyaçları ortaya çıkmış oluyor. Bu analizler ve ihtiyaçlar netleşince, bunlara dayanarak ekipteki herkes bağımsız olarak her iş için bir SP (Story Point) değeri veriyor. Bu SP değerlerini verirken, geçmişte yapılan işlerin büyüklükleri dikkate alınıyor. Basit bir iş 2-3 SP tutarken, ortalama işler 5-8 SP tutabiliyor. Mümkün olduğunca bir story için 8 SP ve üzeri bir SP vermemeye gayret ediyoruz. Eğer o işin SP değeri 13 ya da 20 gibi bir değer alıyorsa o işi daha küçük parçalara bölmeye çalışıyoruz.

 

Agile Test Süreçlerinde Kullanılan Metrikler nelerdir?

Onur: Bu konuda çok çeşitli metrikleri takip ettiğimiz JIRA Dashboardlarımız var. En temel göstergelerimiz; Spint Velocity, Burn-Down Chart, Sprint Progress Bar, Sprint Board Status oluyor. Bunların dışında, development ve test üzerinde ne kadar open, in-progress, completed iş olduğunu gözlemliyoruz. Defect’lerle iligli olarak kaç defect open, in-progress, resolved, closed statüsünde bunlara bakıyoruz. Ayrıca, bu defect’lerin kritiklik seviyelerine, ortamlarına, nedenlerine de bakıyoruz. TestRail üzerinden test ile ilgili aktivite ve statü raporlarını gözlemliyoruz. Her sprint test uzmanı arkadaşlarımız bu metrikleri içeren sprint statü raporlarını paylaşıyorlar. Bunların dışında SonarQube ile statik kod analizi sonuçlarını takip ediyoruz. NewRelic kullanarak canlı sistemlerdeki hata oranları ve her hangi sıkıntılı bir durum olmadığını gözlemliyoruz. Tüm bunlarla birlikte sistem ekibimizin de kurmuş olduğu alarmlar ve takip ettikleri metrikler söz konusu. Burada PRTG gibi araçlar kullanıyorlar.

 

Agile bir ekipte Test Otomasyon Stratejisi Nasıl Olmalıdır?

 Onur: Otomasyon stratejinizi oluştururken ilk olarak dikkat etmeniz gereken şey ne tip bir otomasyon ihtiyacınızın olduğunu belirlemek olacaktır. Eğer bir word-press template firması iseniz sizin için GUI seviyesinde olan otomasyon testleri kritik iken, bir ödeme gateway’i iseniz o zaman ilk olarak API seviyesindeki testleri otomatikleştirmek mantıklı olacaktır. Agile Testing Quadrant’ına ya da Test Otomasyon Piramitine baktığımızda, ilk olarak otomasyona unit test seviyesinde başlamak faydalı ve mantıklı olacaktır. Unit Testlerin yazılmasında iş developer arkadaşlara düşüyor. Ancak test uzmanları da unit testleri review edip, bu testlere senaryo anlamında katkılar sağlayabilirler. Unit Test’leri developer’lar yazarlar ve yazmalıdırlar. Zaten TDD (Test Driven Development) yapıyorsanız, geliştirme öncesi unit testlerinizi yazmak durumundasınız. Bu seviyeden sonra API ve entegrasyon seviyesinde otomasyon yapmak mantıklı olacaktır. Bu testleri yazmak GUI seviyesindeki testlere göre daha kolay ve koşturulmaları da daha hızlıdır. Bu aşamadan sonra da GUI seviyesinde otomasyon yapabilirsiniz. Burada tabiki kullanılabilecek bir çok araç ve kütüphane mevcut. Test edeceğiniz sistemlerden, şirket kültürüne kadar bir çok etken araç seçimini etkileyecektir. Büyük bir organizasyonda birden fazla test otomasyon aracı kullanabilirsiniz. Genelde online sitelerde open source olarak Selenium Webdriver defacto olan bir otomasyon kütüphanesi iken mobildeyse Appium ön plana çıkmaktadır. Her iki otomasyon kütüphanesinin de çok güçlü bir destek kitlesi mevcuttur. Bunun dışında HP UFT, MicroFocus SilkTest, IBM Rational Functoinal Tester, Ranorex, TestComplete, Sahi Pro, Telerik Test Studio vb. çok sayıda ticari test aracı mevcuttur. Yapacağınız POC’ler ile size en uygun olan aracı seçebilirsiniz. Keza mobil test otomasyonu konusunda da Device Lab (Cihaz Laboratuvarı) çözümleri olan bir çok firma mevcuttur. Local device lab kurmak yerine remote device lab hizmeti alarak, mobil test otomasyon senaryolarınızı paralel olarak remote device laboratuvarlarında koşturabilirsiniz. Bu alanda SauceLabs (TestObject), TestDroid, BrowserStack, global olaraka ön plana çıkarken, ülkemizde de; Testinium, Momentum, Robotic.Mobi, Qaulify Labs gibi şirketler benzer hizmetleri sunmaktadırlar. Otomasyon kodlarını yazdıktan sonra bunları bir development pipeline sürecine dahil etmek gerekir. Böylece bu testleri rutin olarak belirli periyodlarla koşturabilirsiniz. Burada da Jenkins, Teamcity, Travis CI, GO CD, Shippable gibi CI/CD orkestrasyon araçlarını kullanabilirsiniz. Otomasyon sürecinde herşeyin otomasyonunu yazmak pek mümkün olmuyor. Bu nedenle ilk olarak sürekli tekrar eden test senaryolarını (regresyon testlerini) otomatikleştirmek mantıklı olacaktır. Bu süreçte Ayrıca testlerin koşturulması sonrasında yapılacak raporlama da oldukça kritiktir. Raporlama konusunda da bir çok raporlama kütüphanesi mevcuttur. ExtentReports, Allure, ReportPortal.io, gibi opensource kütüphanelerin Selenium Entegrasyonları mevcuttur. Ticari test otomasyon araçlarında ise raporlama özellikleri ürünlerin bir özelliği olarak kullanıcılara sunulmaktadır. Bu aşamaları başarı ile aştıktan sonra, görsel otomsayon testleri, performans testi otomasyonu, güvenlik testi otomasyonu gibi çeşitli otomasyon testlerini de sürecinize entegre edebilirsiniz. Bu süreçlerde, yazdığınız otomasyon kodlarının kalitesi ve bakımlarının kolay yapılabilmesi önemlidir. İyi yazılım geliştirme pratiklerini ve otomasyon tasarım kalıplarını otomasyon projelerinizde kullanmak, otomasyon projelerinizin kalitesini artıracaktır. Örneğin Selenium ile bir test otomasyonu yapıyorsanız, Page Object Model (POM), Screen Play Pattern, ya da Cucumber-BDD kullanarak testlerinizi yazabilirsiniz. Otomasyon konusu açıkcası bir derya deniz. Bu noktada benim kısaca önerilerim bunlardır. Ekstra bu konu ile ilgili sorularınız olursa swtestacademy.com sitesi üzerinden bana ulaşabilirsiniz.

 

Agile Testing süreçlerinde kullanılabilecek tool’lar nelerdir?

Onur: Aslında  bu soru sizin kullanmış olduğunuz teknolojiler ve yine ürünüze göre değişiklikler gösterebilir. Eğer web ve mobil ürünleriniz varsa aşağıdaki araçlar size fayda sağlayabilir:

  • Unit Test toolları: (Nunit, MBUnit, JUnit, MSUnit, Xunit, etc.)
  • API otomasyon toolları: (RestAssured, PostMan, SoapUI, Karate, etc.),
  • GUI otomasyon tooları: Selenium, Capybara, Cucumber, RobotFramework, commercial ürünler.
  • Görsel Otomasyon tooları: ImageMagick, ApplitoolsEyes, Galen Framework, PhantomCSS, etc.
  • Performans Test Tooları: Jmeter, Gatling, Locust etc.
  • Güvenlik Toolları: ZAP, Netsparker, CAST etc.
  • APM Tooları: Newrelic, AppDynamics, DynaTrace etc.
  • MOCK Servis Toolları: Mockito, Mockoon, Mocha, etc.
  • Orkestrasyon Tooları: Jenkins, Travis CI, GO CD, Shippable, TeamCity, BitRise, FastLane, etc.
  • Container Tooları: Docker, Rocket (RKT)
  • Provisioning Toolları: Ansible, Puppet, Chef, etc.
  • Logging Toolları: Logstash, GrayLog, etc.
  • ELK Stack: Elastic Search, LogStash, Kibana (Search – Log – Visualization)
  • Code Quality Tooları: SonarQube, Cast, etc.
  • Deployment Toolları: AppVeyor, Octopus Deploy, shell scripting,  etc.
  • Alerting Tooları: Pingdom, Nagios, PRTG (Network Monitor), etc.
  • API Gateway Tooları: Tyke, Kong, etc.

Ve benzeri bir çok tool’u süreçlerimize entegre edebiliriz.

 

Agile için başarı Kritileri Nelerdir?

Onur: Aslında bu soruda biraz özet yapmak gerekecek. Agile’da başarı için bence:

  • Değişime açık olmak.
  • Bir takım olarak çalışabilmek.
  • Değer odaklı çalışmak.
  • Yazılım Geliştirme yaşam döngüsündeki süreçleri olabildiğince sadeleştirmek ve optimize etmek.
  • Müşteri ve iş birimleri ile işbirliği içinde olmak.
  • Sürekli gelişime açık olmak.
  • Süreçlerdeki tekrar eden rutin işleri otomatikleştirmek.
  • Development ve Test süreçlerini bir bütün olarak görmek ve bu şekilde ilerlemek.
  • Bir işi bir bütün halinde değil, parça parça, değer odaklı hayata geçirmek.
  • Teknik borcu mutlaka zamanında ödemek. Ertelememek.
  • Insanların çalışacağı ortamları sağlıklı kılmak.
  • Geri bildirimler vermek ve geri bildirim almaya da açık olmak.
  • İyi niyetli olmak ve GÜVEN ortamı oluşturmak.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.