I want to apologize. I haven't been blogging much for a while due to my Mom being, first in the Hospital, and now in a nursing home.
Things are settling into more of a routine so I should be able to blog more, but she does come first.
Thanks
Friday, April 18, 2008
Wednesday, March 26, 2008
Design Tools
From what I've seen, test engineers don't always do a good job of designing software. They just sort of code away until it's done. And if there is any complexity to the design, they code even harder until it's done. Not a lot of real design is done.
There are a lot of simple design methods that can be done for a better test set. Just a simple flow chart to layout the design is good at a minimum. Something like MS Visio or any drawing program can used.
Another design tool is to do what is called swim lane charts. This is where each separate item (i.e. UUT, Test Set, Other Computer) gets a lane and every time something is required of that item, communication to or from that item, some process/decision/operation block is put in that lane. It shows the interaction between each of the different items and the operation each item does.
UML is another design tool, especially when doing object orienting programming. I read about UML but not done design with it so I don't have a good grasp of it. I know it's a way of displaying objects and showing the interaction between them. The software engineers tend to use UML for their designs.
State diagrams are also really useful for showing transitions between states.
My main thought on all of this is don't just code away with little or no fore thought. Use your tools for a better test set software design, it will work better in the long run and be more maintainable.
There are a lot of simple design methods that can be done for a better test set. Just a simple flow chart to layout the design is good at a minimum. Something like MS Visio or any drawing program can used.
Another design tool is to do what is called swim lane charts. This is where each separate item (i.e. UUT, Test Set, Other Computer) gets a lane and every time something is required of that item, communication to or from that item, some process/decision/operation block is put in that lane. It shows the interaction between each of the different items and the operation each item does.
UML is another design tool, especially when doing object orienting programming. I read about UML but not done design with it so I don't have a good grasp of it. I know it's a way of displaying objects and showing the interaction between them. The software engineers tend to use UML for their designs.
State diagrams are also really useful for showing transitions between states.
My main thought on all of this is don't just code away with little or no fore thought. Use your tools for a better test set software design, it will work better in the long run and be more maintainable.
Monday, March 17, 2008
Test and a lack of understanding of software.
“Software is a necessary evil”, a statement I’ve heard several times made by a test engineering manager. Other of my favorite statements by managers are “Test development is the development of hardware…and then you do software” and “We have no software problems” as everyone developing software laughs or shakes their head.
It’s absurd to think of test development in one dimension, the hardware dimension. If you’re involved with CMMI, Processes, etc. you’ll know that it all started with problems with software, or the mis-understanding of software and it's development. Manager’s didn’t know how software worked, or what it takes to develop it. Software practitioners were just “winging it” and learning by tribal knowledge. Projects were brought down by software problems.
Test engineers developing software for ATE need to at least come into 90’s and develop software using at least some standard software engineering approaches. Simple things such as keeping the requirements. Test requirements very often involve hardware and software and not exclusively one or the other. That’s fine, you still need to understand the software portion of the requirement.
The requirements need to be understood and traced up to any other higher requirement or derived requirement of something in the UUT that is required to test. This can be done in a tool, such as requisite pro or DOORS, or in an Excel spreadsheet. But you need to know what you’re testing.
Other tools that can help is a tool called Requirements Gateway by NI. I haven't used it personally, but it seems like a useful tool.
More test tool stuff to come
It’s absurd to think of test development in one dimension, the hardware dimension. If you’re involved with CMMI, Processes, etc. you’ll know that it all started with problems with software, or the mis-understanding of software and it's development. Manager’s didn’t know how software worked, or what it takes to develop it. Software practitioners were just “winging it” and learning by tribal knowledge. Projects were brought down by software problems.
Test engineers developing software for ATE need to at least come into 90’s and develop software using at least some standard software engineering approaches. Simple things such as keeping the requirements. Test requirements very often involve hardware and software and not exclusively one or the other. That’s fine, you still need to understand the software portion of the requirement.
The requirements need to be understood and traced up to any other higher requirement or derived requirement of something in the UUT that is required to test. This can be done in a tool, such as requisite pro or DOORS, or in an Excel spreadsheet. But you need to know what you’re testing.
Other tools that can help is a tool called Requirements Gateway by NI. I haven't used it personally, but it seems like a useful tool.
More test tool stuff to come
Monday, March 10, 2008
Test Engneers
Most people dealing with Automated Test Equipment (ATE) call themselves “test engineer’s” (TE) or test people. However, since there is typically no degree’s in test engineering, they get degrees in Electrical engineering or software engineering or computer science and engineering and then are recruited in the “test group”. I’ve seen most TE’s come out of the group with EE degrees, a lot of SW Engineers don’t like to touch hardware. But then a lot of EE’s feel that doing software makes them dirty or is FM (Freaking Magic) and only took minimal, how to code classes in college.
Since most TE’s are out of EE the software portion of ATE is “hacked” out (the old-school meaning of hack, to bang out code until it works) the code is less than optimal. In other-words, it works for the normal case and little else.
Some people who have software degrees or have been doing software for a long time work toward having more software discipline in there ATE code, but it still tends to be lacking in most area’s. Software tools tend to go unused or limited use, some believe an IDE is all that is needed.
There’s more to developing software than just an IDE and some time. Tools are available to help develop code. I think software tools aren’t used in test due to a lack of understanding, lack of knowledge, and lack of patience.
Since most TE’s are out of EE the software portion of ATE is “hacked” out (the old-school meaning of hack, to bang out code until it works) the code is less than optimal. In other-words, it works for the normal case and little else.
Some people who have software degrees or have been doing software for a long time work toward having more software discipline in there ATE code, but it still tends to be lacking in most area’s. Software tools tend to go unused or limited use, some believe an IDE is all that is needed.
There’s more to developing software than just an IDE and some time. Tools are available to help develop code. I think software tools aren’t used in test due to a lack of understanding, lack of knowledge, and lack of patience.
Sunday, March 2, 2008
Time to come into the 90s
I apologize for not writing in a long time. I've had family illnesses, Mom going into nursing home and all the financial items that come along with that...things like that. It's not an excuse, it's part of life. I asked myself, what is important to me...there was no contest, it was family.
While real-life has gone on personally, work-life has continued, too, since I like to eat and live indoors. One of my biggest pet-peeves that has been affecting me is people are stuck in "the way we've always done it." It's really just fear, the new way of doing things may affect their job, may affect the bottom line, they may not really understand new ways of doing things.
Have you ever thought where we'd be without evolution? Whether you believe in Creation or Evolution (I personally believe in Creation but we Evolved from there) businesses, business practices, business methods evolve. That's why some business that don't change with the times die-off (ex. Braniff air-lines and Remington Rand Typewriter company) and others change, evolve and continue to thrive (IBM and Harley Davidson Motorcycle company). People in all businesses need to learn to change and evolve or die off. People within the business need to evolve to keep the businesses evolving.
The people who are stuck in the 70s and 80s need to come into the 90s or their businesses will stay in the 70s and 80s. They need to change but I wouldn't want to push them to fast by trying to get them to come into the 2000s.
They need to evolve, try to get up to date in their thinking,
New ideas need to be tried, at least ideas like Object Oriented Programing (OK, that's not new but it is to them), Agile programming, using ASICs and FPGAs. At least get past vacuum tubes and transistors. All this is not magic, it's just evolution, or coming into the 90s from whatever decade you're stuck in.
It is a disservice to the people who work for the less evolved, too. If you want to compete in this world you at least need to be involved in this world.
I don't know how to get these people up to date, or even close to up to date, but for the businesses sake and their sake, it needs to happen.
While real-life has gone on personally, work-life has continued, too, since I like to eat and live indoors. One of my biggest pet-peeves that has been affecting me is people are stuck in "the way we've always done it." It's really just fear, the new way of doing things may affect their job, may affect the bottom line, they may not really understand new ways of doing things.
Have you ever thought where we'd be without evolution? Whether you believe in Creation or Evolution (I personally believe in Creation but we Evolved from there) businesses, business practices, business methods evolve. That's why some business that don't change with the times die-off (ex. Braniff air-lines and Remington Rand Typewriter company) and others change, evolve and continue to thrive (IBM and Harley Davidson Motorcycle company). People in all businesses need to learn to change and evolve or die off. People within the business need to evolve to keep the businesses evolving.
The people who are stuck in the 70s and 80s need to come into the 90s or their businesses will stay in the 70s and 80s. They need to change but I wouldn't want to push them to fast by trying to get them to come into the 2000s.
They need to evolve, try to get up to date in their thinking,
New ideas need to be tried, at least ideas like Object Oriented Programing (OK, that's not new but it is to them), Agile programming, using ASICs and FPGAs. At least get past vacuum tubes and transistors. All this is not magic, it's just evolution, or coming into the 90s from whatever decade you're stuck in.
It is a disservice to the people who work for the less evolved, too. If you want to compete in this world you at least need to be involved in this world.
I don't know how to get these people up to date, or even close to up to date, but for the businesses sake and their sake, it needs to happen.
Sunday, December 2, 2007
Good Enough for DAQmx
Define good enough software. It's a very subjective answer, what's good for th developer may be no good for the customer, even though it was eloquently implemented. What's good for the customer may not be good for the developer, it's what the customer wants even though the developer had to use practices he/she tries to avoid.
Saying that, I've been trying to use National Instrument DAQmx software. As a customer of NI I have to think it's good for the developer. It's probably eloquently implemented, a mastery of object use, and development style. It's probably great if you use it all the time and learn it's idiosyncrasies. But, as a part time user, it's not that great.
My problem with it is they tried to cram all operations for several different classes of devices (I.e Digial I/O, Counter/Timers, A/D, etc) into one set of drivers. Some functions have nothing to do with some boards. You can call a function to start a clock on a board when the board has no clock. You can't tell until the function is run.
The DAQmx function set is so feature rich that it will do almost everything for you except wash the dishes. But in order to Read 1 bit off a Digital I/O board it takes at least 4 calls although I did it (accidentally) in 5 with no complaints from the system. I think it's because I had to set up the clock I didn't use for the operation. The main function that actually does the work of reading the bit takes 8 parameters (I think, after about 5 parameters I usually get tired of counting) and I really only use 3 of the parameters.
I'm sure there was some elegant programing involved, but I don't see it as I'm struggling figure out how to read a bit.
Saying that, I've been trying to use National Instrument DAQmx software. As a customer of NI I have to think it's good for the developer. It's probably eloquently implemented, a mastery of object use, and development style. It's probably great if you use it all the time and learn it's idiosyncrasies. But, as a part time user, it's not that great.
My problem with it is they tried to cram all operations for several different classes of devices (I.e Digial I/O, Counter/Timers, A/D, etc) into one set of drivers. Some functions have nothing to do with some boards. You can call a function to start a clock on a board when the board has no clock. You can't tell until the function is run.
The DAQmx function set is so feature rich that it will do almost everything for you except wash the dishes. But in order to Read 1 bit off a Digital I/O board it takes at least 4 calls although I did it (accidentally) in 5 with no complaints from the system. I think it's because I had to set up the clock I didn't use for the operation. The main function that actually does the work of reading the bit takes 8 parameters (I think, after about 5 parameters I usually get tired of counting) and I really only use 3 of the parameters.
I'm sure there was some elegant programing involved, but I don't see it as I'm struggling figure out how to read a bit.
Friday, November 23, 2007
Without testing, how can you be sure?
There's a lot of questions about "Is testing really needed". By the way, the correct answer is Yes. It seems that during development most developers say they'll develop the tests for their own equipment. This will ensure the unit won't be tested well.
Developers don't necessarily design for testability. Quite often they design connector's that can't be mated to easily, circuit cards that are embedded into the system to where they can't easily be tested, or circuit cards that just hard to deal with.
Designers know what parts of their design is weak and typically test in a way that their circuit will pass. Not consciously, but more of a sub-conscious because they don't want to see their baby fail. Or testing to what is designed and not in a way to truly verify the design.
I say testers are needed and need to be brought in early if they are to be able to help. Also, since quite often management don't see proper testing as a necessity, the test budget and schedule is shorted or cut to the bone. This will hamper the the testing effort and typically cause shotty testing of a unit.
If shotty or only partial testing is desired before sending a unit out to a customer, bring testers in late, or not at all. If you want to ensure the customer is satisfied, bring in the testers early and let them make sure a good job is done.
Developers don't necessarily design for testability. Quite often they design connector's that can't be mated to easily, circuit cards that are embedded into the system to where they can't easily be tested, or circuit cards that just hard to deal with.
Designers know what parts of their design is weak and typically test in a way that their circuit will pass. Not consciously, but more of a sub-conscious because they don't want to see their baby fail. Or testing to what is designed and not in a way to truly verify the design.
I say testers are needed and need to be brought in early if they are to be able to help. Also, since quite often management don't see proper testing as a necessity, the test budget and schedule is shorted or cut to the bone. This will hamper the the testing effort and typically cause shotty testing of a unit.
If shotty or only partial testing is desired before sending a unit out to a customer, bring testers in late, or not at all. If you want to ensure the customer is satisfied, bring in the testers early and let them make sure a good job is done.
Subscribe to:
Posts (Atom)
