QA Books List: 2006

You have gathered requirements from clients, identified key critical business scenarios, analyzed the workload distributions, found out performance goals and requirements, identified tool for generating load, setup the test environment, designed the scripts, executed the performance run, collected the raw data, analyzed it, what next? Send information to stakeholders? No!! Wait!! It needs to formatted, customized for different stakeholder(s) and reported accordingly. This article suggests one of the ways to report performance run results to client especially if the performance testing activity has been outsourced to yours company. It discusses the performance report template and importantly the reasons for including the items in the report. The performance report template contains information by data collected from client side only and doesn’t discuss / talk about data from server side like processor utilization etc. Broadly the performance report has been divi...

Test Case Template for Project Using Agile Methodology

November 04, 2011

User Story One template that can be used while writing user stories could be – “As a (role) I want (functionality) so that (benefit).” For example – As a ‘Bank Customer’, wants to ‘Transfer Funds’ to one of their friends / acquaintances online, which is fast and auditable. Or, the user story could be described as a single line item (2-5 words) as well. For example – Fund Transfer Test Cases Few of the test cases (summary) for above user story could be as follows. These test cases should be developed with the help of Business analyst. Transfer fund when fund is in range of acceptable limit and existing balance is sufficient. Or, Fund transfer amount less than existing balance Transfer fund when fund is in range of acceptable limit but existing balance is not sufficient. Or, Fund transfer amount more than existing balance Transfer fund when fund amount is beyond acceptable limit. Or, Fund transfer amount more t...

Best Practices for Unit Test Case Automation

May 17, 2013

Make each test orthogonal (i.e., independent) to all the others Any given behavior should be specified in one and only one test. Otherwise if you later change that behavior, you’ll have to change multiple tests Don’t make unnecessary assertions Which specific behavior are you testing? It’s counterproductive to Assert() anything that’s also asserted by another test It just increases the frequency of pointless failures without improving unit test coverage at all Have only one logical assertion per test Unit tests are a design specification of how a certain behavior should work, not a list of observations of everything the code does Test only one code unit at a time Architecture must support testing units (i.e., classes or very small groups of classes) independently, not all chained together If you can’t do this, then your architecture is limiting your work’s quality – consider using Inversion of Control Mock out all external services and state Yo...

Search This Blog

Tech Notes