Starting out as a student of Information Technology, but never when I was confident enough when thinking after graduation will find yourself a job related to the field of study. Basically, I am not good at writing code, I am afraid of code, but most of the time, when I asked for a job, it required good coding ability. Until one day I was very sharp with QA (Software) / QC. At first, when I learned about this industry, I saw all the information like this job without knowing the code, doing so idle, playing around with Dev products and finding bugs, defect reports, simple applications. Simple, easy to do, anyone can apply, or do not need to learn IT but still can do it, … Yes and I believe that until I went to the interview, I suddenly realized that it was just a part of the statement. subjective of a few who are already proficient in the profession. So after the bruising times, all the time up and down failures, I was sitting thinking, rearranging the questions when the interview was asked, studying more thoroughly, and thoroughly from which to draw experiences experience to determine the success of the interview. Probably fortunate to have smiled at me when I was finally accepted into the position of Sun’s QA , after more than two months of probation, thanks to the enthusiastic guidance of the leaders and colleagues, I discovered a few The interesting thing about this job is that I would like to share it with everyone, hopefully useful as well as cheering up those of you who are or will intend to come to QA. *
Define goals before testing and don’t just test:
- I remember the first interview, the first question I was asked was, “What do you think is Tester, and why is it necessary to Test”? Until the interviews after that question is always an important premise. And now that question is always in my mind, whenever I accept the task assigned by Leader, the first thing I do is to remember that question. Why is that? This is because when you want to become a QA / QC you must always understand what you are doing and will do, contribute to completing a product or finishing a successful project. Understandably to answer that question, you need to identify the goal when receiving a test for a product – for example, an application, not when starting the work, you dive into finding the wrong application. Use, find ways to dig errors, instead, put yourself in the position of the user (user), spend some time to use the application in the most honest way. Figure out what the target application wants to bring to the user. When you understand the goal, the purpose of use, you will be able to understand the goal of each feature individually. Once you understand the intricate details of your applications, then you will be able to plan your test effectively with a very effective test scenario.
- When your goals as testers fit the goals of the application, you will be able to bring great success results.
- A QA is always capable of multi-tasking, it sounds a bit confusing is not it, don’t worry, the multi-tasking mentioned here are all the strength of skills that a QA needs to identify and cultivate. increasingly self-development. For example, when assigned tasks, you need to determine the priority of each task, when embarking on the task you need to determine which issues need to be addressed first, you cannot just follow instinct and make Everything is messy, then you will be very difficult to complete the work with high efficiency, instead you need to consider carefully and arrange the order according to the priority of the job. Besides, you need to practice thinking brainstorming and constantly ask yourself questions about the object you are testing, such as: How to understand customer requirements, to understand changes are done during work, to identify which is bug and need to fix, … all of these questions will make you think continuously, and quickly determine what you need to do and do as how. This helps you to create a large number of bolder, interesting, and more interesting ideas for work. You also need to be able to analyze, analyze data, and be passionate about experimenting, so you can relate from what your app or project is related to. You have a broader view, and help you think about creating more authentic, more accurate test cases.
- The working environment of my company focuses on the elements of Report – Contact – Discuss, so it helps me to develop reporting skills when working. Do not think this is a difficult and forced request. A QA does a good job of getting the job done when you finish the job, you show the exact results you achieved. It means that in the process of working, you need to regularly communicate, share what you are going through with the project team or closer to your Leader, this skill will help us always be proactive in work. especially when you encounter obstacles, instead of being alone with the mess, if you speak up your problems, surely people will understand and not be afraid to help you troubleshoot. You also need the skill to be able to report negative things in a positive way, but that doesn’t mean making things blurry, which means that you need to have a positive, adaptive attitude. the problem and clearly state the main issues that help to solve the problem better.
- You need to be a sociable, flexible individual with good communication skills and be able to support whenever other members need help, a successful project not just for an individual, but for them. We work as a team, we are a team, we work together to find solutions when we have problems and need empathy to understand more, create a sense of environment friendliness. Working will be more professional and effective. You should also practice the ability to learn regularly and quickly grasp the knowledge and constantly improve learning. Becoming the inspiration and model you want is the motivating factor for us to always build and improve ourselves for the better every day. And the most important thing is to always try to think in the direction of the customers, which will help you have a more complete view of their requirements, when you put yourself in the position of the user, you will There is more than one desire, and it is the benefits of the user that will help you to test the results and the results will be as expected. Contribute to the success of the project and the team dog.
How to when the Dev receive the ticket and still have fun?
- So far, the relationship that has always received the most attention in the project team is between DEV and QA / QC, it is not natural that people often take the topic of the opposition between Dev and QA. Actually this is a very understandable problem, for example if you put yourself in the position of the Dev, when a function is spent day and night efforting the code, so that in an instant can be broken, because QA report bugs / defect, they might be very angry, and sad. And of course, it leads to a conflict when the Dev thinks that it is a feature and QA thinks it is a bug. So what do you mean by yourself? To avoid unnecessary arguments, as a QA, think of the psychological factor first, always bring a spirit and the goal is to contribute to building a quality product, Don’t make a harsh statement, it is easy to affect the psychology of the recipient and easily cause tension between the two sides, and so we need: This is an interesting illustration of our bug discovery
- In terms of test cases, when writing, we need to clear the main requirements, stick to customer requirements, initial steps to test the function or module, avoid the case of unclear test cases, leading to false identification. or omitted, until encountering a problem that would be controversial with the Dev party.
- Avoiding log duplication of bugs, you should minimize this problem, a few times it will cause dev “lose confidence” in you, and take the time of both parties. Therefore, it is necessary to carefully check and filter information before logging a bug, a few dozen can remember it, but when it comes to hundreds, it can not be subjective! And remember that each bug / defect should only focus on one problem, so you use a ticket for many things to express that will confuse the recipient when reading the information and do not identify which factors are important and need. handle now. So, you need to avoid this!
- In terms of log ticket bug / defect, a complete, accurate and specific report bug of each item’s content will make bug replication easier and more convincing. So what is a complete report bug, I would like to share with you details on how to log a bug so that when they reach Dev, they will still be happy to receive and fix the bug. A report bug contains the following:
- Title of the ticket: extremely important because this will be where the developer pays attention to initially identify the bug / defect, including the location of the bug (here specifically the screen, function, …), description describe the error you need to write briefly but easy to visualize or determine the goal of sending, through this title Dev will partly understand the bug you encounter and visualize the fastest: Eg: [Bug / Defect] [Screen X] Display screen default is wrong.
- Pre-condition – Description: This section will be where we define the test environment, the test account, the device, the test time, etc.
- Step to be executed: This will be where you re-present the exact steps to reproduce the bug / defect you encountered, absolutely too wordy, but easy to understand and the Dev can follow it to reproduce correctly.
- Actual result: Is the actual result, also known as the result you get when testing. This is where you confirm the bug you’re experiencing.
- Expected result: The result you want to get, or the exact result.
- Priority / Severity: This is where you determine the priority to fix bugs, important bugs urgently needed or this ticket needs to fix but not yet right in this release, …
- Evidence: This is where you can add illustrations, videos, … to describe in more detail the bug reproduction. You can also provide further evidence about the design and spec to specify the correct requirements for the desired test results
- In addition, you also need to tag the bug, to classify the bug (bug type), this is also important in the process of conducting the bug / defect fix. In addition, you should also check more closely on other test machines to make sure it is not only having a problem on each of your machines alone, but on others’ machines still no problem. Make sure this bug is reproduced.
- But so you can be confident in yourself, believe that when the Dev received a ticket from you will be happy, ready to receive your contributions. There is nothing called hate or scowl when QA understands and sympathizes with Dev’s efforts, thereby helping the two sides relieve tension of sustainable cooperation and the destination is more successful than expected.
Above is what I have been taught and instructed during the last trial period, all that I have rightly concluded is from the dedicated guidance of my sisters and colleagues. And most importantly, I find inspiration and motivate myself to try harder, build and develop the skills I need, so that I can strive for the goal of progressing further in the Karma. I hope you will find your goals and work ideals, and succeed with your choice!