Bir geliştirici aynı zamanda bir test cihazı gibi davranmalı mı? [kapalı]


60

Biz 3 geliştirici, 1 tasarımcı, scrum ustası ve ürün sahibinin bir scrum ekibiyiz. Ancak, ekibimizde resmi bir test uzmanımız yok. Her zaman bizimle olan bir sorun, uygulamanın test edilmesi ve bu testlerin geçilmesi ve hataların giderilmesi, bir PBI (Product Backlog Item) olarak kabul edilmesi gereken kriterlerden biri olarak tanımlanmış olmasıdır.

Ancak sorun şu ki (3 geliştirici ve 1 tasarımcı), uygulamayı test etmeye ve kullanım davalarını ne kadar denemeye çalışsak da, hala bazı hatalar görülmüyor ve sunumumuzu ( Murphy kanunu ) paydaşlara mahkum ediyor.

Bir çözüm olarak, şirketin yeni bir test cihazı almasını tavsiye ettik. İşi yapan biri yalnızca test ediyor ve test ediyor olacaktı. Resmi bir profesyonel test cihazı.

Ancak, sorun şu ki, scrum ustası ve paydaşları bir geliştiricinin (veya bir tasarımcının) da bir test cihazı olması gerektiğine inanıyor.

Haklılar mı? Biz geliştiricilerin de (tasarımcıların) test cihazı olması gerekir mi?


1
Programmers.stackexchange.com/questions/100637/… 'nin muhtemel kopyası, bunun tersi bir bakış açısıyla sorulmasına rağmen.
Adam Lear

Bulunduğum scrum ekibinde, herkes akıllı telefon veya tablet uygulamasını test ediyordu ve hepsi çok yardımcı oldular.
ott

Yazarların bir editöre ihtiyacı var.
JeffO

Yanıtlar:


59

Örnek olarak: Neyin test edilmediği ile ilgili olarak bir çok kafa karışıklığı var gibi görünüyor. Elbette, her geliştiricinin kodunu oluştururken test etmesi gerekir, çalıştığını doğrulaması gerekir. Yapıldığını ve yeterince iyi olduğunu düşünmeden önce bir test cihazına veremez. Ancak geliştiriciler her şeyi görmez. Hataları tanımayabilirler. Bu hatalar ancak daha sonra kapsamlı bir test yapıldığında geliştirme döngüsünde bulunabilir. Asıl soru, geliştiricilerin bu tür bir testi yapıp yapmamaları gerektiğidir ve alçakgönüllü görüşüme göre bunun bir proje yöneticisinin bakış açısına bakması gerekiyor:

Geliştiriciler test edici olabilirler, ancak test edici olmamalıdırlar . Geliştiriciler, istemeden / bilinçsizce, uygulamayı kırabilecek şekilde kullanmaktan kaçınırlar. Çünkü yazdılar ve çoğunlukla kullanılması gerektiği gibi test ettiler.

Öte yandan, iyi bir testçi, uygulamaya işkence yapmaya çalışır. Birincil niyeti onu kırmak. Genellikle uygulamayı geliştiricilerin hayal bile edemedikleri şekilde kullanırlar. Kullanıcılara geliştiriciden daha yakınlar ve çoğu zaman bir iş akışını test etmek için farklı bir yaklaşıma sahipler.

Ayrıca, geliştiricilerin test cihazı olarak kullanılması geliştirme maliyetlerini artırır ve özel bir test cihazına sahip olmak kadar ürünün kalitesine de fayda sağlamaz. Geliştiricilerin, ucuz bir test cihazı tarafından daha iyi bir şekilde yapılmasını sağladığımda işlerini çapraz test etmelerine izin vermem. Yalnızca geliştiriciler ve test yapanlar arasındaki geri bildirim döngüsü çok pahalı hale geldiyse, geliştiricilerin birbirlerinin kodunu geçmesine izin verirdim, ancak benim deneyimime göre nadiren durum böyledir ve sürece bağlıdır.

Bu, geliştiricinin özensiz olması ve her şeyi test cihazına bırakması gerektiği anlamına gelmez. Ünite testleriyle yazılım desteklenmeli ve yazılımı test cihazına vermeden önce teknik hatalar en aza indirilmelidir. Yine de, bazen burada düzeltme yaptınız , orada herhangi bir geliştiricinin göremediği sorunları ya da diğer hataları kırın, sorun değil. Ayrıca, entegrasyon testi çoğunlukla geliştiriciler tarafından yapılmalıdır. Test cihazının temel amacı, gereksinimlerin karşılandığını doğrulamaktır.

Böyle küçük bir ekipte (ve ayrıca uygulamanın boyutuna bağlı olarak), test cihazını hibrit bir rolde, birim testleri ve UI testleri yazarken de görebiliyorum. Kesinlikle bir tane kiralamalısın .

Ancak test cihazından daha önemlisi düzenli donlar / dallardır. Doğru bir şekilde test edilmemiş bir şey sunmayın. Bir özellik eklediğinizde veya bir şeyi değiştirdiğinizde, onu çevreleyen her şeyin yeniden doğrulanması gerekir. Şirketiniz almazsa sadece kötü bir ün kazanırsınız. Dengesiz bir şey bırakmayın. Müşteri yazılımı belirli bir tarihe kadar sahip etmek istediğinde, yeterince erken gelişmeyi bırakıp düzgün bir şekilde test edin; böylece hata düzeltmeleri için yeterli zamanınız olur. Genellikle, son dakika özellik isteklerini reddetmek, bunları kötü uygulamak veya uygun testler olmadan serbest bırakmaktan daha iyidir.


9
Şiddetle ve şiddetle katılıyorum ... Geliştiriciler son derece etkili test cihazları olabilir, ancak bir özelliğin geliştiricisi de aynı özelliğin test edicisi olmamalıdır. Birçok küçük ekip, her biri üç farklı özellik üzerinde çalışan üç kişi tarafından oynadıktan sonra diğer üç geliştiriciden birine testler vererek her iki rolü de oynar. Bir takım bir QA test cihazına sahip olmadığında son derece iyi çalışır.
maple_shaft

5
@maple_shaft: Imho, test yapmamak için bahane yok. Herhangi bir proje, özel bir test cihazı ile daha yüksek kalite sunacak ve geliştiriciler odaklanabilir, varsa geliştirmeye odaklanabilirsiniz. Geliştiricilerin birbirlerinin kodlarını test etmesi, küçük ekipler için bile derhal geçici bir çözümdür. Joel'in makalesini de okumalısın .
Falcon,

3
Geliştiriciler test ediciler olabilir - ve iyi bir geliştirici kodun zayıf olabileceği ve kırılmaya maruz kalabileceği pek çok yeri gerçekten bilir. Sadece insanların tasarladıkları veya yazdıkları kodu test etmemelerini sağlayın - bu işe yaramaz. Başkalarının kodu uygun olabilir.
StasM

4
@deadalnix: İnsanların cevabımı okumadan ve anlamadan neden düşürdüğü beni gerçekten çok şaşırtıyor. Kendimi alıntılamak için: "Yazılım, test cihazlarına desteklenmeli ve yazılımı test cihazına vermeden önce teknik hatalar en aza indirilmelidir."
Falcon

2
"Öte yandan, iyi bir testçi, uygulamaya işkence yapmaya çalışıyor. Başlıca amacı, onu kırmak." - Kesinlikle katılmıyorum. Sürekli olarak klavyeyi ezmeye ya da alanları taşmaya çalışan bir test cihazım var. Elbette, bunlar hata, ancak hata yapan 1 trilyon dolarlık bir trilyon fatura, yapılacaklar listemde kaydolmayacak kadar düşük. Bir BÜYÜK tester çeşitli kullanıcıların uygulamadan kullanırsınız tüm senaryoları test eder. İyi bir geliştirici, tüm kod yollarının test edilmesini ve uygulamanın istenildiği gibi kullanıldığında çalışmasını sağlar.
Paul,

42

Geliştiriciler, diğer geliştiricilerin kodunun test edicisi olabilir.

Ancak kendi kodunuzu test etmek iyi bir hareket değildir - geliştiriciler kendi kodları hakkında zihinsel engellere sahip olma eğilimindedir ve bu nedenle kapsamlı veya uygun testler tasarlamada zorluk çeker.

Bunu iyi yaptıklarını düşünen geliştiriciler her zaman olacaktır, ancak genellikle yapmazlar (ve çok fazla kör noktalarım olduğunu biliyorum).

GERÇEKTEN CANT bir test cihazı kiralarsanız, geliştiricilerin birbirlerinin çapraz testi yapmasını sağlayın - yani, eğer A kodu yazarsa ve birim testleri yapıyorsa, o zaman bu birim testlerine bakmak ve başka şeyler eklenip eklenemeyeceğini görmek için B'yi kullanın. . Ve B'yi, kodu (bir kullanıcı olarak) denemek ve test etmek ve hataları bildirmek için alın.

Bu mükemmel değil ama her şeyi yapmaya çalışan tek bir geliştiriciden daha iyi.

Bazen iş arkadaşlarınız yazılımınızı kırmakta gerçekten iyi olabilirler, çünkü bundan zevk alıyorlar ve çok fazla umursamıyorlar - çünkü bu onların kodu değil.


2
Ah evet, elbette. Kesinlikle katılmak. Sadece istediğinin% 100'ünü alamadığın zaman, daha azına razı olmak zorunda kalabilirsin. Daha azının çok iyi olmadığını biliyorsunuz ama hiç yoktan iyidir.
hızla_

4
Genel olarak çapraz teste katılıyorum, ancak bazı takımlarda çatışmalara yol açacağım. Bazı insanlar başkalarını suçlamaktan hoşlanır ("eşyalarım çalışır, senin değil, lol, senden çok daha iyiyim") ve bu kabul edilemez. Buna defalarca şahit oldum. Geçiş, yalnızca birbirlerine saygı duyan meslektaşlarım arasında yapılmalıdır. Takımımın ben sunduk isimsiz geliştirici her hata herkes kendi / yüzünü kaybeder önlemek için sorumlu tutuluyor. Hatalar isimsizdir, olurlar.
Şahin

5
+1 kendi kodunuzu doğru şekilde test etmeniz mümkün değildir. Aklının size oynayabileceği püf noktaları şaşırtıcıdır - bir işlevi kodladığınızdan ve test ettiğinizden% 100 emin olacaksınız ve size başka birisinin alacağı çok dar bir durum dışında işe yaramadığını ve sizin için çok işe yaramadığını gösterecektir. Bir kere gösterildiğin için açık ol - ama asla kendin göremezsin. Zihin bilişsel kısayollar kullanır ve bunları test ederken kodu doğru şekilde test etmesi için kodu tasarlayan ve geliştiren kişi için imkansız kılar.
StasM

2
@StasM - kabul ediyorum, küçük bir yeterlilikle: aylar sonra kendi koduma döndüğümde hataları görebileceğimi ve nesnel olarak test etmek için daha iyi bir iş yapabileceğimi öğrendim. Ancak yazdıktan sonra kendi testinizi yapmak gerçekten zor.
Çabucak_ancak

1
@ As As: Bir geliştirici hala birim testleri, entegrasyon testleri vb. Yapıyor olmalı. Kör noktalar, gitmelerini istediğin için gitmez.
Çabuk_şimdi

11

Gazeteci doğru yazma eğiliminde olmalı mı? Demek istediğim, tüm gramer hatalarını bulmak düzelticiler ve editörler işidir.

Bununla birlikte, gazeteciler kendileri tarafından bazı yazım denetimi sağlar. Bununla birlikte, düzeltici ayrı ve önemli bir meslektir.

Aynısı, QA'nın geliştirmenin daha önemli bir parçası olduğu gerçeği dışında, geliştiriciler ve test edenler için de aynı şey. İyi bir geliştirici olsanız bile, tüm ortamları, tarayıcıları ve ürününüzün desteklediği işletim sistemlerini kapsayacak şekilde tüm test durumlarını iyice test etmek için vaktiniz yok.

Eğer biri, gelişmenin yanı sıra, sürekli bu işi de yapıyorsa, bu sadece basit bir gerçek demektir - yarı zamanlı bir test cihazıdır.


10

Ne kadar (3 geliştirici ve 1 tasarımcı) uygulamayı denemeye çalışsak ve kullanım davalarını uygulasak da, hala bazı hatalar görülmez ve sunumumuzu paydaşlarımıza mahvederiz.

Bir sprint veya iki için "kontrollü koşu" yapmayı, dev ve test çalışmalarını ayrı ayrı takip etmeyi düşünün. Bu tür bir çalışmanın sonunda, test etmek için ne kadar çaba harcadığınızı bulmak için toplanan verileri analiz edin.

Sınamanın çok çaba harcadığını öğrenirseniz, bu verileri yönetime iletin; bu isteğinizi destekleyen (şu an sahip olduğunuzdan çok daha fazla) zorlayıcı bir kanıt olacaktır .

Aksi halde (testinizin çok az zaman aldığını tespit ederseniz), daha iyi yapmak için ek çaba harcamayı düşünün (veya nasıl yapılacağını öğrenin). Bu anlaşma , ek bir çaba size yönetimiyle için plan - bunun yerine bir tester işe tercih edebilir çünkü. :)


... şirketin yeni bir test cihazı almasını tavsiye ettik. İşi yapan biri yalnızca test ediyor ve test ediyor olacaktı. Resmi bir profesyonel test cihazı.

Ancak, sorun şu ki, scrum ustası ve paydaşları bir geliştiricinin (veya bir tasarımcının) da bir test cihazı olması gerektiğine inanıyor.

İtiraf etmeliyim ki, şirketinizin yönetimi benim için bayağı kötü görünüyor. Yani - Tamam, proje için kaç tane test cihazının en iyi olacağını bulmak gerçekten zor olabilir .

Ancak en az bir test cihazına sahip olmak sadece güvenli bir bahis - gerçekten komik / çevik olduğunu iddia ederken denemek için tereddüt ettikleri gerçekten komik .


9

Birincisi bir giriş ekranında bazı değişiklikler yaptıktan sonra, iki geliştiricinin çapraz testi yaptık. Bu, düzenli test edicimizin doğum izninde olduğu zamanlardadı.

Temel olarak, kullanıcıların bir düzenlemeyi yapmak için "Düzenle" düğmesini kullanarak yakınlaştırmadan önce faturaları seçmek için kullandıkları bir Fatura Listeleme ekranını değiştirdi. Orijinal liste elden geçirildi ve filtreleme, gruplandırma, sıralama ve her türlü harika işlevsellik içeren yeni bir ızgara görünümü eklendi.

Testler iyi geçti ve değişiklikleri ertesi gün müşteriye yükledi. İki hafta sonra müşteri çağırır ve şöyle der: “Girdiğiniz yeni şeyi gerçekten seviyoruz, şimdi her türlü bilgiyi görebiliyoruz. Ama…… ..... şimdi faturaları düzenlemek için nereye gidiyoruz? ??"

Geliştiricinin onay kutusunu (seçim için) çıkardığını ve düzenle düğmesini çıkardığını ve geliştiricilerin bir öğeyi seçmek için her zaman çift tıkladıklarından, hiçbiri yanlış bir şey bulamadı ......

Geliştiriciler ve kullanıcılar farklı dünyalarda yaşar, çapraz teste sahip olmak, geliştiricinin kendi çalışmasını test etmesinden daha iyidir, ancak yine de aynı şey değildir.


3
"Farklı dünyalarda yaşıyorlar" demem ama insanların alışkanlıkları var ve aynı alışkanlığa sahip biri tarafından kullanılacaksa bir geliştiricinin kodu çalışacak. Bir test cihazının bulduğu bir hatayı ne kadar sıklıkla çoğaltamayacağımı, hatayı çoğalırken omzunun üzerinden bakamayacağımı ve "vay, az önce ne yaptığını asla yapmazdım" dedi.
gnasher729

4

Burada başkalarının belirttiği gibi, geliştiricilerin birbirlerinin kodlarını (ünite veya fonksiyonel testler) çapraz testleri olabilir ve belki de scrum usta ve ürün sahibiniz entegrasyon testine yardımcı olabilir, ancak kullanıcı kabul testi için aldığınızdan emin olmalısınız. Müşterinin testinden elde edilen çok sayıda geri bildirim - bu , gerçek kullanıcıların yaptığı gibi gerçekten çalışabilecekleri ve gerçekten açık bir iletişim kanalı olan dağıtımları sık sık ifade eder .


2

Test edilebilirliği göz önünde bulundurarak tasarım yapmalısınız, ancak özel bir test cihazınız yoksa, bazı şeyler çatlaklardan kayar çünkü hem tasarım, uygulama hem de test yazılımı için yeterli saat yoktur.


2

Test yazılımı tam zamanlı profesyonel bir iştir. İyi bir test cihazı olmak için iyi bir beyin, yetenek ve çok fazla deneyime ihtiyacı var. Bir yazılım geliştiricisinin ne kadar zeki olursa olsun, testler günlük çalışmalarının sadece küçük bir bileşeni olduğunda profesyonel bir test cihazına yaklaşabileceğini varsaymak saçma.

Bunun da ötesinde, bilinçaltı olarak yazılım geliştiricinin hataları bulmak istememesi sorunu ortaya çıkmaktadır .


1

Geliştiricilerin / tasarımcıların kodlarını test etmeleri gerektiği konusunda hemfikirim, ayrıca bir kod bölümü yapan tasarımcı / geliştiricinin, yaşamayı taahhüt etmeden önce söz konusu koddaki tek "göz" kümesi olmadığını. Bu her şeyi kapmayacak olsa da, en azından geliştirme sırasında kendi kodunuzu sınama ve yeniden test etme işlemlerinde sürünen körlüğü önlemek için yardımcı olacaktır.

Kullanım durumundan bahsederken, kodunuzun araçlarını da kullandığınızı kabul ediyorum? Aksi halde, hangi kodun test edilemeyeceğini görmeye yardımcı olabilir ve belirli koşullar sırasında beklenmeyen hatalara neden olabilir.

Yeterli çalışma varsa veya kuruluşunuz uygun boyutta ise, profesyonel bir KG kişisine ihtiyaç duyulduğuna, herkesin rolünü biraz daha fazla odaklanmasına yardımcı olacağı ve ne gibi bir kalıp olup olmadığını görebilecekleri söyleniyor. özlüyor ve daha da önemlisi, nasıl düzeltileceğini.

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.