Yazılım testi gerçekten profesyonel projelerde yapılıyor mu?

Birkaç şirkette birçok projede yer aldım çünkü uzun süredir geliştiriciyim ve müteahhitim.

Projelerin % 20'sinden azının metodik olarak test edildiğini tahmin ediyorum . Metodik olarak test edildiğinde, geçici olmayan plan testi ötesinde bir test anlamına gelir.

Ayrıca , projelerin % 10'undan daha azının , ekibin bir parçası olarak test eden test uzmanlarına sahip oldukları, geliştiricilerin otomatik testler yazdığı test plan belgesinin ve test kapsamı izleyen ve sonuçları ölçtükleri durumlarda, sistematik olarak test edildiğini tahmin ediyorum .

İki soru

1. Bu konuda yüzde tahminleriniz neler?
2. Yazılım testiyle ilgili profesyonel deneyiminiz nedir?

Ek not

Metodik test sorusu oldukça taraflı cevaplar alabildiğinden (insanlar diğerlerinden daha üstün olma konusunda övünmek isterler) diğer geliştiricileri (metodik teste maruz kalmayanlar) cevaplarını da sağlamaları konusunda cesaretlendiririm , çünkü aksi halde test gibi görünecektir. her yerde yapılıyor ... şirketiniz dışında.

Kariyerim üzerinde test yaparken gördüğüm model, bir projedeki başarısızlık riskiyle güçlü bir yazışma gösteriyor. Büyük projelerin küçük projelere göre test edilme olasılığı daha yüksektir, kritik görev uygulamalarının bir pazarlama dışı web sitesine göre test edilme olasılığı daha yüksektir, ev sistemlerinde kamuya açık olanlara göre test edilme olasılığı daha düşüktür.

Bununla birlikte, fazlasıyla test edilmiş ve yeterince test edilmemiş projeler var, ancak bunlar azınlık.

Ürettiğimiz her şey tamamen test edilir. Dahili KG ekibimiz aşırı yüklendiyse, projeleri test eden bir offshore ekibimiz var. İç ekibimiz kadar iyi değiller ama bu farklı bir konu.

Son 15 yılda çalıştığım üç firmanın hepsinde otomatik olarak yapılan birim testleri yapıldı.

Bu şirketlerden ikisinde, onları tanıtmak için zorladım.

Son 9 yılda, sadece kabul / regresyon testleriyle karşılaştım. Sadece birkaç ünite testi yapıldı.

Evet.

Test miktarı, uygulamanın gerektirdiği güvenilirliğin yanı sıra programcı kültürünün olgunluğuyla orantılıdır.

Web siteleri oldukça sık (kırık linkler patlak delikler yürüyorlar olan bir kusur).

Video oyunları genellikle sıkıcıdır.

Windows (nihayet) oldukça güvenilirdir.

Yönlendiriciler çok güvenilir

Hastane monitörleri "bozulma"

Mali başarısızlık maliyetinin de güvenilirlik ile ilişkili olduğunu unutmayın.

10 yıl boyunca hiçbir zaman resmi kod testi olan bir proje üzerinde çalışmadım.

Şu anki işimde sadece işlevsel testler yapıyoruz.

Sorun, yönetimde hiç kimsenin kod testi hakkında bir şey bilmemesidir. Test departmanı kod testi hakkında bir şey bilmiyor, sadece üst düzey spesifikasyonları takip ediyor ve davranışsal / işlevsel bir bakış açısından uyup uymadığımızı doğrulıyor.

Bizi kodlamaya zorlayan nitelikli bir yazılım liderimiz yok. Sonuç, spagetti kodu, çok sayıda gerileme, cevapsız programlar vb.

Güney Asya'da orta ölçekli bir denizaşırı şirketiz. Ancak, her zaman ABD merkezli projeler yapıyoruz ve doğrudan ABD şirketinden gönderilen gereksinimlerle çalışıyoruz.

Oluşturduğumuz her uygulamaya metodik test uygularız. Belki de, test kalitesi standart değil, ama onları kullanıyoruz.

İçimdeki saflık kadar, ne kadar titizlikle test ettiğinize veya herhangi bir resmi test yaptırıp yaptırmadığınıza ilişkin kararın içinde bir risk yönetiminin olması gerektiğini kabul etmek istemiyor. Programlama projelerinin büyük bir yüzdesi olduğundan şüphelendiğim iç uygulamalar için, bir hatayı silmenin ve fark edildikten sonra hızlı bir şekilde düzeltme işleminin maliyeti bazen tam bir test ekibinin maliyetinden ağır basabilir. Tabii ki bu uygulamaya ve arızaların potansiyel maliyetine bağlıdır.

Bununla birlikte, risk yönetimi planlamasının resmi testlerin olmamasının nedeni olduğunu sanmıyorum. Bunun teknik olmayan yöneticilerin sağladığı değeri anlamadığı ve sadece maliyeti gördüğü sonucu olmadığını düşünüyorum.

Örneğim yüzdesini bulmak için çok küçük, ama yine de gidiyor.

Bunlardan biri fanatik testler yapan fabless chip + firmware firmasıydı. Onlarca tesiste 7/24 otomatikleştirilmiş testler, her biri onlarca ünite paralel olarak test edilir. Test ekipleri geliştirmeye adanmış yazılım ekipleri. Donanım test ekipleri oluşturmaya adanmış ekipler. Onlarca rakibe karşı uyumluluk testi. Heck, fişlerin dökümhaneden ayrılmasından sonra fabların yaptığı testlerin bazılarını geliştirmek ve hata ayıklamak için multi-milyon dolarlık bir fiş test cihazı bile satın aldılar.

Bir diğeri de banka idi. Bu tamamen farklı bir ortam: ürün açıklaması yok, ancak sürekli çalışmaya devam etmek için çok fazla ve çok sayıda şirket içi yazılım. Bu adamlar cr * p'leri yaptıkları her değişiklikten test etti. DEV / QA / PROD ortamları, otomatik regresyon testi, zorunlu QA testi son kullanıcılar tarafından üretime girmeden önce imzalanan çok sıkı bir şekilde ayrıldı.

Yani evet, insanlar metodik testler yapar. Ama söyleyebileceğiniz gibi, tipik GUI yazılımınızı tipik bilgisayar kullanıcısı için gönderen bir yerde hiç çalışmadım.

Şu anda kablosuz tıbbi cihazlar yapan küçük bir başlangıç ​​şirketi için gömülü ürün yazılımı yazıyorum. Sıkı bir test yapmamız ve doğrudan CEO'ya rapor veren biri tarafından tamamen ayrı bir kalite departmanımız olması gerekmektedir. Kodumu daha önce hiç test etmeden bu kadar ayrıntılı bir şekilde test etmedim (karşılaştırılan tek zaman, yaklaşık 15 yıl önce uydu TV sistemlerinde çalıştığım zamandı.)

Test sonuçlarımız FDA'ya gönderilir (şu ana kadar iki FDA izni aldık - her gönderim yaklaşık 500 sayfa uzunluğundaydı). Hem geliştirme hem de test metodolojilerimiz periyodik denetime tabidir.

Bu yüzden çok sayıda resmi test yapan sadece büyük şirketler değil.

Not - 25 yılı aşkın sözleşme programlamam / danışmanlığımda, neredeyse resmi bir test yapmayan birçok şirket için de çalıştım. Çoğu artık buralarda değil.

Neredeyse her şirkette metodik testler yaptım. Şu anki şirketim bazı temel birim tarzı testlerine sahip ve bu yeterli değil. Bundan dolayı bazı kalite sorunlarımız oldu. Kendin dışında birisinin kullanacağı herhangi bir projede bağımsız testler yapmanı şiddetle tavsiye ederim. Harcanan para buna değer. İşe yarayan uygulamalar alışmaz. Bu hem içten hem dıştan dışa dönüktür.

Kariyerimin son yirmi senesinde, sekiz şirket aracılığıyla, hiçbir zaman test yapmayan bir proje üzerinde çalışmamıştım . Testlerin miktarı her şirkette farklıydı, ancak üzerinde çalıştığım her profesyonel gelişim projesi resmi testler yaptı. Bu, hem küçük hem de orta ölçekli şirketler için aynı şekilde geçerlidir ("küçük" 10 çalışandan az, "orta ölçekli" ise birkaç bin çalışan veya daha az çalışan anlamına gelir).

Bazı şirketler çok otomatik testlere sahip değildi, bazıları çok manuel testlere sahip değildi, ancak en az bir tanesine sahipti.

Bu müşterinin ihtiyaçlarına bağlıdır. Bir sözleşme durumunda muhtemelen kabul testleri vardır. Kurum içi genellikle küçük bir test ile bir tokatlama. Tüketici maddeleri genellikle sık işlevsellik ile kaplıdır, ancak kenarlarda pürüzlüdür.

Kısa cevap: Evet

Uzun cevap:

1. İlk kategori için iyi bir tahminde bulunmuyorum (muhtemelen sıfırdan biraz uzak, ama ne kadar?), Ancak deneyimlerim aslında ikinci tahmininizle de doğrulanıyor. Testlerin miktarı ve türü, geliştirilmekte olan uygulamanın türüne, kullanılabilir zaman dilimine ve geliştiricilerin becerisine ve projenin nasıl yürütüleceğine bağlı olduğundan, anlamlı yüzdeleri vermek zordur. Uygulamada geliştiriciler için en önemli engel kabul testi olacaktır çünkü bu faturalandırma için önemli bir dönüm noktasıdır. Ancak, aynı zamanda beklenmeyen durumların ortaya çıkabileceği zamandır (daha fazla gereksinim) ve geliştiricilere, sorun gidermek ve üstesinden gelmek için gereken zamanın üzerinde mümkün olan ve zamanında (bu aşamada) yapılan herhangi bir geçici testi sunmak ve almak için baskı yapılabilir. beklenmeyen.

2. Yukarıda belirtilen farklı faktörlerin kombinasyonuna sahip çeşitli projelerden geçtim:

   • resmi ünite testi yok, sadece entegrasyon testleri ve çoğunlukla anlık testler

   • ünite testlerinden, özel kalite güvence kaynaklarını, otomatik testleri (test uzmanları tarafından kendi araçları ile yapıldığı gibi) ve kod kapsamı raporlarını içeren ayrıntılı test planlarına kadar çok resmi bir şekilde yer almaktadır. Ancak bunlar, yöneticiler kadar geliştiriciler için her zaman anlamlı değildir.

Bireysel düzeyde, uğraştığım teknolojiye uygun testler yazmak ve bunları kendi takdirime göre uygulamak söz konusu olduğunda seçeneklerimi anlamaya çalışıyorum. Temelde işlerim için gerçekten anlamlı ve faydalı olan şeyler ve sayıları fazla kesiyor.