what do clients really expect from software testers
Bugünün makalesinde, günlük yüz yüze etkileşimlerle müşteri lokasyonlarında ilk elden çalışma deneyimime dayanarak, müşterilerin bizden GERÇEKTEN ne beklediğine inandığım bazı düşüncelerimi paylaşacağım ve açık deniz işbirliği e-postalar veya telefon görüşmeleri yoluyla.
BT hizmetleri, yazılım endüstrisinin önemli ve ayrılmaz bir parçasıdır ve başarılı olmak için müşteri memnuniyeti önemlidir. Her müşteri / kuruluş, süreçlerinde farklı olabilir ve farklı protokolleri izleyebilir ve farklı türdeki işletmelerle ilgilenebilir.
Ancak, aşağıdaki faktörler ortaktır ve genel olarak herkes için önemlidir.
[resim src ]
Ne öğreneceksin:
- Müşterinin Yazılım Testçilerinden Beklediği 5 Şey:
- # 1) Maliyet Avantajı
- # 2) İş Kalitesi
- # 3) İş Anlayışı
- # 4) Kullanılabilirlik
- # 5) İyileştirmenin Kapsamı
- Sonuç
- Önerilen Kaynaklar
Müşterinin Yazılım Testçilerinden Beklediği 5 Şey:
# 1) Maliyet Avantajı
Bir şeyi satmayı veya satın almayı düşündüğünüzde, maliyet önemli bir rol oynar ve genellikle önemli karar verici faktörlerden biridir. Hepimiz Kara Cuma, Flipkart Milyar Gün indirimi veya Amazon'un harika alışveriş festivalini sabırsızlıkla beklemiyor muyuz? Satış sırasında çılgın alıcılar oluyoruz. Paramız için doğru ya da fazladan değer beklemek basit bir insan davranışıdır.
Şirketler ve müşteriler farklı değil. Maliyet avantajları, müşteri-hizmet ilişkilerini artırır ve hizmet şirketlerinin daha düşük teklif veren rakipler nedeniyle tekliflerini kaybetmesi alışılmadık bir durum değildir.
Şimdi BÜYÜK soru şudur: Müşterilerimize maliyet avantajlarını nasıl gösterebiliriz?
Bu noktalar yardımcı olabilir:
- Onlara paralarının değerini gösterin . Gerekçelendirin ve destekleyici kanıtlar sağlayın tahminler .
- Harcamalardan tasarruf etmenin yaratıcı yollarını düşünün.
- Teklifinizi uyarlayın. X tutarında paraya mal olan standart sürecinize bağlı kalmak yerine daha ucuz alternatifler sağlayın. Örneğin : Tam sistem testi yerine kritik yol testi önerin.
- Rakiplerinizi bilin . Fiyatlandırma modeli pazarınızı uygun tutmak için diğer hizmet şirketlerinin müşterilerine hangi maliyetlerle sunduklarına dair hızlı bir gerçeklik kontrolü.
# 2) İş Kalitesi
İşin kalitesi ve miktarı çok farklı iki şeydir.
Üretkenlik veya kalite göstergelerinde oluşturulan test senaryolarının veya hataların rapor edildiği günler geride kaldı. Artık değil.
Durum daha çok aşağıdaki resme benziyor:
A) Ne zaman 'HAYIR' diyeceğinizi bilin
Hepimiz fazla mesai yaptığımız, hafta sonları nöbetçi olduğumuz, gece geç saatlere kadar veya sabah erken saatlerde yapılan aramalara katıldığımız vb. Yerlerde bulunduk. Ancak, fark edemediğimiz şey, işler daha da kötüye giderse HAYIR diyebileceğimizdir. HAYIR demek iş kalitemizi ve akıl sağlığımızı sağlam tutmanın tek yolu bu.
Bunu yaparken endişenizi önceden dile getirin ve kaliteyi savunun.
İşte içinde bulunduğum bir durum ve bu size neden bahsettiğim hakkında daha iyi bir fikir verebilir:
Şirketim yeni bir logo kazandı ve eski bir şirketten şirketime geçişin bir parçası olarak bilgi transferi seansları planlandı. Biz 6 kişilik bir ekip olarak müşteri sitesini gezdik. Tanıtımdan sonraki ilk gün KT planını paylaştık. Adımın birden çok modülde etiketlendiğini buldum. Bu modüllerden biri tamamen kapsamımın dışında olmalıydı çünkü o teknolojinin farkında bile değildim; benim becerilerimle hiçbir şekilde eşleşmedi.
Bilgi geçiş liderine gittim ve ona durumu söyledim -
- Bana çok fazla iş öğesi atandı, bu da kaliteyi ve oturumlarda% 100 yakalama yeteneğimi engelleyecek.
- Planlanan öğelerde becerilerimin uyuşmayacağı alanlar vardı ve uygun olmadığım için geçiş sırasında% 100 anlayamayabilirdim.
Kurşun sorunu anladı ve KT planını revize etti.
kalite güvence mühendisi mülakat soruları ve cevapları
Umarım bu, şunu teyit etmeye yardımcı olur: Tabağımızda bir şey varsa, hepsini yememiz gerektiği anlamına gelmez. Özellikle de kaliteden ödün vermek anlamına geliyorsa.
B) Test Durumunun Tamlığı
Kaçınız, denersek bana katılıyor test senaryoları yazma şeklimizi iyileştirmek , daha iyi kaliteye yol açar?
c - c ++ sözdizimi
Çoğu test senaryosunda yaygın olan bazı yaygın hatalar aşağıdadır:
Test Durumu Bileşenleri | Şuanki problem | Çözüm |
---|---|---|
Amaç | Hedef, herhangi bir test senaryosunun en önemli parçasıdır, tüm test senaryolarını farklı kılan da budur. Hedef ile ilgili yaygın hatalar netlikten yoksundur. Bir işlev için oluşturulan tüm test senaryolarının, her bir test senaryosunun nasıl farklı olduğunu göstermeden tek bir amacı olduğu gibi. | Her bir test senaryosunun Amacı / Amacı, bu test senaryosunun bir parçası olarak hangi işlevselliğin ve hangi test koşulunun test edileceğini açıklamak için açık olmalıdır. Aynı işlevsellik pozitif ve negatif test senaryolarına sahip olabilir, bu nedenle amaç, farkı gösterecek kadar net olmalıdır. Hedefi tanımlamak için test senaryosuna başvurmak iyi bir fikirdir. |
Ön Koşullar | Birçok test kullanıcısı ön koşulu söylemeyi tamamen kaçırır veya çoğu yalnızca kopyalayıp yapıştırır. Her test durumu diğerinden tamamen farklı olabileceğinden, yapıştırma yollarını kopyalamak hatalara neden olur. | Kopyala-Yapıştır hatalarından kaçının ve detaylara dikkat edin. |
Test verisi | Bu muhtemelen en çok gözden kaçan alandır ve çoğu test durumunda boş veya kesin tanımdan yoksun olacaktır. | Girilecek uygun verilerden bahsedin. Bazen doğru olması gerekmez. Örneğin: Kullanıcı kaydı bir kullanıcıyı Anna veya John olarak kaydedebilir ve bu önemli değildir. Ancak, tüm karakterleri içeren ve uzunluğu 4-10 olması gereken geçerli bir adın tanımlanması birçok şeyi açıklığa kavuşturmaya yardımcı olabilir. |
Test Vakası Kimliği | Fazla basitleştirilmiş adlandırma veya numaralandırma kuralı. Diyelim ki bir giriş düğmesini test ediyorsunuz. Genellikle kimlikler: TC_1_Login TC_2_Login | Onları daha açıklayıcı yapın: TC_1_Login_Invalid_User TC_2_Login_Valid_User |
Referans dökümanlar | Referans belgelerden Tutarsız Kopyala-Yapıştır veya daha kötüsü, yanlış bir tane kullanarak. | Her zaman doğru referans belgesinin doğru sürüm numarasıyla belirtilmesi tavsiye edilir, örneğin bazı test senaryoları için FRS ve Teknik Özelliklerin her ikisine de atıfta bulunulabilir, bu nedenle referans bölümündeki test senaryosunda her ikisinden de bahsedilmelidir. |
Test Durumu Adımları | Eksik Adımlar, çoğunlukla uygulamayı çok iyi bilen testçiler tarafından. Bir şeyleri varsayabilirler ve adımlardan bahsetmeyi atlayabilirler. Bu, işletme, gözden geçirenler ve yeni testçiler için sorunlara neden olur. | Uygun adımlar ve sıra kullanılmalıdır. |
Özetlemek gerekirse tasarım aşamasında küçük detaylar dikkate alınırsa test çıktı kalitesi çok daha üstün olacaktır.
# 3) İş Anlayışı
Bu, müşterilerin test kullanıcılarında aradığı en önemli faktörlerden biridir. Ancak, bazı test uzmanlarının işlerinin FRS'ye dayalı test senaryoları yazmak olduğuna inanmaları ve işi anlamak için hiçbir çaba göstermemeleri üzücü.
Önce işletmeyi tanımaya çalışın ve ardından işlevselliğe bakın; yapabilirsin müşterinizin ihtiyaçlarını göz önünde bulundurun daha fazla ve buna göre test edin.
İşte bir örnek- FRS, 'XYZ raporu, Tarih, Ad ve Durum' olmak üzere 3 sütunla oluşturulmalıdır. Aşağıdakiler, bu gereksinimi ilk değerinde aldığınızda karşılaşacağınız test durumlarıdır:
- XYZ raporunu doğrulama
- Doğrulama raporu Tarih, Ad, Durum olmak üzere 3 sütun içerir
- Verileri 3 sütun halinde doğrulayın.
Ancak, bu raporun ticari uygulanabilirliğini aklınızda tuttuğunuzda, şunları test etmeniz gerekebilir:
- Bu raporun iş amacı nedir?
- Bu rapor her gün oluşturuluyor mu?
- Bu rapora bakan işletme kullanıcıları kimler?
- Bu rapor için veri kaynağı nedir?
- Veri yoksa rapor oluşturulmalı mı?
Bu sadece bir örnek, ancak sanırım hepimiz daha iyi testlerin iş bilinci ve uzmanlığı kazanarak elde edilebileceği konusunda hemfikiriz.
# 4) Kullanılabilirlik
İster müşteriyi ister bir ekibi destekleyen tek bir kişi olun, uygunluğunuz her zaman kontrol edilmelidir ( ).
Kullanılabilirlik ile 7/24 destek anlamına gelmez. Sadece izin süresi, alternatif planlar ve ulaşılabilir olma ve MIA'ya gitmeme hakkında açık ve açık iletişim anlamına gelir.
Aşağıda hizmet sektörünün izlediği modellerden bazıları verilmiştir:
- Personel Arttırma Modeli - Bir personel artırma modelinde çalışıyorsanız ve şirketinizin tek temsilcisi iseniz, müşterinin çalışma sürelerinizden ve planlanan izinlerden haberdar edilmesi ve böylece gerekli düzenlemelerin yapılabilmesi tavsiye edilir.
- Yönetilen Projeler Modeli - Büyük proje ekiplerinin oluşturulduğu ve teslim / proje yöneticileri tarafından yönetildiği bir yönetilen proje modelinde, bir yedek kaynak planına sahip olmak artık müşterilerin sorumluluğunda değildir. PM'lerin yönetme ihtiyacı hem planlı hem de plansız izinler. Bu modelde, Proje Yöneticisinin planlanan devamsızlık verilerini takımlarından önceden toplamaya çalışmaları ve buna göre yönetmeleri tavsiye edilir. Müşterilerin hafta sonu desteği veya uzatılmış çalışma saatleri talep ettiği durumlar vardır. Bu tür durumlar da kaynaklar dönüşümlü olarak planlanmalıdır. Bir ekip, gerektiğinde birbirini yedekleyebilecek üyelerden oluşmalıdır. Planlanan detaylar müşteri ile paylaşılmalıdır.
# 5) İyileştirmenin Kapsamı
Bu sadece yazılım endüstrisinde değil, her yerde arzu edilen bir durumdur. İyileştirme getirmek tek günlük bir iş değildir. İyileştirme kapsamı üzerinde sürekli çalışılmalıdır ve aşağıdakilere bölünebilir: 3 adım -
Ayrıca oku=> Test Becerilerinizi Nasıl Geliştirirsiniz ve Rekabeti Nasıl Geçersiniz?
1. Adım: Tanımlayın
Kapsamlı bir çalışma yapın ve iyileştirmeler için alanları / kapsamı belirleyin. Diyelim ki, aynı işlemi kullanarak aynı işlevi birkaç kez test etmeniz istendiğinde, ya projeden çıkmak istediğinizi ya da test edilme şeklini değiştirdiğinizi hissedeceğiniz bir zaman gelecektir. Mevcut yöntemlerimizden sıkıldığımızda iyileştirmeler bu şekilde sağlanıyor, değiştirmeyi ve iyileştirmeyi düşünüyoruz .
Adım 2: İyileştirmeler Sağlayın
İşler manuel olarak yapıldıysa, birkaç şeyi otomatikleştirmeyi dene . Otomasyon dediğimde, bu her zaman otomatik bir araç satın almak anlamına gelmiyor.
Bir durumdan alıntı yapacağım:
Bir veritabanı test ekibinin bir parçasıydım. Günlük işimiz, aynı SQL komut dosyalarını bir günde birden çok kez farklı parametrelerle çalıştırmayı içeriyordu. Projeye başladığımızda bu adımlarda iyiydik ama sonunda sistemi daha iyi anladık ve aynı SQL betiklerinin, parametreleri manuel olarak güncelleyen ve yürüten biri yerine depolanan prosedürlerin bir parçası olarak çalıştırılabileceğini düşündük.
Aşama 3: İyileştirmeyi değerlendirin
Yeni bir süreç uygulandığında, beklendiği gibi çalıştığından ve hiçbir yan etkisi olmadığından emin olmanız gerekecektir. Önceki örneği genişleterek, depolanmış yordamlara giriş, yeni oluşturulan otomatik yoldan çıktının ve manuel yoldan çıktının aynı olup olmadığını kontrol edin.
Diğer kısım, kesinlikle emin olmak ve sonuçları müşterilerinize sunmak için belirli bir süre boyunca faydaları izlemektir. Projemizde, müşterilere test yürütme süresinde% 30 azalma gösterdik ve bu da maliyeti düşürdü.
Sonuç
Sonuç olarak, her birimizin doğuştan gelen yeteneklerine ve hepimizin kendi benzersiz çalışma tarzlarına sahip olduğumuzu ve bunların müşterilerimize daha iyi bir hizmet deneyimi sunabileceğine inandığım birkaç ipucu olduğunu belirtmek istedim.
Yazar hakkında: Bu harika makale STH ekip üyesi Priya R. tarafından yazılmıştır. Bize yazmak ve deneyimlerinizi paylaşmak isterseniz lütfen burada bize bildirin .
Umarım bu makaleyi okumaktan zevk almışsınızdır ve bilgilendirici bulmuşsunuzdur! Paylaşacak farklı bir deneyiminiz varsa bize bildirin.
Önerilen Kaynaklar
- En İyi Yazılım Test Araçları 2021 [QA Test Otomasyon Araçları]
- Küresel Yazılım Test İşletmesi Yakında 28,8 Milyar Dolara Ulaşacak
- Acemi Test Uzmanları için Yazılım Testi Önerileri
- Yazılım Testi QA Yardımcısı İşi
- Yazılım Testçilerinde Motivasyon Nasıl Canlı Tutulur?
- Zen ve Yazılım Testi Sanatı
- Yazılım Test Kursu: Hangi Yazılım Test Enstitüsüne katılmalıyım?
- Kariyeriniz olarak Yazılım Testini Seçme