TEST THE RISK!

Recently I have had lots of interviews for QA Analyst roles in the company. We called engineers from the level of beginner to senior test engineers for these roles. One of the most important questions in our interview is for understanding why we are testing. Actually this question is more about the philosophy of the testing, as we think the philosophy is generally not liked by people, but everyone who does something about a subject everyday from 9 to 6 should think about why he does this job. I wonder whether the testing job is just only to feed himself or he has some other passion about his profession. That's why this question is very important for me. One of the training given by Ståle Amland which is " Exploratory Testing – Risk-Based Agile Testing ", he explains the philosophy of testing as epistemology of testing and he is saying that " all good testers should  practice Epistemology ", see these slides in his training: What is epistemology is acco

If you tend to use tools effectively, testing is easy and enjoyable. For mobile testing there are lots of challenges and to be honest if you don't push yourself to improve your ability as every developer does you can not test the mobile application good enough. Instead of testing mobile application manually, we can automate the stories whenever the stories are prepared by business analyst with writing cucumber files and then we can start writing the code of automation and finally we can run it when the stories are developed by developer for agile development environment. This is iteration based approach, means you can repeat this steps for each iteration. At the end of the milestone you can run your whole automation code and see the result. For the remaining time you can still test application by using Exploratory Testing techniques to find-out any bugs.  The important point is to make your job effective and efficient. For this you should automate or scripted some repetiti

For a company which uses agile development methodology, test automation is very critical. However meaning of test automation in agile is little bit different from the automation activities in waterfall or V-model development methodology. In agile a user story should be automated before the feature is developed and when it is ready then automated test cases can be run to test user stories. For agile test automation, using only selenium is not enough or is not the best approach because of the written test cases. There should be another tool used for writing test cases which automation script can understand and perform what test cases/user stories explain. Cucumber is the tool what I want to explain. With Cucumber we can write test cases and with language called Gherkin which is very easy and understandable for everyone. So we just need to learn the keywords like " Given, When, Then, Examples, Scenario, Scenario Outline , ..." they are not too many, for more information a

Almost every methodological approach in software development aims to reduce development time and produce more qualified products. Continuous Integration (CI) also aims to reduce development time. Basically, CI is software development practice that developers need to check-out their codes in their local development environment and than integrate them to shared repository. According to Martin Fowler who known by his studies about CI, there should be at least one integration to shared repository done everyday, but the frequency of integration is expected to be more than one integration. By this way, test activities are performed during every integration and problems caused by the integration can be minimized. As it is emphasized in this blog , CI says us as "pay me now, or pay me more later" . If we look at the history of CI, it goes back to extreme programming (XP) which advocates that there should be frequently code merged to master to cover unstable requirements of customer

Bir yazılımın geliştirilmesi için duyulan ihtiyaçlar, geliştirme süreçleri, test ve kullanıcıya sunulmasıyla ilgili bilgilerin bulunduğu yani yazılım geliştirme yaşam döngüsü (SDLC) hakkında bilgiler bulunan sunumumu altta bulabilirsiniz.  Konu biraz farklı olarak yazılım testlerinin etkinliğinin arttırmak, başka bir bakış açısıyla daha kaliteli yazılım ürünlerinin üretilmesini, hedef alarak hazırlanmıştır. Sunumda SDLC boyunca testin daha etkin bir şekilde yer alması gerektiğinde yola çıkarak farklı yazılım geliştirme methodolojilerinde yazılım test süreçlerine ait daha fazla bilgiler bulabilisiniz. Software development life cycle yazılım geliştirme yaşam döngüsü from Mesut Güneş

Kalite denilince akıllara hemen fiyat olgusu gelir yani bir hizmet veya malın daha kalitelisini edinmek daha fazla para ödemekle elde edilebilir. Hatta bir mal ne kadar kaliteli ise maliyette o kadar daha yüksektir bilinci biz tüketicelerde hakim olan duygudur. Fakat üretim olarak düşündüğümüzde ise bir mal veya hizmeti biraz daha iyi kalitede üretmek daha fazla maliyet anlamına gelmez. Her üretici için aksayan üretim süreçleri ve üretimde bir fiil görev alanların duygu ve yeterlilikleri gibi etmenler etkilidir, yani üretilen malın kalitesini doğrudan etkiler. Bu yazımda daha kaliteli yazılım ürünleri geliştirmek için yapılması gereken bazı noktalar üzerine duracağım. Kalitenin kelime olarak anlamına Oxford sözlükten baktığımızda, her hangi bir şeyin benzerlerine bakıldığında standartlaşmış olan bir takım özelliklerin ölçülmesi, mükemmelliğe olan yaklaşımı; veya başka bir açıdan ise her hangi bir şeyin sahip olduğu ayırtedici özellik olarak tanımlanıyor. Bu tanımı biraz daha yazı

Yazılım geliştirme metodolojilerini: Waterfall (Şelale), V-Model (Validation and Verification: Sağlama ve Doğrulama), Iterative (yinelemeli) ve Agile (çevik) olarak genel bir sınıflama içerisine alabiliriz. Her bir metodolojinin kendine özel yapısı olmakla birlikte Agile diğerlerinden ayrılmaktadır. Agile iteratif yazılım geliştirmeden esinlenilmiş ve bir grup oluşumu vardır ve grubun başarı kriteri tamamen grubun çıkardığı işin kalitesiyle ölçülmektedir. Grup içerisindeki bütün üyeler deneyimli, iletişime açık ve yardımlaşmanın ön planda olduğu, plandan sapma durumunda herkes sorumluluğu üstenir. Daha fazla insan odaklıdır bu yüzden geliştirme ortamına uyum sağlamak ve saygı temel felsefesini oluşturur. 2001 yılında yayınlanan bir manifestosu vardır ve özetle Agile'nin ne olduğunu açıklamaktadır. Agile bir yazılım geliştirme metodolojisidir ve pratikte oluşturulmuş alt başlıkları vardır. Bunları genel olarak şu şekilde sıralayabiliriz: RUP (Rational Unified Process), Scrum, EP