I have been a professional software tester in various capacities since 2005. In my current role, I am a consulting software tester and writer working with Excelon Development. Outside of work, I am currently serving on the Association For Software Testing Board of Directors as VP of Education helping to facilitate and develop projects like BBST and WHOSE. I am also a student in the Miagi-Do school of software testing, and facilitate sessions for Weekend Testing Americas.
I am deeply interested in software testing and delivery, and also helping organizations fix problems in measurement and metrics programs.
In the quest for writing good code and delivering the right thing to customers, developers have several challenges. But most of them can be boiled down to two main problems: discovering the real scope, and how to do the work. Interestingly, they’re very similar to the problems faced by testers and others in non-dev roles.
When you've worked for months on a big software release, afterward you may want to jump into the next project. But building in some slack time between sprints is a good idea. After a big release, there will probably be more work as new users discover bugs in your software. Plan for some more testing and development.
When your application is scheduled to go to production, the development team may be asked what their regression testing strategy is. This is a perfectly reasonable question, but a lot of people have a hard time answering it. Don't overcomplicate it. Analyze your process, look at the other testing, and put it together.
Many people in testing roles want to grow their skills and learn to build some tests with code. But no matter how well you test, automation is programming work. If you want to get better at automation, your best bet is to get into a role where you are dealing with code. Here are two ways you can break in and learn.
Supposedly there is a constant tension between developers and testers, like the roles of artist and art critic. They can’t exist without each other, and yet they can’t get along. It doesn't have to be that way! Here are two ways testers can reduce that feeling so that developers and testers can work better together.
Some people think a good indication that a piece of work is done is if it's been tested. But by whom, and how? Testing alone doesn’t specifically determine whether you are done—especially when we probably don’t mean the same thing when we all talk about testing. Here are two ways to know when your work is truly done.
Testing can get complicated when each project is using a completely different toolset, language, and reporting status, with different measurements and formats. Testing is a reaction to context and what we encounter, so how we test cannot be standardized. What we can standardize is the stuff that surrounds the testing.