New Hire: lack of documentation vs QA velocity

Question

I've been thinking to raise this question long time ago since I ever started my career as Software QA. We, as IT professionals (that's how I consider us, regardless of the education level) are always facing challenges at work no matter what kind of environment / sort of company we work for. I'm sure on the fact that there is no ideal company in the world where IT department works as smooth as Swiss watches (and we can argue on that probably in the different topic). Slow environments, misunderstanding in the requirements, broken dev / qa / stage builds, late night deployments....you name it. My understanding of being in the industry for over 6 years is that there is no way to escape those situations, nevertheless every team member has to try to minimize them.

The topic that I would like to discuss today is about QA team members, that join new companies. I know that almost everywhere there is a lack of proper documentation (sometimes it is missed at all) on the working projects and usually it takes time to get to understand business logic and infrastructure of the environments. Well, time equals money (that company pays you) and leadership expects you to get on the board right away. But the other side of the coin is you, as experienced tester with the great reputation and feedback shown in the interview, also would like to step on that moving train and display all your best practices. My opinion is that there are 2 cases:

1.Ever since your first day you stay calmed and relaxed. Not disturbing anybody with the "proper" questions about where do download this and that or whom to ask on application/back-end access. You witness some bustling going on around, just trying to listen to people and get an idea from here and there. PROS: Everyone in the team likes you, considers you as a cool, respectable, gentle and easy-going person. CONS: Even in couple of weeks being at the new position you barely understand what is the project about, who is responsible for what, and when the hell I get my workstation and security badge.
2. You start as a crazy horse. Get everyone with the questions on your every concern. Destructing manager every morning stand up on your today's tasks and goals. Standing by DB administrator cubical till he finally provides you with the access. PROS: Within probably several months you start showing good results on the test case coverage / automation scripting. Already have a decent understanding of the projects and their interconnection with each other. Leadership start seeing you as a potential management person with the right skill set. CONS: Everyone hates you for being annoying, bypassing you at every possible chance. No answered emails and Lync messages, everybody is busy when you are in the visibility zone.

My today's question is: what do you consider as a right approach or may be a right consensus in assimilating at the new company with the poor documentation? Thanks.

Answer 1

I guess you should want to find a balance between both options. You don't want to work really hard and go crazy, but you want to find a sustainable pace. I would prefer to start a bit slower and act more as an observer, but I do think being open and honest about what you see is important. Having a proactive attitude is also key for your long term success.

If the documentation lacks, you do need to question people. As a quality person I like to have 30 minutes one-on-one interviews with some key people. Think of users, developers, other testers and managers. Trying to understand how everyone is using the system, where the biggest gaps are, what risks exist and how the company makes money. As a new person you are still an outsider. It so much easier to see the blindspots in the processes. It is possible to get information without being annoying. Just becarefull with how you suggest changes. Seek first to understand, then to be understood. Question how did this process came to be? and have you also tried other options? maybe this one I am thinking about?

I do not value documentation very high. Self-study is not as good as hearing real things from real people. Also documentation (even if it was good in a certain point in time) will always be outdated.

In your first weeks at a new company it is all about learning. Learning the business, the systems, the products, the people. Take a bit of time. You do want to add value as soon as possible. See if you can pair with others on what they are working on. Start working on things you seem to understand, but do make a lot of time for learning.

Answer 2

Assuming one cannot start as a "calm and relaxed horse", and we have only these two options, I would focus on starting to deliver as quickly as possible - at the end this is what you were hired to do.

If there are factors that prevent you from starting to work, this is not your problem - this means that there is something wrong in the company's onboarding procedures. I would make sure to let my supervisor know in which state am I currently in and what prevents me from doing my work. Of course, this should happen in a professional and polite way.

It may also be a good idea to make notes or document your onboarding story - you may then present your experience to your team or supervisor in a sense of what went great, what was clear, what not and what could be improved. This way you may contribute to improving the situation in the future.

Answer 3

Use BDD (Behavior Driven Development) to write human readable tests that describe how the system works.

These tests then act as easy to read technical documentation

As for passive vs. aggressive (to sum up those sections), well yes those are extremes you've described and as with most such things you want to be between them. I would say probably closer to the second option is the way to go - many constant questions. However to avoid your description of being hated you'll need a ton of tact, patience, listening first, praise of others, manager investment, etc. Usually takes experience / maturity.
Sometimes everyone wonders what something means and it takes someone to break the ice and ask. Don't assume you'll be hated. Be respectful. Be careful not to dominate. It is also true though that you are paid to generate value and not paid to make friends.
The wisest people admit ignorance freely and love to ask lots of questions. Do it politely and you may be looked up to as a leader in the right culture such as the one I'm trying to cultivate.