How can we be successful in our projects?

Joining a new consulting company can be a daunting experience. You just went through one or several interviews that might have needed to refresh old concepts before jumping in, gone through onboarding sessions, and even already gone through some interviews with potential clients… And then you make it to a new project!! You get to know your new team, being aware of your capabilities and what skills you carry under your belt. You are the new guy in the neighborhood, you have a new product or products to learn, processes, team structures, and maybe a new releasing pace you need to get used to.

And besides that, suddenly, you are exposed to challenges that you didn’t expect, and that maybe even you haven’t had to deal with before. Lack of documentation, no effective communications channels, unresponsive teams, or maybe even responsibilities you were not supposed to do in that project in the first place, you name it.

The thing is, we are not alone on this, and most likely we are not the first people dealing with these situations. Really something to take advantage of when we work for a company that promotes collaboration, right?

That’s why we conducted a survey to some fella QA Wizeliners currently assigned to projects what were the main challenges they faced when they were assigned to them. After taking a look at their answers, we divided them into four main categories: lack of documentation, data access to documentation/repositories, communication problems, and last but not least, adapting to the project technologies.

If you are just fine in your current project or are not interested in reading about those struggles and how people have dealt with them, then carry on with your daily activities, but just don’t forget your coffee, please! But just in case you are interested, in this article, we bring you some of the main challenges encountered by our fellow QA Engineers at Wizeline and how to tackle them to ensure success in our projects and offer our clients the highest value we can.

Documentation

One of the most common problems we encounter when joining a new project is the lack of documentation or a non-existent onboarding process. It may be frustrating when we want to be up to speed with our coworkers, or smoothly deliver results, and we just don’t have enough information to get started. If there are already some teammates in the project, we can ask them… Well, if they have enough time to explain to us. But if we are the first or only team member in charge of the quality of the product, this task can be more complicated.

There is not really much we can do to understand the process quickly, but it can be easier if we already know what to ask for. If you need a hand in this process, you can follow this checklist:

• Understand your role. What are you expected to do? Learn the scope, duties, and responsibilities of your role. And then, with whom you can request support and unblock yourself if required?
• Do you have access to all the resources you need? Do you need access to CI tools, versioning control tools, repositories, VPNs, general documentation, test cases?
• Are you supposed to follow a specific agile methodology, is it Scrum, Kanban, XP? This is one of the first questions you need to solve. This can give you an idea of the cadence to deliver new increments, and what your responsibilities are. Don’t forget to find out who your PM, PO, or TPM are in each case. Also, you might have some dependencies on different teams, find those out and figure out what is the dependency level you have on them, remember no one is an island, we are one team.
• Find out what the requirements are, and try to classify them. Same with the test cases, if they do not have a level of importance or priority pre-established, try to figure it out.

• Are you joining a product team? Or is this a quality team in charge of delivering a service? Understand who is your client, and what type of documentation and assets you are supposed to deliver. Is it a test plan? Test cases? Maybe a test report? Or you might need to do some kind of auditing. Whatever the type of process you are doing, find out what type of documentation you are supposed to deliver. If there are no templates already provided, try to come up with your own! If you need extra help to start creating your Test Strategy, you will find this template very helpful.
• You might need to understand a very specific process of technical procedure, first find the SME (subject matter expert) of that process or procedure.
• Never stop asking if you still have doubts. You might need some time to process what you have been told or try it by yourself. But if in the end, you still have doubts, keep asking.

If any of those questions are not answered by internal documentation, it will be very kind of you to put together your own version and distribute it to other team members. You might be providing this documentation for the first time! Don’t forget that as QAs, we want to understand what is the risk of each activity. If we haven’t gotten enough information on how to mitigate or understand an item, chances are you still need to dig deeper to achieve your goals.

Keys and Accesses

Sometimes documentation is not the problem, since there is an onboarding process in your current project, you know the databases, the environments, the URLS… and every useful link to get your work done, but guess what? That’s right! They never provide you with some credentials or they are still in the works to get yours done. Anyway, you can’t interact with anything simply because you don’t have any access.

At this point, you should know the Dos and Don’ts of your role, nevertheless, we want to share with you some security tips for your current or future credentials:

• Keep in mind the principle of least privilege (POLP) is a concept in computer security that limits users’ access rights to only what are strictly required to do their jobs. Users are granted permission to read, write or execute only the files or resources necessary to do their jobs.
  Is the access that I have been granted more than enough to do my job? If the answer is yes, you are ready to QA, on the other hand, if for any reason you have access to other tools or parts of the system please raise this concern with your team, sometimes less is better.
• Do not share credentials. This may be really tempting, getting the credentials from someone else just for a while to get your work, no one is going to notice. But that’s not a good practice, actually, you and your partner can face severe consequences, the reasons not to do so are endlessly but here are a couple of good examples:
• When you share your password with another person, you essentially grant them access not only to that account but every account you own that uses the same password. One risk of sharing passwords is that your accounts get immediately compromised.
• If someone else uses your credentials to log in to an account, they will be on your account, meaning that any action they carry out will be done in your name. If the person then chooses to engage in harmful activities or access inappropriate content, it will be you who faces the consequences — and in some cases, these could be quite serious.

Even though these tips are useful, they may not be the solution to your problems. Sometimes they may begin way before: we have no clue where to start asking. But as the saying goes “One who never asks either knows everything or nothing”, so don’t be afraid to ask.

Wizeliner’s main advice for this type of blocker is to ask your teammates. Ask, ask, ask. Communicating your problems right and in time, is a way of taking ownership, one of Wizeline’s core values. Remember we are here to help, if the first person you ask does not know the answer to your questions, they will surely point you in the right direction.

Once you have sorted the access-related problems, maybe it’s time to take the initiative and create a nice “How to…” document for future colleagues who may join the project, and don’t forget to post it somewhere easy to find. Also, if your project has credentials that are used by more than one person, keep in mind to store and share them in safe tools, such as Keybase.

Adapting to project’s technologies

Another common problem when joining a new project is adapting to technologies we haven’t used before. For example, the challenge of testing mobile apps when you have been focused on testing web applications. It is hard enough to start working on a new technology, let alone if you are the only QA in the team. An easy solution would be to have a mentoring session pairing yourself with a Wizeliner experienced on this matter. In this way, you could get some insights on what to do or which information/courses you can take.

Nevertheless, there would be some situations where you have a short time to learn due to the necessities of your project, and would be difficult to find a QA resource available at that moment to help you solve your doubts. In that case, you might want to investigate the subject. That is why we want to give you some recommendations on where you can look for:

• ​​The pulse by Wizeline: This is a blog where you can find different articles updated by Wizeliners about different topics such as Consulting, Design, Engineering, and Life at Wizeline.
• Additionally, if you have some specific questions in a matter or if you want help from someone from the community to help you but you don’t know who to contact. You can use slack channel #qa to post your doubts.
• The QA community also has a really cool page in Medium. On the Wizeline QA Team page, you will find super cool articles and very useful information made by the QA wizeliners. Something good about this page is that you can find articles all related to quality assurance.

• In case you are someone fond of managing their own learning, Wizeline Academy is the best place to do it. Don’t forget you can also add the course to your LinkedIn profile once you have completed it.
• You can also take courses on other platforms such as Coursera, Udemy, Youtube, Udacity, among others.
• Last but not least, pin our communities Confluence and Google page. There you can find interesting sections that could help you with something you might be struggling with at the moment.

Communication

Communication in development teams… And their importance in QA

Communication is the cornerstone to a successful project, but sometimes it gets truncated by misunderstandings, shyness, or simply by ignoring it. All these behaviors could be very harmful to the health of the project and could also create more confusion, simple tasks or good practices could turn into a nightmare if the teammates don’t have good communication between them.

So here are some useful bits of advice that could help you improve the communication in the team, even if you are a new member.

• Don’t be afraid to ask. Maybe you’ve heard this before, but it is the most important part when you are involved in a new project. Asking all the details and doubts that you find in your way is really helpful because you are going to familiarize yourself with the project faster, and also get to meet your teammates! Also, keep in mind that Wizeliners are always open to help, remember that the only bad question is an unasked one. Asking the right questions could save you a lot of time and work.
• Be open to feedback. First, let’s clarify that feedback is not about “what you are doing wrong”, instead it could help you improve some things that you are doing fine, but could be better. Feedback also helps you to get more involved with your teammates, and improve your work and good practices, which could help you with your current and future projects.

• Train your active listening. Sometimes daily standups or technical meetings can be long and this could lead to you losing their attention… But fear not, this may be a great opportunity to train your active listening. Now you may be wondering, what is active listening? Active listening is just trying to understand what the other person has to say. Part of this involves staying engaged with the speaker throughout the message they are trying to convey. This can help you a lot, you will pay more attention to the meetings, be more involved in the dev process and the meetings won’t be boring again!
• Be clear and concise. Currently, most of the teams are working remotely, so it’s important to know how to be clear and concise while we are speaking, sending a mail, or a message in slack. Next time you write a message or have a meeting you can check and review your messages, and go through these points:
• Remove all unnecessary words: Remember to be clear and get to the point, there is no need to add fancy or extra words in a message
• Remove repetitive/redundant words: Check if your message is not repeating terms or if you are saying the same things twice, this can create confusion on the receptor of the message.
• Use plain simple language: Most of the time, we use technical terms that not everybody understands, remember that in a development team not all the areas have the same terms or meanings, so try to use simple language that even a person outside the team could understand.

Now that you know everything you can do to achieve a successful project, the rest is up to you. Don’t forget to share these tips with your colleagues if you feel like they may be useful for them. Happy testing!

Authors

Ana Belen Garcia

Diana Aguilar

Diana Vázquez

Montserrat De la Cruz

Hector Hurtado

Luis Melchor

Carlos Veloz