![]() You need to keep in mind that you may be much more experienced using the software than many of its future users. Don’t make the mistake of just performing ‘blue sky’ testing. Lastly, try to focus on the USER of the software under test. They can help you understand where and how to look for defects. Those defects you have been studying (you have been studying right?) will be very helpful in this area. Having the ability to perform ad hoc testing (testing without a script) can provide you the ability to cover program paths previously untried. I have said earlier that most first year SQE’s know the basic test types. While not strictly about strategy development, you will find this knowledge helpful when performing ad hoc testing. Don’t say, “well I don’t have the time to do this.” If you study closely, you may advance your skills quite a bit faster than if you had to develop the defect writer’s perspective on your own. You will also find defect reports that many would ask, ‘how the heck did you even find that’. You will find many routine defect reports of course. What were the methods used to reproduce the defect? Many of the methods used will likely be transferable to other types of testing. The reports will invariably give you insight into how the analysts think about testing software which may help your strategy development. You can use the tracking product’s search or report function to narrow your view. ![]() Go into your defect tracking product and study the defect reports written by those analysts.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |