It’s a common problem I face as a software Test engineer, ramping-up quickly on new projects. Here’s what usually happens.
My practice area leader gives my team a heads up about our next project when he can. We are usually at the end of a project or had just completed one. So, those who can, will jump on the web and do a search for the new project coming up. It usually does not take long until we were looking at an older version of our next assignment. At first it seems very awkward to navigate, but after about 20 minutes or so we have a general sense of what the application is supposed to do and how to navigate through it. This early exploration slices off some of the team’s ramp up time when the project begins. It also helps the team become subject matter proficient from the very beginning of the project. Even if only one team member can accomplish this, it is still a bonus to the overall team as they have a reference point to spring board questions.
This is a win win situation for the team and the customer. The customer sees results from testing sooner and the team’s ramp up time is cut down considerably, giving us the ability to quickly focus our attention on finding bugs and decomposing the application. I think there are 5 steps to accomplish this 1) Familiarization of the Application. 2) Gaining access to the application. 3) Searching the bug database. 4) Exploration. 5) Being ready for anything.
1. Familiarization with the Application. Being Familiar with an application can significantly reduce the ramp up time to almost nothing. It can mean the difference between fishing all over a lake, trying different kinds of lures and catching small blue gills (nothing wrong with that, blue gills are small but good to eat) or being familiar with the lake, knowing which lure to use and going right to the lily pads where you know the big fish are lurking. Becoming familiar with the application before the ramp up will help the test cases go more smoothly and efficiently and could lead you to some nice sev 1 bugs.
2. Gain Access to the Application. Gain access to the application in whatever form is available, you will need to get a hold of this as soon as possible! If you cannot get the latest version because it’s not quite ready, No problem, and older versions will work just fine. I have gained access to applications from a thumb drive in the past, whatever it takes!
3. Search the bug database. Search the bug database for older applications with a known history. This is a great way to see where the problem areas have been in the past. Reading the repro steps is another way to familiarize the logical steps for how bugs were found. What if no bugs are logged in on this application yet? No problem, simply look for a similar application and dig through those bugs looking for possible similarities. Try searching by severity to get a look at past show stoppers, these could be located in the prime test areas.
4. Explore the Application. At this stage in the game, test cases may still be “under construction”. Cool! Explore the application. Try everything, fear nothing. Clicking and typing information wherever you can. Ask yourself questions like, how deep can I get in this App? What’s this app supposed to be doing? You are seeing the application through unscripted eyes, so decompose it as your mind sees fit.
5. Be ready for anything! Do not be surprised if bugs start appearing right away, like they were patiently waiting your arrival. How exciting! You don’t even have test cases and seem to be wading waist deep in bugs! On the other hand, no need for disappointment if you do not find bugs initially. It’s like the kitchen lights are turned on or something, you know as soon as you turn the lights out, the bugs will appear. But you just cannot find the switch, no worries, try using a different light! The important aspect is you are familiarizing yourself with the application, the bugs are a bonus! Reproduce them and write them up, assigning them to yourself. This way they will not get lost or forgotten.
Subscribe to:
Post Comments (Atom)
I'm trying to understand "be ready for anything." Can you give an example of what it means to NOT be ready to anything?
ReplyDeleteI didn’t see you talk about requirements? We all know that sometimes these do not exists and other times they are so high-level they don’t do much good. Don’t you think it’s important to understand the requirements of the build as part of your 5 steps?
ReplyDeleteI agree with you about familiarize yourself with the app but what happens if you cant? This could be the first drop of code how do you handle this situation? I find that if you have a standard set of test that you can run on any application written and ready to go this can improve your ramp up time considerably. If the application has no requirements have your team meet with the designers/customer and draw the functionality out of them. Conduct this as an interview. Find out what the most critical things to your client are. Get screen shots of their designs (they all have mock ups) and question them during the interview.
Good luck on your new path!
This comment has been removed by the author.
ReplyDeleteIf the requirements are available, (remember we are talking about something coming down the pipeline by word of mouth) that definitely changes how I start my understanding of the application, but not my curiosity as to how it works or what paths I may take in this early decomposing of it. I could not agree more with your following statement "I find that if you have a standard set of test that you can run on any application written and ready to go this can improve your ramp up time considerably." And is exactly what we are doing in our shop.
ReplyDeleteIn answer to your question James, Not being ready for "anything" reminds me of working in the operating room. Being ready for anything was imperative, not being ready for anything was detrimental to the patients well being. Not having a C-clamp on your sterile field ready to clamp an out of control bleeder was something a rooky would not know about. Until it happened, and the doctor used something similar but not as good as a C-Clamp! After that, you would always make sure you had one ready. As I learn about being ready for anything as an Engineer, I find myself adding more things to my "testing tool belt" asking myself questions from the last project where I was missing the "C-clamp". Not being ready for anything, to me, means you don’t have your Testing tool belt on.
ReplyDeleteOkay, so when you say "be ready for anything," it sounds like you mean "be ready for what you can reasonably anticipate, based on your experience."
ReplyDeleteSeems there should be more to it, than that. How might we prepare ourselves for what we didn't anticipate?
In reading about military training, I learned about something called "stress inoculation." This means training under stressful conditions so that real life crises don't seem so difficult to handle. Maybe we testers can challenge each other with puzzles in our off-time as a way of being more ready for the puzzles that surprise us on the job.
-- James
Thanks James, I cant agree more with what you are saying about there being more to it. And as an ex military man. (corpsman in the Navy) "Stress Inoculation" is used, course at the time we called it "WHY IN THE HELL DO WE HAVE TO DO THAT!?"
ReplyDeleteI really like the idea of puzzles! My wife goes to the dollar store and gets funny little toys, which I then take to work and make a game up where critical thinking must be used to figure out the answer. Once they figure it out I change the rules! and they get some treasure to boot! sometimes the secret is shared and a joke is played. Its funny how a good team will share the results with each other, just like when we are testing together, we are always communicating our coordinates in the application and what we are finding, moving through the app like a pack of wolves.