One. Preface: “the most time is the test phase.” Have you ever heard that? This is what most non-testers do when they work on projects and don’t understand how powerful software testing can be.
Software testing is an art that not every software expert can master, yet many underestimate. This article will clear up some common misconceptions about software testing that are prevalent in the technology world. Today we are going to check the misunderstanding of software testing, so far, may be a lot of people’s understanding of software testing are staying on the surface, today based on my experience, Yifei summed up several common misunderstandings of software testing, unlock these misunderstandings, you will find a new world!
Insert picture description two here. Body:
1. Taking the test is simple, easy, dot dot dot dot, can anyone do it?
As a software test engineer, I talk to a lot of development colleagues and many of them have this idea. I don’t know why that came to me, but I will say that the test isn’t as easy as they say. It’s just dot, dot, dot. Of course, some companies don’t pay enough attention to testing, so they may only require testing on the UI layer, just to verify that the UI layer is fine. But such a testing process, it is impossible to control the quality of software.
So this leads to the misunderstanding of testing in the domestic testing industry.
2. Testers don’t need code ability?
This question is not absolute, specific also depends on the test work. Some of the work might be just looking at the quality and smoothness of the video, and it really doesn’t seem to require any coding ability. But when it comes to automated testing, testing tools need to be stacked with code. Even with ready-made testing tools, accumulating test cases requires some coding ability. Of course, if the testers themselves have a deeper understanding of the hardware code, it will definitely reflect on the quality of the tests and help you grow in the future.
3. If there is a problem with the product, is it not properly tested?
In fact, there are a lot of people who do not understand testing will have a misunderstanding, think that what to test? Since we spend money to use you, we should make sure that our products are not defective. The only thing I can say about this is that it’s not rational. The tests aren’t written directly to cause bugs. Therefore, product bugs are the result of the overall process in the whole research and development process, and should not be used as a standard to judge the quality of test work. Testing only improves product quality, not guarantees it. Insert a picture description here
4. Should testing occur late in the development environment?
In the traditional r&d mode, there are special testing stages in the later stage of r&d, including integration testing, system testing, acceptance testing, etc. So there is a misconception that testing happens late in the development phase. However, this is not the case. In modern r&d mode, more emphasis is placed on the migration of test work. In fact, testing is an activity that runs through the whole process of the r&d life cycle, not an independent stage. The earlier testing is involved, the better it will be for the final quality of the product.
5. Is testing boring, uncreative work?
A good test is planned, designed and executed. In order to design good test cases, you need to use your imagination. For an unimaginative tester, you can do the job of executing tests, but you can’t design high-quality test cases. In fact, whether engaged in development or testing, should be from the work to find fun, constantly improve and improve their own.
6. Testing is QA
In many enterprises, QA and Testing are often confused, thinking that Testing is QA (Quality Assurence). QA > testing. As mentioned earlier, quality is not determined by testing, but rather by requirements, design, and development. Therefore, QA work includes not only testing, but also process improvement, ensuring quality standards through the control of key nodes in the process.
QA covers a much larger area than testing and has a different focus. QA is more concerned with quality control throughout the software development process, while testing is more concerned with exposing defects in the current software. They have different concerns and require different skills. Testing cannot be equated with QA work.
7. Testers don’t become project managers.
Many believe that testers lack managerial expertise. But the two are not supposed to interfere. Managers need to master personnel management, cost management, time management and other skills. These skills are irrelevant to the job of a tester, developer, or any other technical person.
Project management skills need to be developed independently, and can be developed by people in any technology or genre around the world. Therefore, as a tester, the pursuit of project management is not encouraged or discouraged. Do you still remember that sentence, as long as you want to work hard, the whole world will make way for you, not afraid! Insert a picture description here
8. Reporting to a development lead is a career hindrance.”
Ideally, there should be separate vertical departments, with both the development lead and QA lead reporting to the project manager. Sometimes, however, the test team and the development team have the same development lead, and you have to report to someone who doesn’t know how to do in-depth testing.
But really, as long as you do your job well and patiently help your leader through the evaluation practice, nothing will go wrong and there will be no long-term negative impact on your career.
9. Software testing is for people with poor coding skills.
In most cases, testing also involves coding. Testers write complex structured Query Language (SDL) to validate data or create test data when performing extract transform load (ETL) tests/data validation. When performing migration tests, testers write code that is converted from one database to another. For automated testing, testers need to write scripts in Java, Perl, or another programming language.
Therefore, the argument simply does not hold water.
10. Software testing is clicking at will.
People often think of testing as clicking randomly on a user interface (UI) and recording the details in Excel or some other document. In fact, testers perform very specific testing steps to ensure that the UI/ application works even under very special circumstances. Therefore, the view is the most important.
Users have no concept of operational constraints, and neither do testers. So it’s important to explore the user interface, which can seem like a lot of random clicks. Only testers know that there is a method to this crazy operation.
11. Testing is documentation, or filling in an Excel spreadsheet.
First, it is important to emphasize that everyone involved in the project must be documented. An accurate and complete document can provide basic proof and historical proof for the project.
For testers, however, documentation is especially important because the product we create is not a program or module, but a quality assurance that is presented manually. The Microsoft Office suite is the first choice for most teams, but if you want to go one better, use test management software.
12. Being a tester doesn’t make a lot of money.
If that’s true of testers, it’s a big mistake. That thinking may need a shift. Even so, compensation depends on many factors, and it would be a mistake to say that being a tester is the only reason for lower pay.
I recommend a software testing and communication group, QQ :642830685, in the group inghui irregularly share software testing resources, test interview questions and industry information.
13. Testers are unappreciated.
Software testing can sometimes feel like a “thankless” job, depending on how much the company culture values the team. Try to stay positive and speak for yourself. I agree with the statement that it would be much easier if companies and customers appreciated the QA team. But if they don’t appreciate the QA team, we shouldn’t underestimate ourselves.
14. Testers slow down project delivery.
Whether or not they start work at the same time as the development team, testers must wait until development is complete before starting testing. This gives the rough impression that testing slows down the project time after time.
This problem does not occur if the test cycle is planned in advance on the computer. Therefore, testing is not the cause of project delays, but incorrect planning and unreasonable expectations.
15. Automated testers do not have to worry about manual testing.
Nothing could be more implausible.
Automated testing is also testing, but the difference is how it is tested. Don’t forget that automated testing continues or follows the process of manual testing. Not all projects are automated projects, and it is also rare to have testers who are proficient in both manual and automated testing.
Manual testing is a basic skill that testers need to develop. It is the foundation. Automated testing is awesome. It’s the closest thing to magic in quality control. But in the world of software testing, we don’t want to evaluate them.
Automated testers can perform manual testing in some projects, and manual testers can perform automated testing in some situations.
16. The test supervisor does not participate in the test.
In fact, by industry standards, the test lead is only 10% of the coordinator, and they are part of the QA team, assisting with testing activities. Of course, there are other tasks.
As a result, QA leads must devote a small portion of their energy to testing activities. In order to become a tester, you must be prepared to perform all the tasks that you are expected to perform as an average QA team member for the rest of your career, or it is time to consider moving on.
17. Testers question everything and are known in the IT industry for being ‘picky.'”
Life is hardest for those who doubt everything. If we really doubt everything, we may even question the existence, use, and efficiency of the software, which means we are still working for the product even though we believe it is useless.
Do you think that’s true? Can we really spend a lot of time on a software system and consider it useless? Contrary to popular belief, testers believe in the performance, efficiency, productivity, and usefulness of software and help it succeed in practice.
However, testers make sure the software is in top shape. When testing, remember that the product is excellent and we must identify and eliminate any factors that may negatively affect this excellent product. We really recognize it and are big fans of it. Insert a picture description here
The test engineer’s job is to break software
It is a common misconception that the test engineer’s job is to break software. The “it’s fine on my machine” that tops the programmer’s list often comes from this misconception. Testers seem to have some magical ability to make correctly running programs fail in the test environment. But it’s not the test engineer breaking the software, it’s not the test engineer creating bugs in the software. They just did something that the programmer didn’t think about, such as not performing dependencies on the test environment. Too often, programmers default to certain scenarios when testing themselves, or develop new features without considering the impact on existing features. That’s why we don’t recommend testing features entirely by developers themselves.
Software bugs can only come from the code that created them, test engineers don’t implement the code, so they can’t break the software, they just find the trigger condition that the software doesn’t work and report it. “Test engineer breaking software” often leads to antagonism between team development and testing, and even blaming the work of test engineer for the software failing to meet customer requirements and a lot of extra work for problem solving. This is very detrimental to team and product success.
Automated testing can replace testing
This misconception is almost an article of faith these days. It is true that, in theory, all test cases can be implemented and executed automatically by technical means, but as we mentioned earlier, testing is not a superposition of test cases plus test executions. The test also includes a lot of creative activities. So automated testing instead of testing is a false proposition (unless, one day, artificial intelligence develops enough to beat human creativity). Besides, even if automated testing can make all test cases run on machines, that doesn’t mean IT should. Because automated testing is an investment in itself, there is a lot of investment in it. There are many test scenarios where automated testing can yield significant value, such as a lot of repetitive validation. However, there are many scenarios that do not require the investment of automation, such as a lot of one-time verification of functions, or functions that rely on human subjective judgment.
A large part of the inspection work in testing can be replaced by automated testing, but the testing work will not be replaced by automated testing. Even in scenarios where automated testing is possible, ROI measurements such as test pyramids are used to determine the need for automated testing
20. Testing is writing test cases and then executing tests is translating requirements into test cases and then executing those use cases in software. This is a misconception that was widespread in the waterfall era, but has changed in the agile era as well, but similar perceptions still exist. In waterfall development, much of the testing effort is strictly required to have a very complete test design document, and then perform validation in an overlay manner against this document. Maybe a senior test engineer writes it and then a junior engineer executes it. This is more of a misapplication of factory-style quality management experience to the software industry. Even today, when agile development models are widely used, we can still see variations of the cognitive approach, such as testing being fully covered by unit tests done by developers. This is still a documentation of the testing effort, but the documentation becomes the unit test code and the execution becomes the computer. The essence is still test = test design + execution
Exporting test design documents is not really that important. In testing, the creative stuff is always more important. Question, research, model, observe, reason, experiment, etc. Documentation is an output form of these activities, and we should not think of testing simply as the mechanical generation and execution of these documents
Well, the above is a fei summary of 20 misunderstandings about software testing, I hope to bring help to the partners in need oh, if you have supplementary content welcome private letter me, we can make the history of the most complete software testing rumor sunflower treasure book. Insert picture description 3 here. Write at the end:
We recommend a software testing exchange group, QQ :642830685, which will share software testing resources, test interview questions and industry information from time to time. We can actively exchange technology in the group.
I wish you and I meet, both gain! Welcome to follow the wechat official account: Program Yuan Yifei