One time a customer came to our store and asked to repair her cellphone. The cellphone was a Nokia C8 as far as I can remember a model number. The operating system behaved in a rather strange way: It would freeze once in a while and it couldn't keep the custom settings for a more than a day. Right away, I thought the phone needed a restore. So I restored the phone to a factory default. But, strangely, this didn't fix the problem. Yeah, I've heard of all these master reset, soft reset etc. None of this helped. Moreover, the customer told me that she brought the phone to the carrier provider and their technical team couldn't fix the issue.
So I went online and found out that in addition to the above-mentioned reset methods there was another method of resetting by entering a special code which wasn't documented. I found the code and voila!, the problem was fixed. And I've learned a lot of new information while researching about that particular problem.
If I just followed the phone's manual, I would've never found a solution, so be creative and learn, don't rely only on what's written.
Sunday, June 9, 2013
Thursday, June 6, 2013
From Techie to Tester
Looking back X years ago, when I was just starting as a self-employed on-call PC techie driving around the town to provide computer repair services to the general population, I wasn't even thinking that I was off to a great journey of Testing. No, I had no clue about software testing at the time, I was just trying to monetize what I was always good at since I had a computer: troubleshooting.
So here I am driving here and there serving people of different ages and backgrounds, I was amazed how technology outpaces human proficiency in using this technology.
It's remarkable, for example, to see people buy those latest Android devices full of endless wonderful features and capabilities an average user will never use or even have a clue of!
Anyway, the job of the on-road computer tech taught me to be sharp-minded and an improviser because of the time constraints that this job implies( I can't stay at a customer's home for the whole day to figure out how to fix the problem). So I try to push my brain to the limit by creating different models in my head taking into the account of what I know about software/hardware and trying to extract the right attack that needs to be implemented in order to fix the problem.
So every day I performed an attack(again, I hadn't any clue about Unit Testing either) and every day just got better and better. Finally, I could almost fix the computer by just listening for the customer explaining the problem over the phone. I could properly prepare myself for an attack based on their story(User stories?) before I visit them by choosing the likely tools that I'll need(looks like the Test Planning phase?).
By gathering the info about the problem, then choosing the right tools and methods, then thoughtfully manipulating the object under repair(OUR:-D) worked out really well.
Then, a couple years ago, I found out about Software Testing and QA stuff and, Wow, I figured that all I was doing these years actually was Software Testing!
So I've started reading blogs of some prominent voices in testing community and gathering as much info about how to test and learned a lot of new approaches and accepted their advice. These people really inspire me and give a different angle of viewing at Testing so the more I read about it the more I start liking it. Let the journey begin!
Please follow my blog, I'll be sharing with you some interesting ideas and approaches from past experience and some more.
So here I am driving here and there serving people of different ages and backgrounds, I was amazed how technology outpaces human proficiency in using this technology.
It's remarkable, for example, to see people buy those latest Android devices full of endless wonderful features and capabilities an average user will never use or even have a clue of!
Anyway, the job of the on-road computer tech taught me to be sharp-minded and an improviser because of the time constraints that this job implies( I can't stay at a customer's home for the whole day to figure out how to fix the problem). So I try to push my brain to the limit by creating different models in my head taking into the account of what I know about software/hardware and trying to extract the right attack that needs to be implemented in order to fix the problem.
So every day I performed an attack(again, I hadn't any clue about Unit Testing either) and every day just got better and better. Finally, I could almost fix the computer by just listening for the customer explaining the problem over the phone. I could properly prepare myself for an attack based on their story(User stories?) before I visit them by choosing the likely tools that I'll need(looks like the Test Planning phase?).
By gathering the info about the problem, then choosing the right tools and methods, then thoughtfully manipulating the object under repair(OUR:-D) worked out really well.
Then, a couple years ago, I found out about Software Testing and QA stuff and, Wow, I figured that all I was doing these years actually was Software Testing!
So I've started reading blogs of some prominent voices in testing community and gathering as much info about how to test and learned a lot of new approaches and accepted their advice. These people really inspire me and give a different angle of viewing at Testing so the more I read about it the more I start liking it. Let the journey begin!
Please follow my blog, I'll be sharing with you some interesting ideas and approaches from past experience and some more.
Subscribe to:
Posts (Atom)