Test etme – muhtemelen uygulama geliştirmenin en az değer verilen kısmı

Kendi çalışmanı test etmen için sana neden para ödeyeyim?

Bu, müşterilerle test bütçelerini tartışırken yıllardır çokça duyduğum bir soru. Deneyimsizler için adil bir soru gibi geliyor. Bununla birlikte, yazılım geliştirmeyle ilgilenen herkes, testlerin ne kadar karmaşık ve zaman alıcı olabileceğini bilir. Test etme, aslında herhangi bir yazılım geliştirme projesinin en önemli parçalarından biridir.

Büyük bir e-ticaret platformu, milyonlarca kod satırı, gigabaytlarca veri ve birçok entegrasyon noktası ile inanılmaz derecede karmaşık bir şeydir. Birbiriyle bağlantılı çok sayıda hareketli parça vardır; zincirde o kadar çok halka var ki, bir şeylerin yanlış gitmesi çok kolay. Uygulama, çok sayıda masaüstü ve mobil cihazda çok sayıda tarayıcı aracılığıyla milyonlarca farklı şekilde kullanılacaktır. Geliştirme projesi, üzerinde çalışan birçok farklı insanla en az 6 ay sürecektir. Test edilebilecek alan ve senaryo sayısı neredeyse sınırsızdır. Her şeyin işe yaraması bir mucize!

Test, bir dizi farklı alana ayrılabilir, ancak her bir test alanının dikkate alınması önemlidir. Her proje biraz farklıdır; Bazı müşteriler testlerin çoğunu kendileri üstlenmekten hoşlanırken, bazıları dış kaynak kullanmaktan hoşlanırken, bazıları geliştiricilerinin hepsini yapmasını bekler. Test ayrıca sabit bir varlık değildir; çok fazla test yapabilir ve biraz yapabilirsiniz. Ne kadar çok test ederseniz, projeyi o kadar riske atarsınız, ancak o kadar fazla zaman alır ve o kadar pahalıya mal olur.

Birim testi

Birim testi, beklendiği gibi çalıştıklarından emin olmak için küçük kod 'birimlerini' test eden bir testtir. Örneğin, bir form gönderildiğinde, girilen ayrıntıları bir veritabanı tablosuna kaydetmelidir. Özel olarak ve yalnızca ünitenin beklendiği gibi çalışmasını sağlayan bağımsız bir testtir. Gerçek bir test odaklı geliştirme metodolojisi kullanan bir geliştirici, herhangi bir kodu gerçekten oluşturmadan önce bir test yazar, böylece kodun yalnızca test geçtiğinde tamamlanmış olarak kabul edilebilmesi sağlanır. Uygulamada birim testi, temel işlevlerin beklendiği gibi çalıştığından emin olmak için uygulamanın yalnızca bazı temel alanlarında kullanılır. Birim testi, işlevsel sorunların ortaya çıkma olasılığını azaltabilirken, geliştirme süresini de artırabilir.

Duman testi

Muhtemelen geliştirme ajansınızın duman testi hakkında çok konuştuğunu duyacaksınız. Duman testi, uygulamanız boyunca temel kullanıcı yolculuklarını ve işlevlerini kapsayan test senaryolarının pragmatik bir alt kümesidir. En azından, geliştiricinizin UAT için size herhangi bir şey teslim etmeden önce duman testleri yapması beklenmelidir.

kullanıcı arayüzü testi

Kullanıcı Arayüzü (UI) testi çok karmaşık ve zaman alıcı bir şey olabilir. Bir web sitesine erişmek için kullanılacak çok çeşitli mobil, tablet ve masaüstü cihazlar, işletim sistemleri ve tarayıcılar, her kombinasyonu kapsamlı bir şekilde manuel olarak test etmenin neredeyse imkansız olduğu anlamına gelir. Kapsanması gereken çok sayıda farklı varyasyon nedeniyle UI testi, otomatik test için mükemmel bir adaydır. Otomatik test araçları, web siteniz üzerinden komut dosyasıyla yazılmış bir yolculuğu izleyebilir ve beklenen sonuçlara ulaşılıp ulaşılmadığını test edebilir. Ayrıca her bir yolculuğu kaydedebilir, böylece her biri yeniden oynatılabilir. Bu yöntem mükemmel olmasa da, bir web sitesinin karşılaşabileceği önemli UI sorunlarının sayısını önemli ölçüde azaltabilir.

Bug Finders gibi bazı 3. taraf test hizmetleri, dünyanın dört bir yanından yüzlerce serbest çalışan insan test uzmanının bir web sitesini test etmek için kullanıldığı ve bir sorun bulduklarında ödeme aldığı kalabalık kaynaklı bir hizmet sunar. Bu yaklaşım, uygulamanızı yüzlerce cihaz/platform/tarayıcı kombinasyonunda test etmenin nispeten uygun maliyetli bir yolu olabilir. Bir test döngüsünün yaklaşık 200 sorunun gündeme gelmesiyle sonuçlanması normaldir. Zorluk genellikle sorunları kategorize etmek ve önceliklendirmektir, böylece kaynaklarınızı en önemli olanlarla ilgilenmeye odaklarsınız. Her web sitesi, asla çözülemeyecek olan düşük seviyeli sorunların sürekli birikimine sahip olacaktır.

Gerileme testi

Regresyon testi, devam eden geliştirmenin son derece önemli bir parçasıdır. Uygulamanın bir bölümünde yapılan herhangi bir değişikliğin başka bir bölümde soruna neden olup olmadığını test etmek için tasarlanmıştır. Örneğin, bize ulaşın formunu doğrulamak için kullanılan bir JavaScript işlevinde yapılan bir değişiklik, ödeme sırasında kullanılan formları potansiyel olarak etkileyebilir. Herhangi bir e-ticaret platformunun karmaşık yapısı nedeniyle, regresyon sorunları nadir değildir, bu nedenle sağlam bir regresyon testi planı tasarlamak, kullanıcılarınızın deneyiminin bu sorunlardan olumsuz etkilenmemesini sağlamak için hayati önem taşır.

UAT

Kullanıcı Kabul Testi (UAT), herhangi bir geliştirme projesinin kritik bir parçasıdır ve müşterinin, canlıya geçmeden önce platformun tam uçtan uca test etmesini içerir. UAT, en sık küçümsendiğini gördüğüm süreçtir. Aynı zamanda, zaman çizelgeleri sıkışık olduğunda ilk acı çeken bir projenin parçasıdır. Ancak, bunun daha yüksek başarısızlık oranına yol açması muhtemeldir. Herhangi bir yeni web sitesi kurulumu için, en az 2 aylık UAT planlanmasını tavsiye ederiz. E-ticaret web siteniz, herhangi bir ticaret işinizin yalnızca bir parçasıdır ve arama, ödeme, sipariş yönetimi, ödeme, sevkıyat, müşteri hizmetleri, finans ve zincirin diğer tüm bölümlerini içeren uçtan uca sürecin tamamlanması gerekir. test edildi.

UAT genellikle, birden fazla sistem arasındaki entegrasyonu özel olarak test edeceğiniz SIT (Sistem Entegrasyon Testi) ile karıştırılır veya birleştirilir. SIT, zincirin tüm parçalarının birlikte doğru şekilde çalışmasını sağlayan uçtan uca testin bir parçasıdır.

İyi UAT, test senaryolarının ve test planlarının oluşturulmasını içerir. Bunlar genellikle, manuel bir test cihazının geçeceği ve sonuca göre testi geçeceği veya geçemeyeceği bir dizi komut dosyası (bir komut dosyası çalıştırılacak bir dizi görevdir) biçimini alır. Uçtan uca bir UAT test planının 500'den fazla test senaryosunu içermesi alışılmadık bir durum değildir.

UAT'deki A, bu kadar önemli olmasının nedenlerinden biridir. UAT sürecinin sonunda, genel olarak başvuruyu kabul etmiş sayılırsınız, bu nedenle, tam olarak beklediğiniz gibi çalıştığından emin olmak için baştan sona test etmeniz önemlidir. Bu, keşfedilmemiş hataların garanti kapsamında olmayacağı anlamına gelmez, ancak beklediğiniz şekilde çalışmayan bir işlevsellik varsa, bunun UAT'de alınması gerekir. Bu kadar önemli olmasının bir diğer nedeni de, yayınlanmadan önce sorunları almak için son şans olmasıdır. Herhangi bir hata ve sorunun, kullanıcı deneyimini olumsuz etkilemesi muhtemeldir.

UAT, müşteri adına, genellikle hafife alınan çok fazla çaba gerektirir. Bazı müşteriler, UAT sırasında kendilerini desteklemek için harici test ajansları kullanır; bu, müşterinin UAT'yi etkin bir şekilde yürütmek için insan gücüne sahip olmadığı bir projenin riskini önemli ölçüde azaltabilir.

Güvenlik testi

Bazı perakendecilerin güvenlik testlerini yeterince ciddiye almamalarına bazen çok şaşırıyorum. Perakendecinin web platformlarında en son ne zaman bir sızma testi gerçekleştirdiğini bilmemesi olağandışı bir durum değildir. Bunlar genellikle henüz bir siber saldırıya uğramamış (veya vurulduğunu henüz bilmeyen) kişilerdir. Siber suçun sıklık ve karmaşıklık açısından artmaya devam ettiği mevcut ortamda ve özellikle Avrupa'da ufukta görünen GDPR ile güvenlik testleri giderek daha önemli hale geliyor. Tüm e-ticaret web platformları, uzman bir üçüncü taraf tarafından en az yılda bir kez, ancak ideal olarak yılda iki kez penetrasyon testine tabi tutulmalıdır. Ayrıca, Nessus gibi özel yazılımlar kullanılarak uygulamanızın güvenlik açıklarına karşı düzenli olarak taranması da önerilir. Envoy'da, uygulama güvenlik açıklarının çok hızlı bir şekilde alınmasını sağlamak için müşterilerimizin web platformlarını haftalık olarak tarama eğilimindeyiz. En azından, üretime her sürümden önce uygulama güvenlik taramaları gerçekleştirmelisiniz. Yeni bir uygulama güvenlik açığı ortaya çıkardığınızda, bir sonraki sızma testine kadar 6 ay beklemek iyi değildir.

Performans testi

Performans testi genellikle web sitenizin ne kadar trafik, sayfa isteği, eşzamanlı kullanıcı ve sipariş hacmini işleyebileceğini belirlemek için kullanılır. Doğru bir şekilde test etmek için gerçek kullanıcı davranışını taklit etmeniz gerektiğinden ve bileceğiniz gibi gerçek kullanıcılar birçok farklı şey yaptığından, hayal edebileceğinizden daha zor bir süreçtir. Yapabileceğiniz en iyi şey, arama, sepete ekleme ve ödeme gibi temel kullanıcı yolculuklarınızı taklit etmektir. İdeal olarak, size çok daha doğru bir resim sunacağından, bir hazırlama ortamı yerine üretim ortamınızda yük testi yapmak istersiniz, ancak bu aynı zamanda test sırasında bir noktada platformunuzu çevrimdışına alabilir.

Çoğu perakendeci, normalde Kara Cuma veya Noel gibi yoğun ticaret dönemlerinden önce yılda bir kez yük testleri yapma eğilimindedir. Bunun neden olabileceği sorun, son yıllık testten bu yana uygulamada çok sayıda değişiklik yapılmış olabilir ve bunların bazıları performans üzerinde artan bir etkiye sahip olabilir. Yıllık yük testi, bir önceki yıla göre performans düşüşü gösteriyorsa, geçen yıldaki hangi değişiklik veya değişikliklerin bu performans düşüşüne katkıda bulunduğunu belirlemek çok zordur. Bu aynı zamanda, en yüksek ticaret başlamadan önce performans sorunlarını çözmek için size yeterli zamanı vermeyebilir.

Buna karşı koymak için, her yeni kod sürümünden önce performans karşılaştırmaları yapılması tavsiye edilir. Amaç, performansın son sürüme göre arttığını veya azaldığını belirlemek olduğundan, her test aynı ortamda gerçekleştirildiği sürece bunların bir üretim ortamında gerçekleştirilmesi gerekmez. Bu yaklaşım, geliştirme ekiplerinin performanstaki herhangi bir artış veya düşüşün nereden geldiğini anlamalarını sağlar. Bu, elbette, zaman alır ve bu nedenle geliştirme süresini ve maliyetlerini artıracaktır.

Yukarıdaki liste ayrıntılı olmasa da, yazılım geliştirme içindeki test kapsamının çok geniş ve karmaşık olabileceğini görebilirsiniz. Her tür test zaman ve çaba gerektirir ve bunların hiçbir ek ücret ödemeden standart olarak yapıldığını varsaymamalısınız. Teste güçlü bir şekilde odaklanan şirketler, herhangi bir proje süresinin %40'ını test etmeye ayıracak ve bu çok şaşırtıcı bir miktar olabilir. İyi bir test, bir projenin riskini azaltabilir ve daha az hata, daha iyi performans ve müşterileriniz için daha iyi bir genel deneyim ile sonuçlanacağından uzun vadede kendisi için ödeme yapabilir.