Geek of QA

Traditionally, software testing teams always focused on functional and system verification of the product. While this is good in terms of gaining confidence in release readiness of your product, it may not help answering two important questions: 1. What product has is what customer wants? (Requirements traceability) 2. Focus on customer use-cases So how to fix those issues? Behavior Driven Testing (BDT) holds a key! So what is BDT? In the simple terms, its a derivative of Behavior Driven Development (BDD) methodology. The idea behind BDD is to enable use of ubiquitous language, called Gherkin which lets you write all your artifacts in expressive english. All software development projects starts with capturing of requirements and it is usually done by business analysts. When requirements are frozen, designers & developers create user stories for their development sprints. QA teams create test cases for their verification. Traditionally all these artifacts (highlighted in bold) ar

While, it is ideal to start performance testing as soon as there is a confidence in stability of the system under test; that shouldn't be an entry criteria always. With that being said, doing performance testing after achieving the desired stability will keep the testing outcome clear and precise. In case of modern, distributed systems; doing performance testing at independent component level shall be right thing to do. For example: Backend can be tested for its overall response/latency measurement and GUI can be test doubled and verified for its overall responsiveness under various conditions, which you can create in your test environment (Ex. high latency network links, slow responding backend under certain load conditions etc.). This strategy shall give you the performance assessment at individual unit level and its good to know baseline & benchmark of each of the component. So when you run end-2-end performance tests after integration, identifying bottlenecks could be relat