Programcılar neden teste ihtiyaç duyar?
Sonraki birkaç seviye, programcıların ihtiyaç duyduğu şekilde test etmeye ayrılacak . Ama önce, testin ne olduğunu ve neden gerekli olduğunu öğrenelim.
Yazılımla ilgili olarak, test etme görevinin programın aşağıdakileri kontrol etmek olduğunu söyleyebiliriz:
- yapması gerekeni yapar
- yapmaması gereken şeyi yapmıyor
Bu arada, ikinci nokta birinciden daha az önemli değil, daha sonra bunun üzerinde daha fazla durulacak.
İlk nokta ile başlayalım. "Program yapması gerekeni yapıyor" ne anlama geliyor?
İlk olarak, birisinin program için tüm kullanım durumlarının bir listesini yapması gerekir. İkinci olarak, programın nasıl çalışması gerektiğini, kullanıcının nasıl davranması gerektiğini ve hangi sonuçların beklendiğini açıklamaları gerekir. Daha fazla devam edemezsiniz.
"Kullanıcının nasıl davranması gerektiğini" yazar yazmaz, iyi belgeler yazma fikri tamamen suya düştü. İnsanlar makine değildir, üstelik insanlar genellikle yazılımla canlarının istediği gibi davranırlar . Hiç kimse teknolojiyle tanışmaya talimatları inceleyerek başlamaz. Bu bir gerçektir.
Bu nedenle, yeni bir gerçeğe ulaşıyoruz: Yazılımın özelliği, birçok farklı çalışma senaryosuna sahip olmasıdır. Bazıları apaçıktır, bazıları belgelenebilir, bazıları varsayılabilir, bazıları tahmin edilebilir ve geri kalan %50'lik kısım aklınıza bile gelmez.
Bir programcının bakış açısından, çoğu hata hiç de hata değildir. Hata, bir programın olması gerektiği veya beklendiği gibi çalışmadığı zamandır. Ve programın nasıl çalışması gerektiğinin net olmadığı veya birbiriyle çelişen senaryoların olduğu birçok durum vardır ...
Sonsuz sayıda senaryo vardır ve üründe her zaman programın beklendiği gibi davranmadığı durumlar olacaktır (programcı kodu yalnızca birkaç düzine senaryo için yazdı). Bu nedenle, herhangi bir programda her zaman hatalar olduğu ve herhangi bir ürünün sonsuza kadar geliştirilebileceği iddia edilebilir .
Bundan sonra, her şey uygunluğa gelir. İlk olarak, programcı en büyük hataları, ardından daha küçük hataları vb. düzeltir. Ve son olarak, ürün sahibinin üzerinde çalışmaya devam etmenin ekonomik olarak mümkün olmadığına inandığı bir aşama gelir.
Ancak herkesin hata olarak kabul ettiği hatalara geri dönelim: program açıkça bir şeyi yanlış yapıyor, düştü, bir şeyi kırdı vb. Bu tür hatalar şartlı olarak 3 kategoriye ayrılabilir: büyük, orta ve küçük.
Ve çoğu zaman, projede hala çok daha ciddi sorunlar olmasına rağmen, bir programcının orta ve hatta küçük hataları düzeltmeye çalıştığı görülür. Onları bulamadı , bu yüzden bildiği en büyükleri üzerinde çalışıyor.
Bu nedenle, herhangi bir projede test ediciler olmalıdır. Bu kişiler özellikle ürüne farklı açılardan bakmayı öğrenirler. Böylece programın daha fazla senaryosunu görebilirsiniz. Görevleri hataları bulmak ve yazmaktır (aynı hatayı birkaç kez bulmamak için).
Test, hataları bulmayı amaçlayan bir süreçtir. Bu hatalar bulunmalı, tanımlanmalı ve önceliklendirilmelidir. Ancak hataların önceliklendirilmesinden sonra etkili bir yazılım geliştirme sürecinden bahsedebiliriz.
Unutmayın, bir sorunu çözmenin ilk adımı, bir sorun olduğunu kabul etmektir . Bilmediğin bir hatayı düzeltemezsin.
Test Otomasyonu
Sanırım hepimiz test etmenin önemli olduğu konusunda hemfikirdik, o yüzden programcılar gibi test etmeye bakalım. Programcılar testi nasıl görüyor? Programcılar diğer insanların çalışmalarını otomatikleştirir. Kaybolan son meslek programlama mesleği olacaktır.
Karşılaştığımız tüm süreçleri otomatik hale getiriyoruz. Bu nedenle testlerin otomatikleştirilmesi gerekiyor. Ve hata araması nasıl otomatikleştirilir? Kısa cevap: hayır. Ama burada yine programcı olduğumuz gerçeği imdadımıza yetişiyor.
Yazılım geliştirme süreci, üzerinde yapılan sürekli değişikliklerden oluşur. sadece sürekli değişiklik yapma sürecinde, programcılar çok sık olarak yakın zamana kadar iyi çalışan bir şeyi bozarlar.
Ve test uzmanları, yeni hatalar aramak yerine, uzun süredir iyi çalışan bir şeyi bozup bozmadığımızı sürekli kontrol etmeye zorlanıyor. Sözde regresyon testi. Otomatikleştirilebilen ve yapılması gereken bu tür testler.
Burada tüm yazılımlar iki bölüme ayrılabilir:
- program kişi ile etkileşime girer
- program başka bir programla etkileşime giriyor
İlk seçeneğin otomatikleştirilmesi daha zordur, özel otomatikleştirici test cihazları gerektirir, bunlara QA Otomasyonu veya Yazılım Test Mühendisi de denir.
Ancak ikinci seçenek bağımsız olarak otomatikleştirilebilir ve otomatikleştirilmelidir. Aşağıdaki özelliklere sahip bir yazılımınız varsa:
- iyi çalışıyor
- zaten test edildi
- ayrı bir modül veya mantıksal blok olarak uygulanır
- değiştirmeyi planlamamak
- diğer modüller veya programlar buna bağlıdır
- işlevsel başarısızlık maliyetlidir
Mevcut işlevselliğinin temel yönlerini yakalayan testler yazmak için zaman ayırmanızı tavsiye ederim. Bunun için çalışma sürenizin %5'ini yani ayda 1 günü ayırmanız mantıklı olacaktır.
Test uğruna test yazmaya gerek yok.
Testlerinizi kimse desteklemiyor. Diğer programcılar değil, kendiniz değil. Kimse bunu yapmaz. Tüm yazılı sınavların %99'u terk edilir ve/veya devre dışı bırakılır. Test yazamıyorsanız - yazmayın. Yalnızca onlarsız kesinlikle yapamıyorsanız yazın.
test türleri
Her programcı, özel bir eğitim almamışsa, kendi sözleriyle testin ne olduğunu söyleyebilecektir: programın yapması gerekeni yapıp yapmadığını kontrol etmek. Bununla birlikte, bu alandaki profesyoneller, tüm test alanlarını (türlerini) ayırt eder.
Tüm testler gerçekten yazılımın güvenilirliği ve kullanılabilirliği etrafında döner, ancak testin yönünü daha iyi anlamak için birkaç örneğe bakalım.
Diyelim ki tipik bir çevrimiçi mağazayı test ediyorsunuz. Ardından, test alanları şu türlere ayrılabilir: performans testi, işlevsel test, entegrasyon testi ve birim testi.
Site sahibi ciddi bir reklam kampanyası başlatmaya karar verirse, siteye aynı anda çok sayıda kullanıcı gelecektir. Site çökmeyebilir, ancak bazı bölümleri yavaşlayabilir ve hatta çalışmayı durdurabilir.
Bunun olmasını önlemek için, bu tür sorunları önceden belirlemeniz ve ortadan kaldırmak için adımlar atmanız gerekir. Bu, yük testi kullanılarak yapılır veya performans testi olarak da adlandırılır.
Ayrıca, arka uç API'nizin nasıl çalıştığını test etmek ve her işlevini test etmek isteyebilirsiniz: kayıt, oturum açma, sepete ekleme, ödeme işleme, veritabanı yazma, vb. Her şey TOR'a göre çalışmalıdır. Bu durumda, fonksiyonel test yapmanız gerekir .
Çevrimiçi mağazanız büyük olasılıkla üçüncü taraf hizmetlerle entegredir: mektup ve SMS gönderme, ödeme sistemleri, çevrimiçi destek sohbetleri, kullanıcılardan geri bildirim toplama, reklam sistemleri vb. Tüm bunların amaçlandığı gibi çalıştığından emin olmak için entegrasyon testi yapmanız gerekir . .
Son olarak, karmaşık ürünler genellikle bağımsız modüllere ayrılır. Bu tür modüllerden, nihai ürünü bir kurucu olarak bir araya getirebilirsiniz. Böyle bir modül geliştiriyorsanız veya bu tür modüllerle etkileşim kuruyorsanız, birim testi yapmanız gerekecektir .
Özetle, sitenin her bir işlevini test etmek için işlevsel testin gerekli olduğunu söyleyebiliriz. Entegrasyon - ürününüzün büyük modüllerinin ve sistemlerinin etkileşimini test etmek için. Modüler - ayrı bir modülü test etmek için, performans testi - sitenizin yük altında çalışmasını kontrol etmek için.
Daha da fazla test türü olabilir: ürün ne kadar karmaşıksa, gelişiminin o kadar çok yönünün kontrol edilmesi gerekir.