8

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.

Improve this question
3
  • Voting to keep this question open. Choosing between the two options might be opinionated, but answering how to handle yourself in a new job where on-boarding and documentation sucks is not. It might differ per culture and industry, but all answers can be very valuable information when starting a new QA job in a chaotic company. – Niels van Reijmersdal Aug 12 '17 at 7:34
  • 1
    Who are these leaders that expect you to "be on board right away" - if they fail to understand how long it takes to on-board an employee they're rather poor leaders. – corsiKa♦ Aug 12 '17 at 7:50
  • @corsiKa By naming leaders I mean a group of people that are sitting "upstairs" and who is expecting only positive results from the development/QA team, not even caring much about the whole infrastructure. Those people usually think that their company is the best in the world. – Tired Of Testing Aug 14 '17 at 14:29
4

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.

Improve this answer
1
  • I fully agree with your opinion @Niels van Reijmersdal. Get to talk to key people for about 30 minutes is a very valuable time to understand business logic. But currently I'm struggling with my new position as it's summer, and all key people are on "workations" : meaning they are sometimes on the call, but not to discuss your on-boarding knowledge gathering. – Tired Of Testing Aug 14 '17 at 14:33
5

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.

Improve this answer
3
  • I like your point and it's absolutely right that we need to collaborate more with the leadership or supervisors on any impediments. The problem that I notice sometimes is that most of the team members are so busy they can't really help you out. And once it comes to explaining new things for new comers it sounds like a struggle for them. – Tired Of Testing Aug 11 '17 at 17:28
  • @GordonFreaman I hear you! We had a lot of new hires over the years and there were multiple occasions when we had to explain some undocumented things, tricks and pitfalls - oftentimes this led to us improving the documentation and our onboarding instructions. I personally enjoy mentoring new hires and showing them around our projects and infrastructure - I look at it as an opportunity to brush up my understanding of how things work in our company and, you know, there is always room for improvement. I guess, most importantly, a newcomer has to be a very adaptive observer at the beginning.. – alecxe♦ Aug 11 '17 at 17:34
  • 1
    I like the idea of documenting your onboarding. :) I do question how clear "what you were hired to do" often is. My personal experience is that I have to create my own job, find quality gaps, focus on improvements. You might thing testers are hired to break the system and write checks, but I think doing only that is a waste of time. How do you deliver "building the best system" and "preventing defects" from the get go? – Niels van Reijmersdal Aug 12 '17 at 7:31
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.