User Acceptance Testing – Kullanıcı Kabul Testi

Kullanıcı Kabul Testi (UAT) nedir?

Kullanıcı Kabul Testi (UAT) , yazılım uygulamasını üretim ortamına taşımadan önce yazılım sistemini doğrulamak / kabul etmek için son kullanıcı veya müşteri tarafından gerçekleştirilen bir test türüdür. UAT, işlevsellik, entegrasyon ve sistem testi yapıldıktan sonra testin son aşamasında yapılır.

UAT’nin Amacı

UAT’nin ana amacı, uçtan uca iş akışını doğrulamaktır. Kozmetik hatalara, yazım hatalarına veya sistem testlerine odaklanmaz. Kullanıcı Kabul Testi, üretim benzeri veri kurulumuyla ayrı bir test ortamında gerçekleştirilir. İki veya daha fazla son kullanıcının dahil olacağı bir tür kara kutu testidir.

UAT’yi kim gerçekleştirir?

  • Müşteri
  • Son kullanıcılar
UAT görüntüsünün performansları

Kullanıcı Kabul Testi İhtiyacı

Kullanıcı Kabul Testi İhtiyacı, yazılım Birim, Entegrasyon ve Sistem testlerinden geçtikten sonra ortaya çıkar çünkü geliştiriciler, kendi anlayışlarına göre gereksinimlerde belirtilen isteklere dayalı olarak yazılım geliştirmiş olabilirler ve geliştirme sırasında gerekli diğer değişiklikler kendilerine etkin bir şekilde iletilemeyebilir, bu nedenle nihai ürün müşteri / son kullanıcı tarafından kabul edildiğinde, kullanıcı kabul testi gereklidir.

Kullanıcı Kabul Testi (UAT) nedir?
  • Geliştiriciler, gereksinimleri “kendi” anladıkları ve aslında müşterinin yazılımdan ihtiyaç duyduğu şey olmayabilen taleplere göre yazılımları kodlar .
  • Proje süresince ihtiyaç değişiklikleri, geliştiricilere etkili bir şekilde iletilemeyebilir.

Kabul Testi ve V Modeli

VModel’de Kullanıcı kabul testi, Yazılım Geliştirme yaşam döngüsünün (SDLC) gereksinim aşamasına karşılık gelir.

Kabul Testi ve V-Model görüntüsü

Kullanıcı Kabul Testinin Ön Koşulları:

Kullanıcı Kabul Testi için giriş kriterleri şunlardır:

  • İşletme Gereksinimleri mevcut olmalıdır.
  • Uygulama Kodu tamamen geliştirilmelidir
  • Birim Testi, Entegrasyon Testi ve Sistem Testi tamamlanmalıdır
  • UAT’den önce sadece Kozmetik hata kabul edilebilir
  • Regresyon Testi büyük bir kusur olmadan tamamlanmalıdır
  • Bildirilen tüm kusurlar UAT’den önce düzeltilmeli ve test edilmelidir.
  • Tüm testler için izlenebilirlik matrisi tamamlanmalıdır
  • UAT Ortamı hazır olmalıdır
  • Sistemin UAT yürütmesi için hazır olduğuna dair Sistem Test Ekibinden gelen bildiri üzerine UAT başlatılır.

UAT Testi nasıl yapılır

UAT, sistemin veya yazılımın hedef kullanıcıları tarafından yapılır. Bu tür bir Yazılım Testi genellikle Beta Testi olarak bilinen istemci konumunda gerçekleşir. UAT için Giriş kriterleri karşılandığında, test uzmanları tarafından gerçekleştirilmesi gereken görevler şunlardır:

UAT Test süreci görüntüsü
UAT Süreci
  • İş Gereksinimlerinin Analizi
  • UAT test planının oluşturulması
  • Test Senaryolarını Belirleyin
  • UAT Test Durumları Oluşturun
  • Test Verilerinin Hazırlanması (Veri Benzeri Üretim)
  • Test senaryolarını çalıştırın
  • Sonuçları Kaydedin
  • İşletme hedeflerini onaylayın

Adım 1) İş Gereksinimlerinin Analizi

UAT’deki en önemli faaliyetlerden biri test senaryolarının belirlenmesi ve geliştirilmesidir. Bu test senaryoları aşağıdaki belgelerden türetilmiştir:

  • Proje Şartı
  • İş Kullanım Durumları
  • Süreç Akış Şemaları
  • İşletme Gereksinimlerinin belirlenmesi
  • Sistem Gereksinimlerinin belirlenmesi

Adım 2) UAT Planının Oluşturulması:

UAT test planı, bir uygulamanın iş gereksinimlerini karşıladığından emin olmak ve doğrulamak için kullanılacak stratejiyi ana hatlarıyla belirtir. UAT için giriş ve çıkış kriterlerini, Test senaryolarını ve test senaryoları yaklaşımını ve test zaman çizelgelerini belgeler .

Adım 3) Test Senaryolarını ve Test Durumlarını Belirleyin:

Üst düzey iş süreciyle ilgili test senaryolarını belirleyin ve net test adımlarıyla test senaryoları oluşturun. Test Vakaları, UAT senaryolarının çoğunu yeterince kapsamalıdır. İş Kullanım durumları, test senaryolarının oluşturulması için verilerdir.

Adım 4) Test Verilerinin Hazırlanması:

UAT için canlı verilerin kullanılması en iyisidir. Gizlilik ve güvenlik nedenleriyle veriler karıştırılmalıdır . Test uzmanı, veritabanı akışına aşina olmalıdır.

Adım 5) Sonuçları çalıştırın ve kaydedin:

Test senaryolarını yürütün ve varsa hataları bildirin. Düzeltildikten sonra hataları yeniden test edin. Yürütme için Test Yönetimi araçları kullanılabilir.

Adım 6) İş Hedeflerinin karşılandığını doğrulayın:

İş Analistleri veya UAT Test Uzmanları, UAT testinden sonra bir onay postası göndermelidir. İmzalandıktan sonra ürünün canlıya çıkması iyidir. UAT testi için teslim edilenler; Test Planı, UAT Senaryoları ve Test Örnekleri, Test Sonuçları ve Hata Kaydıdır

UAT için çıkış kriterleri:

Ürünün canlıya çıkması için önce aşağıdakilerin dikkate alınması gerekir:

  • Açık veya kritik hata yok
  • İş süreci tatmin edici şekilde çalışıyor
  • Tüm paydaşlarla UAT imzalama toplantısı

UAT Test Cihazlarının Nitelikleri:

Kullanıcı Kabul Testi (UAT) nedir?

UAT Tester, işletme hakkında iyi bilgiye sahip olmalıdır. Bağımsız olmalı ve sisteme bilinmeyen bir kullanıcı olarak düşünmelidir . Test uzmanı Analitik ve Yanal düşünen olmalı ve UAT’yi başarılı kılmak için her türlü veriyi birleştirmelidir.

İş gereksinimlerini veya akışlarını anlayan Test Uzmanı veya İş Analisti veya Konu Uzmanları, işletme için gerçekçi test ve veriler hazırlayabilir.

En İyi Uygulamalar:

UAT’nin Başarılı olması için aşağıdaki noktaların dikkate alınması gerekir:

  • Proje yaşam döngüsünün başlarında UAT planını hazırlayın
  • UAT başlamadan önce Kontrol Listesi hazırlayın
  • Sistem Testi aşamasının kendisi sırasında UAT Öncesi oturumu gerçekleştirin
  • Beklentiyi belirleyin ve UAT kapsamını açıkça tanımlayın
  • Uçtan Uca iş akışını test edin ve sistem testlerinden kaçının
  • Sistemi veya uygulamayı gerçek dünya senaryoları ve verileriyle test edin
  • Sistemde bilinmeyen bir kullanıcı olarak düşünün
  • Kullanılabilirlik Testi Yapın
  • Üretime geçmeden önce geri bildirim oturumu ve toplantı gerçekleştirin

Bazı Örnek UAT Kılavuzları

  • Normal yazılım geliştirme senaryolarında çoğu zaman UAT, QA ortamında gerçekleştirilir. Evreleme veya UAT ortamı yoksa
  • UAT, Beta ve Alfa testleri olarak sınıflandırılır, ancak hizmet tabanlı bir endüstri için yazılım geliştirildiğinde çok önemli değildir
  • UAT, müşteri daha fazla dahil olduğunda daha mantıklı olur

Sonuç:

  • Yazılım Mühendisliğinde, UAT’nin Tam biçimi Kullanıcı Kabul Testidir.
  • Yazılım Mühendisliğinde UAT, Kullanıcı Kabul Testi anlamına gelir.
  • UAT, son yirmi beş yılda ortaya çıkan birçok test çeşidinden biridir.
  • UAT ile müşteri, varsaymak yerine üründen “Ne beklemesi gerektiğinden” emin olabilir.
  • UAT’nin faydası, ürün piyasaya sürüldüğünde hiçbir sürpriz olmayacak olmasıdır.

Teşekkürler.

<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> Yazılım Testi | Leave a comment

Yazılım Test Planlamasına Başlamadan Önce Bilmeniz Gereken 10 Şey

Bu makalede, sizleri yazılım test planlaması ve yazılım test planlamasına başlamadan önce bilmeniz gereken en iyi 10 şey hakkında sizleri bilgilendirmeye çalışacağım.

Yazılım testi, iş ve teknik gereksinimleri karşılayan bir yazılım ürününün sağlanmasında hayati bir rol oynar. Birçok kişi, hataları bulmak amacıyla yazılım ürününü hemen test etmeye başlayabileceklerini düşünmektedir.
Ancak, disiplinli bir test yöneticisiyseniz, yazılım test planlamasının test sürecinin çok önemli bir parçası olduğunu bilirsiniz.

Hadi başlayalım ,

1. Müşterinin beklentilerini anlamak
Kulağa basit gelebilir, ancak birçok profesyonel iş sürecini anlamaya ve kolaylaştırmaya yarar. İş gereksinimlerini ve ürün özelliklerini anlamak farklı , müşteri ve izleyici anlayışını anlamak farklı bir şey.
İş gereksinimlerini çalışan yazılımlara dönüştürmek için, genellikle çok fazla teknik ayrıntıya giriyoruz ve kendi önceliklerimizle boğulmuş oluyoruz.
Bazen, yanlışlıkla, bazı modülleri ve özellikleri önceliklendiririz çünkü daha ilginç ve zorlayıcı buluruz;fakat onların işletmeye kattığı değeri görmezden geliriz.
Yazılım testi planlamasına başlamadan önce, müşterinin bakış açısını anlamanız gerekir. Aşağıdaki parametreler üzerinde düşünerek işlemi basitleştirebilirsiniz:

  • Yapısal Olarak İşlevsellik
    Farklı ürünler farklı iş ihtiyaçlarını karşılar. Bir finansal uygulama oluşturuyorsanız, müşterinin odak noktası uygulamanın işlevselliği olacaktır. Küçük bir hatanın büyük etkisi olabileceğinden teknik ayrıntıları dikkate almanız gerekecektir. Benzer şekilde, envanter yönetim sistemi oluşturuyorsanız, renk şeması ve kullanıcı arabirimi istemci için çok değer taşımaz.
  • Kullanıcı dostu arayüz
    İlk maddenin aksine , bir otel rezervasyonu veya tur planlayıcısı web sitesi geliştiriyorsanız – renk şeması, düzen ve kullanım kolaylığı daha büyük bir değere sahiptir.Bu durumda, müşteri karmaşık köşe noktalarını ele almakla ilgilenmez, web sitesinin kullanıcı arayüzü ve pürüzsüz akışı önemli bir önceliğe sahiptir.
  • Pazarlama Süreci
    Dikkate alınması gereken bir diğer önemli faktör, uygulamanın ‘pazara sunma zamanı’ dır. Tahmin edileceği gibi , uzun bir özellik listesine sahip büyük bir ürün geliştirmek için aylar hatta yıllar gerekir. Bu durum, rakip firma sizden önce pazarda aynı fikri ortaya çıkarabileceğinden iş ve süreç için ciddi bir kayba neden olabilir.

    Etkili yaklaşım, piyasaya daha erken adım atmak ve ürünü küçük özelliklerle piyasaya sürmektir. Daha sonra ürün güncelleştirildikçe daha fazla özellik eklenebilir. Bu, ürün tanıtım planına göre özelliklerin ve işlevlerin önceliklendirilmesini gerektirir. Bu tür senaryolarda, test planlamanız entegrasyon ve regresyon testini içermelidir. Daha uzun süre tekrarlanan bir etkinlik olacağından test verimliliği elde etmek için regresyon ve duman(smoke test) kontrol listesini otomatikleştirmek isteyebilirsiniz.
  • Kavram kanıtı (Proof of Concept) ve prototipler
    Bazen bir müşteri gereksinimler hakkında net değildir. ‘Gördüğümde karar vereceğim’ tutumunu taşıyabilirler. Bu durumlarda, yazılım prototipleme modeliyle çalışmanız ve test stratejinizi buna göre planlamanız gerekebilir.

2. Platformlarınızı ve Hedef Cihazlarınızı Tanıyın
Günümüz dünyasında teknoloji pazarı çeşitli platformlar, cihazlar ve ekran boyutları ile dolup taşıyor. Kişisel Bilgisayarlar, Dizüstü Bilgisayarlar, Tablet PC’ler ve Mobil cihazlar bunlardan birkaçı. Ayrıca, bu cihazların her birinin kendine has özel değişiklikleri var. Bunun gibi çoklu platformlar , bir ürünün çıkışında ki süreci ve maliyeti fazlasıyla uzatıp ürün çıkışında ki zorluğu arttırmaktadır.
Bu nedenle, müşteri ile testin gerçekleştirileceği platformlar, cihazlar ve ekran boyutları üzerinde anlaşılması oldukça önemlidir.
Mobil platformlar üzerinde, cihaz ve ekran boyutlarının sayısız kombinasyonu olduğu için bu çok önemlidir. Benzer şekilde, web uygulamaları için test stratejisi tanımlıyorsanız, işletim sistemlerine, tarayıcılara ve ekran çözünürlüklerine karar vermelisiniz. Kitleniz ve hedeflenen kullanıcılar üzerinde pazar araştırması yaparak hedef platformlarınızı, cihazlarınızı, ekran boyutlarınızı, tarayıcılarınızı ve çözünürlüklerinizi kısa listeye alabilirsiniz.

3. Test Stratejinizi Oluşturun

Müşteri ve hedef kitlenin işi için neyin önemli olduğunu net bir şekilde anladıktan sonra, test stratejinizi oluşturmaya hazırsınız. Test stratejisi, belirli bir ürünü test etme yaklaşımınızı tanımlayan üst düzey bir ilerleme yöntemidir. Test stratejisi, görevlerin, sorumlulukların ve zaman çizelgelerinin ayrıntılarını içermediğinden test planından farklıdır.

  • İşletmenin ihtiyaçlarını anlamak
    Yukarıda bahsettiğimiz gibi, yazılım testi planlamasına başlamadan önce iş gereksinimlerini anlamak önemlidir. Test stratejiniz işletmenin ihtiyaçlarını tamamlamalıdır. Kullanıcı dostu bir ürün oluştururken, test stratejiniz kullanıcı arayüzü testi, kullanılabilirlik testi, çapraz tarayıcı testi ve çapraz platform testini içerebilir.
  • Gerekli Test Türlerini Seçin
    Birçok test tekniği mevcut. Tüm test teknikleri her projeye uygulanamaz. Gereksinimlere bağlı olarak, uygulamanızın / ürününüzün tüm alanlarını test etmek için gerekli test türlerini seçersiniz. Test stratejisi çeşitli test türlerinden oluşabilir. Bu, kara kutu testi, beyaz kutu testi, güvenlik testi, veritabanı testi, API testi, yük testi, stres testi, performans testi, kullanılabilirlik testi, çapraz tarayıcı testi, çapraz platform testi, entegrasyon ve regresyon testi tekniklerinin herhangi bir kombinasyonunu içerir.

4. Doğru Test Araçlarını Seçin

Test stratejinizi oluşturduktan sonra, test faaliyetleriniz için doğru test araçlarını seçmeye hazırsınız. Test sürecini kolaylaştırmak ve hızlandırmak için piyasada çeşitli test araçları bulunmaktadır. Bazı durumlarda, bir test aracı kullanmak kaçınılmaz hale gelir. ( Testinium’u öneriyorum 🙂 )
Örneğin, tek makinenizden 1.000 veya daha fazla kullanıcıyı simüle etmede büyük sorun yaşayacaksınız.
Loadium aracı yük ve stres testlerinde size yardımcı olabilir.
Test verilerini hızlı bir şekilde oluşturmanıza yardımcı olması için bazı araçlar da kullanabilirsiniz. Bu tür araçlar, yük testi ve performans testi yaparken kullanışlıdır.
Benzer şekilde, test stratejinizde otomasyon testini tercih etmiş olabilirsiniz. Bu gibi durumlarda, Selenium gibi bazı otomasyon araçlarına ihtiyacınız olacaktır. Mobil test otomasyonu ile çalışıyorsanız Appium’u kullanmak isteyebilirsiniz. Selenium ve Appium kullanımı ve kurulumlarını da yazılarım arasında bulabilirsiniz. Ayrıca, test durumlarınızı, test senaryolarının yürütme durumunu ve hataların raporlanmasını etkin bir şekilde yönetmek için bir test veya hata yönetim aracına ihtiyacınız olacaktır. SpiraTest gereksinimlerinizi, test senaryolarınızı, yürütme durumlarınızı ve hatalarınızı tek bir yerde sorunsuz bir şekilde entegre eden böyle bir araçtır.

5. Kalite Güvence(QA) Süreci Oluşturun

Farklı projeler, proje ekipleri, roller ve görevler için farklı yapılara sahip olabilir. Bu nedenle, şirket içinde kalite güvence sürecine bağlı kalmayı veya projenizin ihtiyaçlarına göre süreci ayarlamayı seçebilirsiniz. Projeniz için hata yaşam döngüsünde durumları da tanımlamanız gerekebilir.


Kalite güvence süreci, ihtiyaçların anlaşılması, test senaryolarının oluşturulması, test senaryolarının yürütülmesi, hataların tanımlanması ve raporlanması, düzeltmelerin doğrulanması ve son ürünün nihai testinin gerçekleştirilmesinden başlayarak proje için tam kalite döngüsünü içerir.

6. Kalite güvence(QA) efor / zamanlarının tahminlenmesi

Test stratejiniz ve test araçlarınıza dayanarak, proje için gereken test çabalarını tahmin edebilirsiniz. Kalite güvence faaliyeti, iş gereksiniminin anlaşılmasını, test senaryolarının oluşturulmasını ve yürütülmesini, test verilerinin oluşturulmasını ve bazı olasılıkları içerir.

  • Test Senaryolarının Oluşturulması ve Yürütülmesi
    Test senaryoları oluşturmak önemli bir kalite güvence faaliyetidir. Ayrıca, beyin fırtınası, ihtiyaçların anlaşılması ve yan senaryoların ortaya çıkmasını gerektirdiği için zorlu bir görevdir. Bir sonraki adım senaryolar için test adımlarının oluşturmaktır. Bazı insanlar test senaryoları oluşturmak için gereken çabayı ve zamanı göz ardı eder. Test senaryoları ve test senaryoları oluşturmak için gereken süreyi tahminlerinize eklediğinizden emin olun.
  • Test Verilerinin Oluşturulması
    Bazen uygulamanız için test verileri oluşturmanız gerekir. Proje gereksinimlerine ve mevcut araçlara bağlı olarak, test verilerinin oluşturulması için gereken çabayı tahmin edebilirsiniz. Tahminler, herhangi bir araç kullanıp kullanmadığınıza bağlı olarak büyük ölçüde değişiklik gösterir.
  • Kaynakların Analizi
    Kaynakların beceri setini ve proje için kullanılabilirliklerini analiz edin. Örneğin, bir uzman kaynağının bir görevi tamamlaması 2 gün sürecektir; burada, yeni başlayan bir uzman aynı görevi 4 günde tamamlayabilir. Benzer şekilde, bazı yeni test araçları kullanıyorsanız, öğrenme eğrisinin süresi tahminlere dahil edilmelidir.
  • Gecikmeler ve Beklenmedik Durum
    Test faaliyetleri için gerçekçi tahminler vermek üzere çeşitli tahmin tekniklerini kullanabilirsiniz. Bununla birlikte, gerçek çalışmanın tahmini çabadan sapma ihtimali hala vardır. Bazı durumlarda, geliştirme daha fazla çaba sarf eder ve son teslim tarihi çok yakın olana kadar sürüm test için kullanılamaz hale gelir. Bu nedenle, bu tür gecikmeleri dikkate almanız ve tahminlere bazı olasılıklar eklemeniz önerilir.

7. Kalite Güvence Faaliyetlerini Programlayın

Tahminler, bir işi tamamlamak için gereken saat sayısını gösterir. Öte yandan, Program size zaman çizgisini anlatır. Program, faaliyetlere ne zaman başlayacağınızı, faaliyetler için son tarihin ne olduğunu ve beklenen gecikmelerin ne olduğunu gösterir. Kalite güvence programınızla birlikte, geliştirme görevleriniz ve gerekli onaylar arasındaki mantıksal ilişkileri belirleyerek kalite güvence sürecinizi planlayabilirsiniz. Örneğin, birkaç gün içinde test verileri, test senaryoları ve test adımlarını hazırlayabilirsiniz; yine de kodlama daha fazla çaba gerektirebileceğinden sürümü beklemek zorundasınız. Benzer şekilde, kaynak tahsisi de programınızı etkileyebilir. Kaynaklar tamamen veya kısmen tahsis edilebilir. Dolayısıyla, Kalite güvence faaliyetleri sırasında göz önünde bulundurulması gereken bir diğer önemli faktördür.

8. Kaynakların Kullanılabilirliği

Yazılım test sürecinizi, test kaynaklarınızın kullanılabilirliğine göre planlayın. Buna test ortamı, test araçları, test cihazları ve insan kaynakları dahildir. Geliştirilmekte olan sisteme uymak için özel yazılım veya donanım gereksinimleriniz olabilir. Bu nedenle, gerektiğinde gerekli test ortamını kurduğunuzdan veya kuracağınızdan emin olun.

9. Test Planının Temel Öğelerini Bilin

Yukarıda belirtilen faktörlerin hepsini göz önünde bulundurduğunuzda, proje için kalite güvence sürecini nasıl yürütebileceğinizin bir taslağını bulacaksınız. Ancak, bunların hepsini kafanızda tutamazsınız ve planınızı ilgili her bir üyeye sözlü olarak açıklayamazsınız. Yazılım test süreci için tüm planlamayı sistematik olarak düzenleyen bir yazılıma ihtiyacınız olacaktır.

10. Koşum Planlama Kadar Önemlidir

Söylemeye gerek yok, planlanan faaliyetlerin yürütülmesi de planlamanın kendisi kadar önemlidir. Başlangıçta planlandığı gibi işlerin gitmediği birkaç durum ortaya çıkacaktır. Bu senaryoları kapsamak için, test planını oluştururken riskleri ve bunlara ilişkin yanıtları önceden analiz etmeniz gerekir.



<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> Yazılım Testi | Yazılım Test Planlamasına Başlamadan Önce Bilmeniz Gereken 10 Şey için yorumlar kapalı

Yazılım Testinin Yazılım Geliştirmeden Daha İyi Bir Geleceğe Sahip Olmasının 11 Sebebi

Yazılım sektöründe yeni mezunlar için iki farklı seçenek vardır , bunlar :
1. Yazılım Testçiliği
2. Yazılım Geliştiriciliği

Son dönemlerde ülkemizde test sektöründe ki merak ve ilgi artmış vaziyette, bu sebepten ötürü Yazılım Test Uzmanlığı / Test Otomasyon Uzmanları da fazlasıyla ilgi görmekte.

Bu yazımda elimden geldiğince sizlere Yazılım Test sektöründe kariyer planlaması yapanların aldıkları karar doğrultusunda yanılmayacaklarına inancımı 11 madde ile göstermek istiyorum.

1.Önem

Yazılım test olmadan tamamlanamaz. Yazılım testi, yazılımı endüstriyel standartları, kullanıcı memnuniyeti düzeyi ve hatalar açısından analiz etmeyi içerir. Ürün yapılan tüm testleri geçmediği(Hata gözetim payı hesaba katılabilir) ve çalışabilirliği onaylanmadığı sürece kullanılamaz veya satılamaz.
Geliştirici , ürünü yapmak için çaba gösterirken , Test ekibi de ürünün kullanım için doğruluğunu kontrol etmelidir. Dolayısıyla yazılım testi daha sorumluluk gerektiren bir iştir.

2. Yetenekler

Yazılım geliştirme, kodlama becerileri üzerinde sıkı bir kavrayış gerektirse de, yazılım testi yaratıcılık ve kullanıcı gibi düşünme yeteneği gerektiren bir alandır. Bu, yazılım testinin kodlamadan uzak olduğu anlamına gelmez.
Günümüz dünyası çevikliğe(Agile) borçludur ve çalışmanın otomatikleştirilmesi gerekmektedir. Bu sebepten bazı testleri kodlayarak bir sisteme yaptırmak süreci hızlandırıp verimliliği arttırıyor.

3.Gelişmeler

Değişen trendlerle birlikte, yazılımın geliştirilmesi farklı şekillerde olabilir.
Aynı kalacak olan yazılımın test edilmesidir (küçük değişikliklerle).
Bununla birlikte, test otomasyonu farklı test türlerini otomatikleştirmek için test ve kodlama becerilerinin artan talepleri ile gelecekte daha verimli ve revaçta olacaktır. Bu, yazılım geliştiricileri ve yazılım testçileri için fırsatların artmasına yol açar.

4. Nesnelerin Interneti (IoT) ve Yapay Zeka

Bu yapılar yeni yeni ortaya çıkmaktadır ve bu nedenle özünde her yazılımın / donanımın olduğu gibi bir yazılım test sürecinin ve bilgisinin de yeri vardır.
Bu teknolojiler bir süre pazarda yer alacak ve başarıları sağlam test otomasyonu ve çekirdek test yapılarına sahip olacak.

5. Maaş süreçleri

İnsanların yazılım testlerini hafife aldıkları yaygın bir efsane, yazılım test kullanıcılarının yazılım geliştiricilerinden daha az maaş beklentisi içinde bulunması da bu sebeptendir.
Gerçek şu ki, ister yazılım testçisi ister bir yazılım geliştiricisi olsun, maaş skalaları aynıdır. Hatta önemli olan isim(ünvan) değildir; adil bir maaş bordrosu için geçerli olan beceriler, performans, alan bilgisi, sertifikasyon vb. olmalıdır.

6. Kodlama Avantajı

Bir yazılım geliştiricisi olmak, aklınıza gelen kodlarla dolu bir okyanusa sahip olmak demektir.Geliştiriciler ayrıca ürünlerinin çalışmasını test edebilir ve doğrulayabilir. Bununla birlikte, önemli kodlama becerilerine sahip bir yazılım testçisi olmak, sizin için ve çalıştığınız kuruluş için ek bir avantajdır.

7. Fırsatlar

Yazılım test kullanıcıları için fırsatlar asla bitmez. Ne tür bir proje üzerinde çalışacağınızı ve gereksinimlerinin ne olduğunu asla bilemezsiniz , özellikle dış kaynak projelerde (out source). Birçok müşteri, ihtiyaçlarını pratik olarak anlamak ve yazılımın endüstriyel ortamlarıyla uyumlu olup olmadığını kontrol etmek için yazılım testçilerinin çalışmasını tercih eder.
Bu sebepten , Yazılım testçilerinin bu fırsatları yakalama şansı oldukça yüksektir.

8. Yazılım geliştirmedeki rolü

Yazılım geliştirme sürecinde, hem yazılım geliştiricileri hem de test kullanıcıları önemli bir rol oynamaktadır. Bununla birlikte, bir yazılım testçisinin sorumluluğu daha fazladır ve bir yazılım geliştiricisi işe/sürece girmeden önce testçinin işi başlar.
Yazılım testçileri , gerçek geliştirmeye başlamadan önce analiz dökümanlarını kontrol etmeli ve daha sonra projenin sonuna kadar analiz dökümanına bağlı şekilde devam etmelidir.

9. Uzmanlaşma

Herkes testçi olamaz. Bir geliştirici bile bir testçinin özel becerilerinin yerini alamaz. Yazılımı test etmek, başarısız kılmak ve daha sonra düzeltilmesi için analiz etmek kolay bir iş değildir. Ve böylece, gerçek yazılım testçilerine olan talep en üst seviyededir.

10. Zorluklar

Zorluklar ne geliştiriciler ne de test uzmanları için yeni değildir. Ancak, tasarım mantığı ve test mantığı farklı anlamlar taşır. Yazılımda çalışan her kod parçasının arkasındaki mantığı test etmek için çok düşünmeniz gerekir.

11. Hiç Bitmeyen Gelecek

Yazılım testinin gerekliliği, geleneksel tekniklerin gelişmesini sağlamıştır. Yazılım dünyasındaki herkes, yazılım testinin kısa bir süre sonra sıkıca öğrenildiğine inanıyor. Yazılımın geleceği, yazılım testçilerinin elinde olacaktır.

<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> Yazılım Testi | Yazılım Testinin Yazılım Geliştirmeden Daha İyi Bir Geleceğe Sahip Olmasının 11 Sebebi için yorumlar kapalı

Agile metodolojisinde Erken ve Sık Görüşler neden önemlidir?

Agile geliştirme ekipleri için ekibin beklendiği gibi ilerleyip ilerlemediğini anlaması için sık sık geri bildirim hayati önem taşımaktadır. Agile ekibi tarafından geliştirilen ürün artışı paydaş incelemesine tabi tutulacak ve Ürün İş Listesi’ne geri bildirim eklenebilir ve bu durum Ürün Sahibinin takdirine bağlı olarak önceliklendirilebilir.

Sık geri bildirim sağlamanın en iyi yollarından biri Sürekli Entegrasyon’dur.

  • Waterfall geliştirme sırasında tasarım, geliştirme, test gibi her etkinlik bir aşama olarak kabul edilir, ancak Agile olarak tüm etkinlikler her yinelemede küçük parçalar halinde yapılır.
  • Waterfall, müşteri projenin sonunda çalışan yazılımı görebilir ve bu aşamada değişiklikler çok maliyetlidir ve önemli ölçüde yeniden işleme gerektirir.
  • Bunun yerine, her yinelemenin sonunda geri bildirim alınırsa, ekibin geri bildirimi oluşturması ve devam etmesi çok kolay olabilir.
  • Ayrıca uygulamadaki değişiklikleri kabul etmek için önemli bir araçtır.
  • En yüksek iş değeri özellikleri, erken ve sık geri bildirim kullanılarak geliştirme ekipleri tarafından müşteriye ilk olarak ulaştırılır.

Aynı zamanda ekibin kendi kapasitesini ölçmesine yardımcı olur, böylece kaba bir şekilde taahhütte bulunmazlar, böylece planlama sürecine yüksek derecede şeffaflık oluştururlar.

Early and Frequent Feedback 
Iterations 
in Agile 
Projects 
Early & 
Continuous 
Feedback 
 Continuous integration is a ...

Örneğin : Bir takım olarak, bu sprint’te kaç tane issue’ya ihtiyacımız var? Daha hızlı hareket etmemize yardımcı olabilecek ne düşünüyorsunuz? Gerçekten ilerlememizi engelleyen bir şey var mı?

Erken ve sık geri bildirimin faydaları şunlardır :

  • Küçük parçalara ayrı ayrı iş parçalarının tüm gerekliliklerinin kırılması, daha sonra düzeltilmesi çok maliyetli olabilecek hatalardan kaçınacaktır.
  • Ekip için herhangi bir sorun için müşterinin bulunması, ürün geliştirmeyi sağlamlaştırır, böylece ekip tam olarak müşterinin istediklerini oluşturur.
  • Ekip, sürekli ve sürdürülebilir bir hızda teslimat yapabilecektir.
  • Agile verimlilik ölçümlerini paylaşmak, ekibin boşlukları daha iyi anlamasına yardımcı olur, böylece kendilerini geliştirmenin yollarını bulabilirler.
<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> ISTQB | Agile metodolojisinde Erken ve Sık Görüşler neden önemlidir? için yorumlar kapalı

Çevik Testlerde Bütün Takım Yaklaşımı Nedir?

Whole Team Approach in Agile Testing , yani Çevik Testlerde Bütün Takım Yaklaşımı
Agile’de tüm ekip yaklaşımı, proje başarısını sağlamak için farklı bilgi ve becerilere sahip herkesi dahil etmek demektir.
Ekip, Ürün Sahibi olarak da bilinen müşterinin temsilcilerini ve ürün özelliklerini belirleyen diğer iş paydaşlarını içerir.
Takım nispeten küçük olmalı, tipik olarak beş ila yedi arasında olmalıdır, ancak başarılı takımlar en az üç kişi ve en fazla dokuz kişiyle gözlemlenmiştir. (Bu kişi belirlemesinin detaylı anlatımı Jake KNAPP’ın Sprint isimli kitabında güzelce anlatılmıştır. Tavsiye ederim 🙂 )

Whole-Team Approach ile ilgili görsel sonucu

İdeal olarak, tüm ekip aynı çalışma alanını paylaşır ve bir grup olarak oturur, çünkü ortak yerleşim iletişim ve etkileşimi güçlü bir şekilde kolaylaştırır.

Tüm ekip yaklaşımı, işin ilerlemesinin iletildiği ve ilerlemenin önündeki engellerin vurgulandığı ekibin tüm üyelerini içeren günlük stand-up toplantıları ile desteklenir . Tüm ekip yaklaşımı, daha etkili ve verimli ekip dinamiklerini teşvik eder.
Daily Stand – Up :
https://www.youtube.com/watch?v=Hv8xtMgGGRg

Ayrıca, tüm ekip yaklaşımını kullanarak, test uzmanlarının geliştiricilere otomatik testler yazmasına yardımcı olabilir ve bunun tersi de geçerlidir ve ürün sahipleri Keşif ve Kullanıcı Kabul Testlerine yardımcı olabilir .

Ürün geliştirme için tüm ekip yaklaşımının kullanılması, Çevik gelişimin temel faydalarından biridir. Yararları şunları içerir:

  • Ekip içindeki iletişimi ve işbirliğini geliştirme
  • Takım içindeki çeşitli beceri setlerinin projenin yararına kullanılmasını sağlamak
  • Kaliteyi herkesin sorumluluğunda yapmak

Agile projelerinde, testçiler veya KG’ler ürünün kalitesinden sorumlu olanlar değil, tüm ekip kaliteden sorumludur.
Tüm ekip yaklaşımının özü, test sürecinin her aşamasında birlikte çalışan test ediciler, geliştiriciler ve iş temsilcilerinde yatmaktadır.

Testçiler , istenen kalite seviyelerine ulaşılmasını sağlamak için hem geliştiriciler hem de iş temsilcileri ile yakın çalışacaktır  . Bu, uygun kabul testleri oluşturmalarına yardımcı olmak , iş tanımlarını tanımlamak , test stratejisi üzerinde anlaşmaya varmak için geliştiricilerle çalışmak  ve test otomasyonu yaklaşımlarına karar vermek için iş temsilcileriyle desteklenmeyi ve işbirliği yapmayı içerir  . Test uzmanları böylece test bilgilerini diğer ekip üyelerine aktarabilir  ve genişletebilir ve ürünün gelişimini etkileyebilir.

Tüm ekip, ürün özelliklerinin sunulduğu, analiz edildiği veya tahmin edildiği tüm istişarelere veya toplantılara katılır  .

<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> ISTQB | Çevik Testlerde Bütün Takım Yaklaşımı Nedir? için yorumlar kapalı

Yazılım Test Prensipleri

Başlamadan önce , Yazılım Test Prensipleri 2.maddesinde “Yazılımı %100 test etmek imkansızdır !” yer almaktadır. Tüm testlerin yapılması mümkün olmadığı için de her zaman hata çıkma olasılığı vardır. Bunu çoğu kişi kabul etmeli arkadaşlar bunu dile getirerek başlamak istedim.

Yedi test prensibi ile test ilkelerini anlamak, test etmenin önemini kavramak ve prensipleri pratikte kullanmak için böyle bir yazı yazma gereği duydum umarım işinize yarar.

1. Testin amacı; yazılımda hataların olduğunu göstermektir, yazılımda hata kalmadığını ispatlamak değildir !
Test ile uygulamalardaki hatalar bulunur. Böylece ürünün kullanımı sırasında olası zaman/para ve itibar kaybı azaltılır. Ancak unutulmaması gereken nokta, ne kadar çok test yapılırsa yapılsın, hala bir yerlerde hatalar olmaya devam edecektir.

2. Yazılımı %100 test etmek imkansızdır !
Bir uygulamadaki tüm kombinasyon ve olasılıkları test edemezsiniz (Bazı aşırı-kritik uygulama istisnaları haricinde). Bu makul bir durum değildir. Ancak teorik olarak sınırsız zaman ve bütçe olması durumunda (Ve psikoloji sağlam test ekibi de dahil) bu seçenek gerçekleşebilir. O yüzden gerçek hayatta, belli parametreleri dikkate alıp(Risk, öncelik vs) ona göre “makul yeterlilikte” test yapılır. Fizibilitesi doğru yapılmış bir test aktivitesi ile bu sınırsız seçeneği test etmeye yakın sonuçlar alınabilir.

3. Teste yazılım geliştirme sürecinin başında başlamak gerekir !
“Early Testing” dediğimiz erken test ; ürünü geliştirme sürecinde , hatta mümkünse geliştirme öncesinde test işlemine başlamak demektir. Bu prensip ile projenin ilerleyen zamanlarında bulunacak ve epey maliyetli olacak hata, daha yolun başındayken bulunur.Bu da kaliteyi hızlı ve etkin bir biçimde ölçme ihtiyacını karşılamış olur. Çünkü kaynaklar ve zamanlamadaki kısıtlamalar ortadan kalkmayan gerçeklerdir.

4. Hatalar yazılımın belli alanlarında yoğunlaşır / Hata Kümelemesi
Yapılan araştırmalar ve elde edilen deneyimlerde, hataların homojen dağılmadığı, genelde belli modüllerde/kısımlarda oluştuğu veya belli kişiler (Geliştirme ekibi) tarafından geliştirilen kısımlarda olduğu görülmüştür. Ekonomi bilimindeki meşhur 80–20 kuralı gibi düşünülebilir (Pareto prensibi).Bu prensip dikkate alınarak en fazla hata alınan alana odaklanıldığında hataların büyük çoğunluğu bulunmuş olur. Böylece kısa sürede birçok kusur(defect) bulmuş oluruz bile.

5. Antibiyotik Direnci/ DNT paradoksu
Aynı test case, aynı data ile (Bir de aynı kişi olursa, paradoks daha güçlenir) defalarca test edildiğinde, artık orada bir hata bulunması zor olur. Test doğası gereği üçüncü/bağımsız bir göz olması ve farklı girdilerle sonuç alması dolayısıyla, aynı şeyi yapmak, artık oradada bir direnç gösterir. O yüzden, belli sürelerde data değiştirilmeli ve mümkünse o testler başka bir ekip üyesi tarafından çalıştırılmalıdır. Yalnız burda ufak bir istisna var: otomasyon testleri. Burda durum tersidir. Yani, aynı test aynı data ve state ile test edilmelidir ki, çıkan hata ona göre tekrar edilebilir (Reproduce) olsun.

6. Test yaklaşımı ve aktiviteleri yazılım projesinin koşullarına göre değişiklik gösterir
Her ne kadar ana konsept aynı olsa da, test yaklaşımı içeriğe/projeye göre değişkenlik gösterir. Farklı sektörlerin, farklı alanların ihtiyaçları farklıdır. Enerji sektörü, Telekom sektörü, Bankacılık sektörü vs hepsinin öncelikleri, riskleri ayrıdır. O yüzden, test stratejisi ve yaklaşımı oluştururken sektörün dinamikleri de göz önünde bulundurulmalıdır.

7. Yeni hata bulunamadığında başarılı bir yazılım elde ettik yanılgısı
“Hatasız Kod Olmaz” , Herkes hata yapabilir. Ne olursan ol, deneyimin ne olursa olsun, bilgi ve pozisyonun her ne ise, sonuçta insansın ve hata yaparsın. O yüzden “ben asla hata yapmam” veya “o hatayı yapmam imkansız” demeyin. Bu durum, özellikle test ekibini çok ilgilendiriyor. Projenin tüm “hata” bulma beklentisi test ekibine yığılıyor. Test ekibindeki insanların “gerçekten noksansız” olması bekleniyor, bu durum hem teknik hem sosyal sorunlara yol açıyor.

<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> ISTQB | Yazılım Test Prensipleri için yorumlar kapalı

Yazılım Test Yaşam Döngüsü

Yazılım test yaşam döngüsü (Software Testing Life Cycle – bundan sonra Yazılım test yaşam döngüsü olarak kullanılacaktır.), bir sırayla yürütülecek bir dizi adımdan oluşan yazılım test sürecini ifade eder. Yazılımın gerekli kalite standartlarını karşıladığından emin olmak ve iyileştirilmesi gereken alanları belirlemek için yapılır. Yazılım test yaşam döngüsü aşamaları kuruluşa bağlı olarak değişebilse de, temel adımlar aynı kalır.

Yazılım Test Yaşam Döngüsü
Test Gereksinimlerinin Analizi

Bu, Kalite Güvence test cihazlarının test gereksinimlerini incelediği ve analiz ettiği yazılım testi yaşam döngüsünün ilk aşamasıdır. Bu aşama, test ihtiyaçlarının kapsamının belirlenmesine yardımcı olur.

İki ana test türü fonksiyonel testler ve fonksiyonel olmayan testlerdir:

  1. İşlevsel test – yazılımın işleyişini değerlendirmek için testler içerir.
  2. İşlevsel olmayan test – performans testi , güvenlik testi ve yük testi gibi sahne arkasındaki özellikleri değerlendirmek için testler içerir .
    İhtiyaç analizi aşamasında yer alan faaliyetler aşağıdaki gibidir:

Kalite Güvence ekibi (QA) gereksinimlerini analiz eder ve test ihtiyaçlarının listesini oluşturur.

  • Herhangi bir şüphe durumunda, Kalite Güvence ekibi müşteriler ve / veya paydaşlarla ilgili tüm endişeleri netleştirecektir.
  • Ardından, Kalite Güvence ekibi projeyi tamamlamak için gereken olası testleri özetler.
  • Projenin otomasyon gerektirmesi durumunda , bir otomasyon çalışması yapılacaktır.
Test Planlaması

Test analizi gereksinimleri tamamlandıktan sonra, bir sonraki adım testin nasıl yapılacağını planlamaktır. Bu, test hedeflerine ulaşılmasına yardımcı olabilecek kaynakları ve faaliyetleri tanımlamayı içerir. Sonuç, Test Planı belgesini üretir . Planlama iki faktöre dayanarak yapılır:

  1. Kuruluşun test stratejisi.
  2. Risklerin analizi ve yönetimi.

Test planlama aşamasında yer alan faaliyetler aşağıdaki gibidir:

  • Projenin kapsamı belirlenir.
  • İlgili riskler analiz edilir ve bunların azaltılması için bir plan yapılır.
  • Test tahmini yapılır.
  • Uygun test çözümlerinin seçimi .
  • Test için gerekli araçlar ve kaynaklar analiz edilir. Buna maliyet, gereken personel, işi tamamlamak için gereken çalışma saatleri ve sonuçların teslim edilmesi gereken son tarih dahildir.
  • Gerekli olması halinde, herhangi bir eğitim ihtiyacının analizi.
Test Durumlarının Geliştirilmesi

Bu aşamada, Kalite Güvence ekibi ayrıntılı test senaryoları oluşturur. Bu önemli görevlerden biridir ve yazılım test yaşam döngüsünün en önemli aşamalarından biri olarak kabul edilir.

İlgili faaliyetler aşağıdaki gibidir:

  • Yazılımdaki tüm özellikler için test senaryolarının geliştirilmesi.
  • Gerekirse otomasyon komut dosyalarının oluşturulması .
  • Test senaryoları ve test otomasyon senaryoları gözden geçirilir.
  • Test verileri oluşturulur.
Test Ortamının Kurulması

Yazılım test yaşam döngüsünün bir sonraki aşaması, yazılım / uygulamanın test edilmesi için gerekli yazılım veya donanımın kurulmasını içerir. Bu aşama ayrıca test senaryosu geliştirme aşamasına paralel olarak da gerçekleştirilebilir.

Kurulum aşamasında yer alan faaliyetler aşağıdaki gibidir:

  • Yazılımın tasarım ve yapısının yorumlanması.
  • Canlı test için test ortamının kurulması .
  • Donanım ve yazılım kurulumu gerekir.
  • Gerekirse herhangi bir üçüncü taraf başvurusunun entegrasyonu yapılır.
  • Yapının kurulumu test edilir.
  • Test verilerinin oluşturulması.
  • Yapı üzerinde duman testi(smoke test) , temel işlevlerin çalışmasını kontrol etmek için yapılır.
  • Yapı, duman testi sonucuna bağlı olarak kabul edilir veya reddedilir.

Yazılım Test Yaşam Döngüsü’nün test ortamı kurulum aşamasının sonucu, test ortamının kurulumunu, test verilerini ve duman testi sonucunu içerir.

Test Vakalarının Yürütülmesi

Test senaryoları bu aşamada test ortamında yürütülür. Kalite Güvence ekibi, test vakalarının yürütülmesi sırasında hatalarla karşılaşabilir ve daha sonra ayrıntılı olarak rapor edilir. Hatalar geliştirici tarafından giderildikten sonra test senaryoları Kalite Güvence ekibi tarafından tekrar test edilir.

Test yürütme aşamasında yer alan faaliyetler aşağıdaki gibidir:

  • Test senaryoları test ortamında yürütülür.
  • Test sonucu belgesi hazırlandı.
  • Başarısız test durumlarındaki hatalar kaydedilir.
  • Test senaryoları ve test planları gerekirse güncellenir.
  • Test durumları, kusurlar giderildikten sonra tekrar test edilir.
  • Yeniden test edildikten sonra çalışıyorlarsa kusurların kapanması.
  • Hataların kapatılmasından sonra sabit kalmasını sağlamak için yazılımın regresyon testinin uygulanması.
  • Yazılım Test Yaşam Döngüsü’nün test yürütme aşamasının sonucu, test senaryosu yürütme raporunun tamamlanmasını, gerektiğinde test vakalarının güncellenmesini ve hata raporlamayı içerir.
Yazılım Test Döngüsü Kapatma Aşaması

Bu aşamada, Kalite Güvence ekibi , test ettikleri ürünlerini tartıştıkları bir toplantı düzenler. Bu toplantının amacı, test sürecinde yapılan hataları anlamak ve gelecekteki projelerde tekrarlanmadığını görmektir.

Test döngüsü kapatma aşamasında yer alan faaliyetler aşağıdaki gibidir:

  • Testin tamamlandığının Test Kapsamı ve Yazılım Kalitesi temelinde değerlendirilmesi
  • Projeden çıkarılan derslerin günlüğü
  • Test sonuçları ciddi kusurların dağılımını anlamak için analiz edilir.
  • Test Kapanışı raporunun oluşturulması
<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> ISTQB | Yazılım Test Yaşam Döngüsü için yorumlar kapalı

Yazılım Testi Nedir?

Yazılımlar, iş uygulamalarından tutun da (örneğin bankacılık) tüketici ürünlerine kadar (örneğin arabalar) yaşamın ayrılmaz bir parçasıdır. Çoğu insan, beklendiği gibi çalışmayan bir yazılım ile karşılaşmıştır. Düzgün çalışmayan yazılımlar; para, zaman veya ticari itibar kaybetme ve hatta yaralanma veya ölüm gibi birçok soruna yol açabilir. Yazılım testi, yazılımın kalitesini değerlendirmenin ve kullanım sırasında oluşabilecek yazılım hatası riskini azaltmanın bir yoludur.

Yazılım testi hakkındaki yaygın yanlış kanılardan biri yazılım testinin yazılımı çalıştırmaktan ve sonuçları kontrol etmekten ibaret olduğudur. Yazılım testi birçok farklı faaliyeti içeren bir süreçtir; test koşumu aktivitesi (sonuçların kontrolü de dahil olmak üzere) bu faaliyetlerden sadece bir tanesidir.

Test süreci aynı zamanda test planlama, test analizi, test tasarımı, testin uyarlanması, test ilerlemesini ve sonuçlarını raporlama ve bir test nesnesinin kalitesini değerlendirme gibi faaliyetleri içerir.

The Software Testing Life Cycle


Bazı testler, test edilen birimin veya sistemin çalıştırılmasını içerir; bu testlere dinamik testler denir.

Diğer testler, test edilen birimin veya sistemin çalıştırılmasını gerektirmez; bu testlere ise statik testler denir. Dolayısıyla testler; gereksinimler, kullanıcı hikayeleri ve kaynak kod gibi çalışma ürünlerinin gözden geçirilmesini de içerir.

Testler hakkındaki bir başka yanlış kanı ise testlerin tamamen gereksinimlerin doğrulanmasına, kullanıcı hikayelerine veya diğer spesifikasyonlara odaklandıklarıdır. Her ne kadar yazılım testleri sistemin belirli gereksinimleri karşılayıp karşılamadığını kontrol etmeyi içerse de, aynı zamanda sistemin operasyonel ortamında/ortamlarında kullanıcı ve diğer paydaş ihtiyaçlarını karşılayıp karşılamadığını kontrol etmek anlamına gelen sağlama yapmayı da içerir.
Test faaliyetleri farklı yaşam döngülerinde farklı şekilde düzenlenir ve yürütülür.

<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> ISTQB | Yazılım Testi Nedir? için yorumlar kapalı

ISTQB Nedir ?

ISTQB 100’den fazla ülkede kar amacı gütmeyen, gönüllü dernekler şeklinde yazılım test ve kalitesi konusunda faaliyetlerini sürdüren en büyük uluslararası organizasyondur.

Türkiye’de de yavaş yavaş önemsenmeye başlanan uluslararası sertifika. Özellikle Avrupa’da Software Testing alanında iş arıyorsanız, cepte birkaç ISTQB sertifikası bulundurmakta fayda var. Sertifikanız varsa bu rahatlıkla iş bulacağınız anlamına gelmiyor olsa da, kendinizi geliştirmek ve test alanında gündemi takip etmek açısından yararlı olduğunu düşünüyorum.

Biz bu yazımızda Foundation Level (Temel Seviye) sertifikasından bahsedeceğiz Türkçe kaynak olarak resmi kuruluşun Türkçe diline çevirdiği Syballusu linkten edinebilirsiniz.
http://www.turkishtestingboard.org/foundation-level-ders-programi-turkce/

Temel Seviye sertifikasında katılım ücreti olarak:
200 USD + KDV belirlenmiştir

Sınav içeriğinden bahsedecek olursak toplam 40 adet sorudan oluşuyor ve geçme notu olarak 40 soru içerisinden 26 Adet doğru cevaba ulaşmak yeterli . Yanlış soru cevapları doğru soru sayısını azaltmamaktadır bu nedenle boş bırakmamakta fayda olduğunu bilin isterim.

Aşağıda ISTQB’nin çeşitli seviyelerde ve çeşitli dallarda ayrılmış sertifika türlerini görebilirsiniz.

http://www.turkishtestingboard.org/
https://www.istqb.org/

<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> ISTQB | ISTQB Nedir ? için yorumlar kapalı