Yazılım iş ihtiyaçları doğrultusunda yapılır. Ürünümüz bir yazılım/uygulama/program olacaktır.
Yazılım testimizin amacı, yazılımı talep eden tarafın(bussines) bakış açısından farklı olarak, yazılımın uyarlanması ile doğabilecek riskleri anlamak üzerine kuruludur(Wiki ye göre).
Test teknikleri, uygulamada hata bulmak için kullanılan yöntemlerin dışında başka yöntemleride içerebilir.
Yazılım testi, doğrulama ve onaylama süreci olarak ifade edilebilir.
Gayemiz şunlardır:

1. Tasarım ve geliştirme rehberliğinde ihtiyaçlarımızı karşılıyor
2. beklediğimiz gibi çalışıyor,
3. aynı karakteristiklerde uygulanabilir

Yazılım testi, uygulamanın geliştirildiği herhangi bir anda yapılabilir. Ancak genellikle istekleri alınmış, uygulama tamamlanmış olduğunda yazılım testi yapılmaktadır.
Yazılım geliştirme modellerinin kendilerine hast test modelleri olabilmektedir. Örneğin ÇEVİK GELİSTİRME modelinde TEST GÜDÜMLÜ GELİŞTİRME modeli kullanılır. Bu yöntemde yazılımcı, klasik olarak tüm uygulamanın tamamlanmasının peşine yapılan testten daha önce, geliştirme sırasında yapar.

Test ile uygulamanın durum ve davranışlarının eleştirilmesi ve kıyaslanması(önceki verisyonlarına, özelliklerine, anlaşma şartlarına, ürettiği sonuçlarına, beklenen sonuçlara, uyması gereken yasal zorunluluklara ve diğer kriterlere göre).
Test, tüm koşullar altında uygulamanın düzgün çalışmasını sağlamak yerine, belirli bir koşul altında düzgün çalışmadığını göstermelidir.

Fonksiyonel ve Fonksiyonel Olmayan Test

Fonksiyonel test, faaliyetleri ifade eder ve kodun belirli bir işlevi ya da eylemini doğrular. Kullanıcı senaryoları ve kullanım durumları kullanılarak geliştirme

830-1998 - IEEE Recommended Practice for Software Requirements Specifications
http://standards.ieee.org/findstds/standard/830-1998.html
Yazılım ürününün ne olduğunu, müşteriler ve tedarikçiler arasında anlaşma için bir temel oluşturmaktır.Yazılım tarafından başarılacak işlevlerin tam tanımlarının belirtildiği SRS kullanıcıya, ihtiyaçlarının karşılanıp karşılanmadığı(müşterinin daha önceden belirtmiş olduğu) veya nasıl değiştirilerek karşılanabileceğini bulmasında yardımcı olacaktır. SRS müşteri ile yapılan sözleşmeninde temeli olacaktır.

IEEE Guide for Developing System Requirements Specifications
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=5982

Ref: http://www.microtoolsinc.com/Howsrs.php

1. Yazılım geliştirme çabasını azaltacaktır.
2. SRS nin hazırlanması, müşterinizin organizasyonu içinde ilgili grupların tüm ihtiyaçlarının tasarım başlamadan ve tekrar tasarım yapmanın önlenmesini ve testinin önüne geçmek için belirlenmesini zorlar.
3. Geliştirme öncesinde tüm yanlış anlamaları, ihmalleri ve tutarsızlıkları ortaya çıkarır.
4. Tahmini zamanlama ve maliyet için temel sağlar.
5. SRS ile programın tahmini fiyatlandırma çıkarılabilir.
6. Doğrulama ve onaylama için temel teşkil ederi
7. Organizasyonlar kendi doğrulama ve onaylama planlarını iyi bir SRS'den daha verimli planlayabilirler SRS'yi Test Plan'ı oluşturmak için kullanabiliriz
8. Başka bölümlerin taleplerine göre yeni uygulamara transferi kolaylaştırır
9. Bir organizasyonda çalışabilen bir uygulamanın SRS dokümanı sayesinde başka bölüm/grupların talebi doğrultusunda bu uygulamanın ya yeni uygulamalara ya da başka bölümlerin kullanımı için transfer edilebilir
10. Sürümü yapılmış olsa bile uygulamanın iyileştirilmesi için bir temel oluşturur.
11. Çünkü SRS ürünü tartışır, projeyi değil. Tamamlanmış ürünün daha sonra geliştirilmesine hizmet eder. SRS'nin sürekli güncellenmesi ve ürünün değişimlerinin yansıtılması gerekir. Aksi halde geçerliliğini ve güncelliğini yitirir. Böylece ileriki değişimlerde referans olmaktan çıkar.

Temel itibarıyle SRS yazarının aşağıdaki hedefleri göze almalı:

1. Fonksiyonellik(İşlevsellik). Yazılımın ne yapması gerekiyor?
2. Harici arayüzler. Yazılım, insanlarla, yazılımın donanımı, diğer donanım ve yazılımlarla nasıl etkileşimde olmalı?
3. Performans. Hızı, erişilebilirliği, cevap süresi v.s.?
4. Özellikleri.. Taşınabilirliği, doğruluğu, bakım yapılabilirliği, güvenlik v.s. ?
5. Tasarım kısıtları. İhtiyaç duyulan standartların etkileri, uyarlama dili, veritabanı bütünlük kuralları, kaynak kısıtları, işletim ortamı v.s.?