Atölye15'te QA süreçleri

Atölye15 için pek çok şey söylenebilir fakat ben sürekli gelişen ve öğrenen bir ekip olduğumuzdan bahsederek söze başlamak istiyorum. Sürekli gelişmek ve yeni teknolojileri takip etmek bilişim sektörünün en önemli ayağıdır. Firmaların son trendleri takip ediyor olması özellikle yatırımcıların ilgisini çekecektir. Atölye15’in kapısından içeri girdiğiniz anda bu havayı hissediyorsunuz. Karşılaşılan bir probleme en uygun çözümü bulabilmek için böyle bir esneklik kazanabilmiş bir ekip ile çalışıyorsunuz.QA süreci ise daha çok taze olmasına rağmen oldukça kolay ilerliyor. Genelde developer’larda hakim olan “QA’e ne gerek var?” düşüncesi aşılmış. developer’lar ile tam bir takım çalışması yapılıyor. Bu durum da biraz ortak dil kullanımı ile kolaylaşıyor. Ekipte QA’e önyargı oluşturmamak için çözümlerle gitmek gerekiyor. Tabii ki beklenilen developer’lık değil; çözüm yolu ya da problemin kaynağını development dili ile bildirmek bile bu önyargıların kırılmasında büyük bir rol oynuyor.

QA’in ekip içindeki rolü sadece bug bulmak, olmuş olmamış demek değil, sistemi nasıl daha iyi hale getirebiliriz, nasıl farklı açılardan bakabiliriz sorularının cevabını bulmak. Burada da tester’lıktan ayrılıp gerçekten “kalite” üzerine yoğunlaşılıyor. Test ve agile süreçleri ile beraber ürünün kalitesinin arttığı da gözle görülebilir hale geliyor.

Agile’da test

Atölye15’in Scrum Agile metodolojisini sonuna kadar kullanan bir ekip olduğunu kesinlikle söyleyebilirim. Amaç %100 bug’sız bir sistem değil, yüksek riskli problemleri canlıya çıkmadan fark etmek ve yakalayabilmektir. Bu durum Test süreci için biraz zorlayıcı olabiliyor bazen. Tabii ki bu durum ekibin beraber iş geliştirmesi ile daha hızlı çözümleniyor. Ekipteki insanları tanıdıkça, geliştirmelerini gördükçe ve sistemi öğrendikçe potansiyel problemleri de öngörebilir hale geliyorsunuz.

Test süreci

Günlük hayatımızda “Sprint boyunca ne iş çıkabilir ki sadece sprint sonunda iş geliyor QA’lere” diye bir tabu var. Fakat durum maalesef öyle değil. Sprint’in ilk gününden son gününe kadar mutlaka bir işiniz oluyor. Sprint’in başında; özellikle ilk günlerinde sprint için alınan maddelerin hepsi için senaryolar hazırlanıyor. Görülen eksiklikler developer ve proje yöneticileriyle konuşulup teyitleşiliyor. Senaryolar hazırlanırken developer’lar da geliştirme sürecine başlıyor. her iki taraf için geliştirme sürecinde net olmayan noktalar ortaya çıkabiliyor. Bu durumda net olmayan noktalar için anlık toplantılarla ya da daily’lerde nasıl aksiyon alınacağı kararlaştırılıp çözüm üretiliyor. Branch-based development yapıldığı için geliştirmeler ilgili branch’e atılıyor, geliştirmeler tamamlandığında ortam artık QA’e bırakılıyor. Sadece ilgili branch ile ilgili kontroller bu ortamda yapılıyor. Farklı bir problemle karşılaşılması halinde bunu Staging ortamında kontrol ediyoruz. Eğer problem orada da varsa bug olarak açıyoruz. Bug’lar da kendi ortamlarında kontrol ediliyor. Eğer QA olarak işin tamamlandığından emin olursak branch müşteriye teslim ediliyor. Her canlı öncesi tüm sistem Staging ortamında kontrol ediliyor. Bunun için otomasyon üzerinde çalışıyoruz. E2E test seti üzerinden hızlıca kontrol edebileceğimiz ve proje için önemli olan senaryoları seçiyoruz. Bunların otomasyonu üzerinde çalışmalara devam ediyoruz.

Hangi Araçları kullanıyoruz

Senaryoların hazırlanması, story’lerin takibi senaryoların koşulması Jira’da Xray kullanılarak yapılıyor. Senaryoların yazımında Gherkin gramer yapısını kullanıyoruz. Bu sayede developer’lara da Cucumber’da kullanmaları için senaryoları verebiliyoruz. Bu gramer yapısında herkesin anlayacağı şekilde bir ortak dil kullanılıyor. Bunları temelde kullanılması gereken tool’lar olarak görebilirsiniz. Bunların dışında test için kullanılan Selenium, Postman gibi uygulamalar her zaman elimizin altında olmalıdır. Problemlerin kaynaklarına inecek kadar merakımızı ve kod okuma (En azından json gibi) özelliklerimizi de kullanmaktayız.

Unit Test

Developer’lar teste oldukça fazla önem veriyor. development sürecinin bir parçası olarak kendi testlerini de hazırlıyorlar. Cypress kullanılarak hazırlanan testlerde hata alınırsa ilgili story sisteme alınmıyor. Bu da kod kalitesini çok çok yükseltiyor. Development sürecinde test yazmanın ne kadar önemli olduğunu bir developer gözünden görmek isterseniz “Test yazmaya zamanımız yok” başlıklı Medium yazımızda ayrıntılı bilgi bulabilirsiniz.
Çalışma sistemimiz ve prensiplerimiz ile ilgili fikirlerimi sizlerle de paylaşmak istedim, umarım keyifli bir okuma olmuştur. Eğer bizimle çalışmak ve bu ekibin bir parçası olmak isterseniz, açık ilanlarımıza göz gezdirmenizi öneririz!

Bir dahaki yazımızda görüşmek üzere!