Today, I like to write a bout some advice that I can provide for new testers.
For a brand new testers, who just graduated from college or stared his/her career as a tester, what kind of advice will help him/her be successful in this field?
I can think of three things to start with.
1. Be a thinker.
This is pretty obvious advice, but it is really important requirement to be a successful test engineer. If a tester does not think and do what was told, he/she is useless in my mind. Can a tester question requirements and specs? Can a tester question application architecture and development design? Can a tester seek to improve the testing process? Can a tester think like a customers/users? Can a tester think about business impact of application failures? Can a tester suggest a better approach in solving problems to devs and PMs?
2. Credibility
In my opinion, the credibility is everything for a tester. This is something we, testers, earns from people(dev, PM, testers, managers, and etc) around us in the team. This can be pretty subjective at the beginning, but as the team delivers projects by projects, people notice testers' credibility. I believe testers' credibility not only affects the success of the project but also the career path of the tester. If a tester crying about every single bug or issue he/she found, project team start not to listen to him/her seriously. We need to make sure to provide reasoning for the bugs and issues. Is that a ship stopper? Why and how this issue impact the operation of the application and the business should be clearly prepared and addressed when a tester write a bug or telling the team about the issue. A credible tester finishes testing on time. People have confidence in delivering a good project, when a credible tester is in the project team.
3. Being as Technical as dev
This maybe applicable to SDETs (Software Development Engineer in Test). I believe the technical skill for SDE I level and SDET1 level should be the same. Sr SDE and Sr SDET should have the same technical skills. The only difference between SDE and SDET is the area they're focusing on. SDE focuses on application development, in which design, architecture, optimization of the code, and performance are important. SDET focuses on application testing, in which test framework design, maintainability of the code, robustness and reliability are important. Knowledge in programming language, coding skills, designing the applications, unit testing, executing DB queries should not be a problem for testers.
Sunday, July 31, 2011
Monday, July 4, 2011
Let's not under estimate the power of automation
Today, I like to write a little bit about usage of the automation or more specifically the use of programming.
You will find a lot of article about software testing strategies, and you can easily find the sentence "Exhaustive testing is impossible." And people write about equivalent partitioning and some related concepts.
Sometimes, this statements prevent me from thinking about executing all the possible inputs in my automation.
One of my test, I can get all the possible inputs from database. It's about 200,000 rows. Executing one test takes about 2 seconds including accessing the DB. Which means I can run all my tests in 400,000 seconds, which is about 1.8 days. And if I use several machines I can run them all within a day.
I had about 3 weeks to do my testing. Of course, I needed to spend time on other test cases but I did not even think about doing it all. I'm not saying that we need to try all the possible inputs for your testing or exercising all the test inputs would always give you better results. I'm saying we should not prevent ourselves from doing all because the data set is relatively large.
You can kick off your test and go home and check the result the next day.
Interesting things about programming is that automation really helps our testing. Machine cannot do testing but it certainly can helps us do testing. How much do you take advantage of the programming in your testing besides running your tests? You probably have multiple machines that you can use for your testing. Even your desktop machine can do something for you while you are at home enjoying family time. Are you under tight testing schedule? Do you want to lower your testing cost?
Actually you can get a lot of things done even if you're not sitting in front of the computer. Make good use of programming in your testing.
You will find a lot of article about software testing strategies, and you can easily find the sentence "Exhaustive testing is impossible." And people write about equivalent partitioning and some related concepts.
Sometimes, this statements prevent me from thinking about executing all the possible inputs in my automation.
One of my test, I can get all the possible inputs from database. It's about 200,000 rows. Executing one test takes about 2 seconds including accessing the DB. Which means I can run all my tests in 400,000 seconds, which is about 1.8 days. And if I use several machines I can run them all within a day.
I had about 3 weeks to do my testing. Of course, I needed to spend time on other test cases but I did not even think about doing it all. I'm not saying that we need to try all the possible inputs for your testing or exercising all the test inputs would always give you better results. I'm saying we should not prevent ourselves from doing all because the data set is relatively large.
You can kick off your test and go home and check the result the next day.
Interesting things about programming is that automation really helps our testing. Machine cannot do testing but it certainly can helps us do testing. How much do you take advantage of the programming in your testing besides running your tests? You probably have multiple machines that you can use for your testing. Even your desktop machine can do something for you while you are at home enjoying family time. Are you under tight testing schedule? Do you want to lower your testing cost?
Actually you can get a lot of things done even if you're not sitting in front of the computer. Make good use of programming in your testing.
Subscribe to:
Posts (Atom)