Min Kwan Park's bLog

Join on new team

mkpark — Wed, 17 Oct 2007 03:34:00 GMT

After 10.5 years in DevDiv for Visual Studio (from VS6 to VS2005), I decided to move onto the different world.

and now I joined AdCenter team since last Monday. over 2 days, I start feeling the differences between shrink wrapped product and on-line/service based team. and it makes me really excited. Hopefully, I can share my experience more on the way.

Catch your elusive bugs..

mkpark — Tue, 13 Mar 2007 05:03:00 GMT

Few weeks ago, I did presentationt to my QA team about how they can found elusive bugs faster and easier. I think that this information can be useful information to any one who tests a Windows application.

Please feel free to share your opinion on this PPT.

My new posting in Korean...

mkpark — Wed, 27 Jul 2005 09:57:00 GMT

One of MVPs in South Korea has a very interesting web site about debugging. and he generously lets me write somethings in Korean on his site.

the site name is http://www.debuglab.com. if you can read in Korean, come over there and check out. :)

We are building city than just a building...

mkpark — Thu, 02 Jun 2005 06:46:00 GMT

Few weeks ago, I got some time to think about how we should approach to our S/W design/test engineering.

IMHO, in many cases, we end up like building construction. I think that it is making sense to see an application as a building which has many internal components and aspects. it has fairly complex interdependency between each features and components. However one thing, which I could see in many chaotic or messy projects in engineering stand point, is that team was just focusing on how to build a building and forget about how each buildings in the over all blue print can work together.

We need to remember that we are building harmonic echo system as one big city than just one small application.

New team....

mkpark — Tue, 25 Jan 2005 08:46:00 GMT

About 3 weeks ago, I moved to new team for Dynamic analysis. I'm still QA but this time, I have my own team to lead. I hope that I can lead this team to right direction and can provide great product to customers. ;)

Looking for VS Beta1 debugger issues?

mkpark — Thu, 29 Jul 2004 03:40:00 GMT

Probably, many of my co-workers are adding these kind of information into their blogs. but I decided to make my own list again. so if you want to see, check “Known debugger issues in VS8 Beta1” article.

my opion on TDD...

mkpark — Sun, 18 Jul 2004 10:40:00 GMT

Around me, I'm seeing some people who are very deep into TDD.

Well, as QA, whenever I heard their mythical belief on TDD, It makes me think why TDD is believed that much.

TDD, it sounds like very testing oriented. yes it is. I agree. and it is good approach. but is it all? and can it find all issues? I don't think so. but many of TDD believers want to believe that it is the final solution for everything.

IMHO, I think that it is just a trend which is good trend because it is focusing on the quality of code at the beginning. however, I don't think that it is everything or final thing which can solve every problem or prevent all issues from your code.

Adding to TDD, we need to understand the bigger picture. you should see the forest with trees, too. otherwise,you will lose harmony in your overall design and process.

While you do test your program...

mkpark — Wed, 14 Jul 2004 11:29:00 GMT

In most times, while I do dogfood/test VisualStudio 2005, I put them under debugger to monitor several things...

- First Chance AV

- Unhandled Exception

- Userbreaks from System to process under debugger

- Appverifier(a tool which is part of Application Compatibility Toolset) notification via Int3(User break)

*ACT is downloadable from http://www.microsoft.com/downloads/details.aspx?FamilyID=7fc46855-b8a4-46cd-a236-3159970fde94&DisplayLang=en

If you are using debug build for testing, you don't have to run your app under debugger in most of cases because your debug build may have enough asserts to show errors in early stage.

However for many QAs, using retail build which will be shipped to customer is more general. so monitoring app with Debugger and appverifier is very interesting ways to do.

For example, I saw fair amount of issues that the thread by RPC call crashes and the AV caught by RPC handler. so caller may handle it without actual crash but it ends up as random and catastropic errors. however under debugger, you can see this kind of issues. so you can easily figure out the real cause of random issues.

Adding to this, with various Appverifier options, you can expose memory and handle issues much easier by reducing the tolerance of memory/handle mis-usages. it is really useful to improve overal stability of your product.

What is your favorite feature from VS debugger?

mkpark — Fri, 02 Jul 2004 00:17:00 GMT

I was always wondering which feature is your favorite feature and why? could you add your comment? :)

No title.....

mkpark — Sat, 24 Apr 2004 03:37:00 GMT

Well, My first computer experience was from my 5th grade in elementary school(I attended to school in South Korea. so the school system may not be same like US. anyway, I was 11year old.). it was MSX(from japan) with GS-Basic and AppleII(I guess). those machines were so interesting and exciting to young geeky boy.

That time, I always dreamed to make games and some interesting hacking tools. :)and when I first met the DOS. I was too excited because I could save something on other than tape. over middle school, I learned fortan and Basic. it was quite interesting experience to see how I can make computer to do something for me. and I always wondered who made that kind of S/Ws. when I first used Turbo C(it might be 1.0, I guess) in high school. I dreamed to meet the people who make that kind of things and to work for/with them someday.

Now after quite a while later, I'm working for Visual Studio which is most powerful dev tool in the world(at least in my opinion.) and around me, there are many people who I used to be eager to work for/with. it is quite interesting feeling. Life is really interesting to live. :)

My baby wants to play with my notebook compueter....

mkpark — Tue, 13 Apr 2004 11:21:00 GMT

I have a daughter who is 14 month old now.

From few months ago, suddenly she started to play with my notebook computer. so whenever I turn it on, she comes to me and just stare at me with hopeful eyes asking me to put her up on my lap and let her play with my notebook. well... I'm not sure whether it is good for eyes and developement. but what I can see is that she loves to mimic what I do normally. so I'd better be good role model for her to follow.

Anyway, back to what I want to say, sometimes I'm really supprised by what she did on the machine. sometimes, she turned it off with proper key sequences and sometimes she launched several apps and play with them. and does many interesting things. I know it just happens by chance because she always just smashes keyboard with her little hands. but it is still amazing to see the result. :)

Last minute issues...

mkpark — Sun, 04 Apr 2004 02:21:00 GMT

You may read many articles and books about Testing and many of them said that the earlier you find issues, the better overall.

Is that really true? well, based on my experience, Yes, it is true. However it is always possible for all issues? No it is not.

There are some issues which we may find only when the product and QA are mature and ready.

I'm not trying to say that QA doesn't have to be part of early planning and reviewing to find out issues. Yes it is very important to find out design level defects. it will help to improve the productivity of overall process and it will reduce the issues later. However, even with all efforts, you will encounter the last minute issues when product is mature and fully integrated, also QA(team or person) have enough knowledge about the product in user's perspective. (it is different topic to talk about why QA can't understand everything at the beginning. so I'll talk about this later.)

Why? in my opinion, it is very obvious that the problem was not there at early stage of product or it was hidden some way and waits until the time comes. it may sound strange. but in my opinion, it is true.

if so, how can we reduce these last minute issues? Well, I don't think that there is gold bullet for these. but I think that there are some things that we can consider the below for improvement.

- Keep in mind the integration at the beginning at design level and QA should look at the level of each individual tree and also the big forest. not just your component integration, but also at the final product level. it doesn't have to be done by everyone. but some one in the org should look into this as early as possible.

- Have better communication channel between teams. modern S/W is very complicated and has complex dependency between components. so if you don't understand the changes and progress of depending components, you can do properly QA work at all. so the information should be delivered appropriately.

- Education on the base technology of the product for QA. why? the more you know, the wider and deeper you can see.

- Have various types of user scenarios in various level. you need to have feature level user scenario, component level, and integration level and real world user level scenarios. just doing feature level unit test will not let you avoid the issues.

- Nothing is wrong. you just need to validate what you are assuming... Generally we assume how the product will be used. and QA team is directed to focus on main line scenario all times. Yes, I agree that it is important and proper way to do approach to product with limited resource. However, we need to validate our assumption in someways like beta feedback and news group monitoring or userability study. Well when you see the result, you will be supprised by the result. there are many different ways for our customers to do their work with product.

There are many things to consider besides these. Anyway, important thing is that we need to understand the process and stage of product and we need to prepared for coming stage and do proper testing.

My habits from my job...

mkpark — Mon, 29 Mar 2004 10:08:00 GMT

After being QA, I got some habits in my normal life... :)

- Alway, don't believe anything until I see and test it.: Well, it may not be from my job. but I got more tendency not to believe anything at the beginning.

- Try to get repro steps even with very dangerous cases...: One time, I got problem with my car on freeway. I was driving on freeway, and my car started not to accelerate and losing power and I could see an warning light on my console. after turning off and on engine again, it did disappear, but I tried to repro it. and I got the repro steps and finally I could convince my service guy to fix it. (it was actually recall class issue which was recalled about a 10 month later.)

- Want to know how it is changed.: Always, my first question to my dev side co-worker after they fix bugs is how you fix it? and now even in my normal life, I want to know what the difference is between before and after for any type of changes.

- Find bugs in many products which I use: With any of my toys, I always try to find out any issue. and try to break it via logical defects. and I could see many of interesting results from them. my wife doesn't like that because I almost broke some kitchen wares. :)

I may get more habbits from my job. anyway, it is interesting to see how job can impact on people. :)

Testing System vs Testing component....

mkpark — Fri, 12 Mar 2004 05:31:00 GMT

Recently I got question on myself about how I do balance between System level testing and component level testing.

First of all, I may need to notify that I'm QAing on heavily UI involved components which are working with many other components from other teams.

System level testing means that you are testing your product like customer at the top level and looking for the harmony with all different components. and component level testing(or Unit testing) means that as you are focusing on the functionality of the component without considering much on how it works with others.

Well, in my opinion, both side has their own importance. and it is not easy to say which one is better. but in practical way, System level testing is more important for most of S/W development cycle which doesn't have enough resource to test component thoroughly, because we can ship something which is working in a good enough degree for general cases with some glitches in specific cases but if each component is working great alone but not working together, Well we did something wrong and we can't ship the product.

However, I don't think that this approach is always correct and proper. there are areas which we should take care of every detail at the component level first like airplane control software, Library codes, and etc. also even though I emphasized the system level testing, I think that certain degree(definitely enough amount; how much is enough is different question) of component level testing is necessary and should be done.

QA should find out balance about how to distribute the limited resource for each side in given situation. and it should be decided as early as possible at least in guide line level.

Are you looking for the latest edition of "The VS7 Debugger doesn’t work. What can I do?" document?

mkpark — Wed, 10 Mar 2004 02:04:00 GMT

Well, while we are moved to this weblog, the link of my document is just gone from gotdotnet. and I got many mails from people about whether the latest document is.

so I moved it on my weblog. it is live!!! whenever there is any new issues from customer, I updated it. so please enjoy it. if you want to get word format doc with pictures, please send me mail. I'll forward it to you.

the link is http://weblogs.asp.net/mkpark/articles/86872.aspx