Testçiler ve programcılar neden birbirlerini sevmiyor? [kapalı]

Bir programcı olarak kariyerim boyunca çeşitli programcılar ve testçiler gördüm ve birçoğu birbirlerini sevmedi / sevmedi. Demek istediğim, programcılar bir test cihazının işinin "gerçek" bir iş olmadığını ve testçiler programcıların çok "gururlu" olduğunu düşünüyor.

Bu benim tarafımdan alınan doğru karar mı, neden böyle ve bu tür problemlerden kaçınmak için ne yapabiliriz?

Bence bu genelleme ve aşırı basitleştirme üzerinde brüt.

Şu anda bir testçiyim, neredeyse bir dev olarak yazdığım kadar kod yazıyorum (test aşamasına bağlı) ve şirketteki en iyi arkadaşım bir dev ve hepimiz iyi geçiniyoruz.

Cevabınızı bulmak için kurum kültürüne ve ekiplerin birbirleriyle ilgili çalışma şekline bir göz atmak isteyebilirsiniz. Benim tecrübeme göre, eğer çok farklı iş noktalarından ya da "saldırı vektörlerinden" birlikte çalışmak yerine çok gerici iş akışlarınız varsa (yani devs ", test etmek için duvarın üzerinden bir yapı atar" ve "hataları geri atar"). Genel olarak her iki departmanın birbirinden hoşlanmayacağını göreceksiniz .

Çalıştığım yerde, her özellik ekibinin veya tasarım ekibinin çıktı üretmek için birlikte çalışan devs kadar test kullanıcısı var. Bu çıktı, test kodu tarafından belirtilen gereksinimleri karşılayan üretim kodudur.

Düzenle

Ayrıca, onusun ikisi arasındaki ilişkiyi desteklemek için test cihazında daha fazla olduğunu düşünüyorum.

Geliştiricilerin hayatlarını daha iyi veya daha kötü hale getirmek bizim için çok daha kolay, ama amaç sadece "hataları bulmak" değil, aynı zamanda potansiyel çözümler bulmak. Eğer yapamazsam, yapamam ve o noktada bir çözüm bulmak için hata atanan kişi ile çalışacağım . Ama bu basit bir çözümse, çeşitli gereksinimleri ve yazacağım nihai regresyon testini karşılayacak potansiyel bir düzeltme olduğuna inandığım şeyi sunacağım.

Ben SEVİYORUM onlar beni gidermek ve ben bir sorun olarak düşünmek olmaz şeyler nokta yardımcı olabilir, ancak müşterilerimiz olur - Benim test. Ve benim için en önemlisi, kötü kodlu birini öldürmediğimden emin olmam için bana yardım ediyorlar.

Sorunlar neden ortaya çıkıyor?

• Sürekli birbirinizin çalıştığına karar veriyorsunuz ve bazı insanlar herhangi bir eleştiride bulunamıyor
• Kötü bir iş yapmak karşıtınızın zamanını harcar
• İkiniz de baskı altındasınız, aynı zamanda, aynı şey için ve kimse şeyleri tutan kişi olmak istemiyor

Yukarıdakilerin birleşimi ile pozisyonların doğası, mevcut öfkenizi ve hayal kırıklıklarınızı birbirinden çıkarmanın gerçekten kolay olduğu anlamına gelir, eğer bu tuzağa düşerseniz birlikte çalışmayı bırakır ve birbirlerine karşı çalışmaya başlarsınız. Bunu kırmak zor ve kimse için iyi değil.

Programcıların bir program yaratması nedeniyle olur sanırım ve test ediciler daha sonra içinde kusurlar bulmaya çalıştıklarını algılarlar (test ediciler aslında nihai ürünü geliştirmenin bir parçası olsalar da). Birisi çok çaba harcadığınız bir şeyde kusur bulduğunda, muhtemelen onlara karşı olumsuz tepki vermek doğal bir tepkidir.

Bunu hafifletmenin yolları, geliştiricilerin ve test kullanıcılarının bitmiş ürünü tüm ekibin (test kullanıcıları ve geliştiriciler dahil) çıktısı olarak görmelerini sağlamak ve testin tek başına bir hata bulma görevi değil, önemli bir parçası olduğunu anlamalarını sağlamaktır. geliştirme süreci. Ve geliştiriciler testin gerçek bir iş olduğunu düşünmüyorsa veya kolay olduğunu düşünüyorlarsa, test matrislerini yazmalarını, yüzlerce test vakasını uygulamalarını, her bir adımı ve her bir sonucu belgelemelerini isteyin.

Birbirinden hoşlanmayan belirli programcıları ve belirli test kullanıcılarını biliyorum, ancak belirttiğiniz nedenlerden ötürü değil, birbirleri için çalıştıkları için.

Canavarın doğası bu. Kodlarının dikkatsizlik / tembellik / vb. Yoluyla hatalara eğilimli olduğunu düşündükleri için belirli programcıları kimin umursamadığını bildiğim bazı test kullanıcıları. Belirli test kullanıcılarına kimin umursamadığını bildiğim bazı kodlayıcılar, gülünç şekilde oluşturulmuş test koşullarını (toplama toplamaları) kullandıklarını ya da stile dayalı kod için revizyonlar isteyeceklerini hissettiler.

Bence kişilikleri bundan uzak tutmak ve eldeki göreve odaklanmak gerginlikleri azaltmak için çok yol kat ediyor. Bir kuruluş yeterince büyükse, çift kör test harika bir fikirdir.

Sorunları açıkça ifade edebilen bir testçi ve çözümleri açıkça uygulayan kodlayıcılar harika bir ekip.

Test kullanıcılarıyla yakın çalıştığım ekiplerde fevkalade iyi anlaştık. Testçiler, alınan çeşitli kararlara giren kararları anlarlar, geliştiricinin programlarının nasıl olduğunu bilirler ve iki grup arasında bir ilişki kurulur.

Testin denizde amorf bir varlık olduğu takımlarda durum böyle değildi. Testçilerin sonuçları daha az alakalı çünkü ne olup bittiği hakkında fazla bir şey bilmiyorlar, geliştiriciler, programın ikiye dokunulmamış olan kısımlarında bulunan önemsiz detaylar olarak gördükleri şeyden oluşan selden korkmaya başlıyorlar. Test ekibi, dosyalanan hataların hiçbirinin sabitlenmediğinden rahatsız olur (çünkü program bozulur ve geliştiriciler demolar için hazırlanmakla veya istenen özellikler vb. eklemekle meşgul olur) ve genel olarak her iki grup da birbirlerini düşman olarak görür ekip üyelerinin aksine "diğerleri".

Yakından çalışın ve işler iyi olacak. Birinin her iki takımın da koordineli ve aynı sayfada olduğundan emin olması gerekir. En iyi deneyimim, test ekibi, dev ekibinin davet edildiği herhangi bir üst düzey toplantıya davet edildi (hepsi) ve hepimiz programı biliyorduk, birleşik bir öncelik listemiz vardı ve devs ve test her ikisinde de aynı (yukarı- güncel gereksinimler belgesi. En kötü deneyimim (test dışında) temelde eşyalarımızı paketledik, bakılmak üzere yurtdışına gönderdik, sonra bir ay sonra bizim bile olmayan yanlış işaretlenmiş şeylerle (yeni tanışan 3. taraf eklentisi) her şeyi geri aldık test ekibinin beklentileri değil).

Ne geliştirici ne de test diğeri olmadan başarılı olamaz. Aynı makinenin iki yarısı gibi çalışırsanız ve diğer tarafınıza daha yakın ekip üyelerinize saygı duyduğunuz kadar saygı duyarsanız, her şey yolunda olacaktır. İki ayrı makine gibi davranın ve makinenizin daha iyi olduğunu varsayalım, işler korkunç olacak.

Programcılar ve testçiler birbirlerini sevmediklerinde, çoğu zaman yanlışlıkla amaçlarının çakıştığını hayal ederler.

Test uzmanları ve geliştiriciler bir "test ekibi" ve "geliştirme ekibi" yerine aynı ekipteyken bu sorunların büyük ölçüde azaldığını buldum. Bence bu yüzden test eden biri olarak şelale gelişimi yerine Agile takımlarında çalışmayı tercih ediyorum. Daha fazla iletişim var, geri dönüş daha hızlı ve geliştiriciler, bu iş daha şeffaf olduğunda teste giren zaman ve yetenek için daha fazla takdir görüyorlar.

Bireysel olarak da yapılabilecek çok şey var. Bir testçi olarak, hataları bulmanın yanı sıra olumlu geribildirim sağlayarak bu sürtünmeyi azaltabildiğimi fark ettim. Bana çok fazla şey öğretemeyen bir geliştiriciyi test etmedim ve geliştiricilerin kodu gerçekten anlamaya çalışan bir test kullanıcısını takdir ettiğini gördüm. Geliştiriciler , iyi bir zanaatkar gibi gurur duyar. Böceklere sahip olmanın onları daha az takdire şayan yapmadığını bilmelerini sağlamak önemlidir.

Geliştirilmiş en iyi kaliteyle çalışmak için en kolay bulduğum geliştiriciler, test etmeden önce yüksek kaliteli kod yazmak için çaba göstererek ön testler (özellikle otomatik birim testi ve manuel duman testi) yaptılar. Bu geliştiriciler ayrıca test için test edilebilirlik için kod incelemeleri yapmasını istediler ve test edicileri mümkün olan en kısa sürede sürece dahil ettiler (tasarımların daha hafif bir yüke sahip olduğu zaman test stratejilerini erken planlamaya başlamasını sağlar). Geliştiriciler, acele ile hangi alanların geliştirildiğini veya hangi alanların birim testi zor olduğunu söyleyerek testçilerin kodlarındaki zayıf alanları bulmalarına yardımcı olabilir. Genel olarak, geliştiricilerin bir testçinin işini kolaylaştırmak için yapabileceği her şey takdir edilir ve testçinin zamanına ve kendilerine değer verdiklerini gösterir. Geliştiriciler bunu yaptığında,

Başka bir sorun, KG'nin çoğu şirket tarafından genellikle bir düşüncedir. Son dakikada projeler hakkında birçok kez söylenir ve geliştirme ekibine kıyasla oldukça az anlaşılır. Bazı yerlerde geliştiriciye giden yol teknik destek, KG ve daha sonra bir geliştiricidir. Bu yüzden bazen geliştirici olmalarını isteyen insanlarla görevlendirilir ... Ve sonra bir kusur bulduklarında tutumları bu kişi nasıl geliştirici olabilir ve ben değil, böyle bir hata yapmam, vb.

Genel olarak bir QA ekibini çok isterim. Ayrıca, birim testinin QA'dan ayrı yazılım geliştirmenin gerekli bir parçası olması gerektiğini düşünüyorum. KG hataları bulduğunda, birim testleri bunu test etmek için değiştirilir. Ayrıca, birim test yapan geliştiricilerin KG'nin ne bulduğunu daha iyi anlayabileceğini düşünüyorum.

Buna ek olarak, birçok KG ekibi işleri manuel olarak yapmak zorundadır, bu durumda GERÇEKTEN sıkıcı bir iştir. Bazı yerlerde KG, komut dosyaları yazar ve komut dosyası GUI'lerine bile izin veren otomasyon programlarını kullanır (düğmeler / vb. İçin ekrandaki bir tür görüntü tanıma yoluyla). İlk başta büyük değişiklikler olduğunda hala zor, ama sonra her şey otomatik ve daha eğlenceli görünüyor ...

Ayrıca bazı geliştiriciler kalite güvencesine bakıyor. Yine de QA müşteriden daha fazla bir kusur bulmak istiyorum.

Testçilerimizi burada seviyoruz, ama sonra çoğumuz onlardan önce nasıl olduğunu hatırlıyoruz. Test cihazlarına sahip olmak, üretime geçtikten sonra müşterinin onları bulmasından çok daha iyidir. Bir hata oluşturmayan veya bir gereksinimi yanlış yorumlayan bir geliştirici canlı değil.

Anahtar, tüm profesyonellere nezaket ve saygılı davranmaktır. İşinizin onlarınkinden daha iyi veya daha önemli olduğunu düşünmeye başladığınızda, o zaman kaybettiniz.

Bu soruya dayanarak: Yazılım Test Teknikleri veya Kategoriler Test uzmanlarına ve genel olarak testlere yönelik bir tutum ayarlamasına ihtiyacınız olduğundan şüpheleniyorum.

Bir geliştirici olarak, gerginlik payımı test kullanıcılarıyla yaşadım.

Bir işte, test ediciler nadiren "doğru olanı" test ederlerdi. Ürünümüzün sunucusu için yeni bir özellik uygulardım ve test kullanıcıları kullanıcı arayüzü ile ilgili bir dizi hatayı rapor edeceklerdi. Bu üründe, kullanıcı arayüzü beri yapılandırılmamış değil kodlu , geliştirme arayüzündeki sorunların varlığı (veya değil) son kullanıcılar benzer sorunlarla bir UI sahip olup olmayacağını kesinlikle hiçbir bağlantısı yoktu. Testçiler bunu biliyordu, ancak yabancı alanlar hakkındaki hataları günlüğe kaydetmede ısrar ettiler.

Bununla birlikte, iyi test ediciler altın ağırlıklarına değer - bir anda iyi bir test cihazı için berbat bir geliştiriciyle ticaret yapardım. İyi bir test cihazı, kaliteli bir ürün sunmada bir ortaktır.

Ayrıca, test edicilere düşman muamelesi yapan bazı geliştiricileri de tanıyorum - sanki test ediciler hataları ortaya koyuyor gibi. Geliştiricilerin testçilerin asla hatayı getirmediğini fark etmeleri önemlidir - sadece ortaya çıkarırlar.

Bu problemlerden nasıl kaçınılır? Birbirinize karşı nazik olmaya ne dersiniz? Birinin kaliteli bir yazılım uygulaması elde etmek için diğerine ihtiyacı vardır, peki neden bunu başarmak için her iki tarafın ne yapması gerektiğine saygı duymuyorsunuz? Her bir tarafın ne yaptığını öğrenin ve gerçekten ilgili işi takdir edebilirsiniz.

Bir gereksinimin doğru yorumunun ne olduğunu her iki taraftaki inatçılık, genel olarak geliştiriciler ve test ediciler arasındaki çatışmayı görme eğiliminde olduğum yerdir. Bir züppe veya kibir görünümü olsa da, her iki taraf da silahlarına yapışır ve doğru olmak ister.

Bu problemden kaçınmanın iyi bir yolu, geliştiricinin, test edenin ve bazı arabulucuların bir iş analisti veya proje yöneticisinin çeşitli sınır durumlarının nasıl ele alınması gerektiği üzerinde çalışmasını sağlamaktır. Dikkate alınması gereken bir şey, geliştiriciler ve test ediciler arasında bir anlaşmazlık olduğunda ne tür egoların ortaya çıkabileceğidir.

Kötü duygu genellikle kötü iletişimin sonucudur, bu da genellikle programcıların ve testçilerin kodun farklı bakış açılarına sahip olmasının sonucudur. Programcı, üzerinde çalıştığı bitleri yakından tanır, ancak genel sisteme (spesifikasyonun ona söylediklerinin ötesinde) nasıl uyum sağladıklarını bilemeyebilir. Testçiler büyük resmi görür, ancak kodu ayrıntılı olarak bilmezler. Gruplar aynı şeyler için farklı terminoloji ve prosedürler kullanabilirler.

Bu, hatalı bileşene karşı kusurların açılmasına neden olabilir (bileşen, akış yukarıdaki bir hataya yanıt verdiği için) veya geliştiricilerin, çevrelerindeki sorunu yeniden üretemedikleri için meşru kusurları kapatabilirler (çünkü gerçekten nasıl çoğaltılacağını anlamıyorlar sorun doğru). Bu çok olursa, gruplar arasındaki ilişkileri zorlayabilir.

Sonra 11. saatte bir dizi kusur elde etmenin sevinci var; son tarihler yaklaşıyor, zincirdeki acil yöneticinizden baskı geliyor ve zaten çözdüğünüzü bildiğiniz bir sorun üzerinde yeni bir dizi hata alıyorsunuz ve gerçekten gitmek için zaman ayırmak istemiyorsunuz kanıtlama süreci boyunca.

Bir gerçekten KG ekibinizi sinirlendirmeye iyi bir yol "yüksek önceliğe sahip kusur birikim o kadar büyük olduğu gerekçesi ile yüz özetle yakın birkaç meşru ama düşük öncelikli kusurları (özellikle aksi işlevsel çirkin veya tutarsız UI'ler aleyhine açılan) etmektir onlara asla ulaşamayacağız. " Program yöneticisinin e-tablosunda kırmızıdan yeşile dönüp, yüksek yönetimden bir saldırgan alırken, KG ekibi bir sürü sahte kusur dosyalamak için metriklerine bir darbe alır.

Kötü juju.

Bu genellikle üç faktörden kaynaklanır -

• Bu gibi sorular, endüstride geliştiricilerin ve testçilerin birbirlerini sevmedikleri bir 'folklor'un varlığına işaret ediyor. İnsanlar, takımlarında böyle bir duygu olmasa bile, bunu güçlendiren yönleri bulmaya çalışırlar.
• Günlüğe kaydedilen hata sayısı gibi metriklerle ilerlemeyi ölçen yetersiz proje yöneticileri.
• İşlevsiz bir ekip (ve bunu düzeltmek için yeterince önem veren liderlerin eksikliği).

Test kullanıcılarını seviyorum, ancak iki davada çatışma olduğunu gördüm.

1. Yönetim test ve birbirlerini devs oyun.

2. Ayrıntı eksikliği olan sorunlar sürekli gönderildiğinde, yani "Ekran x çalışmıyor".

Bence durum böyleyse, bu olgunlaşmamışlığın bir işaretidir. Bazen bir şaka olarak konuşabilirsiniz. Ancak siz (aynı projede çalışan geliştiriciler ve testçiler) bir takım gibi hissetmezseniz, sonuç bir felaket olacaktır.

Test, yazılım geliştirme yaşam döngüsünün oldukça önemli bir parçasıdır (çevik olsun ya da olmasın). Bu nedenle, test kullanıcılarını sizi böceklerle rahatsız etmek için yaşayan insanlar olarak değil, kaliteli yazılım göndermenize yardımcı olan bir takım arkadaşı olarak düşünmelisiniz.