Yazılım Mühendisleri için bir süre Kalite Güvence Mühendisleri olarak çalışmanın iyi bir fikir olduğuna inanıyor musunuz? [kapalı]

İnanıyorum. Neden?

1. KG mühendislerinden bir şekilde daha üstün olduklarına inanan birçok Yazılım Mühendisiyle karşılaştım. Bir süre bir QA mühendisinin işini yaparlarsa ve bunun kendine özgü ve değerli bir beceri seti olduğunu fark etmeleri, bu inancı gidermeye yardımcı olabileceğini düşünüyorum.

2. Bir Yazılım Mühendisi kendi programlarını test etmekte ne kadar iyi olursa, yazılım geliştirme yaşam döngüsünün geri kalanında yol alırken kodlarının oluşma süresi o kadar düşük olur.

3. Bir Yazılım Mühendisi, bir programın nasıl kırılabileceğini düşünmeye ne kadar çok zaman harcarsa, bu vakaları geliştirirken bunları daha sık düşünerek son üründeki hataları azaltır.

4. Bir Yazılım Mühendisinin "tam" tanımı her zaman ilginçtir ... eğer bir QA mühendisi olarak zaman geçirdiyse, belki de bu tanım yazılımların tasarımcısıyla daha yakından eşleşir.

Not Birisinin işe alındığı pozisyonda olmayan bir pozisyonda çalıştığının farkında olduğumdan kesinlikle bu geliştiriciyi kaybetmek için bir reçete olduğunu unutmayın.

Hepiniz ne düşünüyorsunuz?

1. Bir şekilde KG mühendislerinden daha üstün olduklarına inanan birçok Yazılım Mühendisiyle karşılaştım. Bir süre bir QA mühendisinin işini yaparlarsa ve bunun kendine özgü ve değerli bir beceri seti olduğunu fark etmeleri, bu inancı gidermeye yardımcı olabileceğini düşünüyorum.

İyi bir yazılım mühendisliği, test, metrikler ve istatistikler de dahil olmak üzere kalitenin arka planına sahiptir. Her türlü yazılım geliştirme yapan herkes, kalite kaynak kodunu koruduğundan ve etkili test senaryoları ürettiğinden / koruduğundan haberdar olmalıdır (aşina değilse). Zamanla, herhangi bir yazılım geliştiricisinin farklı kalite yönlerini - kod kalitesi, taşınabilirlik, sürdürülebilirlik, test edilebilirlik, kullanılabilirlik, güvenilirlik, verimlilik ve güvenlik - bir anlayış kazanacağından şüphelenirim.

Yazılım mühendisleri yaşam döngüsünün belirli bir yönüne odaklanabilir - gereksinim mühendisliği, mimari ve tasarım, inşaat, test ve bakım. Ancak, odaklanmanıza bakılmaksızın (bir iş olarak veya projenin şu anki aşamasında), kaliteyi hatırlamak önemlidir.

2. Bir Yazılım Mühendisi kendi programlarını ne kadar iyi test ederse, yazılım geliştirme yaşam döngüsünün geri kalanında yol alırken kodlarının oluşma süresi o kadar düşük olur.

Bu doğru olabilir. Ancak bazı konular en iyi gelişimde daha sonra görülür. Örneğin, performans ve verimlilik sorunları entegrasyona kadar görülmeyebilir. İyi, sağlam kod ve etkili birim testlerine sahip olmak sadece bir başlangıçtır. Kalitenin gereksinimlerle başlaması ve bakım faaliyetleriyle sonuna kadar takip etmesi gerekir.

3. Bir Yazılım Mühendisi, bir programın nasıl kırılabileceğini düşünmeye ne kadar zaman harcarsa, bu vakaları geliştirirken bunları daha sık dikkate alır ve böylece son üründeki hataları azaltır.

Bu tamamen doğru bir ifade. Fakat yine de, gereksinimlerde çatışma olmadığını, mimarların tasarımın gerçekten gereksinimleri karşıladığından emin olmak için gereksinim mühendisleri de bağlıdır. Herkes işlerinde delik açmaya çalışmalı ve sonra onları iyi ve sıkı bir şekilde mühürlemek için uygun insanlarla çalışmalıdır.

4. Bir Yazılım Mühendisinin "tam" tanımı her zaman ilgi çekicidir ... eğer bir KG mühendisi olarak zaman geçirdiyse, belki de bu tanım yazılımların tasarımcısına daha yakın olacaktır.

"Tamamlandı" yalnızca gereksinimlere göre ölçülebilir. Gerekler yerine getirilir ve proje tamamlanır ya da eksik gereklilikler vardır ve proje tamamlanmamıştır. Diğer tüm tam ölçüler işe yaramaz.

Programcıları kodlarından sorumlu hale getirmek ve kendi hatalarını düzeltmelerini istemek bununla ilgilenebilir. Bu ve bonus ve / veya iş kaybı.

Bu deneyim yardımcı olmaz, ama bu düşünce tarzı ile ne kadar ileri gidebilirsiniz? Teknik Destek, Satış, Beta Kullanıcısı, tuvaletleri ovun (bu bir hileli deneyim olacaktır).

“... KG mühendisleri olarak çalışmak zorunda ...”? Kendinizi düşmanca ya da cezalandırıyorsunuz.

Ben bir yazılım geliştiricisiyim. Kalite güvence departmanımız olmasına rağmen işimin bir kalite güvencesi mühendisi olmasını da düşünüyorum. Benim işim, bazı şeyleri başaran yazılımlar sunmak ve bunu yapmak için birim testleri yazmak ve yazılımın bunları geçtiğinden emin olmak zorundayım.

KG departmanımızla ortaklık içerisindeyim. Amacım işlerini kolaylaştırmak, tıpkı onların işi gerekenleri yapan yazılımları sunma hedefime ulaşmamda yardımcı olmak, böylece hayatımı kolaylaştırmak. Tıpkı ünite testlerimi yaptığım gibi onları ikinci gözlerim ve biraz da güvenlik ağım olarak görüyorum.

Yazılım geliştirmeyi seçiyorum ve yazılım geliştirmek istiyorum. Bazı yöneticiler bana gelip bunu yapamayacağımı ve KG yapmak zorunda olduğumu söylerse, onlara yeni bir yazılım geliştiricisi VE KG personeli bulmaları gerektiğini söylerdim çünkü orada çalışmayacağım. Benim kod ile olabildiğince anal ama yaratıcı süreç ve programlama bulmaca / meydan okuma benim için son derece önemlidir. Kod yazamıyorsam, çatallı asansörlere geri dönmeyi tercih ederim, çünkü yaratıcı olmak ve benim yoluma meydan okumaksızın kurumsal bir ortamda olmak benim için mutlak bir cehennem olurdu.

Genel olarak sunduğunuz seçenekler çok çekişmeli geliyor ve bazı korkunç geliştiricilerle gerçekten kötü deneyimler yaşayıp yaşamadığınızı merak ediyor. Benim düşünceme göre, bir geliştirici HER ZAMAN kalite sorunlarının ve testlerinin farkında olmalı ve resmi KG departmanının kullanacağı gibi birim testlerinde titiz testler olarak geçene kadar bittiğini düşünmedikleri çalışmalarından yeterince gurur duymalıdır. Eğer bir akranım olsaydı ya da bir takımda teknoloji lideri olsaydım ve KG'ye karşı herhangi bir '' tude '' gösteren bir geliştiricim olsaydı, beni bir tutum düzeltmesi için çektiğini fark ederdi. Yazılım dağıtım madalyonun her iki tarafı işbirliği yapıp ekip olarak hareket edemezse gerçek bir kültür sorunu vardır. Orada çalışmak istemem ve İK ile birlikte üst yönetimin de ele alınması gerekiyor.

Programcıların KG mühendisi olarak çalışmalarını sağlamak, en iyi geliştiricilerinizi kaybetmek için bir reçetedir. Programlama ve kalite güvencesi farklı beceri setleri ve düşünce süreçleri gerektirir.

Ancak, programcılarınızın KG ekibine geçmeden önce kendi çalışmalarını test etme ve doğrulama konusunda yetenekli olmaları önemlidir. Geliştiriciler ve KG farklı araçlara, bilgi ve becerilere erişebilir. Geliştiricilerin, beklenmedik davranışlar, sınır koşulları için birim testi, yarış koşullarını arayan dişli kodunu vurgulama vb.

KG testlerini kullanıcı açısından yapar. Farklı kullanıcı türleri gibi düşünmek, garip uç durumlar icat etmek ve belirsiz sorunları tekrarlanabilir hale getirmek QA becerileridir.

Mutlaka değil - hem programcıların hem de test kullanıcılarının farklı becerilere sahip olmaları gerekir. İyi bir programcı olmanız, iyi bir test kullanıcısı olabileceğiniz anlamına gelmez (birçok insan bunu anlamıyor, ancak bir programcı olmak sizi otomatik olarak test kullanıcısı olarak nitelendirmiyor).

Harika bir test cihazının gerçekten şeytani becerilere sahip olması, yazılımın yapmak için tasarlanmadığı şeyleri yapabilmesi gerekir, ancak kullanıcının gerçek dünyada yapmasını bekleyebilir. Beceri, sabır, neyin yanlış gidebileceğini görme yeteneği, kullanıcının zihniyeti ve diğer birçok faktörü anlamak gerekir.

Programcı ve testçi kelimelerini kullandığımı unutmayın - ancak bir yazılım mühendisi iseniz ve henüz bir programcı mı yoksa testçi mi olmak istediğinize karar vermediyseniz, hem bunları kapsar hem de evet, en azından ikisinde de deneyim sahibi olmalısınız karar vermeden önce hayatınızın ilk birkaç yılında.

Bu, deneyimli bir programcı almanız ve onu sadece QA mühendislerinin ne kadar zor çalıştığını anlamasını sağlamak için bir süre test etmeniz anlamına gelmez.

Teklifinizde gördüğüm bazı potansiyel sorunlar:

1) Sahadaki yeni yazılım mühendislerini KG departmanına kısa bir süre için koymanızı önerirseniz, bunun tam tersi bir etki yaratmaz mı? - QA'nın bir acemi olduğunuzda yaptığınız bir şey olduğunu ve ne yaptığınızı anlamadığınızı varsayabilirler - sonuçta onlar için işe yaradı.

2) Bir süre çok kötü bir testçi olmak, onlara değerli bir şey öğretmek zorunda değildir. Ancak daha sonra erişilemez hale gelebilir, çünkü şimdi test hakkında her şeyi bildiklerini varsayacaklar , çünkü bir kerede bir test departmanında 6 hafta geçirdiler.

3) Açıkçası sadece kısa bir süre orada olacakları ve KG departmanının bunu bileceği göz önüne alındığında, aynı zamanda sadece az gözetim veya anlayış gerektiren, ancak onları meşgul eden nispeten nispeten iddiasız, kolay görevler vermeleri muhtemeldir. . Bu sadece 1 ve 2'yi güçlendirecektir.

4) 1, 2 ve 3'ten kaçınmak istiyorsanız, test departmanınızı test etmekle bile ilgilenmeyen birine öğretmeye ve denetlemeye muazzam miktarda enerji yatırmaya değer olduğuna nasıl ikna edeceksiniz? (Size söyleyebilirim ki, test etme yetenekleri için seçilmemiş biriyle çalışmak korkunç bir zaman ve enerji gerektirir . Birkaç hafta boyunca test ekibine ek kaynak sunmuyorsunuz, Yeni başlayanlara öğretirken onlardan en deneyimli insanlarından birini birkaç hafta kaybetmelerini istiyoruz).

Tüm bunları söyledikten sonra, yeni yazılım mühendislerinin test anlayışını artırmak için genel hedefinizin gerçekten harika olduğunu düşünüyorum. Bence Greg'in önerisinin bunu başarması daha olası - dev & QA ekiplerinizin yakın işbirliği içinde çalışmasını sağlayın ve ekipler arasındaki engelleri aşmaya çalışın. (Şu anda testçilerin ve programcıların aynı ekipte olduğu bir şirkette çalışıyorum - gerçekten harika ve asla ayrı ekiplerde çalışmaya geri dönmek istemiyorum.)

Hala programcıların KG'de bir ipucu yapmalarına hevesliyseniz - işte bir öneri: örnek olarak yol gösterin. Önce kendin git. Belki de ekibinizin üyelerinin zaten iyi olduklarında yapabilecekleri bir şey haline getirin ve her hafta üst üste binen alanlarda uzmanlaşan diğer ekiplerle - test, DBA'lar vb. bunu böyle sunuyorsanız, o zaman başarı şansınız daha fazla olacaktır.

Normalde gördüklerinizin tersi gibi bir kariyer yolum var. Bilimsel olarak zorlu fizik için yazılım desteği olarak başladım, daha sonra bir bilgisayar şirketi için mimarlık, programlama ve algoritmaların kesişiminde çalıştım. Bundan sonra, birkaç yıl boyunca büyük bir mühendislik kodunun performans optimizasyonunu yaptım, ancak bu çalışma bile bitti. Şimdi, emeklilik yaşına yaklaşıyorum, aynı kodda KG yapıyorum. Bu bir meydan okuma ve angarya kombinasyonudur. Hata düzeltmelerinde% 100 çalışan gerçekten keskin bir yeni adamımız var ve onunla çok çalışıyorum. Zor bir pozisyon ve bunu yaparken çok şey öğrenebilirsiniz. Bu noktada, mesleki gelişime olan ana ilgim comp sci college birinci sınıf öğrencisi ikizlerim içindir. Bu yüzden kariyerleriyle, özellikle uygulamalı matematikle ilgili olan şeyleri öğrenmeye (veya yeniden öğrenmeye) yeni bir ilgi duyuyorum. Şimdi QA / validasyon ile ilgili olduğum şeylere farklı bir bakış açısına sahibim, önceki çeyrek yüzyıl için herhangi bir maliyetle hız, hız, hızdı.

Yazılım testi yapıcı olmaktan ziyade yıkıcı bir süreçtir. Ancak programcı, ürünün zamanında ve bütçeyle tamamlanmasını sağlamak için ürünlerine yapıcı düşünür. Yazılım geliştiricisi kendi ürününü yıkıcı gibi düşünüyorsa, ürünü kimin yanında oluşturacak. Bu nedenle, yazılım geliştirme döngüsünün her bir bölümü, geliştirme döngüsünün her bir bölümünde atanan kişiler tarafından yapılmalıdır. Eğer iki ya da daha fazla alanla uğraştıysanız, o zaman bunların hiçbirinde mükemmel olmayacağınızdan emin olabilirsiniz, bu yüzden bir şey ya programcı ya da KG ya da başka bir seçenek yapın ve bu konuda mükemmel olun.