Test otomasyonu artık günümüzün yükselen değeri değil, ihtiyaçlara yönelik alt yapısı oluşturulmuş 7x24 iş yapabilecek bir kavram haline gelmiştir. Hemen hemen her yazılım projesi geliştiren firma artık test otomasyon alt yapısına sahip ve bu yapıya özel çalışmalarını hızla sürdürüyor.
Tabi ki test otomasyon süreçlerinin de geliştirilmesi sabit kalmıyor, otomasyon süreçlerine destek olacak ara katman otomasyon araçları (RPA), uygulamalar, eklentiler vb.. gibi hiç test otomasyon geliştirmesi yapmamış kişilerin bile bu alt yapıyı kullanabileceği şekilde tasarlanan yeni önyüzler geliştirilmeye devam ediliyor.
Örneğin; şuanda kullandığımı Micro Focus şirketinin UFT, ALM ve Sprinter ürünleri bize bu konuda çok büyük ve performanslı bir otomasyon geliştirme alt yapısı sunuyor.
Yeni inceleme şansı yakaladığım SeeTest ürünü de bu gelişimlere örnek olabilir. Tabi ki yerli yatırımları da unutmamak gerek; Momentum ürününü de incelemek istiyoruz, inceleyen varsa yorumlarını makalenin altına yazabilirler. Bizde bilgi sahibi olalım.
Bu ufacık tanıtımlardan sonra asıl konumuz olan Test otomasyon projelerinde nasıl başarılı oluruz ? sorusuna gelelim.
Test otomasyon geliştirme ve yaşam döngüsünü yakından incelediğinizde aslında burada test edilecek uygulamaya özel geliştirilmiş test kodlarının olduğunu görüyoruz. Her proje özelinde farklı yada ortak kütüphaneler ile geliştirme yapılabiliyor.
Günümüz de otomasyon geliştirmesi yapabilen çalışanlara artık Test Developer deniliyor. Çünkü normal bir developer gibi test kodu geliştiriyorlar.
Yazılımı geliştiren çalışanlar genelde “unit test” ile süreci sonlandırabilir ve geniş çaplı bir test otomasyon geliştirmesine odaklanmazlar çünkü onların işi sadece geliştirmektir. — Diye algılanmaktadır ama aslında böyle olmaması gerekiyor.
Böyle bir ortamda iş yine “Testçi” çalışanlara düşüyor. Yazılımcının test etmediği yerleri manuel olarak test etmek, otomasyon alt yapısı kullanmak gibi birçok yöntemi kullanarak efor verirler. Tabi ki bunun yanında yapılan baskılar, regresyon testlerinin 1 gün ile kısıtlı olması, uygulamanın standart geliştirilme mantığına çok uzak olması, yöneticilerin yetişmeyen testlerden, kalitesi yetersiz projelerden, artan kullanıcı şikayetlerinden ve operasyonel işlerin maaliyetlerini azaltmak ve/veya kurtulmak için burada yaptıkları sıkıştırmalar tüm akışı etkilemektedir. . .
Yazılımcılar test isterken, otomasyon süreçleri ile uzun vadede kaliteyi yakalamak ve yükü fazla olan testlerde otomasyon kullanarak bu ihtiyacı karşılamak, manuel testlerin de kalitesini arttırmak için kaynak yaratmak, birim testlerini zorunlu tutarak manuel test ihtiyacını azaltmak içinse tek gerekli şey üst yönetim desteği.
Kısacası, ortaya çıkacak ürünün kalitesi başarılı bir ekip çalışması ve stratejisi doğru olarak kurulmuş bir test sürecinden geçer.
Yukarıda yazdığım tüm Otomasyon & Kalite & Ekip & Geliştirme gibi konular, eğer siz ürün geliştirmesini kendi lokalinizde yapıyorsanız geçerlidir. Ürününüzü birden fazla paydaş ile geliştiriyorsanız vay halinize…
Bu tip süreçlerde ihtiyaç analizi, geliştirme performansı, test eforu, kaliteli uygulama, performansı iyi uygulama, iletişim ve diğer kavramların hepsini unutun. ,
Çünkü Isengard lokali artık SARUMAN’ın eline geçmiştir, hepimize geçmiş olsun.
Bu süreçten sonra oturun, gözlerinizi kapatın ve etrafınızda şöyle sesler duyacaksınız;
“abi otomasyon bulguları eğer canlıyı etkilemiyorsa geçişi yapalım.”
“abi neden otomasyon geçişi engelliyor ?”
“manuel olarak baktık tek kullanıcı ile performans sorunu göremedik, bence yük testi bu modül için göz ardı edilebilir.”
“sadece otomasyon koşulsa yeter manuel kontrollere gerek yok”
“o bulgu öylece canlıya geçti artık canlıda fixleriz ardından bugfix için otomasyon koşarız”
“regresyon sonrası paket taşıması yapmak çok mantıklı ve kabul edilebilir bir şey değil ama bu seferlik yapalım.”
Gibi yukarıdaki sesleri duyabilirsiniz, hatta uslu bir çocuk olursanız Şirinleri bile görebilirsiniz!
Otomasyon projelerinde başarıya giden yol aşağıdaki adımlardan geçer;
- İyi kurgulanmış bir test planı,
- Ürün proje ekibine kalite algısını anlatıp bu ihtiyacı destekleyici bir geliştirme süreci tasarlanması,
- Üst yönetimin bu konuda desteği,
- İş gücü kaynağına göre kişilerin planlaması,
- Yazılımcıların test otomasyon süreçlerine önem vermesi ve TDD yöntemi ile ürünü geliştirmesi,
- Release öncesi regresyon koşumları için planlanan gün sayısı min. 2–3 gün olmalı,
- Otomasyon testi geçiş öncesi yapılmalı ve geçiş otomasyondan çıkacak rapora göre yönlendirilmeli,
- Uygulamanın standart geliştirme mantığına uygun olması, ekranda görülen her elementin benzersiz bir “uniqId“ sahibi olması,
- Mutlaka yük, stress ve perfromans testlerinin yapılması,
- Ayrı test geliştirme ortamlarının olması,
- Gerçek kullanıcı davranışına yakın otomasyon kurguları yapılması,
- Geliştirilen kodun ve raporun herkesin anlayacağı şekilde yazılması,
- Test datasını sadece test için kullanılması,
- Oluşan hataların loglarını izleyebilecek bir monitoring alt yapısı olması,
- Testlerin planlı şekilde çalıştırılması, CI entegrasyonlarının verimli kullanılması,
- Proje tipine göre test tiplerinin belirlenmesi,
- Risk yönetiminin sağlıklı şekilde yapılması,
Okuduğunuz için teşekkür ederim :)
