And thank you to all who contributed.
1. Things I have learned - Take a class in the programming language that you are testing. This will improve not only your skills, but your ability to communicate with the developers.
2. Always keep in mind that some of your best teachers are also your co-workers.
3. Keep your ears open about projects both new and in progress. Get to know the requirements of the project and what the expectations of the users are.
4. Establish a partnership relationship with your developers. Sit down and discuss mutual expectations.
5. Ask questions.
6. Be persistent.
7. Be precise. Whether you are reporting a defect or reporting a process improvement need, if you cannot precisely describe the problem and the impact, you won't get far.
8. Pick your battles. You cannot change everything at once. If you are trying to establish or improve your testing process or development process, do a thorough assessment of where you are and how you need to improve, and prioritize this list.
9. Pick some "low hanging fruit", document, implement, assess --- and hopefully as people begin to SEE the benefits, you'll win more converts. So your next process improvement attempt will go more smoothly.
10. Read recommended literature
11. Make sure everything you do gets reviewed by at least one experienced person (No matter how long I have been in this industry, I still follow this principle)
12. Don't be afraid to ask questions!!! I learned so much from the developers at my first company, it was unbelievable! And at a subsequent company, I got a developer to give QA a bit of a session on EJBs when they were still bleeding edge technology we were working with. If you ask, they will generally help - because it shows that you don't profess to know everything better than they do, which can be a misconception!
13. Keep up on new technology. Even if you're not using it now, you might be someday, so take the time to at least read up on the basics!
14. Look at joining a User's Group or QA group in your area, if one exists. The.networking, venting, and communication are priceless!
15. Think about what you think might need to be checked.
16. Ask questions and be curious.
17. NEVER criticize the developers for defects.
18. Get a mentor. We all know how demanding QA and Test can be and having someone to bounce ideas and thoughts off is extremely useful. My own mentor was a very experienced QA/Test Manager who was extremely good and helped me enormously
19. Don't be afraid to ask for help and questions, find a mentor. We like to share our thoughts and knowledge. I worked for a larger company that had many different testing departments. One of the things we did was form. a 'corporate' qa steering committee. This was a way to share ideas, network with others, and do some streamlining.......
=============================================
And here is a little history on how some of us got into QA/Testing.
1. My degree is in math, and my first job was as a data analyst for research satellites. But that was rotating shift work, which got old fast. So I applied to the IV&V group on the same contract. So basically I went the user to tester path. When I joined that group, our company was going for CMM level 3 certification, ISO certification, and TQM (yes, all at once). So I was immediately sent off to training for all that. (Your government dollars at work ). All of my initial testing training was "on the job" with a large group of testers (30-40 testers in that group). Since then I have done testing and/or quality assurance work in aerospace, computer gaming, brokerage, and now retail/ecommerce. That's one aspect of my job that I like --- learning a new industry. (BTW --- I like retail best so far.)
2. I was working as a Project Manager for a large Telecommunications company that was rolling out TQM. I got friendly with the TQM manager for our division and he got me interested. I applied for, and got, a QA Manager job with a software house where QA was just being started up, for "QA", read "Test" (they wanted a Project Manager, rather than a QA Manager, as they wanted someone who would be pragmatic - which shows their level of maturity) so I had to learn quickly, found it fascinating, stayed for 6 years and implemented a lot of real QA as well as improving testing.
3. I was working tech support for a free web-based email provider, and got SO sick of the way our software went out that I was first in line to apply for a testing position when they finally brought in a QA Manager!
4. I started out doing user testing. One of the first places I worked at didn't have people to do client server testing. So I would do the testing in between my customer service job. I found a mentor in the QA department, expressed my interest in learning more about testing and when a position opened up in the department I applied for it and got it.
5. How I started - I worked second level support on multiple systems within my former company. When the company needed someone with unix experience to test a new system they offered me the job. I have been doing it ever since.
6. I was a software trainer who kept getting sent out with buggy software to train on. I told my company that I wanted to have a day or so before I took it out, just to bang on it myself before I tried to train so I'd know to avoid pitfalls. All testing became my responsibility from then on. (That was in the early '80's so it probably wouldn't happen that way now.)
文章來源于領測軟件測試網 http://www.kjueaiud.com/
