Test Temelleri ve Test Tasarımı

Test Perspektifi

Dr. Öğr. Üyesi Oğuz Emre Kural

2025

Giriş

Classroom

• Sınıf Kodu: jqy6dzns
• classroom.google.com → Sınıfa katıl → kodu girin (bil.omu.edu.tr ile).

Hatırlatma

• SDLC içinde test ne zaman başlar?
• V-Model’de geliştirme artefaktları test seviyelerini nasıl besler?
• “Test = en sonda yapılan kontrol” düşüncesi neden yanlıştır?

Öğrenme Kazanımları

Bu dersin sonunda öğrenciler;

• Yazılım testinin amacını (kalite/kabul edilebilirlik değerlendirme ve problem keşfi) açıklayabilecek.
• Testin temel kavramlarını (error–fault/defect–failure–incident) ve commission/omission kusur ayrımını ayırt edebilecek.
• Bir test case’in temel bileşenlerini ve test yürütme adımlarını (önkoşul–girdi–beklenen çıktı–son durum) tanımlayabilecek.
• Oracle problemini ve beklenen çıktıyı belirlemede referans test yaklaşımını özetleyebilecek.
• S–P–T Venn modeli ile spesifikasyon-temelli ve kod-temelli yaklaşımların kapsam boşluklarını yorumlayabilecektir.

Test’e Bakış Açısı

Neden test yaparız?

• Yazılımın kalitesi / kabul edilebilirliği hakkında hüküm vermek
• Problemleri keşfetmek (kusur, arıza, risk)
• Çünkü yanılabiliriz — özellikle yazılım ve yazılım kontrollü sistemlerde

Temel Tanımlar

• Test literatüründe terminoloji sıkça karışık ve zaman zaman tutarsızdır.
• Bunun nedeni: test teknolojilerinin on yıllar boyunca ve çok sayıda yazar/ekolle evrilmiş olmasıdır.
• Bu derste kullanılan terimler şu iki yaygın referansla uyumludur:
  • ISTQB (International Software Testing Qualifications Board): kapsamlı test terimleri sözlüğü
  • IEEE (Institute of Electrical and Electronics Engineers): yazılım mühendisliği standartları

Hata (Error)

• İnsanlar hata yapar (eş anlamlı: mistake).
• Kod yazarken yapılan hatalar pratikte sıklıkla bug olarak adlandırılır.
• Hatalar yayılma eğilimindedir:
  • Gereksinimdeki hata → tasarımda büyür → kodlamada daha da artabilir.

Kusur (Fault) / Defect

• Kusur, bir hatanın sonucudur.
• Daha net ifadeyle: Kusur, hatanın bir temsilidir (ör. metin, UML diyagramı, hiyerarşi şeması, kaynak kod).
• Eş anlamlı: defect (bazı bağlamlarda bug da kullanılabilir).
• Kusurlar bazen zor yakalanır.

Kusur Türleri: Yapma / Yapmama

• Commission (İşleme) kusuru: Temsile yanlış bir şeyin girilmesi
• Omission (Eksiklik) kusuru: Temsilde olması gereken doğru bilginin eksik bırakılması
• Genel gözlem: Omission kusurları tespit ve çözüm açısından daha zordur.

Başarısızlık (Failure)

• Başarısızlık, bir kusura karşılık gelen kod çalıştığında ortaya çıkar.
• İki kritik nokta:
  • Başarısızlık yalnızca çalıştırılabilir bir temsilde olur (genelde derlenmiş/yüklenmiş kod).
  • Bu tanım doğrudan daha çok commission kusurlarını yakalar.

Peki “Omission” kusurları?

• Omission kusurları:
  • bazen uzun süre tetiklenmeyebilir,
  • hatta hiç çalışmayan bir yol/koşul nedeniyle hiç görünmeyebilir.
• Bu yüzden yalnızca çalıştırma testleri yetmez; inceleme (review) gibi yöntemler de gerekir.

Review Bağlantısı

• Review’lar, arıza oluşmadan önce kusur bulmayı hedefler.
• İyi yapılan review’lar özellikle omission kusurlarını yakalamada etkilidir.
• İlerleyen haftalarda detaylandıracağız.

Incident (Olay)

• Bir arıza (failure) oluştuğunda kullanıcı/tester bunu her zaman hemen fark etmeyebilir.
• Incident, arızanın kullanıcıyı uyaran görünen belirtisi/semptomudur.

Test (Test Etme)

• Test; hata, kusur, arıza ve belirtilerle ilişkilidir.
• Test, yazılımı test caselerle çalıştırma eylemidir.
• Testin iki temel hedefi:
  • Arıza bulmak (failure discovery)
  • Doğru çalıştığını göstermek (correct execution)

Test Case (Test Durumu)

• Bir test case:
  • bir kimliğe (ID) sahiptir,
  • belirli bir davranış ile ilişkilidir,
  • bir girdi seti içerir,
  • beklenen çıktı(lar) içerir.

Test Yaşam Döngüsü (Model)

Geliştirme boyunca:

• İnsanlar hata yapar → kusur oluşur → kusur yayılabilir
• Düzeltme (fix) aşaması da yeni hata/kusur üretme riski taşır

Fix Riski: “Düzeltme” Yeni Problem Doğurabilir

• Fix sonrası daha önce doğru çalışan kısım bozulursa:
  • fix yetersiz/deficient olabilir
• Bu durumu ileride regresyon testi ile ele alacağız.

Test Sürecinin Adımları

Test süreci şu adımlara bölünebilir:

1. Test planlama
2. Test case geliştirme
3. Test caseleri çalıştırma
4. Sonuçları değerlendirme

Test Caseler

• Yazılım testinin özü: test edilecek öğe için uygun bir test case seti belirlemek
• Test case, geliştirme sürecinde üretilen ve yönetilen resmî bir artefakt olmalıdır.

Tam (Complete) Bir Test Case Neleri İçerir?

• Test case kimliği (ID)
• Amaç (örn. iş kuralı / business rule)
• Önkoşullar (preconditions)
• Girdiler (test case inputs)
• Beklenen çıktılar (expected outputs)
• Beklenen son durum (expected postconditions)
• Çalıştırma geçmişi (execution history)

Çalıştırma Geçmişi (Execution History) Nedir?

Çalıştırma geçmişi esas olarak test yönetimi için tutulur; örnek alanlar:

• Çalıştırma tarihi
• Çalıştıran kişi
• Koşulan sürüm / build
• Sonuç: pass/fail

Zor Kısım: Çıktı ve Beklenen Çıktı (Oracle Problemi)

• Test case’in çıktı/beklenen çıktı kısmı sıkça ihmal edilir.
• Oysa çoğu zaman en zor soru şudur:
  “Doğru çıktıyı nereden bileceğiz?”

Örnek: Hava koridoru kısıtları + hava durumu verisi ile “en iyi rota”yı bulan bir sistem
- “Gerçekten en iyi rota hangisi?” sorusunun cevabı her zaman net değildir.

Oracle Yaklaşımları

• Oracle: “doğru cevabı” veren referans kaynak/ölçüt (her zaman elimizde olmaz)
• Akademik yaklaşım: “tüm cevapları bilen” bir oracle varmış gibi varsaymak
• Endüstriyel yaklaşım: Referans test (reference testing)
  • Sistem, uzman kullanıcılar eşliğinde test edilir
  • Uzmanlar çıktının kabul edilebilir olup olmadığına karar verir

Test Case Çalıştırma (Execution) Adımları

1. Gerekli önkoşulları sağla
2. Girdileri ver
3. Çıktıları gözle
4. Çıktıları beklenen çıktılarla karşılaştır
5. Beklenen son durum oluştu mu kontrol et
6. Sonuç: test geçti mi? (pass/fail)

Test Caseler Neden Değerlidir?

• Test case’ler en az kaynak kod kadar değerlidir
• Bu yüzden test case’ler:
  • geliştirilmeli
  • review edilmeli
  • kullanılmalı
  • yönetilmeli
  • saklanmalıdır

Venn Diyagramından Çıkarımlar

• Testin odağı davranıştır: yazılımın ne yaptığı
• Geliştiriciler genelde kod odaklı bakar: yazılımın ne olduğu
• Bu iki bakış çoğu zaman farklı eksenlerdir.
• Kısaca: kod odaklı bakış “ne olduğu”na, davranış odaklı bakış “ne yaptığı”na odaklanır.
• Sorun: Temel proje dokümanları (gereksinim/tasarım) çoğu zaman geliştirici için yazılır
  → bu yüzden testçinin aradığı davranış bilgisi yeterince açık olmayabilir

Bu bölümde basit bir Venn diyagramı ile “neyi test ediyoruz?” sorusunu netleştireceğiz.

Davranış Evreni

• Bir yazılımın gösterebileceği tüm davranışları düşünün: davranış evreni
• İki küme tanımlayalım:
  • S: Spesifikasyonda tanımlanan davranışlar (Specified)
  • P: Kodda gerçekten uygulanmış davranışlar (Programmed)

S ve P: Testçinin Karşılaştığı Temel Problemler

• S’de var ama P’de yoksa: istenen davranış uygulanmamış → eksik bırakma (omission) kusuru
• P’de var ama S’de yoksa: kodda “fazladan/yanlış” davranış var → yanlış ekleme (commission) kusuru
• S ∩ P: hem tanımlı hem uygulanmış → “doğru kısım”

“Doğruluk”, sadece spesifikasyon + uygulama birlikte düşünülünce anlamlıdır.

Testi Bu Çerçevede Nasıl Görürüz?

• Test, “S ∩ P bölgesinin ne kadar büyük olduğunu” anlamaya çalışır
• Yani amaç: tanımlanan davranışların gerçekten uygulanıp uygulanmadığını kanıtla ölçmek

Üçüncü Küme: Test Caseler (T)

• Bir test case çalıştırıldığında bir davranış gözlenir
• Bu yüzden üçüncü küme:
  • T: Test caselerin kapsadığı davranışlar

S, P, T İlişkisi: Ne Tür Boşluklar Olabilir?

• S var ama T yok: Tanımlanmış ama test edilmemiş davranış → test eksik
• T var ama S yok: Tanımlanmamış davranışa test yazılmış → 3 olasılık:
  1. Test gereksizdir
  2. Spesifikasyon eksiktir (tanım yazılmalıydı)
  3. “Olmaması gereken davranışın olmadığını” kanıtlamak istenmiştir (negatif davranış testi)

Bir de P açısından bakalım

• P var ama T yok: Uygulanmış ama test edilmemiş davranış → risk
• T var ama P yok: Testin hedeflediği davranış uygulanmamış olabilir
  (test “beklediğini göremez” → gereksinim/implementasyon uyumsuzluğu yakalanır)

Her Bölge Neden Önemli?

• Tanımlı davranış olup test yoksa → test tamamlanmış sayılmaz
• Tanımsız davranışa test yazıldıysa:
  • ya test hatalıdır,
  • ya spesifikasyon eksiktir,
  • ya da “olmaması gerekeni” hedefleyen iyi bir test vardır

İyi testçiler bu yüzden gereksinim/tasarım incelemelerine katılmalıdır.

Testçilik “zanaatı”: Bölge 1’i büyütmek

Amaç: - S ∩ P ∩ T kesişimini (hepsi aynı anda) mümkün olduğunca büyütmek

Test Caseleri Nasıl Belirleriz?

• Test case belirlemek için iki temel yaklaşım vardır:
  • Geleneksel adlarıyla: fonksiyonel ve yapısal test
  • Daha açıklayıcı adlarıyla: spesifikasyon-temelli ve kod-temelli
• Her yaklaşımın birden fazla test case belirleme yöntemi vardır.
• Aynı yöntemi izleyen iki testçi, genelde benzer test caseler üretir.

“Yöntem” Demek Ne Demek?

• Test case’ler rastgele seçilmez.
• Bir yöntem; “nereden bakacağımı” ve “ne üreteceğimi” söyler.
• Sonuç: Yöntem, testçinin kararlarını tutarlı hale getirir.

Spesifikasyon-Temelli Test

• Yazılımı bir kara kutu gibi düşünürüz.
• Test caseleri sadece spesifikasyondan çıkarılır:
  • Girdi → beklenen çıktı

Neden “Fonksiyonel Test” de Denir?

• Program, girdileri çıktılara eşleyen bir “fonksiyon” gibi görülebilir.
• İçerideki uygulamayı bilmesek de, girdi–çıktı davranışı üzerinden test edebiliriz.
• Bu da başka bir eş anlamlı terime götürür: kara kutu testi (black box testing).
• Bu yaklaşımda kara kutunun içeriği (uygulama/implementasyon) bilinmez; kara kutunun işlevi tamamen girdiler ve çıktılar üzerinden anlaşılır.

Spesifikasyon-Temelli Yaklaşımın Avantajları

1. Koda bağımlı değildir
   • Uygulama değişse bile spesifikasyon aynıysa testler geçerli kalabilir.
2. Paralel yürütülebilir
   • Test caseleri, kod geliştirme ile aynı anda tasarlanabilir.

Spesifikasyon-Temelli Yaklaşımın Sınırlılıkları

• Tekrarlılık: benzer testler gereksiz yere çoğalabilir
• Kapsam boşluğu: spesifikasyonda olmayan ama kodda olan davranışlar kaçabilir

Bu yüzden sadece bu yaklaşım yetmez; kod-temelli yaklaşımla tamamlanır.

İki Farklı Yöntem: A ve B

• Aynı yaklaşım içinde bile farklı yöntemler:
  • biri daha çok test case üretebilir (A)
  • diğeri daha az test case üretebilir (B)
• İkisi de genelde tanımlı davranış kümesinin içinde kalır.

Bu Domainde Hangi Teknikler Var?

Spesifikasyon-temelli (black-box) tekniklere örnekler:

• Eşdeğer Bölütleme (EP)
• Sınır Değer Analizi (BVA)
• Dayanıklılık (Robustness) testleri
• Karar Tablosu ile test tasarımı

Kod-Temelli Test

• Kod-temelli test, test case belirlemenin diğer temel yaklaşımıdır.
• Kara kutu testine karşıt olarak bazen:
  • beyaz kutu (white box)
    
  • hatta şeffaf kutu (clear box) diye adlandırılır.
• Temel fark: Testçi, sistemin içini (uygulamayı) bilir ve test caseleri buna göre seçer.

“İçini görmek” ne sağlar?

• Test caseler, fonksiyonun gerçekte nasıl yazıldığına göre belirlenir.
• Böylece:
  • hangi dalların/koşulların test edildiği daha net takip edilir,
  • “ne kadar test ettik?” sorusu daha anlamlı cevaplanır.

Teorik temel ve “coverage” (kapsam)

• Kod-temelli testin arkasında güçlü bir kuramsal temel vardır.
• Özellikle kontrol akışı gibi konuları anlamak için (ör. graf teorisi kavramları) altyapı faydalıdır.
• Bu yaklaşım, test kapsamı (coverage) metriklerini doğal olarak doğurur.

Coverage metrikleri neden önemli?

• Bir yazılımın ne kadarının test edildiğini açıkça ifade etmeyi sağlar.
• Bu da:
  • test yönetimini daha “ölçülebilir” yapar,
  • eksik kalan bölgeleri görünür kılar.

Venn ile Bağlantı: Testler P’nin İçinde Kalır

• Kod-temelli yöntemler koddan çıktığı için, test caseler genelde:
  • P (uygulanmış davranış) kümesinin içindedir.
• Bu yüzden:
  • kodda olmayan davranışlara test üretmesi zordur
  • ama kodun içinde “hangi kısımlar test edildi?” sorusunu iyi yanıtlar

Spesifikasyon-Temelli mi Kod-Temelli mi?

• İki farklı yaklaşım olunca doğal soru: Hangisi daha iyi?
• Literatürde iki tarafın da güçlü savunucuları vardır.
• Venn diyagramları bu tartışmayı sadeleştirir:
  • İki yaklaşımın hedefi aynı: test case üretmek

İki yaklaşımın veri kaynağı farklıdır

• Spesifikasyon-temelli: test case’leri spesifikasyondan çıkarır
• Kod-temelli: test case’leri uygulamadan (kaynak koddan) çıkarır

Tek başına hiçbiri yeterli değildir

• Eğer spesifikasyondaki bazı davranışlar uygulanmamışsa:
  • kod-temelli testler bunu göremeyebilir (kodda yoksa test de üretmez)
• Eğer kod, spesifikasyonda olmayan davranışlar içeriyorsa:
  • spesifikasyon-temelli testler bunu yakalamayabilir

Örnek risk: Spesifikasyonda yok ama kodda “gizli” davranış (örn. trojan benzeri)

“Doğru cevap”: İkisi birlikte

• En pratik yaklaşım: dengeleyerek birlikte kullanmak
  • Spesifikasyon-temelli → güven oluşturur (beklenen davranışı doğrular)
  • Kod-temelli → kusur arar (uygulama içindeki zayıf noktaları hedefler)

Neden birlikte kullanınca daha iyi olur?

• Spesifikasyon-temelli testlerde görülen iki problem:
  • tekrarlılık (benzer testlerin çoğalması)
  • kapsam boşluğu (test edilmeyen kısımlar)
• Kod-temelli yaklaşımdaki coverage (kapsam) metrikleri ile birlikte kullanınca:
  • tekrarlılıklar fark edilir
  • boşluklar görünür olur

Testçilik “zanaatı” burada başlar

• Üretilen test seti T, seçtiğiniz yönteme bağlıdır.
• İyi soru: “Bu yöntem bu sistem için ne kadar uygun/etkili?”
• İpucu: Hata → kusur → arıza → belirti zincirini bilmek, hangi kusurlara yatkın olduğumuzu görüp daha uygun yöntem seçmeyi sağlar.

Mini Soru

Bir sistemde riskler şöyleyse:

• Karmaşık koşul/dal mantığı çok fazla
• Gereksinimler de net değil

Sizce test stratejisinde:

• spesifikasyon-temelli mi ağır basmalı?
• kod-temelli mi ağır basmalı?
• nasıl bir denge kurarsınız?

Kusur Sınıflandırmaları (Fault Taxonomies)

• Hata (error) ve kusur (fault/defect) tanımlarını netleştirmek için, süreç ve ürün ayrımı önemlidir.
  • Süreç: işi nasıl yaptığımız
  • Ürün: sürecin sonunda ortaya çıkan çıktı
• SQA (Yazılım Kalite Güvencesi) genelde ürünü, süreci iyileştirerek iyileştirmeye çalışır.
• Test ise daha çok üründe kusur bulmaya odaklanır.
• İkisi de kusur türlerini daha net tanımlayınca fayda görür.

Kusurlar Nasıl Sınıflandırılabilir?

Kusurlar farklı açılardan sınıflandırılabilir:

• Hatanın oluştuğu geliştirme aşaması
• Arızanın etkisi / sonuçları
• Çözüm zorluğu
• Çözülememe riski
• vb.

Buradaki odak: Kusurun “anormallik olarak ortaya çıkma biçimi”.

Anormallik (Kusur) Görülme Biçimi

Kusur (anormallik) şu biçimlerde görülebilir:

• Tek seferlik (one time only)
• Aralıklı (intermittent)
• Tekrarlayan (recurring)
• Tekrar üretilebilir (repeatable)

Girdi/Çıktı Kusurları (Input/Output Faults)

Tür	Örnekler
Input	Doğru girdinin kabul edilmemesi
Input	Yanlış girdinin kabul edilmesi
Input	Açıklamanın yanlış veya eksik olması
Input	Parametrelerin yanlış veya eksik olması
Output	Yanlış format
Output	Yanlış sonuç
Output	Doğru sonucun yanlış zamanda gelmesi (çok erken/çok geç)
Output	Eksik veya hiç üretilemeyen sonuç
Output	Gereksiz/uygunsuz sonuç
Output	Yazım/dilbilgisi
Output	Kozmetik (görsel/biçimsel)

Mantık Kusurları (Logic Faults)

Mantık Kusurları
Eksik durum(lar) (missing case(s))
Yinelenen durum(lar) (duplicate case(s))
Aşırı uç koşulun göz ardı edilmesi (extreme condition neglected)
Yanlış yorumlama (misinterpretation)
Eksik koşul (missing condition)
Gereksiz koşul(lar) (extraneous condition(s))
Yanlış değişkenin test edilmesi (test of wrong variable)
Yanlış döngü iterasyonu (incorrect loop iteration)
Yanlış operatör (örn. ≤ yerine <) (wrong operator)

Hesaplama Kusurları (Computation Faults)

Hesaplama Kusurları
Yanlış algoritma (incorrect algorithm)
Eksik hesaplama (missing computation)
Yanlış operand (incorrect operand)
Yanlış işlem (incorrect operation)
Parantez hatası (parenthesis error)
Yetersiz hassasiyet (yuvarlama/kesme) (insufficient precision)
Yanlış gömülü fonksiyon (wrong built-in function)

Arayüz Kusurları (Interface Faults)

Arayüz Kusurları
Yanlış kesme yönetimi (incorrect interrupt handling)
G/Ç zamanlaması (I/O timing)
Yanlış prosedür çağrısı (call to wrong procedure)
Var olmayan prosedür çağrısı (call to nonexistent procedure)
Parametre uyumsuzluğu (tip/sayı) (parameter mismatch)
Uyumsuz tipler (incompatible types)
Gereksiz dahil etme (superfluous inclusion)

Veri Kusurları (Data Faults)

Veri Kusurları
Yanlış ilklendirme (incorrect initialization)
Yanlış depolama/erişim (incorrect storage/access)
Yanlış bayrak/indeks değeri (wrong flag/index value)
Yanlış paketleme/açma (incorrect packing/unpacking)
Yanlış değişken kullanımı (wrong variable used)
Yanlış veri referansı (wrong data reference)
Ölçek/birim hatası (scaling or units error)
Yanlış veri boyutu (incorrect data dimension)
Yanlış alt indis (incorrect subscript)
Yanlış tip (incorrect type)
Yanlış veri kapsamı (incorrect data scope)
Sensör verisi limit dışı (sensor data out of limits)
Bir eksik/bir fazla (off by one)
Tutarsız veri (inconsistent data)

Neden Bu Tablolar İşe Yarar?

• Test tasarımında “neye bakacağım?” sorusuna listeyle cevap verir.
• Review/checklist hazırlarken güçlü bir başlangıç sağlar.
• Bulunan kusurları sınıflandırmak, tekrar eden kök nedenleri görünür kılar.

Test Seviyeleri (Levels of Testing)

• Şimdiye kadar konuşmadığımız kritik konu: soyutlama seviyeleri
• Test seviyeleri, klasik SDLC’deki (özellikle şelale modelindeki) soyutlama seviyelerine benzer.
• Modelin eksikleri olsa da, testte şunlar için faydalıdır:
  • seviyeleri ayırmak
  • her seviyenin hedefini netleştirmek

V-Model Bağlantısı (ISTQB Terminolojisi)

• Şelale modelinin test açısından sık kullanılan varyantı: V-Model
• Bu bakış, tasarım seviyeleri ile test seviyeleri arasındaki eşleşmeyi vurgular.

Tasarım Seviyeleri ↔︎ Test Seviyeleri

Spesifikasyon-temelli bakışta şu eşleşme özellikle nettir:

• Gereksinim / Spesifikasyon ↔︎ Sistem testi
• Ön tasarım ↔︎ Entegrasyon testi
• Detay tasarım ↔︎ Birim testi
• Kodlama ↔︎ (testlerin çalıştırıldığı temel)

Kod-Temelli vs Spesifikasyon-Temelli: Seviyeye Göre Uygunluk

Genel kabul gören pratik ilişki:

• Kod-temelli test çoğunlukla birim seviyesinde daha uygundur
• Spesifikasyon-temelli test çoğunlukla sistem seviyesinde daha uygundur

Bu, “hangi bilginin o aşamada daha hazır olduğu” ile de ilgilidir.

Neden Böyle Olur?

• Birim seviyesinde elimizde:
  • kod, kontrol akışı, koşullar → kod-temelli yöntemler daha doğal çalışır
• Sistem seviyesinde elimizde:
  • uçtan uca iş davranışı, kabul kriterleri → spesifikasyon-temelli yöntemler daha doğal çalışır

Entegrasyon ve Sistem Seviyesinde Kod-Temelli Test

• Kod-temelli kavramların entegrasyon ve sistem seviyesine uygulanması daha zordur.
• Yine de mümkündür; zamanla bu seviyelerde de (özellikle modern sistemlerde) daha fazla yapı ve ölçüm ortaya çıkmıştır.

Alıştırma

1. Verilen ifadeyi yansıtacak şekilde bir Venn diyagramı çizin: “… yapmamız gerekeni yapmadık ve yapmamamız gerekeni yaptık …”

2. Aşağıdaki senaryo için S (tanımlı davranış), P (uygulanmış davranış) ve T (test edilmiş davranış) kümelerini düşünerek bir Venn diyagramı çizin ve hangi bölgelerde risk oluştuğunu belirtin:

• Bir e-ticaret sisteminde “kupon uygulama” özelliği vardır. Spesifikasyonda; kuponun aynı siparişte yalnızca bir kez kullanılacağı, kargo ücretine uygulanmayacağı ve iade durumunda kuponun tekrar aktif olmayacağı yazmaktadır. Ancak üretimde bazı kullanıcıların kuponu iki kez uygulayabildiği ve bazı iade senaryolarında kuponun tekrar kullanılabildiği raporlanmıştır.