Ne Kadar Agile Tester’iz ?

Bu yazımda sizlere her sabah kimi zaman soluk soluğa yetiştiğimiz, vazgeçilmez daily stand-upları olan, kimi zaman hararetli tartışmalara sahne olan grommingleri, reviewleri ile bizleri kendimize getiren, bazen de 3 günlük efor az mı, 5 günlük efor fazla mı acaba diye kafa patlattığımız story pointleri ile günümüzü neşelendiren Agile-Scrum dünyasına bir test uzmanı gözüyle bakacağız.

Agile kavramı konuşulmaya başlandığında ilk söylenen kelime “çeviklik”. Peki nedir bu çeviklik, neden çevik olmamız isteniyor? Çeviklik kavramını, içinde bulunduğumuz projenin sürekli değişimine hızlı ve tam uyum sağlamak, yeni fırsatlar yaratmak için her an hızlı değişimlere açık olma yeteneği olarak düşünebiliriz. Peki bir test uzmanı nasıl çevik olur? Şimdi, haftada 2 (kimi zaman 3) kez canlıya çıkılan, analiz dokümanının günde en az 2 kez değiştiği, rakip şirketlerle lansman yarışında olduğunuz bir proje hayal edin. Böyle bir ortamda bir test uzmanı bu sürece nasıl adapte olabilir, nasıl çevik kalabilir?

İster Agile metodolojisini eksiksiz, tam ve doğru bir şekilde uygulayalım, istersek de dostlar alışverişte görsün bizim de Scrum ekibimiz var diyelim, daily scrum meetingler bizlerin bu yolda vazgeçilmezidir. Ekipte kim hangi task üzerinde çalışıyor, takıldığı bir yer var mı eğer varsa ben bu konuda arkadaşıma nasıl yardımcı olabilirim, test sürecini etkileyecek bir değişiklik söz konusu mu, teste acil gelebilecek ya da gecikecek bir durum var mı, test ekibinden beklenilen bir test datası, test ortamı hazırlığı vs. bir beklenti söz konusu mu, ya da olabilir mi soruları mevcuttur. İşte tüm bu ve buna benzer nedenlerden dolayı daily scrumlar hem test uzmanı hem de tüm ekip üyeleri için önemli bir toplantıdır. Daily süresince o güne ait ekibin iş akışını öğrenip, toplantı sonrası günümüzü planlarken daily notlarını göz önünde bulundurmalıyız.

Agile’in temelinde eğer çeviklik, hızlı değişim kavramlarından bahsediyorsak, Agile Testing’de de karşımıza “Test Otomasyon” kavramının çıkması kaçınılmaz. Çünkü yapılan her bir değişiklikte, canlıya her çıkışta binlerce test senaryosunun defalarca koşulması zor, uzun ve maliyetli olacağından test otomasyonda oluşturacağımız regresyon suitlerimiz işimizi oldukça kolaylaştıracaktır. Çıkılan her build için defalarca test otomasyon suitlerimizi koşabilir, var olan hataları belirli kriterler çerçevesinde raporlayıp ilgili kişilere anlık mailler atabiliriz. Tüm bunlar test süreçlerimizi çevik hale getirmemize destek olacaktır. Critical, E2E, regression, smoke vs. gibi oluşturacağımız farklı test suitleri ile de koşumlarımızı özelleştirebileceğiz. Ayrıca bu çevik yapı bize manuel olarak gözden kaçan birçok bug bulmamız, reproduce edemediğimiz bir çok case için tekrarlama şansını da verecektir. Yani çeviklik test kalitemizi direkt olarak olumlu yönde etkileyecektir. Burada dikkat edilmesi gereken nokta şudur: test otomasyon yapıyoruz fakat her release için regresyon suitimizi koşamıyor, manuel test ekibinin yükünü hafifletemiyor, maintain süreçleri can sıkıcı hale geliyorsa, test otomasyon çeviklik değil ekibimize yük getirmiştir demektir.

Bir test uzmanı için güçlü ve etken bir iletişim vazgeçilmezdir. Bazen hazırlanacak tek bir test datası için farklı departmanlardan onlarca kişiyle görüşmeniz gerekebilecektir. Eğer çeviklik kavramı penceresinden iletişimi değerlendirecek olursak kurduğumuz birebir ya da toplu iletişimlerimiz de çevik olmalıdır. Olabildiğince görüşmelerimizi yüz yüze yapmaya özen göstermeliyiz. Yüz yüze iletişimde kendimizi daha rahat ve kolay ifade ettiğimiz, işlerin çoğu kez hızlandığı kaçınılmaz bir gerçektir. Ayrıca süreç içerisinde herhangi bir konu ile ilgili bilgi bekleniyorsa, sürekli olarak aynı mail üzerinden “fyi” ya da “any update” yerine konuyu ve süreci toparlayan, aciliyeti vurgulayan, ya da bloklanan – beklenen noktayı tekrar özetleyen kısa bir maille tekrar dönülmesi daha anlamlı ve etkili olacaktır.

Agile kavramı ile birlikte tartışılan bir diğer konu ise dokümantasyondur. Dokümantasyon olmalı mı, olacaksa nasıl olmalı. Çevik bir sürecekte dokümantasyon yapılırken nelere dikkat edilmeli? Oluşturulan doküman nasıl güncel tutulmalı. Çevik bir süreçte dokümantasyonun fayda sağlaması için nasıl yapılması gerekir. Bu noktada test uzmanının imdadına checklistler yetişiyor. Kullanışlı, kolay güncellenebilen ana istekleri kapsayan bir checklist test sürecimizi çokça kolaylaştıracaktır. Hatta regresyon test suitleri için manuel ekibin hazırlayacağı bir kritik işlem seti checklisti işleri büyük ölçüde kolaylaştırır. 

Agile süreçlerde bug reporting konusunda da yine çeviklik, hızlı aksiyon alma asıl amacımız olmalı. Test ortamının ve test datasının çeşitliliğine göre önemli noktalarda genel tanımlara gidilebilir ya da bu noktalar bahsedilmeyebilir. Fakat eğer hatanın ortaya çıktığı test datası, hatanın karşılaşıldığı saat-tarih bilgisi, ortam bilgisi paylaşılmayacaksa bu hatanın her halükarda reproduce edilebilir olması gerekir. Örneğin mobil testlerde karşılaştığımız bir hata specific bir cihaza, versiyona ya da işletim sistemine bağlıysa bu önemli bilgi mutlaka paylaşılmalıdır.

Tüm bunları uygulayabilmek, belli yaptırımlara sahip olmak, gerçekten çeviklik merkezli çalışabilmek için kurum kültürü kimi zaman en büyük destekçimiz olurken, kimi zamanda karşımızdaki aşılması güç en zor engeldir. Her ne kadar Agile-Scrum dediğimiz yapıların kendilerine ait, özel kuralları olsa da bazen hatta çoğu kez bu kuralların esnetildiğini, yumuşatıldığını hatta daha da ileri gidip değiştirilebildiğini görmek mümkün olabiliyor. Scrum board üzerindeki işlerin geriye gitmesi, dailylerin sabah değil de akşam yapılması gibi farklı durumları örnek gösterebiliriz. Kurum kültürünün getirdiği farklılıklar kimi zaman hatalı dahi olsa eğer sürece hızlı bir şekilde entegre olup, etken ve doğru tepkilerle sürece katkı sağlayabiliyorsa her şey yolunda demektir. 

Keyifli, çevik günler 😉