Geliştiriciler test aşamalarında yer almalı mıdır?


10

klasik bir V-şekilli geliştirme süreci kullanıyoruz. Daha sonra gereksinimler, mimari, tasarım, uygulama, entegrasyon testleri, sistem testleri ve kabulümüz var.
Testçiler projenin ilk aşamalarında test senaryoları hazırlıyorlar. Sorun, kaynak sorunları (*) nedeniyle, test aşamalarının çok uzun olması ve zaman kısıtlamaları nedeniyle genellikle kısalmasıdır (proje yöneticilerini biliyorsunuz ...;)). Geliştiriciler birim testlerini gerektiği gibi yapıyorlar.

Bu yüzden sorum basit: geliştiriciler test aşamalarına dahil olmalı mı ve çok 'tehlikeli' değil mi? Korkarım, proje yöneticilerine iş yapıldıkça yanlış bir daha kaliteli bir his verecektir, ancak eklenen man.days herhangi bir değere sahip olacak mı? Testler yapan geliştiricilerden gerçekten emin değilim (burada suç yok ama hepimiz birkaç gün içinde yaptığınız birkaç tıklamayla kırmanın oldukça zor olduğunu biliyoruz).

Düşüncelerinizi paylaştığınız için teşekkürler.

(*) Belirsiz nedenlerden dolayı, test edenlerin sayısının arttırılması bugün itibariyle bir seçenek değildir.

(Sadece peşin, o birinin kopyası değil tasarım testlerinde Meli programcılar yardım test? Hangi biz geliştiricilerin ima önlemek sınav hazırlığına değil deney yürütme, bahsediyor)


Bizim geliştiricilerin bu hassas Düzenlenen edilir onların birim testleri yapıyor. QA adamları döngüye girdiğinde, birim testlerinden sonraki aşamalar hakkında endişeliyim.
LudoMC

Hmmm, "mutlak kesin EVET" ve "kesinlikle hayır" arasında seçim yapmak kolay olmayacaktır. Biraz daha düşünecek, daha net bir görüş elde etmek için diğer cevapları veya cevaplarla ilgili yorumları bekleyeceksiniz.
LudoMC

Tamam, bir cevabı kabul ettim ama aynı zamanda soruna iyi argümanlar sağlayan diğer cevaplardan bazılarını da oyladım. Herkese teşekkürler.
LudoMC

Yanıtlar:


13

Sorunuza tam anlamıyla bakmak ("dahil olmak") Tek cevabım kesin bir kesin

EVET

Devs, kendi kodlarında asla son sözü söylememelidir .

Ancak Devs, diğer geliştiricilerin çalışmalarının test edilmesinde yer almalıdır. İki şey yapar:

  1. Bir geliştiricinin teste ilişkin kavrayışını getirir. Bu, hem belirli bir noktada hangi API'lerin muhtemelen kullanıldığını, bu API'lardan gelebilecek istisnaları ve bunların nasıl ele alınması gerektiğini bilmenin genel durumudur. Ayrıca, belirli bir projeye de yardımcı olur, çünkü geliştiriciler, bir şeyin neden yapıldığına dair genel olarak yaptığından daha fazla çeşitli tartışmalara çok daha fazla maruz kalırlar, yani KG'nin yapamayacağı son vakaları tespit edebilirler. Bir geliştirici tarafından tespit edilen hataların düzeltilmesi daha ucuz olacaktır, çünkü bir geliştirici genellikle daha fazla bilgi ve hemen nasıl düzeltileceği hakkında daha fazla bilgi sağlayacaktır.
  2. Uygulamanın aksi takdirde maruz kalmayacakları kısımlarına geliştiriciyi verir. Bu onları uzun vadede bu uygulama için daha iyi geliştiriciler yapacak. API'mın nasıl tüketildiğini bildiğimde, yapmam gereken bir sonraki şeyi tahmin etmede çok daha iyiyim. En önemlisi, uygulamayı ve kullanımını biliyorsanız, kodlamaya başlamadan önce spesifikasyonun ne zaman yanlış olduğunu söyleyebilirim .

Son olarak, neden mümkün olduğunca fazla göz kullanmıyorsunuz? Çatışma zamanı için ek KG kişilerini işe almak için işe alma ve işe yerleştirme sürecinden geçmeyi nadiren karşılayabilirsiniz. Peki, ihtiyacınız olan ekstra gözleri nerede buluyorsunuz? Yoksa aynı sayıda KG ile krizi geçirmeye mi çalışıyorsunuz? Geliştiriciler zaman testlerinin% 20'sini ve hataların ne olursa olsun% 80'ini düzeltmek için harcasalar bile, uygulamada daha önce olduğundan daha fazla göz var. Otomatik test sadece size belirli bir güvence sağlar ve asla% 100 olmayacaktır.

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29


Geliştiricilerin başkalarının kodlarına bakması gerektiğinden +1
Gary Rowe

Bunu 1 - sağlanan bağlantı (çok ilginç ve durumumuzla yakından bağlantılı) 2 - cevabınızdaki iyi argümanlar nedeniyle geliştireceğim: geliştiricilerin kendi kodlarını test etmemesi gerektiği, onlara iyi bir görüş vermesi uygulamanın veya sistemin diğer bölümlerinin.
LudoMC

11

Birim testi dışında hiçbir şey için kesinlikle değil. Geliştiriciler sadece uygulama hakkında çok fazla şey biliyor ve objektif test uzmanı olmak için nasıl çalışması gerekiyordu.


2
Çoğunlukla, buna tamamen katılıyorum. Ancak yazı, QA ekibinin test senaryolarını bulmaktan sorumlu olduğunu söyledi. Testlerin kapsamlı bir kapsama sahip olduğunu varsayarsak, yazılımları KG'ye yayınlamadan önce geliştiricilerin test senaryolarını geçememelerinin zorlayıcı bir nedenini görmüyorum. Hataların erken yakalanmasına ve birden çok hata düzeltme sürümünden kaynaklanan ek yükün azaltılmasına yardımcı olabilir.
Pemdas

2
Bu bakış açısına katılmıyorum çünkü bir geliştiricinin gözüne sahip olmak fonksiyonel testler sırasında son derece faydalı olabilir. Bir geliştirici değerli bir kaynaktır, bu nedenle rote test senaryolarından geçmemelidir, bunun yerine test kullanıcılarına uygulamayı daha verimli bir şekilde nasıl kıracaklarını önerebilir (test cihazlarının hayatını daha eğlenceli hale getirir ...)
Gary Rowe

GR ... genel olarak geliştiricilerin değerli bir kaynak olma konusundaki ifadenize katılıyorum, ancak buradaki konu gerçekten yeterli test kapsamını sağlamak için zaten hangi kaynağa sahip olduklarını yeniden düzenlemekle ilgilidir. Bu, geliştiricilerin bazı Katar testlerine girmeleri gerektiği anlamına geliyorsa, öyle olsun.
Pemdas

8

Geliştiriciler ve Q'lar arasındaki felsefelerin test edilmesindeki temel fark şudur: programcı tipik olarak kodunun çalıştığını kanıtlamak için programını test eder ("pozitif" test). KG bunu yapabilir ve yapar, ancak yazılımı kırmaya çalışarak neyin işe yaramadığını bulmaya daha fazla odaklanır ("negatif" test kullanarak).

QA personeli potansiyel olarak bu test programcılar tarafından bozulmuş olabileceğini ölçüde yazılım çalışmaları olması gerektiğini "kanıtlıyor" izolasyon geliştirici testleri ve QA testi arasında. Geliştirici, neyin işe yaradığını göstererek KG testine kesinlikle yardımcı olabilir, ancak yazılımın kırılmadığını bağımsız olarak doğrulamak KG'ye bağlıdır .

Programlayıcının test çalışmasına yardımcı olmak için yapabileceği en iyi şey, gereksinimler belgesindeki bireysel gereksinimlere uygun testler içeren kapsamlı, yüksek kaliteli, doğrulanabilir bir birim test paketi sağlamaktır.


2

Test açısından 3 çeşit var.

Kara kutu, gri kutu ve beyaz kutu.

Kara kutu, ürünün dahili olarak nasıl çalıştığı hakkında hiçbir bilgiye sahip olmayan, ürünü test eden kullanıcılara atıfta bulunur.

Gri kutu, bilgisayar programlama hakkında bilgi sahibi olan ancak geliştirme ekibinde olmayan güç kullanıcılarını ifade eder. Bu kişiler, ürünün bellek sızıntısı olup olmadığını, sistem gereksinimleri sorununu vb. Test edecektir.

Ana bölüm: Beyaz kutu, ürün üzerinde kod düzeyinde test eden geliştiricileri ifade eder. Bu, birim testi, hata ayıklama, vb. Yaptıkları anlamına gelir.

Bu nedenle, kullanıcıların ve geliştirme ekibinin test aşamasına dahil olmaları iyidir, ancak testlerin her biri, neyin test edildiğine bağlı olarak kullanıcılardan ve geliştirme ekibinden uygun bir taahhüt seviyesi gerektirir.


2

BİRİM TESTİ tüm geliştiriciler için bir zorunluluktur

Bunun yararınıza nasıl kullanılabileceği hakkında bilgi için, C ++ geliştirmesi için aşağıdaki bağlantıları okuyun:

QA KİŞİSİNİN BU TESTLERİ YAPABİLECEĞİ YOL YOKTUR. OLMAZ.


Katılıyorum ama soruyu başka şekilde soruyordum. Geliştiriciler, genellikle yalnızca KG kişilerinin dahil olduğu testlere (birim testleri hariç) dahil olmalıdır.
LudoMC

1

Projenin önemli sayıda geliştiricisi olduğunu varsayarsak, elbette geliştiriciler test üzerinde çalışıyorlar. Bir uyarı, geliştiricilerin kendi kodları için test üzerinde çalışmadığıdır (bu, birim testini içermez).


Kendi kodlarını test etmeyen geliştiriciler için +1 (veya en azından yalnız değil)
LudoMC

0

İdari personelin (veya gerçek potansiyel kullanıcıların) KG testini geliştiricilere göre yapmasını tercih ederim. Ürünün çalışmak için nasıl tasarlandığını bilmeyen birisinin onu kullanmaya çalışması gerekir. Geliştiriciler teste nasıl yaklaştıklarında çok sınırlı olma eğilimindedir ve açıkçası KG testi için kullanmak için saat başına çok pahalıdırlar.


0

Sen yaz:

Sorun şu ki, kaynak sorunları (*) nedeniyle, test aşamaları çok uzun ve zaman kısıtlamaları nedeniyle genellikle kısalıyor. Çünkü geliştiriciler bunları yapmıyor. En iyi en istikrarlı ürünler sunmak en büyük internet şirketlerinden biri yok hiç test kullanırlar. Yalnızca geliştiricilerin kendileri tarafından yapılan otomatik testleri kullanırlar. Sonuçlar, geliştiricinin testi "test kullanıcılarına" bıraktığından x10 daha iyi ürünlerdir.

Bu, inşaat işçileri evinizi inşa etmek gibi, ancak farklı bir ekibin binanın gerçekten durduğundan, kapıların açık ve kapalı olduğundan, klimanın çalıştığından emin olun ... Binaları inşa etmek muhtemelen x10 alacak ve çoğu güvenilmez olmak.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.