Successful business Test career

Regarding the tester's career plan, I think whether it is the newly-started classmate, the test engineer who has worked for several years, or the Daniel people, all need to face and ponder carefully. What is the future of testing? How to achieve excellence? Perhaps this problem seems to be a bit utilitarian, but also too divergent. But from the current industry's personnel structure, the new people accounted for the vast majority of the distance there is a beacon will appear very important. In thinking about it, I thought of James Whittaker, author of the first reading of exploratory software testing, who answered the question. He likens the path of career development to mountain climbing, and tells a good example of what we should do at each stage. I have a strong resonance in reading the process.

-------------------------------------------a piece of software exploratory testing---------------------------------------------------

Successful business Test career

James A. Whittaker

How did you start doing the testing work?

When I was a graduate student at the University of Tennessee in 1989, I completed the transformation from software developers to software testers. And this transformation is not out of my own choice. The change in my fate happened one morning, and my professor questioned why I missed so many development meetings. I explained that because the meeting was arranged in the morning of Saturday, it was inconvenient.

Proletariate, a new graduate student who left home for the first time in his life, has some trouble with this time period. It is interesting to note that waiting for my punishment is not a dismissal notice, but rather a penalty for the team's only tester and cannot communicate with the development team.

It's a big decision for my career! It was this decision that finally made dozens of papers on the test, built a variety of tools that I couldn't even remember, published five books, and brought endless hours of happy work. Testing has always been the creative and technical challenge of my happy career. However, not everyone likes it. It can be said that my earliest exposure to the test is to pursue a postgraduate course, there is no denying that the high-intensity study and work at that time really benefited me. In addition, I think there is a "test mountain" between the beginner stage and the expert stage, and people need to go over the mountain through a series of personal tutoring, getting information and receiving regular guidance. It's easy to be a test beginner, and it's not difficult to become a professional tester. The focus of this chapter is on how to climb the peaks between the professional testers and the test experts.

Back to the future

In the field of software testing, time seems to have stalled. The way we do things in 21st century is almost exactly the same as in the last century. Bill Hetzel's Test Knowledge series, published in 1972, is still quite valuable today. As I wrote, the first publication of the How-to-Break software series in 2002 is still synonymous with the main resource for practical software testing technology today.

Indeed, if we can convert the the 1970s testers to time and space today, I guess their skills are enough to deal with modern software testing. Of course, they need to learn the network and various network protocols, but they have the actual testing technology will be able to be very good application. If you look for a tester from the 1990s, you don't need almost any training.

For developers, this is not the case, and the skills they have mastered in the last century are almost completely outdated. Let a person who does not write code for a period of time start programming again to see what the reaction will be. What makes me uneasy is that we can hire people directly from the road, and those who are hired will be able to have a harvest from the first day of testing. Is it really that simple? Or is our expectations only that low? What makes me even more uneasy is that we do not have any predictable way to train the right test talent from a competent state of work to a test expert. Is it really that hard to test?

This is the peak again. The threshold is low, but the path to mastery is tough.

At the entrance to the test peaks, we rely on the fact that many aspects of testing are easy to master. Most people can learn to be model-like. Even if you apply a little bit of common sense to the input selection, you can find the flaw. This level of testing is like fishing in a bucket, simply enough to make anyone think they are smart. However, after the entrance, the road quickly steep up, and testing knowledge becomes more and more obscure. We find that someone is good at this, and we call these "gifted people" and appreciate their instincts.

Must you rely on instinct? Is there a way to climb a mountain for people who don't seem to have the expertise? Is it possible to teach test skills in some way to develop more experts? To think that this mountain is passable, and this chapter is my note on how to go this way, you can apply it in your career. This is not a recipe, a career cookbook. But there are a few things you can do to speed up your career. But, as you might have guessed, it's really easy to say, it's hard to do.

Mountain

The early stages of the Test career were mainly to prepare for the long climb to conquer the test peaks. The best advice I can give is to think in two ways. For each project that you participate in, there are two parts (not necessarily equal) tasks. The first part of the task is to ensure that the current test project has been successful. The second part of the task is to learn what you should do to make the next test project easier. I call it "test today's project and prepare for tomorrow's project". If you do each project and divide it into the two halves above, you can almost guarantee that you will continue to make progress. This way, you can grow to be a better tester as each of the participating projects grows.

Now let's focus on the second part of the task------prepare for the next project. We need to be aware of three concepts: repetition, technology, and vulnerability.

Repeat

Do anything, never repeat twice without realizing or questioning this is actually a problem. I hope all young testers will keep this in mind. I've seen a lot of beginners who have wasted too much time on monotonous tasks, such as setting up test machines, configuring test environments, installing applications for testing in the lab, choosing a product version to test-the list of tasks can become very long, and finally you'll find that the amount of time you actually spend on testing software is pathetic.

This is a common mistake many novices make. They failed to see the repetitive nature of the work they did day after day, and when they realized the repetition, a few hours had passed, and in those hours they had not done any actual testing work. Pay attention to these repetitive tasks, and be aware of the resulting real software testing time lapse. In order to be able to turn over the peak of the test, it is necessary to do the work that the tester should do, not the lab administrator or the test machine administrator.

Test automation is a solution to repetitive labor, and is a topic later in this chapter.

Technology

Testers often analyze software failures. When we analyze defects, we learn how to write reliable code from the failure of the developer. We also analyze the flaws that we have overlooked. After the application is listed, customers will start reporting defects, and we will be faced with a lot of failures and looking for important flaws. Each defect reported by the user indicates that there is a problem with our process and that our testing knowledge is not perfect.

But it is equally important to analyze our success, and many new recruits have failed to take advantage of this handy resource. Every flaw we find in our testing indicates that our testing process is working effectively and is a success. We need to hold on to this wonderful opportunity, only in this way can we continue to repeat the success.

Sports teams often do this, they watch the video of the game and analyze why each action works or why it doesn't work. I remember a little story clearly, a friend of mine took some pictures of my son playing football. One of the photos recorded the moment he played and the goal was scored more than the other goalkeeper. When I gave it to my son, I pointed out that the leg he was standing on was perfectly seated and his toes tightened and the batter was in the right place between the laces. He stared at the picture for a long time, and since then he seldom played in the wrong pose. His score may have been the right thing to do, but since then he has consciously used these techniques to make it nearly perfect.

Now go back to the Novice tester's course. Every one of us will have a moment of pride. We are thrilled that we have found important loopholes or found a high-priority flaw. But take some time to think about the overall situation first. What technology did we use to find the flaw? Can we create a way to find more of these kinds of flaws? Can we remember these practical test experiences and constantly apply them to help improve our productivity? What are the symptoms of the software that can prompt us for defects? Can we get more warning from those symptoms in the future? In other words, it's not just a flaw or a success, what does this flaw teach us, whether it makes us a better tester in the future, just as my son scored, even though the first flaw was discovered by accident, it does not mean that the rest of the success is accidental. It is important to understand the reasons for our success, and only by doing so will success be replicated. For testers, the reason for this success is a series of test techniques, recommendations, and tools that can improve our productivity in future projects.

Loopholes

Testers will eventually become very good at finding flaws, but to get over the peak of the test, we have to be faster and more efficient: high-speed low-resistance. In other words, we have to have a defect-free search technology that doesn't have its own flaws!

I like to think about it: Testers also need the ability to look for flaws when they examine their work. We must use the same process as the search for product defects to find our own testing processes and defects in the testing process. Is there a problem with my test process? Is there any defect in this? Is there a hindrance to my efficiency?

You must always look for a better way. Consciously identify those that limit power, hinder progress, and slow things down. Just as defects limit the ability of the software to meet the user's needs, what limits the ability to test? Use the testing capabilities you have to optimize your testing process, which will help you quickly climb the test peaks and increase your chances of becoming an expert after climbing the mountain.

Testing the peak of a mountain is a wonderful place. If you have succeeded in being there, congratulate you. But this is not the most all-day mark. This means that you have become an outstanding tester. The descent of this time is to use your insight and expertise to help the people around also become excellent testers. It's one thing to be at the top of your own, and it's quite another to help others (those who are not as good as you) to climb to the top.

In general, those who have successfully ascended the peak of the test will become masters of the use of tools. Those business tools, open source free tools, and your own tools (my personal favorite tool) are great ways to improve your work output and increase your productivity. However, a tool is just one way to achieve that goal, but in many ways it is a limitation because too many people don't see anything outside the functionality of the tool. They are limited to what the tools can do for them, and they are not able to see or understand the need for tools. The summit need to really master is "information." Because many tools can process information and make it easier to get information, testers become overly dependent on their tools. But the information itself and how to use it is the key to success.

Proficiency in information, which means understanding what information will affect the test and ensuring maximum use of these effects. There are several types of information that you must focus on to test the summit. I'm going to talk about two of them: information from the application and information from the previous tests.

Information from the application includes requirements, architecture, code structure, source code ... It's even about running information about what the application did when it was executed. This kind of information needs to be considered when writing and executing test cases, but the amount of information depends to a large extent on the ability of testers, a capability that makes testing more efficient. The more you use this type of information in your tests, the more likely it is to be more engineering than guesswork.

At Microsoft, we have a game test organization (Games Test Organization, GTO), which is responsible for testing Xbox and PC games. When it comes to harnessing the information of applications, they are the best. The game is incredibly rich and very complex to test. Many of the things that can be tested in the game are hidden (because it is one of the pleasures of the game for those players to find something that can be exchanged). If the GTO testers are only playing games, they will find no more problems than the end user. To be able to do better, they worked with the game's developers to create some information dashboards that exposed some information that could basically be cheated to testers. In this way, testers can know in advance where monsters will be placed, where items are hidden, and they can see the other side of the wall to control some of the enemy's behavior. Their cheat tools (i.e. test tools) basically make them gods in the game, allowing them to control the information they see so they can test more quickly and skillfully. This example gives the testers a lesson.

The information from the test means that you have to focus on everything you do during the test and use the information you get to influence future testing. Do you know how your tests are combined with requirements and know when a particular requirement has been adequately tested? Do you use code coverage to influence future testing? Do you know whether those tests will be affected when code updates or bug fixes, or is knowledge rerun all tests? Understand how well the test is going and adjust the test strategy with the test, which is the hallmark of the test maturity.

I used to work in a team at Microsoft's Visual Studio, and we used a lot of code churn (code that changed because of adding new or bug fixes) and code coverage to influence our testing. It took a lot of effort to notify testers of code overrides and code churn to help them understand which test cases contribute to coverage, and help them test the changed or modified components. The end result is that when the code is actually altered, we clearly know which tests will be affected and only rerun those tests. We also know how each new test case works for the overall interface, features, and code coverage to guide our testers and allow everyone on the team to write more meaningful tests based on all of the test cases that they create.

What information do you use to guide your tests? How do you ensure that information is available so that it can be readily available for testing? How do you make information useful so that it can affect your testing in a good way? The answers to these questions will determine the speed at which you move toward the experts to test the peaks.

Down

By the time you reach the peak of your test peak, you have become a very capable tester, and your abilities may be equal to the sum of all the colleagues in your group. No matter what you do, don't try to do better than your entire team, no matter how good you feel about it or how tight your boss is to you. Once you're on a downhill path, stop fighting for the "find the most flawed person" or the "find the most significant defective person" for an honorary title. Instead, I recommend that you reduce the time spent on testing and take innovation as your top priority.

Innovation in testing means not rushing forward, but observing, gaining insight, finding bottlenecks and improving the way that everyone else in the team works. Your work turns into helping others to progress. At Microsoft, we have a formal position for this purpose-test architect. But don't let yourself be frustrated by the lack of a cool title. No matter what they call you, the best thing you can do when you're on a downhill path is to try to make sure more people can successfully climb the other side of the mountain.

Successful business Test career