Çevik çalışma ortamında yazılım test mühendisinden beklenenler nelerdir?

Çevik (Agile) yaklaşım, yazılım geliştirme sürecindeki değişikliklere hızlı ve esnek bir şekilde yanıt verebilmek için tasarlanmış bir çalışma çerçevesidir. Bu çalışma çerçevesi, yazılım ürününün daha hızlı teslim edilmesine, müşteri geri bildirimlerinin daha etkili bir şekilde kullanılmasına ve sürekli bir geliştirme döngüsünün oluşturulmasına olanak tanır.

Çevik yaklaşımda, test mühendisleri de yazılım geliştirme mühendisleri ve iş analistleri gibi geliştirme takımlarında önemli bir role sahiptir. Bu yazıda, Çevik yazılım geliştirme ortamında test mühendislerinden beklenenler konusuna değineceğim.

Çevik Yazılım Geliştirmenin Temelleri

Çevik proje üzerinde çalışan bir test mühendisi, geleneksel projede çalışan bir test mühendisinden farklı şekilde çalışacaktır. Test mühendisleri, Çevik projelerin temelinde yatan değerleri ve prensipleri anlamalı ve test mühendislerinin de diğer paydaşlar gibi bütün takım yaklaşımının ayrılmaz bir parçası olduğunu bilmelidir. Çevik projedeki paydaşlar birbirleriyle erken ve sık iletişim kurarlar, bu da hataların erken aşamalarda giderilmesine ve kaliteli bir ürünün geliştirilmesine yardımcı olur.

Çevik Yazılım Geliştirme ve Çevik Manifesto

Hepimizin bildiği gibi Çevik Manifesto, dört değer ifadesi içerir:

Süreçler ve araçlardan ziyade bireyler ve aralarındaki etkileşimlere
Kapsamlı dokümantasyondan ziyade çalışan yazılıma
Sözleşme pazarlıklarından ziyade müşteri ile iş birliğine
Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye önem vermek.

Çevik Manifesto, soldaki kavramların da değerli olduğunu kabul ederken, sağ taraftakilerin daha büyük değere sahip olduğunu iddia etmektedir.

Bütün Takım Yaklaşımı

Çevik projelerde kalite konusu takımın tamamının sorumluluğundadır. Bütün takım yaklaşımının özü, diğer ekip üyeleriyle birlikte test mühendislerinin de geliştirme sürecinin her adımında uyum içinde çalışmasıdır. Test mühendisleri, geliştiricilerle ve iş temsilcileriyle yakın iş birliği yaparak istenen kalite düzeylerinin sağlanmasını sağlayacaklardır. Bu, uygun kabul testlerini oluşturmalarına yardımcı olmak için iş temsilcileriyle desteklenerek, test stratejisi konusunda geliştiricilerle iş birliği yaparak ve test otomasyon yaklaşımlarını kararlaştırarak gerçekleştirilir. Test mühendisleri, böylece test bilgisini diğer takım üyelerine aktarabilir ve ürünün gelişimini etkileyebilirler. Ürün özelliklerinin sunulduğu, analiz edildiği veya tahmin edildiği herhangi bir danışmanlık veya toplantıda bütün takım yer alır.

Erken ve Sık Geri Bildirim

Çevik projeler kısa iterasyonlara sahiptir ve bu sayede proje ekibi ürün kalitesi hakkında erken ve sürekli geri bildirimler alır. Hızlı geri bildirim sağlamanın bir yolu, sürekli entegrasyondur.

Şelale yöntemi gibi sıralı geliştirme yaklaşımları kullanıldığında; müşteri ürünü, genellikle proje neredeyse tamamlandığında görür. Bu noktada, müşterinin sahip olabileceği herhangi bir sorunu etkili bir şekilde ele almak için genellikle çok geçtir. Çevik takımları, proje ilerledikçe sık müşteri geri bildirimi alarak çoğu yeni değişikliği ürün geliştirme sürecine entegre edebilirler. Erken ve sık geri bildirim, takımın iş değeri veya ilgili riski en yüksek olan ürün özelliklerine odaklanmasına yardımcı olur ve bu özellikler müşteriye öncelikli teslim edilir.

Erken ve sık geri bildirimin faydaları şunları içerir:

Daha sonra düzeltmenin pahalıya mâl olacağı gereksinim yanlış anlamalarını önlemek.
Müşterinin ürün özelliği isteklerini netleştirip önceliklendirerek, bunları müşteri için erken kullanılabilir hale getirmek.
Kalite sorunlarını (sürekli entegrasyon yoluyla) erken keşfetmek, izole etmek ve çözmek.
Düzenli proje momentumunu teşvik etmek.

İşbirlikçi Kullanıcı Hikayesi Oluşturma

Genellikle, test mühendisinin benzersiz perspektifi, eksik ayrıntıları veya işlevsel olmayan gereksinimleri belirleyerek kullanıcı hikayesini geliştirir. Bir test mühendisi, kullanıcı hikayesi hakkında iş temsilcilerine açık uçlu sorular sormak, kullanıcı hikayesini test etmek için yöntemler önermek ve kabul kriterlerini doğrulamak suretiyle katkıda bulunabilir.

Kullanıcı hikayesinin işbirlikçi yazımı esnasında, beyin fırtınası ve zihin haritalama gibi teknikler kullanılabilir. Test mühendisi, kaliteli bir çıktı sağlanması için INVEST tekniğini kullanabilir. İyi bir kullanıcı hikayesi aşağıdaki özelliklere sahip olmalıdır:

Bağımsız (Independent)
Müzakere edilebilir (Negotiable)
Değerli (Valuable)
Tahmin edilebilir (Estimable)
Küçük (Small)
Test edilebilir (Testable)

3C (Card, Conversation, Confirmation) konseptine göre, bir kullanıcı hikayesi üç unsurdan oluşur:

Kart: Bir kullanıcı hikayesini tanımlayan fiziksel bir ortamdır. İhtiyacı, önem derecesini, beklenen geliştirme ve test süresini ve kullanıcı hikâyesi için kabul kriterlerini belirler. Tanım doğru olmalıdır çünkü ürün iş listesinde kullanılacaktır.
İletişim: Yazılı veya sözlü olabilir ve yazılımın nasıl kullanılacağını açıklar. Test mühendisleri; geliştiriciler ve iş temsilcilerinden farklı bir bakış açısına sahip oldukları için düşüncelerin, görüşlerin ve deneyimlerin değişimi için değerli bir girdi sağlarlar. İletişim, Release planlama aşamasında başlar ve kullanıcı hikayesi planlandığında devam eder.
Onay: İletişim aşamasında tartışılan kabul kriterleri, kullanıcı hikayesi işinin tamamlandı statüsüne çekilebileceğini onaylamak için kullanılır. Bu kabul kriterleri birden fazla kullanıcı hikayesini kapsayabilir. Kabul kriterlerini karşılamak için hem pozitif hem de negatif test senaryoları kullanılmalıdır. Onay aşamasında, çeşitli katılımcılar test mühendisi rolünü oynar. Bu katılımcılar içinde; performans, güvenlik, uyumluluk ve diğer kalite özelliklerine odaklanan uzmanlar da olabilir. Bir kullanıcı hikayesi işini tamamlandı statüsüne alabilmek için belirlenen kabul kriterleri mutlaka test olarak koşulmalı ve bu kriterlerin karşılandığı gösterilmelidir.

**Görsel 1:** https://expleoacademy.com/int/the-agile-tester-2/

Retrospektifler

Çevik geliştirme çerçevesinde retrospektif; her iterasyonun sonunda neyin başarılı olarak yapıldığı, neyin iyileştirilebileceği ve iyileştirmelerin nasıl uygulanacağı ile gelecek iterasyonlarda başarıların nasıl korunacağı konularını tartışmak için yapılan bir toplantıdır.

Retrospektifler, karşılıklı güvene dayalı olarak profesyonel bir ortamda gerçekleştirilmelidir. Test mühendislerinden retrospektif toplantılarında önemli bir rol oynamaları beklenir. Test, her iterasyonda gerçekleşen ve başarıya giden yolda vazgeçilmez olan bir aktivitedir. Test mühendisleri geliştirme takımının bir parçasıdır ve benzersiz bakış açılarını takımın hizmetine sunarlar. Test mühendisleri ve diğer tüm takım üyeleri, retrospektif toplantılarında test ve test dışı faaliyetler hakkında faydalı girdiler sağlayabilirler.

Sürekli Entegrasyon

Ürün teslimatları; her iterasyonun sonunda güvenilir, çalışan, entegre yazılım gerektirir. Sürekli entegrasyon, yazılımda yapılan tüm değişiklikleri birleştirerek ve değiştirilen tüm bileşenleri düzenli olarak, en azından günde bir kez entegre ederek bu zorluğu ele alır. Yapılandırma yönetimi, derleme, yazılım oluşturma, dağıtım ve test etme işlemleri tek, otomatik, tekrarlanabilir bir süreç haline getirilir. Geliştiriciler sürekli olarak işlerini entegre eder, sürekli build oluşturur ve bunları sürekli olarak test ederler. Bu sayede kod hataları daha hızlı tespit edilir.

Otomatik build ve test süreci günlük olarak gerçekleştirilir ve entegrasyon hatalarını erken ve hızlı bir şekilde tespit eder. Sürekli entegrasyon, test mühendislerinin otomatik testleri düzenli olarak çalıştırmasına olanak tanır ve bazı durumlarda otomatik testler sürekli entegrasyon sürecinin bir parçası olarak bile kullanılabilir ve bu sayede kodun kalitesi hakkında takıma hızlı geri bildirim sağlanabilir. Koşulan testlerin sonuçları, özellikle otomatik raporlar sürece entegre edildiğinde, tüm takım üyeleri tarafından görülebilir. Otomatik regresyon testleri, iterasyon boyunca sürekli olarak yapılabilir. İyi yapılandırılmış otomatik regresyon testleri, önceki iterasyonlarda teslim edilen kullanıcı hikayeleri de dahil olmak üzere mümkün olan tüm fonksiyonları kapsar. Otomatik regresyon testlerinde iyi bir kapsama, büyük entegre sistemlerin oluşturulmasına (ve test edilmesine) yardımcı olur. Regresyon testi otomatik olduğunda test mühendisleri; yeni özellikler, uygulanan değişiklikler ve hata düzeltmelerinin onayları gibi manuel testlere konsantre olmak için imkân bulurlar.

Release ve İterasyon Planlaması

Planlama sürekli bir etkinliktir ve bu durum Çevik yaşam döngülerinde de geçerlidir. Çevik yaşam döngüleri için, iki tür planlama yapılır: release (yazılan programı yayınlama, piyasaya sürme) planlaması ve iterasyon planlaması.

Release planlaması, genellikle proje başlangıcından birkaç ay önce ürünün tamamlanıp yaygınlaştırılmasına odaklanır. Release planlaması, ürün iş listesinin tanımlanması ve yeniden tanımlanmasıyla birlikte, büyük kullanıcı hikayelerinin daha küçük hikayeler içeren bir koleksiyona dönüştürülmesini içerebilir. Release planlaması, tüm iterasyonları kapsayan bir test yaklaşımı ve test planı temelini oluşturur. Release planları yüksek seviyeli (high level) planlardır. Detaylara girmezler.

Release planlamada, iş temsilcileri takım ile iş birliği yaparak Release için kullanıcı hikayelerini belirler ve önceliklendirir. Bu kullanıcı hikayelerine dayanarak, proje ve kalite riskleri belirlenir ve yüksek seviyeli (high level) bir efor tahmini yapılır.

Test mühendisleri, release planlamasına dahil olur ve özellikle aşağıdaki faaliyetlerde değer katarlar:

Kabul kriterleri de dahil olmak üzere test edilebilir kullanıcı hikayelerinin tanımlanması
Proje ve kalite risk analizlerine katılma
Kullanıcı hikayeleriyle ilişkili test etme eforunun tahmin edilmesi
Gerekli test seviyelerinin tanımlanması
Release için test planlaması yapılması

Release planlaması tamamlandıktan sonra, ilk iterasyon için iterasyon planlaması başlar. İterasyon planlaması, tek bir iterasyonun sonuna kadar olan süreyi dikkate alır ve iterasyon iş listesine odaklanır.

Seçilen kullanıcı hikayelerinin sayısı, belirlenmiş olan takım hızına ve seçilen kullanıcı hikayelerinin tahmini boyutuna göre belirlenir. İterasyon içeriği netleştirildikten sonra, kullanıcı hikayeleri görevlere bölünür ve bu görevler uygun takım üyeleri tarafından gerçekleştirilir.

Test mühendisleri iterasyon planlamasına dahil edilir ve özellikle aşağıdaki faaliyetlerde değer katarlar:

Kullanıcı hikayelerinin detaylı risk analizine katılım sağlamak
Kullanıcı hikayelerinin test edilebilirliğini belirlemek
Kullanıcı hikayeleri için kabul testleri oluşturmak
Kullanıcı hikayelerini görevlere ayırmak (özellikle test görevleri)
Tüm test görevleri için test efor tahmini yapmak
Test edilecek sistemdeki fonksiyonel ve fonksiyonel olmayan yönleri belirlemek
Testin birden fazla seviyesinde test otomasyon çalışmalarına destek sunmak ve katılmak

Proje ilerledikçe, ürün iş listesindeki her bir kullanıcı hikayesinde meydana gelebilecek değişiklikler de dahil olmak üzere, release planları değişebilir. Ek olarak, bir iterasyon sırasında iterasyon planları da değişebilir. Örneğin, tahmin sırasında nispeten basit olduğu düşünülen belirli bir kullanıcı hikayesi beklenenden daha karmaşık olabilir.

Release ve iterasyon planlaması, geliştirme faaliyetleri gibi test planlamasını da ele almalıdır. Testle ilgili ele alınması gereken konular özellikle şunları içerir:

Test kapsamı, kapsamdaki alanların test edilme derecesi, test hedefleri ve bu kararların nedenleri.
Test aktivitelerini gerçekleştirecek olan takım üyeleri.
İhtiyaç duyulan test ortamı ve test verileri, bunların ne zaman gerektiği ve proje öncesinde veya sırasında test ortamı ve/veya verilerinde herhangi bir eklemeye veya değişikliğe ihtiyaç olup olmadığı.
Test aktivitelerinin hangi geliştirme faaliyetleriyle nasıl ilgili olduğu da dahil olmak üzere; fonksiyonel ve fonksiyonel olmayan test aktiviteleri için zamanlama, sıralama, bağımlılıklar ve önkoşullar (örneğin, regresyon testlerinin ne sıklıkla çalıştırılacağı, hangi özelliklerin diğer özelliklere veya test verilerine bağımlı olduğu vb.)
Ele alınacak proje ve kalite riskleri

Ek olarak efor tahminleri yapılırken, gerekli test aktivitelerini tamamlamak için gereken zaman ve çaba da dikkate alınmalıdır.

Bağımsız Test için Organizasyon Seçenekleri

Bağımsız test ekipleri genellikle hataları bulmada daha etkilidir. Bazı Çevik takımlarda, geliştiriciler otomatik testler şeklinde birçok test oluştururlar. Bir veya daha fazla test mühendisi takımda yer alır ve birçok test görevini yerine getirir. Ancak, bu test mühendislerinin takımdaki konumları nedeniyle bağımsızlık ve nesnel değerlendirme konularında yeterli özeni gösterememe riski vardır.

Diğer bazı Çevik takımlar, tamamen bağımsız ayrı test takımlarını koruyarak, her sprint’in son günlerinde takıma test mühendisleri atayabilirler. Bu uygulama bağımsızlığı koruyabilir ve bahsi geçen test mühendisleri yazılımın objektif, tarafsız bir değerlendirmesini sağlayabilir. Ancak, zaman baskısı, üründeki yeni özelliklerin anlaşılamaması ile paydaşlar ve geliştiricilerle ilişki sorunları, genellikle bu yaklaşımda sorunlara neden olur.

Üçüncü bir seçenek, uzun vadeli bazda Çevik takımlara atanan test mühendislerinin bağımsız ayrı bir test ekibi oluşturmasıdır. Bu şekilde, bağımsızlıklarını korumalarına, ürünü iyi anlamalarına ve diğer takım üyeleriyle güçlü ilişkiler kurmalarına izin verilmiş olur. Ayrıca bağımsız test ekibi; uzun vadeli ve/veya iterasyon bağımsız faaliyetler için özel test mühendislerine de sahip olabilir. Örneğin otomatik test araçları geliştirme, fonksiyonel olmayan testleri gerçekleştirme, test ortamları ile verilerini oluşturma ve destekleme ve bir iterasyon içinde iyi yönetilemeyebilecek test seviyelerini gerçekleştirme (örneğin sistem entegrasyon testi).

Çevik Bir Takımda Test Mühendisinin Rolü ve Becerileri

Çevik takımlarda, test mühendislerinin tüm diğer takım üyeleri ve paydaşlarla yakın iş birliği yapmaları gerekmektedir. Bu durum, test mühendislerinin sahip olması gereken beceriler ile bir Çevik takım içinde gerçekleştirdiği faaliyetler açısından birçok sonucu beraberinde getirir.

**Görsel 2:** https://www.clearvision-cm.com/blog/how-to-hire-an-agile-tester/

Çevik Yazılım Geliştirme Çerçevesinde Test Mühendisi Becerileri

Çevik yazılım geliştirme çerçevesinde bir test mühendisi; test otomasyonu, test odaklı geliştirme, kabul testi odaklı geliştirme, beyaz kutu, siyah kutu ve deneyime dayalı test gibi alanlarda yetkin olmalıdır.

Çevik metodolojileri, takım üyeleri arasındaki iş birliğine, iletişime ve etkileşime büyük ölçüde bağlı olduğundan, Çevik takımlardaki test mühendislerinin iyi bir kişisel iletişim becerisine sahip olmaları gerekmektedir. Çevik takımlardaki test mühendisi ayrıca aşağıdaki özelliklere sahip olmalıdır:

Takım üyeleri ve paydaşlar ile olumlu ve çözüm odaklı iletişim kurmalıdır.
Ürün hakkında eleştirel, kalite odaklı ve kuşkulu düşünce yapısı sergilemelidir.
Yazılı belgelere tamamen güvenmek yerine paydaşlardan bilgi toplamalıdır.
Test sonuçlarını, test ilerlemesini ve ürün kalitesini doğru bir şekilde değerlendirip rapor etmelidir.
Test edilebilir kullanıcı hikayelerini, özellikle kabul kriterlerini tanımlamak için paydaşlarla birlikte etkili bir şekilde çalışmalıdır.
Takım içinde iş birliği yaparak, yazılım geliştiriciler ve diğer takım üyeleriyle birlikte çalışarak test yapmalıdır.
Değişikliklere hızlı bir şekilde yanıt vererek; test senaryolarını değiştirme, yeni senaryolar ekleme veya senaryo iyileştirme çalışmalarını yürütmelidir.
Kendi işini planlamalı ve organize etmelidir.

Tüm test mühendisleri için, özellikle Çevik takımlardaki test mühendisleri için; sürekli beceri gelişimi, kişisel iletişim becerileri de dahil olmak üzere hayati önem taşımaktadır.

Çevik Bir Takımda Test Mühendisinin Rolü

Bir Çevik takımdaki test mühendisinin rolü; sadece test durumu hakkında değil, test ilerlemesi ve ürün kalitesi ile birlikte sürecin kalitesi hakkında da geri bildirim sağlayan faaliyetleri kapsar. Bu faaliyetler şunları içerir:

Test stratejisini anlama, uygulama ve güncelleme
Test kapsamını ölçme ve raporlama
Test araçlarının uygun kullanımını sağlama
Test ortamlarını ve test verilerini yapılandırma, kullanma ve yönetme
Hataları raporlama ve çözüm için takım ile birlikte çalışma
Diğer takım üyelerine testin ilgili yönleri konusunda koçluk yapma
Release ve iterasyon planlaması sırasında uygun test görevlerinin planlanmasını sağlama
Gereksinimleri netleştirmek için geliştiriciler ve paydaşlarla aktif iş birliği yaparak özellikle test edilebilirlik, tutarlılık ve eksiksizlik açılarından yardımcı olma
Takım retrospektiflerinde proaktif olarak yer alarak iyileştirmeler önerme ve uygulama

Çevik bir takımda, her takım üyesi ürün kalitesinden sorumlu olup test ile ilgili görevleri de yerine getirmek konusunda rol oynar.

Çevik organizasyonlar, test ile ilgili aşağıdaki organizasyonel risklerle karşılaşabilir:

Test mühendisleri geliştiricilere çok yakın çalıştıkları için uygun test bakış açısını kaybedebilirler.
Test mühendisleri; takım içinde verimsiz, etkisiz veya düşük kaliteli uygulamalara hoşgörülü veya sessiz kalabilirler.
Test mühendisleri zaman kısıtlı iterasyonlarda gelen değişikliklere yetişemeyebilirler.

Bu riskleri azaltmak amacıyla organizasyonlar, testin bağımsızlığını korumak için alınabilecek önlemleri göz önünde bulundurabilir.