This question had raised in Lean coffee session at the TestBash. @FriendlyTester was kind enough to share th list. Thank you for that.
As soon as I saw the topic, I thought I should collect my thoughts on it. I too have faced the challenge in every company I had been and was able to overcome it as well. I believe these are common experiences of many others but here goes.
Learn the product by asking questions
I was a software developer before back in the era where we used Visual Basic , and then I thought testing is fascinating and wanted to change my career and never looked back. Ever since when I joined new companies, role of the tester was not recognized or either recognized but not taken seriously . We testers sit at the back of the room where cool kids – the developers, architects and business analysis take the lead.
I was never happy with this. I am a person who ask questions until I understand what’s going on and do not wanted to be ignored. The first few months of a new job can be the almost crazy time period for me because I question everything. Applications and documents does not reflect the tacit knowledge the team have. For them that piece of information is just another funtion. That how it work. That function behave because of this business rule. No team realise how much tacit knowledge everyone have until a new team member and question or say I do not know about that or show you a blank face with lot’s more questions. Induction sessions may contain too much information at a given session or the sessions may be not detailed enough as you want it to be. There is always something unsaid. Therefore always ask questions. Make sure you understand the application and its hidden rules.
Learn the product exploring
I want to be the person who everyone ask questions from. Every time I go to a new project I want to learn and want to know everything around if. I want to know how code looks like, how to control the application with configs, feature flags, how database tables look like. I do not want to be in a meeting room without knowing how to question the requirements or the solution, whether the discussion is on topic or off topic, why that person asked that question. I want to be the person who have almost all the answers or the person who may translate the business requirements to technical wording and vice versa. Therefore I try to learn these things by myself. I learn more when I explore. I get to see how the application works and get the detailed understanding. Explore and expand your knowledge.
Every time if someone doubt my abilities on my skills, responsibilities and credibility I always want to prove otherwise. Example, I worked on a project about statistics and I wanted to know more about database tables other than the stored procedures given. This was questioned by the technical lead and didn’t want to give me access to the database as it was an unnecessary complicated task that I won’t understand. I somehow got the access and explore the tables and understood how data stored in different tables, relationships and this helped me to find more issues that not only helped us on delivering a quality product it increased my credibility on the project as well.
Manage your stakeholders
Understand your stakeholders and develop a good relationship with them. They help you to understand the product from a different point of view. This always helped me in discussions as it helps me to see the bigger picture. Know how all the different components comes together is an advantage. How sales, marketing, customer support use the application and about the other supporting applications sometimes are over sighted. By talking to the stakeholders and be interested on their job role always helped me to think outside the code and its rules. This knowledge always helped me in discussions.
Get involve in requirement gathering sessions
There was a time that I see the requirements first when development completed. Testers were not part of the requirement gathering sessions and almost projects did not understand the value. When I get the piece of function to be tested that I have no knowledge of before to understand the requirement and what the functionality does I ask questions. In many occasions it was understand that requirements may be missing or mis-interpreted by the time it reach the testing. By joining the initial meetings and I was able to share my understand with the rest of the team to prevent issues before the requirement reach the implementation stage.
It is always overwhelming when team members doubt you for what you are because you are new to the project and because everyone do not know you. Always your actions makes you who you are. Go the extra mile to learn more about the project and how its being used. Reasons behind the features and why it is built under the given rules and but not otherwise. Be confident on what you know and be responsible on what you do not know. Learn and feedback as soon as possible. Help others to understand the areas that others do not know. Get in to meetings and ask questions. Explain the business reasons behind the implementation. Always stand out. Your voice will be respected.