well it easy to debug when your in a network. for me I use to do for debugging certain kind of problem on my network I just do the basics specially when the problem is on my printer.. like on my hp 640 fax inkprinter machine,
I'm really late in getting to this course, but can now really relate to the leaking dishwasher example. Last week we fixed the leak in my son's dishwasher. First replaced two inexpensive parts recommended by the manufacturer to no avail. Made a very good diagnoses of the likely component, only to prove in testing it was not the cause. More thinking led us to the actual problem which was simply cleaning the steam vent.
@JoeWojcicki: You asked if Testing & Debugging = Troubleshooting. The way I use the terms, Debugging and Troubleshooting are the same, both are trying to figure out what is wrong. Testing is to make sure things work right, and if they don't, then we move into Debugging/Troubleshooting mode.
@Ran: Isn't the lack of institutional knowledge a form of "language barrier"? When they called for help with "multiple issues that need and have immediate resoultions," the HP engineers couldn't give them those solutions because the outsource team couldn't understand what was being told them. Given sufficient time, money, and effort on both side, yes, a lack of institutional knowledge can be resolved. And the same holds true with foreign language issues.
@GStringham - The lack of institutional knowledge doesn't lend itself well to excuses. It can and should be resolved. Language, on the other hand, has no solutions beyond what you have mentioned. When dealing with multiple issues that need and have immediate resolutions to be given over the phone, failed communication can make a simple problem seem almost insurmountable.
@Ran: Language is just one of many factors that needs to be considered and budgeted for when planning a new product. I talked about the failed outsourcing experiment - that was to a company in the States so language was not a problem. But the lack of institutional knowledge, which was not fully understood beforehand, was the cause of that failure.
@THasham: HP has had to adjust their quality of the LaserJet because of market forces. Printer prices would go down. Someone else would sell a cheap printer that mostly works and could sell it because people were willing to buy it, even though the quality was inferior. It was hard, but we had to change our thinking, "It's not perfect but is it good enough?" So using plastic parts and cheaper materials lead to a different problem - we would wear out a printer before we could finish the entire test suite of tens of thousands of pages.
@Ran: One time I went over to Japan to work with the Canon engineers. It made for a great face-to-face visit. But I was also over to work on problems. We used a lot of diagrams on white boards, hand waving, saying key words, and having someone else nearby to do some rudimentary translations. We made progress because we were in the same room, could see each other's faces, and could draw and point. That is hard to do over a phone call. Troubleshooting over email took days. Face-to-face was better but I had to fly to Japan (which was a fun experience for me.)
The only time it crossed my mind to replace my 10 yers old B/W Brother's laserjet was these past few months, because of my willingness to print from my iPhone/iPad via the wireless radio. I still resist to move.
@luizcosta: The government has different goals than the consumer electronics market. They want their jet fighters and submarines to still work 20 years later. So they "overkill" on the procurement process to make sure those parts will still be around then. Apple does not want their iPads to last 20 years. If Apple used the same lengthy, drawn-out process to procure parts, today's iPads would only have black and white, 400x300 LCD screens.
ing experience in engineering at the system integration test level for a major corporation, I tend to agree with what was presented within your first day of lecturing. Having access to the old test plan and using it as a template for the next version of the same product line really helps out. Also many contacts with the others one the team keeps you in focus on where the result is headed. For management the big question was how many bugs did we find where the product did not perform as intended to. The list in Bugzilla grows as the team bonds tighter together and greater time is spent in fixing as many as possible before the drop dead date arrives.
I have been using HP laserjet 4 without problem to date and my coworker had already been through later model and had to replace them every two or three years lately... They are becomming cheap and useless. No offense to anyone though.
@GStringham - Thanks for the comeback. Using translators sounds like a good idea, but during troubleshooting efforts, that solution sounds like it can draw out the project to be quite lengthy. Any other suggestions?
I've had a few experiences with technical translations in the past few years, Yes, I agree that slang and jargon gets us into trouble. I also discovered that technical language is an issue. terms are not literal translations and need someone with the right background to translate into something meaningful.
Language is definitely a hurdle to deal with. We at HP worked with Canon in Japan. English was the language we used. But many Japaneze engineers knew very little English. So they hired technical translators to translate documents and emails. The translators were often native Japanese, so, though they had good English, it was not perfect. But we on the US side learned how to read and write "Japanese-English." We could not use slang or coloquial terms. We had to make sure our English was simple and clear. And we were successfull.
Gary, reminds me when I was Mgr of a Test group. Tried to have my team work with design to develop test strategies and plans for product ahead of time. Design groups always said they didn't have time. Once the product failed in test, they had plenty of time to figure out what went wrong.
Gary: Very important slice of any technology develpment. I have found a lot of information written about this topic around the procurement process used by the Pentagon and other government agencies, since the 80s. There has been a lot of resistance to adopt the formal methodologies. It seems everywhere you promose them, people tend to consider a "overkill." I personally don't think so, because only then, companie can seize product longevity. Can you comment on that?
I am aware that there are USB to serial and USB to parallel devices out there. At HP we would use a network to 16-serial port box to access 16 printers under test. We would remote log in through the network box and we have console access to the printers.
@MizianLab,..we had the same issue a couple of years back. But nowaday you can easily get USB to serial or parrall adapter on the market easily and if they are configure right they can be used in place of hardware serial or parallel port
With regards to using technology such as video conferencing for face-to-face, yes, that can be done, but it is hard to follow nuances, inflections, and watch others in the "room." But video is better than none.
Ran - a suggestion that we used in a previous company I worked with was to provide accent recent classes for a week when they join the project to help better communication, as they understand the US culture better
GStringham - As you know, many times a remote team may be in a foreign country. As such, there may be a language barrier. Communication is critical on projects but can be nearly impossible in such scenarios.
Do you have any suggestions in how to overcome such problems which can ruin project plans?
We are involved with lots of sophisticated Lab instruments which are equipped with parallel and serial ports. Now days to upgrade new software for networking between older equipment, we have to replace older computers and use Laptops which don't have parallel or serial ports other than USB port. Do you have any idea to solve this problem?
Gary - Any opinion about using technology (e.g. video conferencing) vs. an actual face-to-face meeting? Increasingly, we are being "encouraged" to leverage the technology instead of traveling to reduce overhead costs. This includes both client and internal team meetings. Personally, you can't beat a face to face over a cup of coffee.
what worked best for me was h/w, s/w, f/w and mech design, done almost in the same time and in house. it was fast and efficient. but before that, everybody knew what to do in big detail. additional meetings for sync or on the fly small changes helped a lot. but not everywhere can be done this way. you really need to have a very good and complex team for that.
WHEN TO START TESTING? In my experience developing formal software development, I learned that the best time to start with test, is when writing the requirement specification, when the requirements for test design are defined. When the programmers join the project, all those requirements are part of their development kit.
When writing software I find it helps to put simulation into the program, especially when I don't have access to the actual equipment. The simulation part is turned on by a setting in an ini file. I then have fake data to test the rest of the program.
The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.