Bazı sistem yöneticilerini tanıyordum ve ona göre, test kuruluşlarına geliştiricilere kıyasla bir organizasyonda tercih verilmiyor. Hiç şüphe yok ki test ediciler olmadan yazılım sürümleri mümkün değildir, ancak testten asla haberdar olmadım. Saldırı amaçlı değil.
Yanıtlar:
Deneyimlerime göre, maalesef, genellikle ikinci sınıf çalışanlar gibi muamele görüyorlar ve daha da kötüsü programcılar için anlamsız bir yetenek.
Bir dizi şeyden kaynaklanıyor:
Testçiler işlerini doğru bir şekilde yaparken, programcılar dışında herkesin var olduklarını bile unutmaları kolaydır. Bir ağ yöneticisi gibi, onları yalnızca işlerini yapmadığında veya kötü bir şekilde yaptıkları zaman fark edersiniz. Dolayısıyla, kuruluşun geri kalanı açısından, sadece hataları nedeniyle hatırlanırlar.
Yanlışlıkla programcı olmak isteyen, ancak henüz bu işler için nitelikli olmayan kişiler için giriş seviyesi bir iş olarak görülüyor. Aslında, çalıştığım bir şirkette, Soru-Cevap iş unvanı alma zevklerine rağmen Jr. Programcı iş unvanları verildi. KG departmanında olmaları bile İK'nın bu konuda karar vermesi için yeterli değildi.
# 2 nedeniyle, test edicilerin hepsinin giriş seviyesi insanlar olduğu ve buna göre ödeme yapılması gerektiği varsayılmaktadır.
Kimse eleştirilmekten hoşlanmaz ve savunma programcılarının test edicileri beğenmemesi çok yaygındır, çünkü işleri tüm gün programcı hatalarına işaret etmelerini gerektirir. Bir yönetici olarak, programcılara QA ekibinin onları iyi görünmelerini sağlamak için orada olduklarını hatırlatmak için bir PR görevindeydim.
İnsanların en azından başlangıçta seçim değil kazayla girdiği bir iş olma eğilimindedir. Katıldığım okulların hiçbirinde insanları yazılım soru-cevaplarına hazırlayan herhangi bir derece planını hatırlamıyorum. Varlar, ancak genellikle sadece daha az yetenekli profesyoneller oldukları fikrine katkıda bulunan alt sınıf meslek okullarında.
Test işleri, deniz dışında gönderilecek programlama işlerinden çok daha olasıdır. En azından programcılar, tasarım ihtiyaçlarını yerel olarak iletmenin daha verimli olduğunu ve şirketin amiral gemisi uygulamasının şirket içinde nasıl çalıştığını bilmenin değerli olduğunu iddia edebilirler. Bununla birlikte, testlerin modüle edilmesi çok daha kolaydır ve bu nedenle dış kaynak kullanımı daha kolaydır.
Yukarıdaki tüm nedenlerden dolayı, testçiler duvardaki yazıyı görme ve özellikle gerçekten iyi olanlar gibi diğer işlere (programlama gibi) geçme eğilimindedir. Bu, çoğu test işinin, henüz yanmamış veya başka şeylere geçmemiş daha fazla giriş seviyesi insanıyla personel alma eğiliminde olduğu anlamına gelir; bu da maalesef yukarıdaki fikirlerin birkaçını güçlendirir.
Şirkete bağlıdır, ancak genellikle. Genellikle ikinci sınıf vatandaşlar olarak görülürler ve birçok şirkette testler, daha sonra gerçek bir geliştirici olmaya geçeceğiniz giriş seviyesi bir konum olarak görülür.
Bu elbette saçmalık. Bazı iyi testçilerle çalıştıktan sonra, bunların hem değerli hem de gelmesinin zor olduğunu söyleyebilirim. Zihinsel olmayan hataları bulmak için yeterince yaratıcı ve kapsamlı bir iş yapmak için yeterince metodik olan bir zihne sahip biri.
Ancak bir istisna: Birkaç Microsoft test adamı tanıyorum ve test uzmanlarının birinci sınıf vatandaşlar olduğunu duydum.
Oldukça büyük bir projede bir yıl boyunca fonksiyonel test cihazı olarak çalıştım. 10 üyeden oluşan her takımda 2-3 kişi test edildi. Şunu söylemeliyim ki, proje için geliştiriciler kadar eşit derecede davrandık.
Hata bulmak kolay değil. İlk olarak, test kullanıcıları kodun ne yapması gerektiğini anlamalıdır. Bu, gereksinimleri okumak ve anlamak anlamına gelir. Burada önemli olan gereksinimleri anlamaktır - eğer testçiler pozitif test senaryolarının nasıl yazılacağını bilmek için gereksinimleri yeterince iyi anlayamıyorlarsa endişelenmelisiniz. Bu, geliştiricilerin yaptıklarını varsaydıkları şeyi yapan bir kod yazdıkları anlamına gelir. Bu varsayım doğru mu? Gereksinimleri çözene kadar bilmiyorsunuz ve testçilerinize bu kusuru buldukları için teşekkür edebilirsiniz.
İkincisi, testçiler kodun yapması gerekeni yapmamasını sağlayan yanlış test senaryoları yazmalıdır . Makul bir kural, her pozitif test vakası için 5-10 yanlış test senaryosu yazmanızdır. Bu, gereksinimleri daha da iyi anlamak ve çoğu zaman bubilgi, ya da en azından projemizde kafa karıştırıcı ve belirsizdi. (Ve bu, gereksinimleri toplama konusunda az çaba gösterdiği için değildi - sadece ekibimizde 13.000 gibi bir şey vardı.) Yine, geliştiriciler kodlarını varsayımlarını kullanarak yazacaklar, hatta daha da kötüsü, bunu hiç düşünmemişlerdi. Peki, kod normal olmayan bu koşullar altında ne yapar? Test edene kadar bilmiyorsun. Belki program yanıt vermez; belki sadece çöker; belki de verileri yok eder; belki kullanıcının komutları root kullanıcısı olarak çalıştırmasına izin verir. Ne yaparsa yapsın, bilmek istersin. Aksi takdirde bir gün gazetede şu başlığı okuyorsunuz - [ŞİRKETİNİZİN ADI] 'ın BAYRAK PROGRAMI MÜŞTERİLERİN KREDİ KARTI NUMARALARINI BUNUN.
Bu yüzden test edicilerinize iyi davranın. Onlara iyi davran. Sonuçta, yazılımınızdaki hataları köklendiren ve hayatınızı ve bizim hayatımızı kolaylaştıranlardır.
Sorunları verimli bir şekilde analiz edebilen ve iyi test otomasyonu yapabilen iyi test ediciler, orada çok sayıda kovboy test cihazı olduğu için ağırlıklarına değer (bir "test cihazı" ile röportaj yaparken, gülüyor olduğunu bildiğimiz anda gülüyor CV'sinde test edilirken yerinde dolduruyor).
Ekibimde test görevlisi eşit muamele görüyor - sorumluluk ve maaş da dahil. Eğer tüm gün ertesi gün tıklayan bir test cihazı istiyorsanız - onları ucuz bir yere dış kaynak (biz de bunu).
Diğer cevapları okuduktan sonra güncelleyin: Yaptıkları işi seven birçok KG uzmanı var. Saygın KG pozisyonlarına rastlamadıysanız başka bir perspektif vermek için, burada bir örnek: Önde gelen otomobil üreticileri için yerleşik uygulamalar / mobil uygulamalar testi. Bir araç piyasaya sürülmeden önce iş gereksinimlerinin tamamen karşılandığından emin olurlar ve hiçbir kullanıcı yavaş veya tepkisiz bir araç kontrol panelini deneyimlemez. Yöneticiler ve üst düzey yönetim ile ve ayrıca QA sürecini planlamadan tasarım tesisinde simülatörler üzerinde uygulamalı testlere kadar geliştiricilerle yakın çalışırlar. Düşük profilli olduklarını düşünemiyorum, büyük sorumlulukları ve sahipliklerini ele alıyorlar ve en iyi mühendisler arasındalar.
şimdi benim önceki cevabım, kapak tarafı:
Mühendislik mezunlarının test birimlerine tahsis edilmekten nefret ettiklerini gözlemledim (bağlam: Hindistan, her şeyin 'iş gereksinimleri' tarafından yönlendirildiği büyük yazılım hizmetleri firmaları), çünkü bunu teknik olmayan bir çalışma ortamı olarak görüyorlar. Onlara 'web sayfasındaki tüm bağlantıları tıklayın ve doğrulayın' gibi talimatlar içeren excel sayfaları verilir, bir aşağılama olarak gördükleri ve teknik becerilerinin olmadığı gibi hissettiği teknik olmayan akışlardan (bilim, sanat) mezunlarla çalışmak zorunda kalırlar. kullandı. Bu tahsisler tamamen kurumun gereksinimlerine dayanmaktadır ve daha taze olan çoğu zaman kariyer yolunu müzakere etme gücüne sahip değildir. Dolayısıyla, bu kadar büyük bir BT şirketini hedefleyen bir iş arayan iseniz, uyarıldınız. Şirketten doğru zamanda çıkmak dışında pratik olarak fazla bir şey yapamazsınız.
Otomatik test, yük / performans testi vb. Öğrenme fırsatları olmadığı sürece, kariyer bir dereceye kadar durgundur. kuruluşumdan başka herhangi bir birimden daha fazla. Tüm alanlardaki projelerde test kaçınılmaz olduğundan, tüm sektör dikeyleriyle bir dolgu veya yapıştırıcı olarak çalışırlar.
Kariyerinizi istediğiniz gibi sürdüğünüzden eminseniz, test düşük profilli bir şey değildir. 4-5 yıllık deneyim ve biraz şans ile, bazen en üst düzey iş kullanıcıları ile etkileşime giren çok iyi bir pozlama elde edebilirsiniz. Ayrıca, çalıştığınız endüstri / alanı iyi bir şekilde kavrayabilirsiniz (çoğunlukla sistemin bir kısmına odaklanan bir geliştiriciye kıyasla). Bu noktada iş analisti türünde bir role de geçmeyi tercih edebilirsiniz.
Yayın ekibinden QA ekibinin sorumlu olduğu şirketleri biliyorum. Bu, kalite eksikliği nedeniyle bir tahliyeyi engelleme gücüne sahip oldukları anlamına gelir. Sahada bir sorun bildirilirse, bunlar yangın hattındaki ilkidir (saha mühendisinden hemen sonra).
Genellikle daha yüksek alan bilgisine sahiptirler. Geliştiriciler modüllerine / özelliklerine odaklanırken ürünün genel işlevselliğini daha iyi tanıma eğilimindedirler.
Ayrıca kendi test araçlarını yazmak zorunda oldukları QA kuruluşlarını da biliyorum. Tüm şeyleri otomatikleştirmekten bahsetmiyorum bile. Ben bir geliştiriciyim ve her zaman özelliklerimi test eden KG kullanıcılarına değer verdim.
En azından benim organizasyonumda KG, geliştiricilere eşit davranılıyor. Protokol ve ağ mimarisi bilgisinin programlama becerileri ile eşit derecede değerlendiği alan (telekom) nedeniyle olduğunu düşünüyorum.
Evet. Beğen ya da bırak aynı derecede önemlidir, ancak her zaman daha az tercih edilirler. Değiştirilmesi kolay olduğu için olabilir.