Kurumsal Web Sitesi Teslim Alma Kontrol Listesi: Erişim, Test, SEO ve Destek

Kurumsal bir web sitesini teslim almak, ana sayfanın açıldığını ve tasarımın güzel göründüğünü onaylamaktan ibaret değildir. Sağlıklı bir teslimde kritik kullanıcı akışları çalışır, hesap ve verilerin sahipliği bellidir, teknik ayarlar kontrol edilmiştir, yedek ve geri dönüş yöntemi açıklanmıştır, müşterinin siteyi yönetebilmesi için gerekli erişim ve bilgiler paylaşılmıştır.

Teslim kontrolünü dört soruyla yürütün:

1. Ne kontrol edilecek?
2. Nasıl doğrulanacak?
3. Hangi sonuç kaydedilecek?
4. Bu maddeden kim sorumlu olacak?

Bu yaklaşım, “kontrol edildi” gibi yoruma açık ifadeleri test edilebilir kabul ölçütlerine dönüştürür. Aşağıdaki liste her projede aynı kalemlerin bulunacağını varsaymaz. Teklif, sözleşme, onaylanan kapsam ve sitenin gerçek işlevleri esas alınmalıdır.

Web Sitesini Teslim Almak Ne Anlama Gelir?

Teslim; projenin onaylanan kapsamının çalıştığının, müşterinin gerekli varlık ve erişimleri kontrol edebildiğinin ve yayın sonrasındaki sorumlulukların yazılı hâle geldiğinin karşılıklı olarak doğrulanmasıdır.

Üç farklı onayı birbirine karıştırmayın:

• Tasarım onayı, sayfa düzeni, görsel dil ve kullanıcı arayüzü kararlarını kapatır.
• İşlevsel kabul, formlar, bağlantılar, yönetim işlemleri ve entegrasyonların beklenen senaryolarda çalıştığını doğrular.
• Teknik teslim, hesap, veri, erişim, yedek, dokümantasyon ve destek sorumluluklarını kayıt altına alır.

Kumsal Ajans projelerinde tasarım onayı alınana kadar revizyonlar sınırsızdır. Tasarım onayından sonra mevcut yapıyı veya onaylanan kapsamı değiştiren talepler ise ek geliştirme olarak değerlendirilir. Bu sınırın teslim aşamasında yeniden tartışılmaması için tasarım onayı, kapsam ve kabul ölçütleri ayrı kayıtlarla tutulmalıdır.

Projenin tamamlandığı müşteriye e-posta ile bildirilebilir. Projenin niteliğine göre teslim kontrol listesi veya karşılıklı onay tutanağı da kullanılabilir. Önemli olan yöntemden çok, hangi maddelerin kim tarafından ve ne zaman onaylandığının geriye dönük olarak anlaşılabilmesidir.

Teslim Kontrolüne Onaylanan Kapsamla Başlayın

Kontrol listesi hazırlamadan önce sözleşme, teklif, ihtiyaç dokümanı, tasarım onayı ve varsa değişiklik kayıtlarını aynı dosyada toplayın. Bir işlevin hata mı yoksa yeni talep mi olduğunu bu belgeler belirler.

Örneğin teklifte yalnızca iletişim formu bulunuyorsa, teslim sırasında bayi başvurusu veya üyelik modülü talep edilmesi hata düzeltmesi değildir. Buna karşılık onaylanan iletişim formu veri göndermiyor ya da bildirim e-postası üretmiyorsa kapsam içindeki işlev tamamlanmamıştır.

Proje henüz teslim aşamasında değilse önce web sitesi ihtiyaç dokümanı hazırlama rehberindeki kapsam sorularını yanıtlayın. Birden fazla teklif değerlendiriliyorsa web sitesi teklif karşılaştırma puan kartı, teslim ve sahiplik maddelerinin daha sözleşme kurulurken görünür olmasına yardımcı olur.

Kısa Teslim Kontrol Tablosu

Bu tablo bir başlangıçtır. E-ticaret, üyelik, ödeme, rezervasyon, bayi yönetimi veya kuruma özgü entegrasyon bulunan projelerde ilgili iş akışları ayrı test maddelerine ayrılmalıdır.

1. Sayfaları, Menüleri, Bağlantıları ve Hata Durumlarını Kontrol Edin

Önce onaylanan sayfa envanterini çıkarın. Ana menü, alt menü, logo, sayfa içi bağlantılar, butonlar, dosyalar, sosyal ağlar, telefon ve e-posta bağlantıları beklenen hedefe gitmelidir.

Yalnızca ana sayfayı dolaşmak yeterli değildir. Şunları ayrıca test edin:

• Doğrudan açılan iç sayfalar
• Değiştirilen veya kaldırılan eski URL'ler
• Geçersiz bir adreste gösterilen 404 sayfası
• Logo ve breadcrumb üzerinden geri dönüş
• Yeni sekmede açılması gereken dış bağlantılar
• İndirilebilir PDF veya dosyalar
• Yönetim panelinden eklenen yeni içeriğin doğru şablonda görünmesi

Eski bir site yenileniyorsa önemli eski URL'lerin yeni karşılıkları yazılı bir yönlendirme listesinde bulunmalıdır. Her eski adresi ana sayfaya göndermek yerine kullanıcıya en yakın yeni hedef belirlenmelidir.

2. Formları ve E-posta Bildirimlerini Gerçek Senaryolarla Deneyin

Bir formun görünmesi, çalıştığı anlamına gelmez. İletişim, teklif, başvuru, abonelik veya diğer formlar gerçekçi test verisiyle gönderilmelidir.

Her form için şu akışı izleyin:

1. Zorunlu alanları boş bırakıp hata mesajlarını kontrol edin.
2. Geçerli verilerle başarılı gönderim yapın.
3. Kullanıcının gördüğü başarı mesajını doğrulayın.
4. Kayıt yönetim paneline gidiyorsa doğru alanlarla oluştuğunu kontrol edin.
5. Bildirim e-postasının doğru alıcıya ulaştığını ve yanıt adresinin kullanılabilir olduğunu doğrulayın.
6. Kişisel verinin e-posta, panel ve dış servisler arasında nasıl işlendiğini proje kapsamındaki gereksinimlere göre inceleyin.

Projeye özel entegrasyonlarda yalnızca başarılı senaryoyu değil, servis yanıt vermediğinde veya eksik veri geldiğinde oluşan hata durumunu da test edin. Kabul kaydına test tarihi, kullanılan senaryo ve sonucu yazın; gerçek müşteri verisini kontrol için gereksiz yere kullanmayın.

3. Mobil, Tablet ve Güncel Tarayıcı Kontrollerini Ayırın

Masaüstünde düzgün görünen bir sayfa, dar ekranda aynı kullanıcı görevini tamamlatmayabilir. Menü açılması, form alanları, butonlar, tablolar, görseller, çerez bildirimi ve sabit öğeler mobilde ayrı kontrol edilmelidir.

“Mobil uyumlu” ifadesini tek ekran görüntüsüyle kapatmayın. En azından şu durumları deneyin:

• Dar ve geniş telefon ekranları
• Dikey ve yatay kullanım gerektiren kritik sayfalar
• Tablet görünümü
• Güncel Chrome, Safari, Firefox veya proje kitlesi için öncelikli tarayıcılar
• Dokunmatik kullanımda menü, form, açılır alan ve butonlar
• Uzun başlık, farklı dil ve gerçek içerik uzunlukları

Her tarayıcı ve cihaz kombinasyonunu test etmek mümkün değildir. Bu nedenle desteklenen ortamları teklif veya kabul belgesinde önceden tanımlayın; kritik sorunları gerçek kullanıcı önceliğine göre sınıflandırın.

4. Türkçe ve İngilizce Sayfaları Bağlı Bir Sistem Olarak Test Edin

Çok dilli bir sitede yalnızca İngilizce menünün açılması yeterli değildir. Türkçe bir hizmet veya blog sayfasından İngilizce seçildiğinde o sayfanın İngilizce karşılığına; İngilizceden Türkçeye dönüldüğünde de doğru Türkçe karşılığa ulaşılmalıdır.

Teslim sırasında şu kontrolleri ayrı ayrı yapın:

• Ana sayfa ve önemli iç sayfalarda TR → EN geçişi
• Aynı sayfalarda EN → TR dönüşü
• Karşılığı olmayan içerik için belirlenmiş davranış
• Her dilde doğru menü, kategori ve breadcrumb
• Dil bazında başlık, açıklama ve görsel metinleri
• Her yerelleştirilmiş sayfanın kendi canlı URL'si
• Canonical ve hreflang ilişkileri

Google'ın çok dilli sayfalar rehberi, farklı dil sürümlerinin ayrı URL'lerle sunulmasını ve aralarındaki ilişkinin hreflang ile belirtilmesini açıklar. Görünür dil düğmesi kullanıcı deneyimini, hreflang ise arama motorlarına dil ilişkisini anlatır; biri diğerinin yerine geçmez.

5. Teknik SEO Teslimini Bir Sıralama Garantisine Dönüştürmeyin

Temel teknik SEO kontrolü, sitenin arama motorları tarafından erişilebilir ve anlaşılabilir olması için gerekli işaretleri inceler. Belirli bir sırayı veya indexlenme süresini garanti etmez.

Teslim kapsamına göre aşağıdaki maddeleri kontrol edin:

• Her önemli sayfada benzersiz ve anlamlı başlık
• Sayfa içeriğini doğru özetleyen meta açıklaması
• Tek ve açıklayıcı H1
• Beklenen canlı URL'yi gösteren canonical
• Yanlışlıkla kalan noindex veya engelleyici robots kuralları
• XML sitemap'in açılması ve yalnızca uygun canlı URL'leri içermesi
• Eski adreslerden yeni karşılıklara 301 yönlendirmeleri
• Görsellerde açıklayıcı alternatif metin ve uygun dosya boyutu
• Projede kullanılan yapılandırılmış verinin görünür içerikle uyumu
• Çok dilli sayfalarda karşılıklı hreflang

Google Search Central sitemap rehberi, sitemap'in önemli URL'ler ve aralarındaki ilişkiler hakkında bilgi verdiğini; ancak URL'lerin taranmasını veya indexlenmesini garanti etmediğini belirtir. Bu nedenle teslim kaydında “sitemap mevcut ve uygun URL'leri içeriyor” denmelidir; “tüm sayfalar kesin indexlenecek” iddiası olmamalıdır.

Canonical kontrolünde yalnızca etiketin bulunmasına değil, doğru canlı URL'yi göstermesine bakın. Google'ın canonical belirleme rehberi, farklı yöntemlerin tercih edilen URL hakkında sinyal verdiğini açıklar. Yanlış hedef, doğru etiketten daha ciddi bir teslim sorunudur.

6. GA4 ve Search Console'da Hesap Sahipliğini Doğrulayın

Sayfada bir analiz kodunun bulunması, müşterinin ölçümleme hesabını yönettiği anlamına gelmez. Teslim sırasında hangi Google hesabının hangi hesap ve mülkte hangi role sahip olduğu açılarak doğrulanmalıdır.

GA4 için şunları kontrol edin:

• Doğru hesap, mülk ve veri akışı
• Müşterinin kabul edilen rol düzeyinde erişimi
• Sayfa görüntülemelerinin ve kapsam dâhilindeki kritik olayların gelmesi
• İç trafik veya çapraz alan ölçümü gibi projeye özel ayarlar varsa bunların kaydı
• Ajans erişiminin destek ilişkisine göre sürdürülmesi, azaltılması veya kaldırılması

Google Analytics erişim yönetimi dokümanı, hesap ve mülk düzeyinde Administrator, Editor, Marketer, Analyst ve Viewer gibi farklı roller bulunduğunu açıklar. Bu nedenle teslim tutanağında yalnızca “GA4 erişimi verildi” değil, hesap/mülk ve rol bilgisi de yer almalıdır.

Search Console için doğru mülkün seçildiğini, müşterinin sahip veya uygun kullanıcı rolünde bulunduğunu, sitemap kaydını ve önemli URL'lerde inceleme yapılabildiğini doğrulayın. Search Console sahip ve kullanıcı rehberine göre yalnızca mülk sahibi kullanıcılar diğer kullanıcıları ve yetkileri yönetebilir; doğrulanmış sahiplik en yüksek kontrol düzeyidir.

7. Performansı Tek Bir Skorla Kabul Etmeyin

Performans kontrolünde test edilen URL, cihaz profili, bağlantı koşulu, test tarihi ve ölçüm türü kaydedilmelidir. Ana sayfadaki bir laboratuvar skoru, bütün siteyi ve gerçek kullanıcıların deneyimini tek başına temsil etmez.

Şunları birlikte değerlendirin:

• Ana sayfa ve kritik şablonlardan örnek URL'ler
• Mobil ve masaüstü sonuçları
• Aşırı büyük görsel, video veya üçüncü taraf komut dosyaları
• Sayfa açılırken beklenmedik kaymalar
• Menü ve form gibi etkileşimlerin yanıtı
• Varsa gerçek kullanıcı saha verisi ile laboratuvar testinin farkı

web.dev Core Web Vitals açıklaması, LCP, INP ve CLS'nin gerçek kullanıcı deneyiminin farklı yönlerini ölçen saha metrikleri olduğunu ve değerlendirmede sayfa görüntülemelerinin 75. yüzdeliğinin kullanıldığını belirtir. Teslimde bir hedef aralık belirlenebilir; ancak ağ, cihaz, içerik, üçüncü taraf servis ve ölçüm koşullarından bağımsız mutlak skor garantisi verilmemelidir.

Kumsal Ajansın standart teslim kontrollerinde sayfa hızı ve görsel optimizasyonu incelenir. Projeye özgü performans kabul değerleri gerekiyorsa test edilecek sayfalar, araçlar, koşullar ve sorumlu taraf teklif aşamasında ayrıca tanımlanmalıdır.

8. SSL, Erişim Güvenliği, Yedek ve Geri Dönüşü Kontrol Edin

Tarayıcıda kilit simgesinin görünmesi önemli bir kontroldür; fakat bütün güvenlik gereksinimlerinin tamamlandığını doğrulamaz. Yönetim paneli rolleri, kritik formlar, dosya yüklemeleri, entegrasyon erişimleri, hata kayıtları ve yedekler sitenin işlevine göre ayrıca ele alınmalıdır.

OWASP Web Security Testing Guide; yapılandırma, kimlik, kimlik doğrulama, yetkilendirme, oturum, girdi doğrulama, hata yönetimi, kriptografi, iş mantığı, istemci ve API gibi farklı test alanları tanımlar. Buradan çıkan pratik sonuç, her kurumsal siteye aynı güvenlik test paketini uygulamak değil; veri, roller ve işlevlere göre kabul kapsamını yazmaktır.

Teslimde en azından şu soruları cevaplayın:

• SSL sertifikası çalışıyor ve yenileme sorumlusu belli mi?
• Yönetim kullanıcıları kişilere göre ayrıldı mı?
• Gereksiz veya geçici erişimler kaldırıldı mı?
• Form ve entegrasyon hataları kayıt altına alınabiliyor mu?
• Canlıya geçiş öncesi dosya ve veri tabanı yedeği alındı mı?
• Yedeğin konumu, saklama sorumlusu ve geri yükleme yöntemi belli mi?
• Kritik hata durumunda önceki kararlı sürüme dönüş yaklaşımı var mı?

Kumsal Ajans süreçlerinde temel SSL ve erişim güvenliği, yedekleme yapısı, hata kayıtları ve gerektiğinde önceki sürüme dönüş imkânı teslim öncesinde kontrol edilir. Ayrıntılı güvenlik denetimi veya bağımsız sızma testi gerekiyorsa ayrı kapsam, ortam, sorumlu ve kabul ölçütüyle tanımlanır.

9. Hesap, Kod, Veri ve Servis Envanterini Teslim Edin

Teslimin en kritik sorularından biri şudur: Siteyi yarın başka bir yetkili ekip yönetecek olsa hangi hesap, veri ve belgelere ihtiyaç duyar?

Proje kapsamına göre teslim envanterinde şunlar bulunabilir:

• Alan adı, kayıt kuruluşu ve yenileme bilgileri
• Hosting, sunucu ve DNS erişimleri
• SSL ve e-posta servisleri
• Markaya özel yönetim paneli kullanıcıları ve roller
• Kaynak kod deposu ve güncel proje sürümü
• Veri tabanı ve gerekli yedekler
• GA4, Google Tag Manager ve Search Console
• Harita, mesaj, ödeme veya diğer üçüncü taraf servisler
• Lisans ve abonelik bilgileri
• Tasarım dosyaları ve proje varlıkları
• Kurulum, yayın ve entegrasyon notları

Kumsal Ajans projelerinde bu erişimler kapsamına göre müşteriye teslim edilir veya müşteri adına açılmış hesaplara aktarılır. Her projenin sözleşmesi farklı olabileceği için “bütün kalemler otomatik olarak devredilir” varsayımı yapılmamalıdır. Müşteri adına açılan hesap, ajansa sınırlı teknik yetki verilmesi ve hizmet sona erdiğinde erişimin kaldırılması genellikle sahipliği daha görünür kılar.

Üçüncü taraf hizmetin mülkiyeti ile projeye özel çıktının teslimi de ayrılmalıdır. Lisanslı yazılım, harita, e-posta veya benzeri servisler kendi kullanım ve ücret koşullarına tabidir.

10. Yönetim Paneli Eğitimini Gerçek Bir Görevle Tamamlayın

Eğitim yalnızca ekranların gösterildiği bir sunum olmamalıdır. İçeriği yönetecek kişi, kendi hesabıyla en az birkaç gerçek görevi uygulamalıdır:

• Bir sayfadaki metni güncellemek
• Görsel eklemek ve alternatif metin yazmak
• Yeni blog veya haber taslağı oluşturmak
• Türkçe ve İngilizce karşılıkları doğru bağlamda düzenlemek
• Form kayıtlarını görüntülemek
• Kullanıcı rolü kapsamındaki işlemleri gerçekleştirmek

Kullanım sınırlarını da anlatın. Hangi değişiklikler içerik ekibinin, hangileri teknik ekibin sorumluluğundadır? Yanlış bir işlemde taslak, önizleme, geri alma veya destek süreci nasıl çalışır?

Teslim dokümantasyonu projenin kapsamına göre kullanım, erişim, yenileme, kurulum, yayın, yedekleme, entegrasyon ve lisans bilgilerini içerebilir. Belgenin varlığı kadar güncel sürümle eşleşmesi ve müşterinin erişebildiği ortak bir konumda tutulması önemlidir.

11. Kabul, Ücretsiz Destek ve Ek Geliştirme Sınırını Yazın

Kabul tutanağında açık kalan işler, sorumlular ve hedef tarihler yer almalıdır. Kritik bir işlev çalışmıyorsa nihai kabulün ertelenmesi gerekebilir. Kullanımı engellemeyen küçük bir düzenleme ise tarafların onayıyla açık iş listesine alınabilir.

Kurumsal web sitesi projelerinde Kumsal Ajans, aksi teklif veya sözleşmede belirtilmedikçe, hata düzeltmeleri ve küçük destek ihtiyaçları için canlıya geçişten sonra ilk altı ay ücretsiz destek modeli uygulayabilir. Sonrasında yıllık bakım ve destek ayrıca planlanır.

Bu destek aşağıdakilerle aynı şey değildir:

• Yeni sayfa veya modül geliştirilmesi
• Yeni entegrasyon kurulması
• Tasarım onayından sonra mevcut yapının değiştirilmesi
• Yoğun içerik veya veri girişi
• Üçüncü taraf servis ücretleri
• Onaylanan kapsamda bulunmayan yeni iş akışları

Hata ile yeni talebi ayırmak için tekrar onaylanan kapsam ve kabul ölçütlerine dönün. Teslim edilen bir işlev onaylandığı şekilde çalışmıyorsa hata olabilir; kapsamda bulunmayan bir işlev ise yeni geliştirmedir.

Bakım bütçesini ilk tekliften ayrı düşünmeyin. Alan adı, hosting, lisanslar, servis kullanımları ve destek dönemlerini üç yıllık web sitesi bütçe rehberindeki tabloyla takip edebilirsiniz.

Anonimleştirilmiş Gerçek Teslim Örneği

Aşağıdaki örnek tamamlanmış gerçek bir kurumsal web sitesi projesinden uyarlanmış ve müşterinin kimliğini korumak için anonimleştirilmiştir. Sektör, tarih, cihaz modeli ve teknik altyapı ayrıntıları paylaşılmamaktadır.

Teslim kontrolü sırasında iletişim formu masaüstünde çalışmasına rağmen bazı mobil cihazlarda gönderilemiyordu. Aynı kontrolde, yabancı dil menüsündeki bir sayfanın kendi dil karşılığı yerine yanlış bir adrese yönlendiği görüldü.

Sorunlar yalnızca ana sayfaya bakılarak fark edilemezdi. Mobil formun gerçek gönderim senaryosuyla, dil geçişinin ise iki yönde sayfa eşleşmesiyle test edilmesi gerekiyordu. İki hata yayın öncesinde düzeltilip yeniden test edildi ve proje daha sonra teslim edildi.

Bu örnek bir performans, dönüşüm veya sıralama artışı iddiası değildir. Gösterdiği nokta şudur: teslim kontrolü, görünür tasarımın ötesinde gerçek kullanıcı görevlerini ve sayfalar arası ilişkileri sınamalıdır.

Doldurulabilir Teslim Tutanağı Özeti

Aşağıdaki alanları proje bazında doldurun:

Parolaları ve gizli anahtarları bu tutanağın açık metin alanlarına yazmayın. Tutanakta hangi erişimin hangi güvenli kanaldan ve kime teslim edildiğini kaydetmek yeterlidir.

Sonuç: Görünümü Değil, Çalışan ve Sahiplenilebilir Sistemi Teslim Alın

Kurumsal web sitesi tesliminde sayfaların görünümü, işlevlerin çalışması, hesapların sahipliği ve yayın sonrası sorumluluklar birlikte değerlendirilmelidir. Onaylanan kapsamı başlangıç noktası yapın; kritik kullanıcı akışlarını gerçek veriye benzer testlerle çalıştırın; mobil ve çok dilli senaryoları ayrı doğrulayın; SEO ve performans kontrollerini garanti olarak sunmayın; erişim, yedek, dokümantasyon ve desteği yazılı teslim kaydına bağlayın.

Bu yöntem, teslimi uzatan belirsiz geri bildirimler yerine test edilebilir maddeler oluşturur. Ayrıca müşteri ile ajansın hangi işi tamamladığını, hangi maddenin açık kaldığını ve yayın sonrasında kimin neyi yöneteceğini görmesini sağlar.

Projeniz için teslim ve kabul ölçütlerini daha teklif aşamasında tanımlamak istiyorsanız Kumsal Ajans web tasarım hizmetini inceleyebilirsiniz.

Sık Sorulan Sorular

Web sitesi tesliminde hangi erişimler alınmalıdır?

Proje kapsamına göre alan adı, hosting, DNS, yönetim paneli, kaynak kod, veri tabanı, yedekler, GA4, Search Console ve üçüncü taraf servis erişimleri teslim listesinde bulunabilir. Her kalemin hesap sahibi, rolü, yenileme ve teknik yönetim sorumlusu ayrıca yazılmalıdır.

Kaynak kod her web sitesi projesinde müşteriye teslim edilir mi?

Teslim modeli teklif ve sözleşmede açıkça belirtilmelidir. Kumsal Ajans projelerinde projeye özel kaynak kod, veri ve erişimler kapsam ve ödeme/teslim koşullarına göre müşteriye devredilebilir. Açık kaynak veya lisanslı üçüncü taraf bileşenler kendi lisans koşullarına tabidir.

Web sitesinin yayına alınması teslimin tamamlandığı anlamına gelir mi?

Hayır. Canlıya geçişten sonra kritik sayfalar, formlar, bildirimler, dil geçişleri ve entegrasyonlar üretim ortamında yeniden kontrol edilmelidir. Hesap devri, yedek, eğitim, dokümantasyon ve destek başlangıcı da tamamlanmadan teknik teslim eksik kalabilir.

İlk altı aylık ücretsiz destek neleri kapsar?

Aksi teklif veya sözleşmede belirtilmedikçe, kurumsal web sitesi projelerinde teslim edilen kapsam içindeki hataların düzeltilmesi ve küçük destek ihtiyaçları için uygulanabilir. Yeni sayfa, özellik, entegrasyon, tasarım değişikliği, yoğun içerik girişi ve üçüncü taraf ücretleri ayrı kapsamdır. Altı ay sonrasında yıllık bakım ve destek planlanabilir.

Web sitesi tesliminde belirli bir performans skoru garanti edilmeli mi?

Performans hedefleri proje, sayfa türü, içerik, cihaz, ağ ve üçüncü taraf servisler dikkate alınarak tanımlanmalıdır. Tarihli ve koşulları belli ölçümler kabul kaydına eklenebilir; ancak tek bir laboratuvar skoru bütün gerçek kullanıcı deneyimi veya gelecekteki performans için mutlak garanti sayılmamalıdır.