QA

One of the first projects I worked on at TMW was doing Quality Assurance (QA). This process includes testing new product development in order to make sure they work correctly and trying to find bugs in current products before clients do - for every complex software has bugs. Since there are a plethora of items to test, especially right before the end of a sprint, testing can be made easier for QA by developers making "QA Docs." Hence, our on Dev Team creates a document on how they test a code update, so then the QA team can just review the document and can quickly test it on their own.

This was a great way to ease me into the company for I did not have the immediate pressure of diving into coding, but I was still getting familiar with the products, and more specifically the interfaces my team develops. Thankfully there was a template I worked off of to start my QA doc and simply used the snipping tool to highlight which parts of the product I was interacting with in order to test. The point of the QA doc is to express a thorough successful (or failed) test as if you were a user, separately from the developer who coded it to ensure that the component works in multiple different scenarios.

View the snippets below to see some examples of my QA experience (all TMW products are public)

During the process of doing Quality Assurance, not only did I get great exposure to the complexity of TMW'S Products, but also I believe that I helped the programmer practice a simplified explanation of their development that helped with demos, as well as adding thorough client perspective on the QA docs from being a novice with the usage of the products.