Statik Test Ve Statik Analiz Nedir ?

Image for post

Statik test kod yürütülmeden kodun veya diğer proje dokümanlarının manual olarak gözden geçirilmesidir.

Statik testler dinamik testlere geçilmeden önce yapılmalıdır.

Projenin başlarında gözden geçirme yoluyla tespit edilen hataların çözülmesi ilerleyen aşamalarda bulunmasından daha az maliyetlidir.

İnsan faktörü sebebiyle ortaya çıkan hatalar bu aşamada tespit edilir.

Statik Test Teknikleri Nelerdir ?

Image for post

Teknikleri Nelerdir ?

Gözden Geçirme (Review)

Gayri resmi gözden geçirme (Informal Review)

Ürünü geliştiren kişilerden farklı kişi veya kişiler tarafından kodun incelenmesidir.

İnceleme sonucunda bulunan hataları ve iyileştirme önerilerini ürünü geliştiren kişiye bildirir

Üzerinden Geçme (Walkthrough)

Planlı olarak ürünü gözden geçirecek kişi veya kişilere sunulmasıdır. Küçük ölçekteki iş ürünleri için kullanılır, herhangi bir ön hazırlık yapılmaz.

Teknik Gözden Geçirme (Technical Review)

Ürünü geliştiren kişilerin plansız ve herhangi bir hazırlık olmadan toplanıp, ürünü gözden geçirmeleri ve sonuçlara göre iyileştirme önerileri yapmalarıdır.

Teftiş (Inspection)

Ürünü geliştiren kişilerden farklı, benzer birikime sahip kişilerin ürün yayımlanmadan önce yürüttüğü resmi gözden geçirmedir.
Toplantıyı moderatör yönetir,
Planlı şekilde düzenlenir katılacak kişiler ön hazırlık yapar ve hatalar saptanmaya çalışılır.

Statik Test Analizi(Static Analysis)

Statik analiz ürünün (kod, veri) çoğunlukla çeşitli araçlar kullanılarak test edilmesidir.

Amaç clean kod yazmak için gerekli kriterlerin sağlanmasını kolaylaştırmaktır.

Kriterler;

  • Kodlama standartlarına uygunluk
  • Tekrardan kaçınma
  • Birim testlerinin yeterliliği
  • Karmaşıklığın doğru dağılımı
  • Spagetti olmayan tasarım
  • Yeterli yorum frekansı
Image for post
Statik Analiz örnek

Kullanılabilir Araçlar

Bu araçların bir kısmı halihazırda kullanılan Visual Studio, IntelliJ Idea gibi popüler IDE’ler ile entegre iken, bir kısmı da bağımsız olarak yer almakta. PMD, Checksytle ve Findbugs bu araçlardan Java ekosistemi içinde en fazla kullanılanlardan.

Checkstyle

Kısaca yazılan kodun, kodlama standartlarına uygunluğunu kontrol eden bir araçtır. Belirlediğiniz kod konvansiyonuna göre, isimlendirme, kütüphane kullanımı, boşluklandırma ve yorum frekansı gibi kodun okunabilirliğini ve bakım yapılabilirliği arttıracak nitelikleri kontrol eder.

FindBugs

Bu araç diğerlerinden farklı olarak direkt bytecode üzerinden analiz işlemi yapmaktadır. PDM’ye benzer özelliklere sahip olmasının yanında concurrency sorunları ve bazı zafiyetlerin bulunması yardımcı olmaktadır.

PMD

En temel anlamı ile yazılan koddan üretilen Abstract Syntax Tree (AST) üzerinden kodu çalıştırmadan analiz işlemi yapan bir araçtır. Erişilemeyen veya tekrar eden kod parçacıklarını, aşırı karmaşıklığı, olası hataları ve optimize edilmemiş alanları belirleyen etkili bir open-source yazılımdır.

Diğer araçlar

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

White Box Test Nedir?

White Box testleri, Beyaz kutu, şeffaf kutu, cam kutu, açık kutu gibi isimler alır. Burada ki amaç kod içinde ki sorunları tespit etmektir. Bu testte, testi yapan kişi sorunun tespiti için kodun içeriğindeki sorunlu noktayı incelemelidir.

Image for post

Beyaz kutu testleri birim ve tümleştirmeyi incelememizi sağlar. Birimden kasıt şudur, kodlar tümleştirilmeden önce birim testi yapılır ve kodun çalışır olmasından emin olunur. Ardından tümleştirilen kodlar tümleştirme testinden geçer. Ve burada birleşen kodların bir arada uyum içinde çalıştığından emin olunur.

White Box testinin en önemli noktası kod bilgisi olmalıdır. Ve White Box testleri yazılım sürecinin en başında başlaması çok iyi olur. Olası hataların tespiti en erken şekilde bulunması ile yazılım maliyetleri en aza çekilebilecektir.

White Box neyi amaçlar?

En temel anlamda kullanmamızın amacı, yazılımın kodlarının doğruluğunu ve uyumluluğunu anlamaktır. Bu testten çıkarımda bulunabileceğimiz Temel başlıklar ise şöyle;

· Testteki her hangi bir potansiyel hata verecek kod yapısını tespiti.

· İlerleyen süreçlerde çıkacak olan gizli hataların olmaması birim aşamada emin olmak.

White Box testinin Türleri

· Birim test: Birim kod içindeki sorunların tespiti için.

· Entegrasyon test: Birimler arası çıkacak pürüzlerin tespiti için

· Sistem testi: Alt sistemler arası yolların test için kullanılır.

White Box avantajları

· Kodun optimizasyonunu sağlar.

· Fazlalık şişkinlik yapan kod parçalarının kaldırılmasını sağlar.

· İlk bakışta görülmeyen hataların en küçük seviyeden tespitini sağlar

· Hangi verinin kodu en iyi şekilde test edeceğini görmeyi sağlar.

White Box dezavantajları

· Testleri belirli koşullarda yapınca maliyet artar.

· Kodu tek tek incelemek can sıkıcı ve yorucu bir işlemdir.

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

Black Box Test

Tamamen Yazılım gereksinim ve özelliklerine dayanan bir test türüdür. Black Box Testinde, yazılımın dâhili çalışma yapısının hiçbir değişime ya da incelemeye alınmadan sisteme giriş ve çıkış değerlerinin irdelendiği bir test türüdür.

Image for post

Black Box neyi amaçlar?

En temel anlamda kullanmamızın amacı, yazılımın kullanıcının isteklerini tatmin edip etmediğini anlamaktır. Bu testten çıkarımda bulunabileceğimiz Temel başlıklar ise şöyle;

· Sistemin açılış ve kapanış esnasında karşılaşılacak problemlerin keşfi.

· Yanlış veya eksik çalışan fonksiyonların keşfi.

· Ara yüz zafiyetlerinin keşfi.

· Veri tabanına erişim kayıtlanma veya olası diğer zafiyetlerin keşfi.

· Sistemin davranışsal hatalarının ve uygulama sorunlarının keşfi.

Gibi şeyleri sayabiliriz.

Black Box testi yapmanın akışı nasıldır?

1. En ilk yapılacak şey, Sistemin gereksinimlerini analizi edilmelidir.

2. Test cihazı, yazılımın doğru işlediğini algılayabilmesi için referans olabilecek girdiler(input) değerler girilir. Bunlar geçerli doğru senaryolar(pozitif) ve geçersiz sayılması gereken yanlış senaryolar(negatif) seçimleri yapılır.

3. Test cihazı girilen girdiler için çıkması beklenen çıkış(output) değerlerini belirler.

4. Girdiler için Test senaryolarını oluşturur.

5. Test senaryolarının koşması sağlanır.

6. Test cihazı beklenen değerler ile gerçek sonuçları karşılaştırır.

7. Eğer hata bulunur ve hata giderilirse tekrar koşma sağlanır.

Black Box testinin Türleri

Black Box testinin çok türü vardır, Fakat biz akla ilk gelenlerine bakacağız;

· Fonksiyonel test: Yazılım testçileri tarafından yazılım fonksiyon gereksinimlerini kapsayan test türüdür.

· İşlevsel olmayan test: Performans, işlevsellik, ölçeklendirebilirlik vs. gibi işlevsel olmayan gereksinimleri kapsayan test türüdür.

· Regresyon testi: yapılan yeni kod düzenlemelerinin eski çalışır akışın bozulmadığına dair yapılan test türüdür.

Black Box için Kullanılabilecek araçlar

Kara kutu testi için kullanılan araçlar büyük ölçüde yaptığınız kara kutu testi türüne bağlıdır.

  • Fonksiyonel / Regresyon Testleri için şunları kullanabilirsiniz — QTP , Selenium
  • Fonksiyonel Olmayan Testler için — LoadRunner , Jmeter
<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> Yazılım Testi | Leave a comment

Daha iyi bir programcı olmak için 10 altın kural

Daha iyi bir programcı olmak için 10 altın kural
1. Kendini tekrar etme

Bu takip edilmesi gereken harika bir prensiptir. Ben gerçekten yazmış olduğum koda geri dönüp birden çok kullandığım kısımlarını yeniden düzenlemekten keyif alıyorum. Bazı uzun metodları parçalara ayırıyorum. Ctrl+R+M kısayolu Visual Studio üzerinde kodları yeniden düzenleyerek parçalara ayırmama yardımcı oluyor. Bu kodu yeniden kullanabilir ve test edilebilir yapıyor.

2. Değişkenlerinizi ne olduklarına göre isimlendirin, hangi data tipine sahip olduklarına göre değil

Bu konudaki tek istisnai durum başkasının kodu üzerinde birşeyler yaparken olabilir. Bu durumda yazan kişinin notasyonuna göre ilerlemelisiniz.

3. Metodlarınıza ne yapacaklarını belirleyen isimler verin

Bunu düzgün bir şekilde yaparsanız, yorumlamanız gereken yerleri en aza indirgersiniz. Eğer kodunuz okunabilecek kadar açıklayıcı ise, yorum satırları eklemenize de gerek kalmaz.

4. Kod içerisine gömülmüş sihirli numaralar veya karaktersel ifadeler kullanmayın

Kod içerisinde; bir başkasının gelip o kodu okuduğunda ne olduklarını anlayamayacakları sayısal veya karaktersel ifadeler kullanmayın. Constant (sabit)’lar oluşturun, enumları veya private değişkenlere kolay anlaşılabilir isimler verin ve onu kullanın.

5. Metodlarınızı mümkün olan yerlerde herhangi bir uygulamanın bir parçasına bağlı olmadan test edilebilecek şekilde yazın.

Metodun nereden çağırıldığının bir önemi olmasın. Bu kodu daha test edilebilir ve yeniden kullanılabilir yapar.

Eğer Session Value (oturum değerlerini)’ları veya App Settings’leri (uygulama ayar değerlerini) kullanıyorsanız, onları metodlarınızı çağıracağınız noktada değişkenlerin içerisine atayarak kullanın. Bu onları daha da test edilebilir yapar.

6. Yardım istemekten korkmayın

Size herşeyde yardım isteyin kendiniz birşey öğrenmeyin demiyorum. Demek istediğim şey bundan çekinmeyin, eğer bir yerde sıkışıp kaldıysanız bir başkasının yardımını isteyin. Onlar sizin karşılaştığınız problem ile daha önce karşılaşmış ve çözmüş olabilirler. Aynı zamanda birine yapmaya çalıştığınız şeyi, ne beklediğinizi ve probleminizin ne olduğunu anlatmak çözümü sizin de bulmanıza yardım eder.

7. İzci kuralına uyun

Çok hatalı veya berbat bir kod gördüğünüz yerde çözün ve yolunuza devam edin. Onu bir başkasının yapmasını beklemeyin fakat aynı zamanda tüm programı da yeniden yazmayın.

8. Bilginizi başkalarıyla paylaşın

Bildiğinizi kendinize saklamak konusunda bencillik yapmayın. Kültürünüz başkalarına yardım etmek olsun. Bir takım olarak çalışmanın ve birbirinizi geliştirmenin en iyi yolunu bulacaksınız. Çalışma arkadaşlarınızın gelişmesine katkıda bulunmak bilginizin uçup gitmesi veya işizi tehlikeye atmanız demek değil. Kendinizi bilgisini elinde tutan birine göre daha değerli yapar, aynı zamanda da etrafınızakilerin gelişimine yardımcı olmuş olursunuz.

9. Çalışma arkadaşlarınızı önemli birşeyin ortasındayken rahatsız etmeyin

Bi düşünün, programlama yaparken tüm parçaları kafanızda bir araya getiriyorsunuz, tıpkı iskambil kartlarından ev yapıyor gibi çok dikkatlice hareket ediyorsunuz. Tam o sırada biri bir soru soruyor, konsantrasyonunuz gidiyor ve üst üste koymuş olduğunuz tüm iskambil kartları birden yerle bir oluyor. Konsantrasyonları dağıldıktan sonra tekrar onu sağlamak ve tüm parçaları tekrar bir araya getirmek en az 5-10 dakikalarını alır, Googlayabilecekken veya bir başkasına sorabilecekken bunu yapmayın. Eğer çalışma arkadaşlarınıza bu saygıyı gösterir ve bunu farkettirirseniz, onlarda size aynı şekilde davranır, bu da sizi daha verimli biri yapar.

10. Kritik yaparken negatiflik yerine pozitifliği kullanın.

Bana göre kritik yapmak kendimi geliştirmem için bir şans.

Eğer birşeyleri yaparken aklıma gelmeyen veya bilmediğim başka bir yol varsa kendimi geliştirmek için onu öğrenmek isterim.

Paul Seal tarafından yazılmış “10 golden rules for becoming a better programmer” yazının Türkçe çevirisidir.

Çeviride bulmuş olduğunuz hataları bana iletirseniz “birlikte” gelişmiş oluruz.

Source: http://www.codeshare.co.uk/blog/10-golden-rules-for-becoming-a-better-programmer/

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

Test Aktiviteleri ve Yapılacak İşler

Bir test süreci aşağıdaki ana aktivite gruplarından oluşur:
• Test planlama
• Test gözetimi ve kontrolü
• Test analizi
• Test tasarımı
• Test uyarlama
• Test koşumu
• Test tamamlama

Her aktivite grubundaki her bir aktivite, bir
projeden veya sürümden diğerine değişebilen birçok ayrı işi içerebilir.

Ayrıca, bu aktivite gruplarının birçoğu mantıksal olarak sıralı görünse de, genellikle döngüsel olarak uygulanırlar. Örneğin,
çevik yazılım geliştirme, devamlı planlama tarafından desteklenen ve sürekli olarak gerçekleşen yazılım tasarımı, geliştirme ve
testlerin küçük döngülerinden oluşur. Dolayısıyla, bu yazılım geliştirme yaklaşımı içinde test aktiviteleri de döngüsel ve sürekli
olarak gerçekleşir. Sıralı yazılım geliştirmede bile, kademeli mantıksal aktivite dizisi; kesişme, birleşme, eşzamanlılık veya
çıkarmayı içerir. Bu nedenle bu ana aktivitelerin genellikle yazılım ve proje bağlamında düzenlenmesi gerekir.

Test planlama

Test hedeflerini belirleyen aktiviteler ve proje bağlamının dayattığı kısıtlamalar dâhilinde test hedeflerini
yerine getirme yaklaşımını içerir (örneğin, uygun test tekniklerini ve işlerini belirlemek ve bunları belirtilen zamanda bitirmek
için bir test zaman çizelgesi oluşturmak). Gözetim ve kontrol faaliyetlerinden gelen geri bildirimlere dayanarak test planları
gözden geçirilip güncellenebilir.

Test gözetimi ve kontrolü

Test gözetimi, test planında tanımlanan test gözetim metriklerini kullanarak planlanan ile gerçekleşen ilerlemenin sürekli
karşılaştırılmasını içerir.

Test kontrolü, test planında belirlenen hedeflere ulaşmak için gerekli önlemlerin alınmasını içerir.
Test gözetimi ve kontrolü, çıkış kriterlerinin değerlendirilmesiyle desteklenir; bu kriterler bazı yaşam döngülerinde
“Tamamlandı” tanımı olarak da bahsedilir.

Örneğin, bir test seviyesinde için test koşumu çıkış kriterlerinin değerlendirilmesi aşağıdakileri içerebilir:

• Test sonuçlarının ve kayıtlarının belirtilen kapsama kriterleriyle karşılaştırılarak kontrol edilmesi

• Test sonuçlarına ve kayıtlara dayanarak birim veya sistemin kalite seviyesinin değerlendirilmesi
• Daha fazla test gerekip gerekmediğinin belirlenmesi (örneğin, belirli bir ürün riskinin kapsanması için ek testlerin
yazılması ve koşturulması)
Test ilerlemesi, planla karşılaştırmalı olarak test ilerleme raporlarında paydaşlara iletilir; buna plandan sapmalar ve testleri
durdurma kararını destekleyen bilgiler de dâhildir.

Test analizi

Test analizi sırasında, test edilebilir özellikleri belirlemek ve ilgili test koşullarını tanımlamak için test esası analiz edilir. Diğer bir deyişle, test analizi ölçülebilir kapsama kriterleri açısından “neyin test edileceğini” belirler.
Test analizi aşağıdaki ana aktiviteleri içerir:
• Test seviyesine uygun şekilde test esasını analiz etmek, örneğin:
o Gereksinimler, fonksiyonel gereksinimler, sistem gereksinimleri, kullanıcı hikâyeleri, epikler, kullanım senaryoları gibi gereksinim spesifikasyonları veya istenen fonksiyonel ve fonksiyonel olmayan birim veya sistem davranışını belirten benzer çalışma ürünleri.
o Sistem veya yazılım mimarisi şemaları veya dokümanları, tasarım spesifikasyonları, çağrı akışları, modelleme şemaları (örneğin, UML veya ER şemaları), arayüz spesifikasyonları gibi tasarım ve uygulama bilgileri veya birim veya sistem yapısını belirten benzer çalışma ürünleri
o Hayata geçirilmiş kod, veri tabanı meta verileri ,sorgular ve arayüzler
o Birim veya sistemin fonksiyonel, fonksiyonel olmayan ve yapısal yönlerini dikkate alan risk analizi raporları
• Aşağıdakiler gibi çeşitli tiplerdeki hataları belirlemek için test esasını ve test öğelerini değerlendirme:
o Belirsizlikler
o Çıkarmalar
o Tutarsızlıklar
o Yanlışlıklar
o Çelişkiler
o Gereksiz ifadeler
• Test edilecek özelliklerin ve özellik gruplarının belirlenmesi
• Test esasının analizine dayanarak fonksiyonel, fonksiyonel olmayan ve yapısal özellikleri, diğer iş ve teknik faktörleri ve risk seviyelerini dikkate alarak her özellik için test koşullarının belirlenmesi ve önceliklendirilmesi
• Test esasının her unsuru ve ilgili test koşulları arasında çift yönlü izlenebilirliğin belirlenmesi


Kara kutu, beyaz kutu ve tecrübeye dayalı test tekniklerinin uygulanması, test analizi sürecinde önemli test koşullarının gözden kaçırılma olasılığını azaltmak ve daha kesin ve doğru test koşulları tanımlamak için faydalı olabilir.
Bazı durumlarda, test analizi, test tüzüklerinde test hedefi olarak kullanılacak test koşullarını üretir. Test tüzükleri, bazı tecrübeye dayalı test çeşitlerinde tipik çalışma ürünleridir. Test esasıyla bu test hedefleri ilişkilendirilebilir ise, tecrübeye dayalı testler sırasında elde edilen kapsam ölçülebilir.
Test analizi sırasında hataların belirlenmesi, özellikle başka bir gözden geçirme tekniğinin kullanılmadığı ve/veya test sürecinin
gözden geçirme süreci ile yakından bağlantılı olmadığı durumlarda, önemli bir potansiyel faydadır. Bu tür test analizi faaliyetleri sadece gereksinimlerin tutarlı, doğru ifade edilmiş ve eksiksiz olduğunu doğrulamakla kalmaz, aynı zamanda gereksinimlerin müşteri, kullanıcı ve diğer paydaş ihtiyaçlarını doğru şekilde karşılayıp karşılamadığının sağlamasını da yapar.
Örneğin, kodlamadan önce kullanıcı hikâyelerinden ve kabul kriterlerinden test koşulları ve test senaryoları oluşturmayı içeren, davranış odaklı yazılım geliştirme (BDD) ve kabul testi odaklı yazılım geliştirme (ATDD) gibi tekniklerle kullanıcı hikâyeleri ve kabul kriterleri doğrulanır, sağlaması yapılır ve hataları bulunur.

Test tasarımı

Test tasarımı sırasında test koşulları; üst seviye test senaryoları, üst seviye test senaryo grupları ve test yazılımları gibi ayrıntılar belirlenir. Bu nedenle, test analizi “ne test edilecek?” sorusuna cevap verirken, test tasarımı “nasıl test edilecek?” sorusuna cevap verir.
Test tasarımı aşağıdaki ana aktiviteleri içerir:
• Test senaryolarının ve test senaryo gruplarının tasarlanması ve önceliklendirilmesi
• Test koşullarını ve test durumlarını desteklemek için gereken test verilerinin belirlenmesi
• Test ortamının tasarlanması ve gerekli altyapı ve araçların belirlenmesi
• Test esası, test koşulları, test senaryoları ve test prosedürleri arasında çift yönlü izlenebilirliğin tespit edilmesi
Test koşullarının test senaryolarına ve test senaryosu gruplarına genişletilmesinde genellikle test teknikleri kullanılır.
Test analizinde olduğu gibi test tasarımı da test esasındaki benzer hata çeşitlerinin belirlenmesini sağlayabilir. Yine test analizinde olduğu gibi, test tasarımı sırasında hataların belirlenmesi önemli bir potansiyel faydadır.

Test uyarlama

Test uyarlama sırasında, test koşumu için eğer gerekiyorsa test yazılımı oluşturulur ve/veya tamamlanır; buna test senaryolarından test prosedürleri üretmek de dâhildir. Dolayısıyla, test tasarımı “nasıl test edilecek?” sorusuna cevap verirken, test uyarlama “şu anda testleri koşmak için gerekli şeylere sahip miyiz?” sorusuna cevap arar.
Test uyarlama aşağıdaki ana aktiviteleri içerir:

• Test prosedürlerinin yazılması, önceliklendirilmesi ve gerekiyorsa test betiklerinin otomasyonu
• Test prosedürlerinden ve yazıldıysa otomatikleştirilmiş test betiklerinden test grupları oluşturulması
• Test gruplarını, test senaryolarını ve otomatikleştirilmiş test betiklerini içeren test koşum çizelgesi oluşturulması
• Test ortamının oluşturulması (gerekiyorsa test kuluçkası, servis sanallaştırması, simülatörler ve diğer altyapı öğelerini dâhil ederek) ve ihtiyaç duyulan her şeyin doğru şekilde kurulduğunun doğrulanması
• Test verilerinin hazırlanması ve test ortamına düzgün şekilde yüklenmesinin sağlanması
• Test esası, test koşulları, test senaryoları, test prosedürleri ve test grupları arasında çift yönlü izlenebilirliğin doğrulanması ve güncellenmesi

Test tasarımı ve test uyarlama görevleri genellikle birlikte hayata geçirilir.
Keşif testlerinde ve diğer tecrübeye dayalı test çeşitlerinde, test tasarımı ve uyarlaması, test koşumunun bir parçası olarak gerçekleştirilebilir ve dokümante edilebilir. Keşif testleri, test tüzüklerine (test analizinin bir parçası olarak üretilir) dayandırılmış olabilir ve keşif testleri tasarlandıktan ve uyarlandıktan sonra hemen koşturulur

Test koşumu

Test koşumu sırasında, test grupları test koşum çizelgesine uygun olarak çalıştırılır. Test koşumu aşağıdaki ana aktiviteleri
içerir:
• Test öğesinin/öğelerinin veya test nesnesinin, test aracının/araçlarının ve test yazılımının kimlik numaralarının ve versiyonlarının kaydedilmesi
• Testlerin manuel olarak veya test koşum araçları kullanılarak koşulması
• Gerçekleşen sonuçlarla beklenen sonuçların karşılaştırılması
• Olası nedenlerin belirlenmesi için anomalilerin analiz edilmesi (örneğin, koddaki hatalar nedeniyle arızalar oluşabilir, ancak yanlış pozitifler de ortaya çıkabilir
• Gözlemlenen arızalara dayanılarak hataların bildirilmesi
• Test koşum sonucunun kaydedilmesi (örneğin, başarılı, başarısız, engellendi)
• Bir anomali için ya da planlı testlerin bir parçası olarak test aktivitelerinin tekrarlanması (örneğin, düzeltilmiş bir testin, onaylama testinin ve/veya regresyon testlerinin koşturulması)
• Test esası, test koşulları, test senaryoları, test prosedürleri ve test sonuçları arasındaki çift yönlü izlenebilirliğin doğrulanması ve güncellenmesi.

Test tamamlama

Test tamamlama aktiviteleri; test projesinde elde edilen deneyimi, proje boyunca üretilen test yazılımını ve elde edilen diğer ilgili bilgileri toplar ve bir araya getirir. Test tamamlama aktiviteleri, bir yazılımın piyasaya sürülmesi, bir test projesinin tamamlanması (veya iptal edilmesi), bir çevik proje döngüsünün tamamlanması (örneğin bir geriye dönük değerlendirme toplantısının parçası olarak), bir test seviyesinin tamamlanması veya bir bakım sürümünün tamamlanması gibi proje kilometre taşlarında gerçekleştirilir.
Test tamamlama aşağıdaki ana aktiviteleri içerir:
• Tüm hata raporlarının kapatılıp kapatılmadığının kontrol edilmesi, test koşumu sonunda çözülmeden kalan hatalar için değişiklik taleplerinin ürün iş listesine girilmesi
• Paydaşlara iletilmek üzere bir test özet raporunun oluşturulması
• Test ortamının, test verilerinin, test altyapısının ve diğer test yazılımlarının daha sonra tekrar kullanılmak üzere sonlandırılması ve arşivlenmesi
• Test yazılımının bakım ekiplerine, diğer proje ekiplerine ve/veya test yazılımının kullanımından faydalanabilecek diğer paydaşlara teslim edilmesi
• Gelecek döngüler, sürümler ve projeler için gereken değişikliklerin belirlenmesi amacıyla tamamlanan test faaliyetlerinden çıkarılan derslerin analiz edilmesi
• Test süreci olgunluğunun artırılması için toplanan bilgilerin kullanılması

<span class="entry-utility-prep entry-utility-prep-cat-links">Posted in</span> ISTQB | Leave a comment

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ı