Yazılım kabul testi, geliştirilen uygulamanın işletmenizin üzerinde anlaşılan ihtiyaçlarını karşılayıp karşılamadığını gerçekçi işlemlerle değerlendirmektir. Bir ekranın açılması, formun kaydedilmesi veya raporun indirilmesi tek başına işin tamamlandığını göstermeyebilir. Kullanıcının yaptığı işlemin doğru sonucu üretmesi ve diğer adımlarla tutarlı çalışması gerekir. Bu rehber, teslim öncesinde hangi işlemleri deneyeceğinizi, bulguları nasıl kaydedeceğinizi ve kararınızı neye dayandıracağınızı açıklayan bir hazırlık yöntemi sunar.

Bir müşteri yönetim uygulamasında kullanıcı kaydı bulunabilir, ancak satış çalışanı gerekli müşteriyi aramada bulamıyorsa günlük iş yine aksar. Bir stok sisteminde ürün çıkışı yapılabilir, fakat miktar raporu güncellenmiyorsa kayıtlar birbirini tutmaz. Böyle durumlarda sorun yalnızca tek ekranda aranamaz. İşlemin baştan sonuna denenmesi gerekir. Yazılım kabul testi, uygulamayı kullanacak kişilerin iş bilgisini değerlendirmeye katmak için düzenlenir; geliştirme ekibinin teknik testlerinin yerine geçtiği varsayılmaz.

Bu yazı belirli bir yazılımın hatasız olduğunu veya bütün projelerde aynı kabul yönteminin kullanılacağını iddia etmez. Deneme kapsamı uygulamanın işlevlerine, verisine ve üzerinde anlaşılmış teslimlere göre belirlenir. Henüz geliştirme başlamadıysa ihtiyaç listesi hazırlama rehberinden yararlanabilirsiniz. Testte kullanılacak beklenen sonuçları erken yazmak, teslim gününde yalnızca kişisel izlenimlere dayanan bir değerlendirme yapılmasını azaltır. Başlangıçta bilinmeyen konular da ayrıca işaretlenmelidir.

Yazılım kabul testi ile teknik test aynı mı?

Hayır. Teknik testlerde uygulamanın parçalarının doğru çalışması, veri akışı veya güvenlik kontrolleri gibi konular değerlendirilir. Kullanıcı kabulünde ise işletme açısından beklenen davranışa bakılır. Bu ayrım, bir grubun sadece teknik diğer grubun sadece görsel konularla ilgileneceği anlamına gelmez. Aynı problem farklı testlerde görülebilir. Önemli olan kimlerin hangi kontrolü yapacağını ve ortaya çıkan sonucun nasıl değerlendirileceğini önceden açıklamaktır. Kullanıcı denemesi planlanırken geliştirme ekibinin teknik sorumluluğu ortadan kalkmaz.

Yazılım kabul testi sırasında kullanıcıların iş akışı bilgisi özellikle değerlidir. Bir geliştirici siparişin başarıyla kaydedildiğini görebilir; depo sorumlusu ise kısmi hazırlık durumunun günlük işte gerekli olduğunu hatırlatabilir. Bu bilgi her zaman yeni özellik talebi değildir. Başlangıç kapsamındaki bir iş kuralının eksik anlaşılmış olması da mümkündür. Hangi durumun hata, hangi durumun kapsam değişikliği sayılacağını üzerinde anlaşılmış gereksinimler ve örnekler üzerinden konuşmak gerekir. Test bulgusunu doğrudan tartışmaya dönüştürmek yerine önce davranışı açıklayın.

Denemeye başlamadan önce ortak hedef belirleyin

Yazılım kabul testi için ilk soru, hangi teslimin değerlendirileceğidir. Henüz tamamlanmamış bir modülün bütün işlevlerini test etmek beklenemez. İlk sürüm yalnızca müşteri ve teklif sürecini kapsıyorsa muhasebe aktarımının bulunmaması otomatik olarak hata sayılmaz. Test kapsamını sürüm ve işlev listesiyle birlikte yazın. Sonraya bırakılmış başlıklar biliniyor olsun. Böylece kullanıcıların farklı beklentilerle aynı uygulamayı değerlendirmesi ve aynı bulguya farklı anlamlar yüklemesi azaltılabilir.

Hedefi tek cümlede ifade edebilirsiniz: “Satış çalışanı müşteri seçip teklif oluşturabilmeli, onaylanan tekliften sipariş açılabilmeli.” Bunun altına kontrol edilecek kuralları ekleyin. Fiyat alanını kim değiştirebilir, onaysız teklif siparişe dönüşebilir mi, iptal kaydı raporda nasıl görünür? Yazılım kabul testi bu soruları görünür hale getirir. Bütün cevapların teslim gününde ilk kez verilmesi yerine geliştirme sürecinde konuşulması yararlıdır. Değişen bir karar varsa güncel belgenin hangisi olduğu açıkça belirtilmelidir.

Yazılım kabul testi için 8 adım

1. İş senaryolarını seçin

Uygulamada yapılacak temel işleri listeleyin. Yeni müşteri oluşturma, sipariş kaydetme, ürün çıkarma veya destek talebi kapatma gibi işlemler ayrı senaryolar olabilir. Listeyi menü başlıklarından kopyalamakla yetinmeyin. Bir işin başlatılması, kontrol edilmesi ve tamamlanması farklı ekranlardan geçebilir. Kullanıcının baştan sona yapacağı işi tarif edin. Her senaryonun bir sahibi ve beklenen sonucu bulunmalıdır. Günlük işte sık yapılan işlemleri önce seçmek yararlı bir başlangıçtır.

Yazılım kabul testi yalnızca en sık kullanılan işlerden oluşmamalıdır. Seyrek fakat etkisi yüksek işlemler de önemlidir. Örneğin yanlış kaydın geri alınması, kullanıcının erişiminin kapatılması veya toplu veri aktarımı daha az yapılabilir. Bunların hatalı çalışması önemli sonuçlar doğurabilir. Senaryoları seçerken sıklığı ve etkiyi birlikte değerlendirin. Her ihtimali aynı ayrıntıda denemek mümkün olmayabilir; testin sınırlarını açıkça yazmak, tamamlanmamış kontrollerin yanlışlıkla yapılmış gibi kabul edilmesini önler.

2. Beklenen sonucu önceden yazın

Bir test adımı yalnızca “sipariş aç” şeklinde bırakılmamalıdır. Hangi verinin girileceği ve işlem sonunda ne görüleceği açıklanmalıdır. Örneğin müşteri seçildiğinde bağlı adreslerin listelenmesi, ürün miktarının pozitif olması ve kaydetme sonrasında sipariş numarası oluşması beklenebilir. Bu beklentilerin hepsi her projede geçerli değildir; kendi iş kurallarınıza göre düzenleyin. Deneme sonucunu gördükten sonra beklenen davranışı değiştirmek, değerlendirmenin ortak zeminden uzaklaşmasına neden olabilir.

Yazılım kabul testi için kabul ölçütünü sade cümlelerle yazın. “Sistem kullanıcı dostu olmalı” yerine “kullanıcı müşteri adına göre arama yapabilmeli ve bulduğu kaydı seçebilmeli” gibi denenebilir ifadeler kullanın. Görünümle ilgili beklentiler varsa onları da somutlaştırın. Örneğin önemli uyarının işlem düğmesine yakın görünmesi istenebilir. Değerlendirmenin ölçülebilir olması, tasarımla ilgili her kararın tek bir nesnel cevabı olduğu anlamına gelmez. Yoruma açık konuları da açıkça işaretleyin.

3. Temsilî test verisi hazırlayın

Denemede kullanılacak müşteri, ürün ve sipariş kayıtlarını önceden hazırlayın. Gerçek kişisel bilgileri kullanmanız her zaman gerekli değildir. Kayıt yapısını temsil eden örnek değerler çoğu durumda yeterli olabilir. Aynı isimli iki müşteri, boş isteğe bağlı alan veya farklı teslim adresleri gibi durumları da ekleyin. Bütün denemeleri tek bir kusursuz kayıt üzerinden yapmak, farklı veri koşullarında ortaya çıkabilecek eksikleri saklar. Örneklerin hangi senaryoda kullanılacağı belli olmalıdır.

Yazılım kabul testi verisinin canlı işletme verisinden ayrı tutulması tercih edilebilir. Deneme siparişinin gerçek depoyu, müşteriyi veya faturalama sürecini etkilememesi gerekir. Dış sistem bağlantıları varsa test ortamı ve deneme hesapları konuşulmalıdır. Bildirim gönderimi de dikkate alınmalıdır; örnek kayıt yanlışlıkla gerçek kişiye mesaj göndermemelidir. Hazırlanan verinin temizlenmesi veya yeniden oluşturulması gerekiyorsa bunun sorumlusu belli olsun. Aynı başlangıç koşullarının tekrarlanabilmesi, düzeltmenin gerçekten işe yarayıp yaramadığını kontrol etmeyi kolaylaştırır.

4. Kullanıcı rollerini ayrı deneyin

Yönetici hesabıyla her ekranı açabilmek bütün kullanıcıların işini yapabildiğini göstermez. Satış, depo veya destek çalışanlarının görevlerine uygun hesaplarla deneme yapın. Bir rolün görmesi gereken kayda erişememesi de görmemesi gereken kaydı açabilmesi de bulgu olabilir. Roller yalnızca menü görünürlüğüyle sınırlı değildir. Doğrudan bir bağlantıyla başka kayda erişim veya işlem düğmesinin farklı davranışı da değerlendirilebilir. Teknik erişim kontrolleri için geliştirme ekibinin ayrıca test yapması gerekir.

Yazılım kabul testi sırasında hesapların kime ait olduğu ve test sonrası ne olacağı belirli olsun. Ortak hesap kullanmak hangi işlemi kimin yaptığını anlamayı zorlaştırabilir. Çalışan rolü değiştiğinde yetkilerin nasıl güncelleneceğini de deneyin. Güvenlik gereksinimlerini somutlaştırmak için OWASP ASVS gibi bir açık çerçeve üzerinde konuşulabilir. Bunun adını kullanmak güvenlik testinin tamamlandığını göstermez. Hangi kontrollerin kim tarafından yapılacağı ve sonucun nasıl belgeleneceği proje özelinde açıklanmalıdır.

5. Hatalı ve istisnai işlemleri ekleyin

Boş zorunlu alan, yanlış biçimde tarih veya eksik ürün bilgisi gibi durumları deneyin. Uygulamanın kullanıcıya anlaşılır bir açıklama sunması ve tutarsız kayıt oluşturmaması beklenebilir. Ancak hangi alanın zorunlu olduğu üzerinde anlaşılmış olmalıdır. Test sırasında yeni bir iş kuralı keşfedilirse bunu ayrıca değerlendirin. Her uyarının metni ve yeri önemlidir; “hata oluştu” gibi genel bir mesaj kullanıcının ne yapması gerektiğini açıklamıyorsa geliştirme ekibine örnekle bildirin.

Yazılım kabul testi kapsamında iptal, kısmi teslim ve düzeltme senaryolarını da düşünün. Gerçek işler her zaman tek yönde ilerlemez. İptal edilen siparişin raporlarda nasıl görünmesi gerektiği veya yanlış miktarın hangi yöntemle düzeltileceği açıklanmalıdır. Bir işlemi tamamen silmekle durumunu değiştirmek aynı davranış değildir. İşletmeniz için gerekli kayıt geçmişi baştan konuşulmalıdır. Deneme sırasında fark edilen ihtiyaçları mevcut kabul ölçütleriyle ilişkilendirin; aynı bulgunun farklı kişiler tarafından tekrar tekrar açılmasını önleyin.

6. Bulguları yeniden üretilebilir biçimde kaydedin

Bir bulgu kaydında sürüm, kullanılan rol, adımlar, beklenen sonuç ve gözlenen sonuç bulunsun. “Çalışmıyor” ifadesi yerine hangi işlemin hangi koşulda başarısız olduğunu yazın. Ekran görüntüsü yararlı olabilir, ancak kişisel veya ticari bilgilerin görünmediğinden emin olun. Bir hata mesajı varsa metnini ekleyin. Deneme saatini ve ilgili örnek kayıt numarasını belirtmek, geliştirme ekibinin uygulama kayıtlarıyla karşılaştırma yapmasını kolaylaştırabilir. Gereksiz parola veya erişim anahtarı paylaşmayın.

Yazılım kabul testi bulgularını tek bir yerde toplamak yararlıdır. Farklı mesajlaşma kanallarındaki dağınık notlar unutulabilir veya aynı sorun birden çok kez ele alınabilir. Her kayda bir kimlik ve durum verin. Yeni, inceleniyor, düzeltildi, yeniden test bekliyor ve kapandı gibi aşamalar kullanılabilir. Durum adlarının hepsini kullanmak zorunda değilsiniz; önemli olan sorunun hangi noktada olduğunu anlayabilmektir. Bir kaydın neden kapatıldığı da kısa bir açıklamayla görülebilmelidir.

7. Düzeltmeleri tekrar test edin

Geliştirme ekibinin bir bulguyu düzeltildi olarak işaretlemesi, işletmenin kontrolünü tamamladığı anlamına gelmez. Aynı örnek veri ve adımlarla yeniden deneyin. Beklenen sonuç oluşuyorsa kaydı kapatabilirsiniz. Hata devam ediyorsa hangi davranışın sürdüğünü belirtin. Deneme yapılan sürümün güncel olduğundan emin olun; eski tarayıcı sekmesi veya farklı test ortamı yanlış sonuç görmenize yol açabilir. Sürüm ve ortam bilgisini bulgu kaydında tutmak bu karışıklığı azaltır.

Yazılım kabul testi sırasında yapılan bir düzeltme ilişkili başka işlemleri etkileyebilir. Örneğin sipariş toplamı değiştirildiğinde rapor veya dışa aktarım sonucu da kontrol edilmek istenebilir. Hangi ilişkili senaryoların yeniden deneneceği, değişikliğin etkisine göre değerlendirilir. Bütün uygulamanın her düzeltmede baştan denenmesi her zaman gerekli olmayabilir. Buna karşılık yalnızca tek ekrana bakmak da eksik kalabilir. Geliştirme ekibiyle etkilenen alanları konuşun ve tekrar test kapsamını açıkça kaydedin.

8. Kabul kararını açık kayıtla verin

Test sonunda hangi senaryoların geçtiğini, hangilerinin açık kaldığını ve hangilerinin denenmediğini yazın. Bütün maddeleri tek bir “tamam” ifadesinde toplamayın. Kullanımı engelleyen bir eksikle daha sonra ele alınabilecek bir iyileştirme farklı değerlendirilebilir. Bunun kararı iş etkisine ve anlaşılmış teslim koşullarına göre verilir. Açık kayıtların kimin sorumluluğunda olduğunu ve hangi adımla izleneceğini belirleyin. Kabul belgesinin, bilinmeyen sorunların hiç bulunmadığına dair mutlak güvence gibi yorumlanmaması gerekir.

Yazılım kabul testi sonunda karar verecek kişi baştan belirlenmiş olmalıdır. Günlük kullanıcıların geri bildirimi alınırken işletmenin yetkili sorumlusunun değerlendirmesi de gerekir. Deneme kapsamındaki bir işlevin ertelenmesine karar verildiyse bunun gerekçesi kaydedilsin. Yeni talepler sonraki aşamaya taşınabilir; fakat mevcut kapsamın eksikliği sırf teslimi hızlandırmak için görünmez bırakılmamalıdır. Ortak kayıt, teslim sonrasında aynı konunun farklı hatırlanmasını azaltır ve destek sürecine daha düzenli başlangıç sağlar.

Örnek test kaydı nasıl yazılır?

Örnek olarak tekliften sipariş oluşturma işlemini ele alalım. Ön koşul, örnek müşteriye ait onaylanmış bir teklif bulunması olabilir. Kullanıcı rolü satış çalışanıdır. Adımlar; teklifi açmak, sipariş oluşturma işlemini başlatmak ve kaydı kontrol etmektir. Beklenen sonuç, yeni siparişin doğru müşteri ve ürün satırlarıyla oluşmasıdır. Teklifin onay durumu veya fiyatların nasıl taşınacağı kendi iş kurallarınıza göre ayrıca yazılmalıdır. Bu örnek bütün uygulamalarda aynı davranışın gerektiğini söylemez.

Yazılım kabul testi kaydına gözlenen sonucu ayrı ekleyin. Örneğin ürün satırları gelmiş fakat teslim adresi boş kalmış olabilir. Adresin taşınması beklenen davranışsa bunu bulgu olarak kaydedin. Bir ekran görüntüsü ve örnek kayıt numarası, geliştiricinin aynı işlemi denemesini kolaylaştırabilir. Bulgunun başlığı sorunu kısa açıklamalıdır: “Onaylı tekliften açılan siparişte teslim adresi taşınmıyor.” Böyle bir kayıt, “sipariş ekranı bozuk” cümlesinden daha somut ve yeniden üretilebilir bilgi sunar.

Öncelik ve etkiyi birbirinden ayırın

Bir bulgunun teknik büyüklüğüyle iş açısından önceliği her zaman aynı olmayabilir. Küçük bir alan hatası, günlük işlemi durduruyorsa yüksek etki taşıyabilir. Daha görünür bir tasarım sorunu ise temel kullanım sürerken daha sonra değerlendirilebilir. Öncelik kararını yalnızca bulan kişinin sesini daha çok duyurmasına bırakmayın. İşlemin tamamlanmasına etkisini, etkilenen kullanıcıları ve geçici bir çözüm bulunup bulunmadığını konuşun. Bu değerlendirme proje koşullarına göre yapılmalıdır.

Yazılım kabul testi bulgularına gelişigüzel kritik etiketi vermek, gerçekten önemli sorunları görünmez hale getirebilir. Aynı şekilde bütün sorunları küçük saymak da teslimin eksik değerlendirilmesine neden olur. Kullanılan seviye adlarının ne anlama geldiğini yazın. Örneğin “iş akışı tamamlanamıyor” ile “görsel tutarsızlık” ayrılabilir. Her seviyenin otomatik bir çözüm süresi olduğu varsayılmamalıdır; destek ve düzeltme koşulları ayrıca kararlaştırılır. Amaç ortak bir değerlendirme dili oluşturmaktır.

Yazılım kabul testi için kontrol listesi

• Değerlendirilen sürüm ve ortam belli mi?
• Kapsamdaki iş akışları açıkça listelendi mi?
• Her senaryonun beklenen sonucu yazıldı mı?
• Temsilî ve güvenli örnek veriler hazır mı?
• Farklı kullanıcı rolleriyle deneme yapıldı mı?
• İptal, düzeltme ve eksik veri durumları eklendi mi?
• Bulgular adım ve sonuç bilgileriyle kaydedildi mi?
• Düzeltmeler aynı koşullarla yeniden test edildi mi?
• Açık ve denenmemiş başlıklar ayrı gösterildi mi?
• Kabul kararının sorumlusu ve tarihi belli mi?

Bu liste yazılım kabul testi hazırlığının eksik kalan noktalarını görmek için kullanılabilir. Bir kutunun işaretli olması, o başlıktaki bütün risklerin ortadan kalktığını göstermez. Örneğin kullanıcı rolleri denenmiş olabilir fakat belirli bir istisna henüz kontrol edilmemiş olabilir. Test kapsamını açık yazmak bu sınırı anlaşılır kılar. Kullanıcının hangi işlevi hangi koşulda değerlendirdiğini kaydetmek, sonradan aynı sonucun beklenebileceği durumları anlamaya yardımcı olur. Değerlendirmeyi yalnızca tek bir toplam puana indirgemeyin.

Örnek senaryo: Sipariş uygulamasında kısmi teslim

Bir işletmenin sipariş takibi için uygulama geliştirdiğini düşünelim. İlk denemede müşteri seçiliyor, ürünler ekleniyor ve sipariş tamamlandı durumuna geçebiliyor. Normal akış çalışıyor gibi görünüyor. Depo çalışanı gerçek işte ürünlerin bazen farklı günlerde gönderildiğini belirtiyor. Başlangıç kapsamı incelendiğinde kısmi teslimin gerekli olduğu anlaşılıyor. Bu anlatım varsayımsal bir örnektir; gerçek bir müşteri çalışması, kazanım oranı veya teslim sonucu olarak sunulmaz.

Yazılım kabul testi senaryosuna iki ürünlü örnek sipariş eklenir. İlk ürün gönderildiğinde siparişin tamamının kapanmaması ve kalan ürünün izlenebilmesi beklenir. Raporlarda gönderilen miktarla bekleyen miktarın ayrı görünmesi gerekebilir. Bu beklentiler işletmenin kabul ölçütlerine göre yazılır. Denemede siparişin tamamen kapanması görülürse adımlar ve örnek kayıt numarasıyla bulgu açılır. Sadece bir ekran görüntüsüne dayanarak bütün uygulamanın başarısız olduğu veya hatanın önemsiz olduğu sonucuna varılmaz.

Düzeltme sonrasında aynı örnek sipariş yeniden denenir. Kalan ürünün teslimi, iptal durumu ve rapor sonucu da kontrol edilir. Yazılım kabul testi kaydı, hangi senaryoların geçtiğini açıklar. Sonucun belirli bir zaman veya maliyet tasarrufu sağladığı iddia edilmez; bunun için ayrıca ölçüm gerekir. Örneğin değeri, günlük işteki bir istisnanın test kapsamına nasıl taşınacağını göstermesidir. Senaryo üzerinde anlaşılmış kapsamda yoksa yeni gereksinim olarak değerlendirilmesi gerekir.

Sık yapılan kabul hataları

Yazılım kabul testi için yalnızca yönetici hesabını kullanmak yaygın bir eksiktir. Uygulamadaki bütün işlemlere erişen kişi, daha sınırlı yetkideki kullanıcıların yaşayacağı sorunu görmeyebilir. Bu nedenle her rolün kendi işiyle denenmesi gerekir. Bir başka hata, örnek kayıtları sürekli değiştirmek ve aynı sorunu tekrar üretilemez hale getirmektir. Düzeltme kontrolünde başlangıç koşulları bilinmiyorsa sonuçların karşılaştırılması zorlaşır. Deneme verisini ve sürümü kayıtla birlikte saklamak yararlıdır.

Yazılım kabul testi sırasında kapsam dışı her yeni fikri mevcut hatayla aynı listede önceliklendirmek de karışıklık yaratabilir. Yeni rapor isteği değerli olabilir ancak mevcut işlevin yanlış hesaplama yapmasıyla aynı şey değildir. Kayıtların türünü belirtin. Bunları ayırmak, yeni fikirleri reddetmek anlamına gelmez; hangi çalışmanın mevcut teslimin parçası olduğunu anlamayı sağlar. Bir başlığın türü üzerinde anlaşmazlık varsa önce ilgili gereksinime ve kabul ölçütüne dönün. Kişisel yorum yerine ortak belgeyi inceleyin.

Bir diğer eksik, test tamamlanmadan gerçek verilerle kontrolsüz kullanıma geçmektir. Kullanım planı projenin ihtiyacına göre hazırlanmalıdır. Test ortamındaki örnek işlemin canlı ortamda farklı sonuçlar doğurabileceği unutulmamalıdır. Hesaplar, bildirimler ve dış sistem bağlantıları kullanıma geçişte yeniden değerlendirilebilir. Yazılım kabul testi sonunda elde edilen bulgular, geçiş planına girdi sağlar. Buna rağmen kabulün bütün teknik işletim sorumluluklarını otomatik olarak tamamladığı varsayılmamalıdır. Yedekleme ve destek gibi başlıklar ayrıca konuşulmalıdır.

Temel terimler

Senaryo: Kullanıcının belirli bir işi tamamlamak için izlediği işlem dizisidir. Başlangıç koşulları ve beklenen sonuçla birlikte tanımlanır.

Kabul ölçütü: İşlevin beklentiyi karşılayıp karşılamadığını değerlendirmek için kullanılan somut koşuldur. Deneme sırasında gözlenebilir olması gerekir.

Bulgu: Test sırasında beklenen davranışla gözlenen davranış arasındaki farkın veya araştırılması gereken durumun kaydıdır. Her bulgu kesinleşmiş hata olmayabilir.

Yeniden test: Düzeltildiği belirtilen bir sorunun aynı veya karşılaştırılabilir koşullarla tekrar denenmesidir. Sonuç kayda eklenir.

Regresyon kontrolü: Bir değişiklikten etkilenebilecek daha önce çalışan işlevlerin yeniden değerlendirilmesidir. Kapsamı değişikliğin etkisine göre belirlenir.

Test ortamı: Denemelerin yapıldığı uygulama ve veri düzenidir. Canlı sistemden ayrımı, özellikle bildirimler ve dış sistem bağlantıları açısından açık olmalıdır.

Maltepe ve İdealtepe’de yazılım projesi teslimi

Yazılım kabul testi, Maltepe veya İdealtepe’deki bir işletmede de Türkiye’nin farklı bir şehrindeki uzaktan projede de açık senaryolara ihtiyaç duyar. Anadolu Yakası’nda yakın bir ekiple çalışmak görüşme tercihiniz olabilir; fakat test sorumlulukları ve karar yöntemi ayrıca belirlenmelidir. Denemelerin yüz yüze veya çevrim içi yapılması, kullanılacak veri ve ortak kayıt düzeninin önemini değiştirmez. Belirli bir görüşme veya destek koşulu, ancak gerçekten kararlaştırılmışsa teslim beklentisine eklenmelidir.

HD Bilgisayar Yazılım Sistemleri’nin özel yazılım geliştirme hizmeti ve proje vitrini üzerinden çalışma alanlarını inceleyebilirsiniz. Merkez Altayçeşme, Oba Çıkmazı No:3, Maltepe / İstanbul adresindedir. Yazılım kabul testi beklentilerinizi ihtiyaç özetiyle birlikte konuşmak için 0532 396 34 71 numarasından iletişim kurabilirsiniz. Güncel bilgiler HD Bilgisayar web sitesinde bulunur. Test ve teslim kapsamı projenin gerçek gereksinimlerine göre değerlendirilir; bu rehber belirli bir hizmet seviyesi taahhüdü içermez.

Sık sorulan sorular

Yazılım kabul testi kim tarafından yapılır?

İşletmenin günlük kullanıcıları ve yetkili sorumlusu değerlendirmeye katılabilir. Geliştirme ekibi ortamı hazırlayabilir, bulguları inceleyebilir ve düzeltmeleri yapabilir. Görev dağılımı proje özelinde belirlenir. Kullanıcının test yapması firmanın teknik test sorumluluğunu ortadan kaldırmaz. Kimin hangi kararı vereceğini başlangıçta açıklamak, geri bildirimlerin dağılmasını ve teslimin belirsiz kalmasını azaltır.

Bütün hatalar kapanmadan kabul verilebilir mi?

Bu karar bulguların etkisine ve anlaşılmış teslim koşullarına bağlıdır. Kullanımı engelleyen eksiklerle daha sonra değerlendirilebilecek iyileştirmeler aynı değildir. Açık kalan başlıklar gizlenmemeli; sorumlusu ve sonraki adımı yazılmalıdır. Yazılım kabul testi sonunda verilen karar, test edilmemiş alanların da sorunsuz olduğuna dair mutlak güvence gibi sunulmamalıdır. Kararın hangi kapsam için verildiği açık kalmalıdır.

Test için gerçek müşteri verileri gerekli mi?

Birçok senaryo temsilî verilerle değerlendirilebilir. Gerçek kayıtların kullanılması gerekiyorsa erişim, paylaşım ve veri koruma koşulları ayrıca ele alınmalıdır. İlk denemelerde bütün müşteri listesini göndermek genellikle gereksinimi açıklamanın tek yolu değildir. Alan yapısını temsil eden sınırlı örnekler kullanılabilir. Test verisinin dış sistemlerde gerçek işlem başlatmaması da özellikle kontrol edilmelidir.

Yazılım kabul testi ne kadar sürer?

Süre uygulamanın kapsamına, kullanıcı rollerine, senaryo sayısına ve bulunan sorunlara bağlıdır. İnceleme yapılmadan bütün projeler için tek süre vermek doğru olmaz. İşletmenin test için ayırabileceği zaman da planı etkiler. Senaryoları ve sorumluları önceden belirlemek yararlıdır. Düzeltmelerden sonra yeniden deneme yapılacağını da takvime dahil edin; ilk denemeyi sürecin tamamı gibi planlamayın.

Yeni bir özellik aklıma gelirse ne yapmalıyım?

Özelliği ayrı bir talep olarak kaydedin ve mevcut teslimle ilişkisini açıklayın. Başlangıç kapsamındaki bir gereksinimin eksikliği mi, yoksa yeni bir ihtiyaç mı olduğu değerlendirilmelidir. Her yeni fikir otomatik olarak mevcut teslimin hatası değildir. Bununla birlikte kapsamda olduğu halde eksik uygulanmış bir işlev de yeni talep gibi kapatılmamalıdır. Ortak belge ve kabul ölçütleri bu ayrımda kullanılabilir.

Ekran görüntüsü tek başına yeterli mi?

Görsel yararlı bir kanıt olabilir, fakat çoğu durumda hangi adımların izlendiği de gerekir. Kullanıcı rolünü, örnek kaydı, sürümü ve beklenen sonucu ekleyin. Aynı sonucun yeniden üretilebilmesi düzeltmeyi kolaylaştırır. Görüntüde kişisel bilgi veya erişim bilgisi bulunmamasına dikkat edin. Bir mesajın tam metnini eklemek de geliştirme ekibinin olayı anlamasına yardımcı olabilir.

Teslime hazırlanırken son kontrol

Test sonuçlarını değerlendirirken sürüm değişikliklerini takip edin. Aynı gün içinde birden fazla düzeltme yüklenmiş olabilir. Bir kullanıcı eski sekmede, başka biri yeni sürümde deneme yapıyorsa çelişkili geri bildirimler ortaya çıkabilir. Kullanılan ortamın adresi ve sürüm notu kayıtla birlikte bulunmalıdır. Tarayıcıyı yeniden açmak veya hesabı değiştirerek kontrol etmek gerekebilir; bunun gerekli olup olmadığını geliştirme ekibine sorun. Belirtiyi görmeden her sorunu önbelleğe bağlamak da doğru değildir. Önce hangi sürümün denendiğini doğrulayın.

Kullanıcı eğitiminde görülen soruları test bulgularıyla ilişkilendirmek de yararlıdır. Bir işlemin nasıl yapılacağı anlaşılmıyorsa bunun açıklama ihtiyacı mı yoksa arayüzün davranışıyla ilgili bir problem mi olduğu değerlendirilebilir. Her soruya yeni düğme eklemek gerekmez; bazen kısa bir açıklama veya uygun başlangıç verisi yeterlidir. Buna karşılık kullanıcının yanlış yapmasını sürekli kolaylaştıran bir akış varsa bunu sadece eğitim konusu olarak kapatmayın. İşin gerçek koşullarını dinleyerek değerlendirin ve kararın gerekçesini kaydedin.

Son olarak kullanılan örnek hesapları ve verileri gözden geçirin. Deneme için açılmış bir hesabın canlı kullanımda gereksiz yetkilerle kalmaması gerekir. Test bildirimleri, dış hizmet bağlantıları ve örnek siparişler konusunda sorumlularla kontrol yapın. Bu işlemler kabul kararının yerine geçmez; kullanıma geçiş hazırlığının ayrı parçalarıdır. Teslim belgesinde teknik işletim adımları ile kullanıcı kabulünün farklı sorumluluklar olduğunu açık tutmak, hangi konunun kim tarafından tamamlanacağının anlaşılmasını sağlar.

Yazılım kabul testi tamamlanırken geçen, açık kalan ve denenmemiş senaryoları ayrı gözden geçirin. İlgili kullanıcıların değerlendirmesi alınmış mı, düzeltmeler güncel sürümde yeniden denenmiş mi ve kararın kapsamı açık mı? Bu sorular, teslimi yalnızca bir ekran gösterimine veya sözlü onaya dayanmaktan çıkarır. Test kayıtlarını saklayın ve kullanım başlangıcındaki destek düzenini ayrıca konuşun. Böylece uygulamanın hangi ihtiyaçları hangi koşullarda karşıladığı anlaşılabilir bir başvuru kaydına dönüşür.