1. Please introduce yourself first.
First of all, the first question in the interview is self-introduction. Personally, I think that the self-introduction of the software testing post must start from the perspective of what work you have done, what skills you know, and what type of work you can undertake. As for yourself Interests and hobbies are secondary, and other topics that have nothing to do with testing work are not mentioned.
Example:
Hello interviewer, I am very glad to have this opportunity for this interview. I am XXX, from XX city. I have graduated from a university majoring in computer science for five years. I have been an intern in a software company since my senior year and have 6 years of testing experience. During this period, I have worked in two software companies, and the scope of work includes functional testing, interface testing, automated testing, performance testing, etc.
In the first company, I joined the company as an intern. I started with ordinary functional testing, wrote test technical documents, test cases, and performed functional tests. Later, I also learned performance testing because of business needs (here you can write other Appropriate, to achieve closed-loop) skills and actually help the development to locate performance problems. In the continuous work and study, I was promoted to be a department manager in the third year.
Later, due to personal reasons, I went to another company xxx, which is a type of xxx business. Here, I grew up very fast. After the accumulation of previous work experience and continuous learning, I can use it skillfully in the new company. Linux statements for system deployment, proficient use of SQL statements to operate database auxiliary functions, performance testing, use Jmeter interface testing tool for interface testing, performance testing, use selenium+python mode for UI automation testing, etc.
Personally, I am a person who does not want to be left behind by the industry. Apart from work and life, I will keep learning new knowledge to ensure that I keep pace with the times.
The above is my self-introduction. If you have anything else you want to know, please continue to communicate.
2. Can you briefly talk about the testing process of your previous company?
This question has been asked by the companies I have interviewed before. Although I have not interviewed too many companies (personally looking for a job is still very fast ^_^), I think this is a good reflection of personal language organization ability and job identification. Questions about the level of experience.
Example:
In the two software companies I have stayed in before, the testing process is similar. Basically, it starts from participating in the requirements review meeting. After the meeting, the test needs to give an approximate test time. After the product manager updates the requirements document after the meeting, the person in charge of the test Start to make a test plan, including the planning of time, manpower, equipment and other resources and the design of the test plan, and then the testers of the project start to write the test cases for the modules they are responsible for, execute the test after the test, bug tracking management, and regression testing. When the launch standard is finally met, a test summary report will be written, and all relevant personnel will be notified by email and corporate WeChat. After the second company goes online, it needs to do a special online verification.
3. What do you think a good test case should look like?
As a tester, whether you are doing functional testing, performance testing, interface testing, automated testing, security testing, etc., this is an unavoidable problem. Use cases mean that testing has a soul, and you must know it.
Example:
I think the first principle of writing test cases is to fully cover the requirements and strictly follow the requirements;
Then the idea of writing use cases should be clear. For example, if there is a total-point-total idea, first analyze how many modules the system has, and how many small modules each large module contains. After dividing it into the smallest module unit, divide the Extract all function points, write use cases one by one, and finally connect all business-related modules into process test cases.
The third point is to maintain the independence of use cases. There should be no dependencies between use cases. If there is indeed a relationship, you can clearly describe in the preconditions how the data that this use case depends on is obtained.
Then there are a few very important points. The title of the use case is clear and clear, and the name is clear; the steps are clear and operable; the expectations are consistent with the requirements.
In addition, the granularity of use cases should be moderate. Don't describe the whole story in one sentence, and don't be too detailed.
The last and very important point is that you have to think about the problem from the perspective of the user. Although sometimes the requirements document is not clearly described, if you assume that you are a user, how would you operate the system? What are the business pain points? What is the possibility of misuse and the like.
4. How many rounds do you usually test? What is the focus of each round of testing?
This is a question with no fixed answer. What the interviewer wants to examine may be your understanding of the test and how you do it in actual work (I guess).
Example:
I have done many projects before, and different development leaders will directly affect the number of testing rounds. But I'll sum it up, it's probably around three to five rounds.
Before the formal test, we do a smoke test to confirm that the main process is not hindered and enter the first round of testing.
The first round: All use cases need to be executed, and the key processes should be focused on testing.
The second round: first return the bugs found in the first round, close or activate the bugs according to the actual repair situation, and then use the test
Execute the example again. (Some companies only focus on the first round of problematic and main process testing when time is critical)
The third round: Return all the bugs in the previous two rounds, and then open the requirements documents, prototypes, etc. for scanning tests to prevent missed tests. After that, some compatibility tests, weak networks, disconnected networks, and long-term inactivity will be done. Wait for the special test, and end if there is no problem, otherwise continue (it may continue for many rounds due to a bug).
If the business requires it, interface and performance tests may also be done.
In special circumstances, such as before the Spring Festival, a packet test will be done.
5. You think it is a bug, but the developer thinks it is not a bug. How to solve it?
This question is also frequently asked, because the test itself needs to work closely with developers. For this question, it is necessary to have a firm stand and principle for testing, and to communicate and coordinate effectively with development (that is, not to communicate with development). fight up...)
Example:
First of all, I will carefully study the requirements document and verify with the product manager. If it is indeed a bug, I will explain it to the development based on my understanding of the requirements, and then explain that the product manager agrees. If the development approves, modify the bug, that is Enter the bug tracking management process. If the developer still disagrees, I will ask him to explain how he understands it. If I think what he said is reasonable, I will also ask the product manager to come in and discuss it together, and finally draw a conclusion. If it is indeed a bug in the end and the development is determined not to change it, then I will explain to his leader and let the leader deal with it. If it is not dealt with, it will be written in the test report.
6. Can you write test documents in the company? What kind of documents do you usually write? how to write?
To do tests, you need to use writing skills. After all, you need to write use cases, write bugs, and write documents. If you write bugs, development can’t understand them at all, so what should you do? Then testing generally requires writing some technical documents, such as plans, reports, and some companies also require testing to write user manuals, etc.
Example:
In addition to writing test cases, bugs, etc. in my company, I also need to write test plans and test reports.
First of all, the test plan , which needs to be finalized after the demand review meeting, the company will have a corresponding template, I just put the content in it, and need to make corresponding adjustments according to the actual situation of the project. It mainly includes the following contents:
-
Test objectives and test scope;
-
roles and responsibilities for implementing the plan;
-
Task scheduling and resource allocation;
-
Risk assessment and contingency planning;
-
Entry/exit criteria for testing.
Then the test report also has a template to apply, mainly including the following:
-
Test objectives and test scope;
-
Test process and conclusions (how many rounds of testing, how many problems were found, how many were repaired, how many were left over, how to deal with them, etc.);
-
Whether the system fully complies with the description of the product requirements specification;
-
Whether it meets the online standard;
-
Is there a risk.
7. How is your company's bug level divided? Is there any basis?
There is no standard answer for this. I want to say roughly the same. The interviewer should know that you really have your own understanding. When I recite it, I will give a rough idea in my own language.
Example:
Different companies have different classification methods, but the difference is not big. Before us, bugs were generally divided into four levels:
1) Level 1: Fatal bug
-
The test directly leads to system crash, crash, blue screen, hang or illegal exit of the program;
-
There are security flaws, clicks cause important data to be lost, damaged, and cannot be recovered;
-
The main modules and function points have not been realized.
2) Level 2: Serious bug
-
The secondary function points of the system under test have not been realized, or the security requirements have not been realized;
-
An error in a certain function point of the software makes it impossible to complete the complete process test (obstructive bug);
-
There are obvious and high-impact UI bugs on the main interface.
3) Level 3: General bugs
-
Functional bugs inconsistent with expected results only affect this function;
-
Poor software interactivity makes it difficult for users to understand and operate;
-
More serious bugs appearing under stricter conditions;
-
Errors in descriptions such as text appearing on the interface cause user misunderstandings.
4) Level 4: Suggestive bugs
-
There are minor differences between actual functions and expected results;
-
Ordinary level bugs appearing under stricter conditions;
-
There are text description problems in the interface, programs or prompts, etc., but the impact is not significant;
-
There are minor differences between the UI and the design diagram;
-
Program usability suggestions, user experience optimization suggestions.
8. The bug that impressed you the most
I feel that this question is a bit of a proposition. Ordinary bugs are nothing to impress. They will only be more impressive if they cause bad consequences. People will mutter, you will not have this kind of "accident with me, right?" . . . So what should I say? I think it’s best not to take full responsibility for the bug that caused disastrous consequences. It’s better to talk about your summary of this bug and make progress.
Example:
When I was testing a product background system in xxx company, I reported a bug online once, that is, after modifying the functions related to inbound and outbound in the product background, I had no problem with the demand test, and there was no related mobile terminal verification. The sales function was launched directly. At that time, we had special testers to test the mobile terminal. I was only responsible for the background function, but that colleague was in another office area during that time, and she asked for leave. I don't know, the project was launched directly, which caused the changes in the background of the product to affect the front-end sales, and caused certain losses to customers. The most fundamental reason for this bug is our company's division of labor mechanism and information out of sync. Later, in order to avoid this situation from happening again in the future, I recorded an interface automation script. Every time a new demand comes online, I will Run the interfaces of all mainstream business processes in the background and front-end once to ensure that there are no problems before going online.
When you go to an interview for a testing position, you will encounter various questions. In addition to some classic questions, there are also some special basic questions, such as questions about databases, Linux commands, automation, and python. I'll tidy up some more when I have time.