software testing documentation guide
Yazılım Testi kariyerimde, insanların yazılım test dokümantasyonu hakkında pek konuştuğunu hiç duymadım. Test dokümantasyonuyla ilgili genel görüş, boş vakti olan herkesin Test senaryosu, Test planı, durum raporu, Hata raporu, proje teklifi vb.Gibi dokümantasyonu yapabileceğidir.
Hatta dokümantasyon konusunda daha fazla strese girmedim, ancak tüm verileri siyah beyaz olarak yerleştirmek ve bu konuda başkalarını da güncellemek benim alışkanlığım diyebilirim.
Ne öğreneceksin:
- Benim deneyimim
- Test Belgeleri: Bu Nedir?
- Test Dokümantasyonu Hedefine Ulaşmanıza Yardımcı Olacak 10 İpucu
- Önemli Yazılım Test Belgeleri
- Sonuç
- Önerilen Kaynaklar
Benim deneyimim
Sadece deneyimimi sizinle paylaşmak istiyorum:
Müşterilerimizden birine (kızgın müşteri) bir proje (bu konuda bilinmeyen bir sorunu olan) teslim etmiştik. Ve sorunu bir Müşteri tarafında buldular, bu bizim için çok kötü bir durumdu ve her zamanki gibi tüm suç QA'larda idi.
Sorun, bir web sitesinin uyumluluğuyla ilgili bir şeydi. Bana geldiğinde, web sitesinin uyumluluğunu da kontrol etmem gerektiğini belirten böyle bir gereksinim belgesi almadığıma dair kanıtım vardı. Tanrıya şükür güvendeydim.
Benim için ders buydu, dokümantasyonun önemini anladım ve o günden itibaren belgeler üzerinde çalışmaya başladım ve Test planı, Test senaryoları, akıl sağlığı testi kontrol listesi, hata raporu ve daha pek çok test dokümanı oluşturdum.
'Mürekkep en iyi bellekten daha iyidir' - Çin atasözü
Test Belgeleri: Bu Nedir?
Hepimiz test teknolojileri ve yöntemleri hakkında çeşitli makaleler okuyoruz, ancak çoğumuz dokümantasyonla ilgili makaleler gördük? Hiç şüphe yok ki çok az var, bu belgeler önemli değil mi? Hayır, çünkü belgelerin önemini henüz anlamadık.
Ancak, gözlemlersek gerçek şu ki, Tüm belgelerin bulunduğu yüksek olgunluk düzeyine sahip projeler.
Çoğu şirket, yazılım geliştirme sürecine verdikleri kadar dokümantasyona az da olsa önem vermemektedir. Web'de arama yaparsak, çeşitli türlerde belgelerin nasıl oluşturulacağına dair çeşitli şablonlar bulabiliriz. Ancak bunlardan kaçı gerçekten kuruluşlar veya bireyler tarafından kullanılıyor?
Gerçek şu ki dikkatli dokümantasyon bir kuruluşun zamanından, çabalarından ve parasından tasarruf sağlayabilir.
Herhangi bir sertifikasyon türü için giderken, neden dokümantasyon üzerinde stres var, bunun nedeni müşterinin ve süreçlerin birey ve organizasyon için önemini göstermesidir. Ürününüz ne kadar iyi olursa olsun, kullanıcı için rahat bir belge üretemediğiniz sürece kimse kabul etmeyecektir.
Benim deneyimim, biraz kafa karıştırıcı işlevselliğe sahip olan bir ürüne sahibiz.
Bunun üzerinde çalışmaya başladığımda Yönetici'ye bazı yardım belgeleri istedim ve 'Hayır, hiçbir belgemiz yok' cevabını aldım Sonra bununla ilgili bir sorun çıkardım çünkü bir QA olarak biliyordum, kimse nasıl yapılacağını anlayamıyor ürünü belge veya eğitim olmadan kullanın. Ve eğer kullanıcı memnun değilse, o üründen nasıl para kazanacağız?
'Dokümantasyon eksikliği kabul için bir sorun haline geliyor' - Wietse Venema
Aynı şey Kullanıcı kılavuzları için de geçerlidir. Bir Microsoft örneğini ele alalım, her ürünü uygun belgelerle piyasaya sürüyorlar, Office 2007 için bile çok açıklayıcı ve her kullanıcı için anlaşılması kolay olan bu tür belgelere sahibiz. Bu, tüm ürünlerinin başarılı olmasının nedenlerinden biridir.
Küçük şirketlerde, her zaman 'teklif veya başlangıç aşamasında proje reddedildiğini' duyduk, bunun nedeni teklif belgelerinin kısa ve açıklayıcı bir dilden yoksun olması ve kuruluşun kapasitesini göstermesidir.
Küçük şirketlerin kaliteli projeler sunamayacaklarından değil, yeteneklerini ifade edememelerinden kaynaklanıyor. (Ben de 80 çalışandan oluşan küçük bir kuruluşla çalışıyorum ve bunu pek çok kez duydum)
Kişisel olarak kalitenin bunu mümkün kılan tek departman olduğunu hissediyorum. Bu konuda tartışabilecek ve organizasyonlarımıza başarılı bir gelecek sağlayabilecek tek departman biziz.
Tüm tartışmaları kalite perspektifinde birkaç noktada organize edelim:
- Kalite hedefini ve yöntemlerini netleştirin
- Görevler ve performans tutarlılığı hakkında netlik sağlayın
- Müşteri çalışmasında iç koordinasyonu sağlayın
- Önleyici eylemler hakkında geri bildirim sağlayın
- Planlama döngünüz için geri bildirim sağlayın
- Kalite yönetim sisteminizin performansının nesnel kanıtlarını oluşturun
Test Dokümantasyonu Hedefine Ulaşmanıza Yardımcı Olacak 10 İpucu
Daha önceki yazımda da bahsettiğim gibi, genel olarak, yazılım test dokümantasyonu hakkındaki anlayış “Sadece boş zamanı olan kişi tarafından yapılabilir” dir. Bu zihniyeti değiştirmemiz gerekiyor ve o zaman projelerimizdeki dokümantasyon gücünü ancak biz kullanabiliriz.
Dokümantasyonu nasıl doğru yapacağımızı bilmediğimizden değil. Sadece önemli olduğunu düşünmüyoruz.
Herkes, Test stratejisi, Test Planı, Test senaryoları ve Test verilerinden Hata raporuna kadar her türden dokümantasyon için standart şablonlara sahip olmalıdır.
Bunlar sadece bazı standartları (CMMI, ISO, vb.) Takip etmek içindir, ancak gerçek uygulama söz konusu olduğunda bu belgelerin kaç tanesi bizim tarafımızdan gerçekten kullanılmaktadır? Sadece kalite sürecimizi dokümantasyon standartları ve bir organizasyondaki başka bir süreçle senkronize etmemiz gerekiyor.
Her türlü dokümantasyonu takip etmenin en basit yolu proje dinamiklerini, etki alanını, hedefini ve teknolojisini anlayan bir kişiyi başlangıç aşamasından projeye dahil etmektir. Ve bunun için bir QA kişisinden daha iyi kim olabilir (elbette bunu yapacak teknik yazarlar var - ancak teknik yazarların bulunmadığı küçük şirketlerin genel bir senaryosunu göz önünde bulundurarak).
Bu test ve dokümantasyon hedefine ulaşmak için bazı noktalara odaklanmamız gerektiğini düşünüyorum.
Test dokümantasyonu hedefine ulaşmanıza yardımcı olacak en iyi 10 ipucu:
# 1) Kalite Güvencesi ve Dokümantasyonun birlikte çalışması için QA, projenin ilk aşamasına dahil edilmelidir.
#iki) Kalite Güvencesi tarafından tanımlanan süreç, teknik kişiler tarafından takip edilmelidir, bu, kusurların çoğunun ilk aşamada giderilmesine yardımcı olur.
# 3) Sadece yaratmak ve sürdürmek Yazılım Test Şablonları yeterli değil, insanları kullanmaya zorlayın.
c ++ 'da assert nasıl kullanılır
# 4) Yalnızca belgeyi oluşturup bırakmayın, Gerektiğinde güncelleyin.
# 5) Değişiklik gereksinimi projenin önemli bir aşamasıdır, bunları listeye eklemeyi unutmayın.
# 6) Her şey için sürüm kontrolünü kullanın. Bu, belgelerinizi kolayca yönetmenize ve izlemenize yardımcı olacaktır.
# 7) Tüm kusurları belgeleyerek kusur giderme sürecini kolaylaştırın. Herhangi bir kusuru belgelerken kusurun net bir açıklamasını, adımları, etkilenen alanı ve yazarla ilgili ayrıntıları yeniden oluşturduğunuzdan emin olun.
# 8) Çalışmanızı anlamanız için neyin gerekli olduğunu ve gerektiğinde paydaşlarınıza ne üretmeniz gerektiğini belgelemeye çalışın.
# 9) Dokümantasyon için standart şablonu kullanın. Herhangi bir excel sayfa şablonu veya doc dosya şablonu gibi ve tüm belge ihtiyaçlarınız için buna bağlı kalın.
# 10) Projeyle ilgili tüm dokümanları tek bir yerde paylaşın, her ekip üyesinin referans için erişebileceği ve gerektiğinde güncellenebileceği.
Adımları uygulayarak ani sonuçlar elde edeceğinizi söylemiyorum. Bu değişikliğin bir veya iki gün içinde olmayacağını biliyorum, ancak en azından bu değişikliklerin yavaşça gerçekleşmeye başlaması için başlayabiliriz.
Sonuçta 'dokümantasyon dokümantasyona ihtiyaç duyar'. Değil mi?
Yazılım geliştirme ve test yaşam döngüsünde kullanılan yüzlerce belge vardır.
Önemli Yazılım Test Belgeleri
Burada düzenli olarak kullanmamız / bakımını yapmamız gereken birkaç önemli yazılım test belgesini listeliyorum:
1) Test Planı
2) Test Tasarımı ve Test Durumu Spesifikasyonu
3) Test Stratejisi
4) Test Özet Raporları
5) Haftalık Durum Raporu
6) Kullanıcı Belgeleri / Kılavuzları
7) Kullanıcı Kabul Raporu
8) Risk değerlendirmesi
9) Test Günlüğü
10) Hata Raporları
on bir) Test verisi
12) Test Analizi
Ayrıca, Yazılım test uzmanlarının aşağıdaki belgelere düzenli olarak bakmaları gerekir:
1) Yazılım Gereksinimi Özellikleri
2) İşlevsel belgeler
Sonuç
Yazılım Test Belgeleri, Proje geliştirme / Test aşamasında her zaman önemli bir rol oynar. Bu yüzden her zaman mümkün olan her şeyi belgeleyin. Sözlü iletişime güvenmeyin. Daima güvenli tarafta olun.
Belgeler yalnızca sizi kurtarmakla kalmayacak, aynı zamanda kuruluşun uzun vadede eğitimden binlerce dolar tasarruf etmesine ve daha da önemlisi geliştirme ve test belgelerinin eksikliğinden kaynaklanan sorunları gidermeye yardımcı olacaktır.
Sadece size parmakla işaret etmekten kaçınmak için belgelemeyin, ancak belgeleme alışkanlığı kesinlikle test sürecinize sistematik bir yaklaşım getirecek ve geçici testleri geride bırakacaktır.
Yazar hakkında: Bu makale STH ekip üyesi tarafından yazılmıştır. Tejaswini. Bir organizasyonda QA yöneticisi olarak çalışıyor.
Günlük test faaliyetlerinizde başka hangi belgeleri tutuyorsunuz?
Önerilen Kaynaklar
- Yazılım Testi Haftalık Durum Raporu Nasıl Yazılır
- En İyi Yazılım Test Araçları 2021 (QA Test Otomasyon Araçları)
- Yazılım Testi QA Yardımcısı İşi
- 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
- Yazılım Testi Teknik İçerik Yazarı Serbest Çalışan İş
- SoftwareTestingHelp'ten En İyi QA Yazılım Test Hizmetleri
- Yazılım Testi Türleri: Ayrıntılarla Birlikte Farklı Test Türleri