incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijayendra Bhamidipati <>
Subject Review of QA test plans for full clone feature (CS-670)
Date Tue, 19 Mar 2013 01:32:22 GMT
Hi Prashant,

This is a review of the QA test plans you put up at

Test Id: 2
In the steps, please change the table name from vm_clone_setting to user_vm_clone_setting.

Test Id: 3
In the expected results, please add the following:
	2 - Confirm that a new entry has been added to the user_vm_clone_setting table, with the
clone_type set to "linked".

Test Id: 4
Same changes to be made as in test id 3, this time checking whether the clone_type is set
to "full".

Test Id: 8
I think it would be good to specify the steps more granularly, mentioning that the global
flag is set to true first, then creation of the full clone is attempted, and before step 5,
the flag is set back to false and step 5 is attempted. Would help novice readers.

Test Id: 9
Need to change the db table name to user_vm_clone_setting. In general, it would probably be
a good idea to split those steps and the expected results so that they don't appear mixed.
I know it would mean more typing but it would add to coherence. Just a general observation,
you can do it if time permits.

Test Id: 12
In the expected results column, add a check to ensure that a duplicate entry is not made in
the user_vm_clone_setting for a vm id. This is because when a VM is destroyed, the corresponding
entry will not be removed from the user_vm_clone_setting table. This is intended by design.

Test Id: 13
" 1-vm created in step 3 should be expunged successfully" - when you're not destroying the
full clone, why do you expect it to be expunged?

Test Id: 14
In step 6 - are you referring to the vmdk file or the template? If you delete the template,
I don't think the VM should be affected. If you delete the root disk however, the VM would
crash. In the results column, the wording needs to be changed to "root disk".

Test Id: 16:
Why would you want to do this? The change in the value of the global flag will not be recorded
until the mgmt. server is restarted, and there is no direct relevance to this feature in restarting
the mgmt. server while the user VM deployment is going on - that would be more like testing
failure scenarios in vm deployment - anyway if you need to test it, the result will be that
the VM being created will be a full clone (and you must confirm that by checking the entry
in the user_vm_clone_setting table for that VM id). After the mgmt. server comes up again
with the flag set to false, any new user VMs created must be linked clones. Similar comments
for Test id 17.

Test Ids: 18-21:
If the host is put into maintenance mode, and/or the VM is migrated, it should still be a
full clone or linked clone as it was before the migration/maintenance. Same if the host is
put out of maintenance later on. The VM should not be affected in any way w.r.t its clone


View raw message