ALT-2 How to become a Software Qa Expert
This is to be the first in a series of articles on how to move from being a novice or average QA engineer to being an expert QA engineer that is an indispensable member of a development team. This article will contain some broad generalizations with future articles going into much greater depth on each area.
As a former QA Engineer and a QA Manager I have worked with hundreds of people that have the title of QA Engineer. Not surprisingly the level of knowledge among this group ranges from the novice that has no idea what they are doing to the expert that has spent years honing his or her craft and has earned the respect of their peers within the QA community as well as the developers they work with.
Often one hears about the adversarial relationship between developers and the quality assurance team. It is important to understand that this is because as a QA engineer joining a new team you are very unlikely to get any respect from the development team. This isn't because they don't like you but rather because they have met many of your kind before and many of them have undoubtedly been incompetent. Fortunately for you this stereotype is easily broken if you know what you are doing.
Your first goal should be to learn all that you can about the business domain and the software being created. Developers often have pieces of the puzzle but do not understand the system from end to end. As a QA engineer you do not have that luxury. If you want to be a QA expert then you must know the system better than anyone. If you are doing your job right you will be the one people come to when they have questions about how or why the software system works.
In addition to knowing the business domain you will need to truly understand the software development life cycle in a deeper way than you probably do right now. It is your goal to inject the QA team into the process as early in the SDLC as possible. By attending design meetings you will be able to discover areas of the software that deviate from the requirements long before the code is ever even written. You should know how to write requirements. You should know how to write code. This is not to say that you need a four year degree in computer science. When I started I had never written a single line of code and now I write the programs I used to test. I invested in these skills because I wanted to be a software developer but what I learned along the way was that these skills made me a true expert in testing. I had an understanding of the system and the process on a level that no one else around me did and that knowledge earned the respect of those I worked with.
