Starter kit as QA Engineer
When I was still young, although I am still, depending on what year you are reading this. I thought that having a job was all in rainbow and stars. When you work then you will get paid. That’s how I live for almost 3 years after graduating college.
Then one day, I realized that I want to do more things than what I am doing before. So I applied for a developer job but got accepted as tester (QA Engineer) instead. At that time, software tester was probably not necessary. Since developer was also doing testing and everything(the term right now is full stack engineer).
It was a good opportunity, I accepted it and joined the software development world. At that time, my life change to 360 degrees. Yes, the work concept is still there. You will work you will get paid. But I wasn’t able to prepare myself that sometimes in your dreams or in the shower, the solution will pop itself.
What is QA Engineer
I did not know anything. Literally, nothing. I just accepted it because it was a good opportunity to try new things. During those times, I can only rely on Google which is also a starter at that time. So sometimes there are no answer to your problem and you need to solve it yourself. So again, how did I managed to learn the roles and responsibilities as tester?
Here are my list:
- Key value of a tester
- Responsibilities of a tester
- Test a system manually
- Create a test cases
- Find bugs and report them
- Communicate well in the team
These are things that I needed to learn in order to be where I am right now. The keyword is to “understand”. It might be hard to understand at first especially when you try to test a system without a manual. Next, I will go through all of the list above and give a brief explanation each.
Key value of a tester
The key value as a tester, is that we need to ensure that the application or system. That we provided to a user will have an easy to use interface and smooth transaction on their operation. Also, we need to able to understand the developers ways too. Not too technical, just enough to see how things will work in order for the application or website works well.
We will be what we called “first-hand user” at the same time as “developers interpreter”.
Responsibilities of a tester
As tester there will be a lot of responsibilities. As for me, the list below are the things that I need in order to become a good tester.
- Able to think as user – what kind of scenario’s that user might take or other crazy user will do.
- Able to create your own test cases – in this industry that’s full of standards. Yet creating test cases does not have one. Each company have different formats. So it’s the best that you understand what are the necessary for test case and create your own. If you do, it will be much easier to understand the next time you seen unfamiliar test cases formats. Creating your own test cases will make it easier for you to create a bug list too.
- Know how to detect bugs – the main aspect as tester. You need to be able to find bugs without being biased. Since we are part of the development process, we are prone to it.
Test a system manually
When we start working on a project, we tend to do everything manually. Since we are trying to recreate the steps that the user might take. As I wrote earlier, we are first-hand user. It means, we don’t need a manual documents to test a certain application or website. Unless the company will require us to do so.
By having no manual or things you need to see before testing, you will not be biased. Just always think as user, and try all the possible path and operation that a user might take.
It’s okay to break the website or application from time to time while testing. Just make sure that it is a QA environment though.
Understand how to create a test case
Writing a test cases for the first time will be hard. I did have a hard time creating one. Especially if you don’t know what are the items that will be needed. I’ve created just two things on how did I successfully created one.
- If your company doesn’t have one. Then create a test cases based on your understanding and for your ease of use. You can explain it to your teammates later. For me, this is the effective way in creating the base of test cases in the company I worked for.
- If they company have a based test cases. Then understand it and if there’s a room for improvement then suggest it. Prepare yourself to explain why you think you need those improvements.
Find bugs and report them
Finding bugs is something fun for a tester but a hell situation for developers. I’ve seen a few of developers and testers quarrel about these things. These how I define the situation when I saw that.
- When tester reporting a bug, it was more on finding faults of the developer works more that the system itself. As a tester, you need to remember without the developer our jobs won’t exist. I am not saying that they are always correct, but they know the program more than we do (logically speaking). So, just listen and analyze the situation. If you still think it is a problem, then gather evidence to prove your point.
- Developers was so sensitive on tester’s comment and sometimes explaining things he can only understand. Developer should also remember that not all tester are technical. We are here to help stabilize a system not on anything else. We should help each other as a team.
These are some of the usual things you see when you join in this department. But you need to remember that as a tester, we need to understand both user and developers. Since we are like the bridge in between those two people.
Rules when reporting a bug:
- You need to test it twice or thrice – make sure that you can replicate it few times. I’ve seen few of tester doing this kind of thing. Please don’t do that, try be considerate to each other and it will make the development progress smooth. If we can even provide the console log or where the problem is, it will really help a lot.
- You need to write test cases steps – yes, steps. User operation steps. Explain it in details, what screen, steps, expected and actual result. Please don’t just put a summary or check list.
- Screenshot and video – it is a requirement to attached a screenshot or video to make it easier to understand. There are bugs that is environment based, data-driven based and etc. So just to make it easier for the developer and other qa to replicate it.
Understanding how to communicate well in a team
Every company that I went to, they always says communication is a key to smoother projects. As for me, “communication” is a broad word. Each person have a unique style of communication when interacting to others. I will just list 4 types of communication types that I read somewhere but I forgot the link. The description is mine though.
- Passive – a person who love peace
- Aggressive – a person opposite to passive
- Passive-Aggressive – a person who struggles between her/his inner-self.
- Assertive – a fair negotiator
Looking at these list, the key communication is being “assertive”. Where that person can freely express their own needs, desire and feelings while also being considerate to others. By being an “assertive communicator”. We can aim for the balance of each person within the team which will lead to a smoother transaction. So next time, somebody tell you that “communication” is a key. Ask them what type of communication they are looking for.
Having no experience as QA is a lot of work. You will feel a lot of times giving up especially when you want something to improve to yourself. The road maybe rocky road right now, but always remember that things will always get better.
That’s it for today’s blog, see you on the next. I’m off