Test writing Guidelines

In one of his latest blog entries, a friend of mine writing a blog regarding system engineering discussed the basic design questions When thinking of how to start writing a test plan you need to make sure that the said test plan provides answers to certain questions which are very similar. 1. What: what is the system supposed to so? - Functionality in general 2. How: what are the steps for the above mentioned ? Functionality in detail 3. How much: basic estimation of capacities / throughput. - load and system benchmarking 4. When: when do you want the solution? * we need to cover the first 3 questions if we are to write a full testing specification. When approaching the task of writing these tests we should not contemplate about the feasibility of the tests but rather create what I like to refer to as a "Tests wish list" only after covering all relevant aspects of the feature / component / system and reviewing this can we ask and answer the last forth question - In an idealistic world time is not a factor but in the real world we need to take into consideration the following: * delivery commitments in respect to dates or content - which may affect the order of the tests * simulation capability - on systems handling external inputs ... can we simulate this type of input / how much will it cost us? and so on. how ever the pure test plan should not include these aspects since making allowances in the test writing phase will lead to not testing the system.

Virtualization and its contribution to QA

There are many benefits to using virtual machines in testing. First, we need to bear in mind that applications change, and QA must test different applications in different conditions. for example testing different UI applications on different host types will potentially require a lot of resources which in these times of financial instability may pose a problem, since theoretically, it will require separate machines for each type of set-up, in the same manner when keeping a big version install the base you will need to maintain different machines running different versions of the SUT (System Under Test). In order to provide for this need one of the best cost-effective solutions would be running multiple virtual machines. This solution allows for running endless versions in parallel... this is effective for both QA and Support since one can simulate defects/ retest them knowing with full confidence that his system is identical to the one of the customer reporting the problem. further to this virtual machines can be used to allow easier/ simpler deployments or upgrades, since you can send the machines preconfigured in advance from the factory. As can be seen, there are many advantages to using virtual machines in QA.