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. Understand the defect writer’s perspective on testing which might help you do a better job.ĭetermine the very best analysts in your department.Revealing previous unknown relationships between functions that you hadn’t thought about.Help you prioritize your test strategy.The newest components (unknown reliability).Relationships between similar functions.The most/least error prone parts of the software.You will be astounded what information is lurking in this area. The third tip, was to survey defect reports of existing or similar components or applications. I also interviewed these analysts about why they included what they included in their strategy documents. Talk about a goldmine of ideas! The study of these saved me at least couple of years of self learning. That included any strategy documents or position papers they might have written. If I wanted to understand how an experienced analyst thought, it would make sense to read their writings. The second thing my mentor told me was just a suggestion. Importantly, if you can get a copy of the database schema that can be very helpful to creating your diagram and understanding the data flows. Keep it pinned somewhere so that you can update it and refer to it often. Even a rudimentary drawing will help you see relationships that might otherwise be missed. Whether you use pencil and paper, white board or sticky notes, it doesn’t matter. It was unusual for me to see analysts using this type of tool. The combination of studying data flow information, database schemas, and the application workflow (UI) helps complete your picture.įlow charts and similar documents are basic tools for architects and developers. Not necessarily a flow chart, rather a block diagram laying out all the components/functions and any of their integrated relationships (including data) that I was able to discern from documents and interviews with the product stakeholders. The first was to draw a picture of the system under test. My mentor taught me several important skills that changed how I performed my job. While this was to be expected, many ‘captures’ were too late for my taste. Many of these ‘misses’ became clear after multiple iterations. While his guidance was extremely helpful, I was still frustrated by the things I was unable to capture initially while developing my test strategies. I was fortunate early in my career to work with a very experienced analyst. One of the most difficult or frustrating things for the new analyst is acquiring the analytical insight that comes from experience. Using Diagrams and Defect Reports to become a better analyst and miscellaneous soft test strategies.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |