- January 2018
- December 2017
- November 2017
- October 2017
- June 2017
- November 2016
- July 2016
- February 2015
- January 2015
- December 2014
- October 2014
- September 2014
- June 2014
- January 2014
- July 2013
- May 2013
- April 2013
- February 2013
- November 2012
- August 2012
- April 2012
- December 2011
- November 2011
- October 2011
- September 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- January 2011
- December 2010
- November 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- Air International (Air Enthusiast) Index
- Bill Abbott’s Current Resume, 2 page version
- Five of my favorite John McPhee books:
- Modeling Projects Update
- Paint and finishing for model builders
- Porsche 911 GT1 1996, 1997 “evo” and 1998 references
Category Archives: Tools
I wrote this some years ago. I should simplify the context and incorporate what I reference from the OP and other responders, so that it stands alone. But this has meaningful observations which took effort to reach, so I’m putting a copy up here to start with.
Ziv, the questioner asks: ” … how would one proceed if he wants to learn QA?
More specifically, a programmer who wants to learn about the QA process and how to manage a good QA methodology. I was given the role of jumpstarting a QA process in our company and I’m a bit lost, what are the different types of testing (system, integration, white box, black box) and which are most important to implement first? How would one implement them?“
There are simple rules of thumb.
Try what the manual says. Install and run on a clean target, user license, the works. Does it work? Did you have to add anything not covered in the manual?
Are all the default control values usable? Or is there something that’s wrong, or blank, by default and always has to be changed?
Set every value in the user interface to something other than its default. Can you detect a difference caused by the change? Is it correct? Do them one at a time, or in the smallest sets possible, to make the results clear.
Set every value in the user interface to a second, non-default, value. Change everything at once. Can you detect the difference? Is it correct?
One by one, do something to cause every error message to be generated. Do something similar, but correctly, so that no error message is generated.
All of the above depend on changing a condition, between an “A” case and a “B” case, and that change having a detectable result. Then the “C” case produces another change, another result, and so forth. For 10 tests, you need 11 conditions. Using defaults as much as possible is a good first condition.
By now you’ve got a list of things to test, that you recorded, and results, that you recorded, and maybe some new bugs. Throw something big and complicated at the solution. Give it a file of 173000 words to sort, paste a Jane Austin novel or some telecommunications standard 100 pages long, a 50MB bitmap graphic, 3 hours of streaming video. Open the performance monitor and get CPU-bound, or I/O bound. For an hour. Check memory use: always increasing? Rises and falls?
Take the list of bugs closed in the last week, month, sprint, etc. Check them. All. Are they really fixed?
Keep track of what to do, how it worked on what version/release/build/configuration, open and closed bugs, what controls have been set or changed, what data, test files or examples have been used, etc. is all part of Quality world. Keep results as tables in a spread sheet, make version controlled backups / saves.
Someone writing software, or any one creating anything, has an idea of what they’re trying to make. The quality process starts with expectations. Requirements, specifications, rules, or another articulation of what’s expected. Then there’s the solution, the thing offered to perform, assist, enable or automate what’s expected. Then there are tests, operations, examples, inspections, measurements, questionnaires, etc., to relate one or more particular solution(s) to (relevant) expectations. Finally, there’s an adjustment, compensation, tuning, correction or other positive action that is hoped to affect the solution(s).
When one writes software, one has a goal of it doing something, and to the extent that’s expressed, the behavior can be checked. Hello.exe displays “Hello World” on a screen. “2**150” in the Python interpreter displays, “1427247692705959881058285969449495136382746624L”. Etc. For small problems and small solutions, its possible to exhaustively test for expected results. But you wouldn’t test a word processor just by typing in some words, or even whole documents. There are limits of do-ability and reason. If you did type in all of “Emma” by Jane Austin, would you have to try her other four novels? “Don Quixote” in Spanish?
Hence an emphasis on expectations. Meeting expectations tells you when the solution is complete. My web search for “Learn Quality Assurance” just returned 46 million potential links, so there’s no shortage of opinions. Classic books on the subject (my opinion, worth what you paid for it:) include
Take 5 minutes to read some of the Amazon reviews of those books and you’ll be on your way. Get one or more and read them. They’re not boring. Browse ASQ, Dr. Dobbs, Stack Overflow. Above all, just like writing software. DO it. Consider the quality of some software under your control. Does it meet expectation? If so, firm hand-shake and twinkle in the eye. Excellent!. If not, can it be corrected? Move to the next candidate.
I like the Do-Test-Evaluate-Correct loop, but its not a Universal Truth. Pick a process and follow it consciously. Have people try the testing, verification and validation steps described in the language manual they use most frequently. Its right there on their desk, or in their phone’s browser.
Look at your expectations. Are they captured in a publicly known place? With revision control? Does anyone use them? Is there any point where the solutions being produced are checked against the expectations they are supposed to be meeting?
Look at your past and current bug reports. (You need a bug tracking system. If you don’t have one, start there.) What’s the most common catastrophic bug that stops shipment or requires an immediate patch? Whats the most commonly reported customer bug? What’s the most common bug that doesn’t get fixed?
Take a look at ISO 9000 process rules. Reflect on value to your customers/users. Is there’s a “customer value statement” that explains how some change affects the customer’s perception of the value of the solution? How about in the requirements?
By “the QA process”, you could mean “Quality Assurance”, versus “QC”, “Quality Control”? You might start with the http://www.ASQ.org web site, where the “American Society for Quality” dodges the question by not specifying “Control” (their old name was “ASQC”) or “Assurance”.
Quality; alone, “assured” or “controlled”, is a big idea with multiple, overlapping definitions and usages. Some will tell you it cannot be measured in degrees- its present or not, no “high quality” or “low quality” for them. Another famous claim is that no definition is satisfactory, so its good to talk about it, but avoid being pinned down in a precise definition. How do you feel about it?
The original posting is at http://programmers.stackexchange.com/questions/255583/how-does-one-learn-qa/255595#255595
Linked-in are now listing ala-carte qualifications which one can endorse one’s acquaintances on, or be endorsed by them. No surprise, 20 people say I’m good at “hardware”, which is my highest endorsement. What I want to draw your attention to here is that if you hover your pointer over each of the possible qualifications, Linked-in will show you a working definition and the year-to-year trend on people who say they do-have-know-practice-are-qualified-in the specific item.
Not so surprising, people saying they know ‘hardware’ are down year on year… also C, C++, software engineering, Perforce, customer support, regression test, unit test, and so forth. VMware is 0% – neither up nor down over last year.
Agile Methodologies are up, Windows 7 is way-up, Python is up, Scrum is up. The other 44 categories, on my list, not including VMware at 0 and Windows 8 which doesn’t have a year on year trend, are down.
So, among people who list qualifications similar to mine, the majority and growth area are Python users, on Windows 7, employing Scrum and Agile project management methods.
Your choice whether that’s:
a) what everyone wants;
b) what people looking for work think they need;
c) some cross section of professionals on Linked-in.
I think its worth noting in passing, but not worth a lot of study. But it is a curiosity.
Here’s the punch line:
In Java, Prussia can extend (“be a”) one of the super-classes, Holy, Roman or Empire, but only one. Prussia can implement the other two as interfaces, but only with methods and fields uniquely its own. If Prussia is to be Holy, be Roman and be an Empire, the strictly hierarchical relationship of those three super-classes has to be worked out separately and in detail, in advance. I can only imagine Herr von Bismark would approve.
And the whole magilla:
1) What is the difference between an interface and an abstract class?
An abstract class defines data (fields) and member functions but may not, itself, be instantiated. Usually, some of the methods of an abstract class are abstract and expected to be supplied by a sub-class, but some of the methods are defined. Unless they are final, they can be overridden, and they can always be overloaded. Private parts of an abstract super class, for example, data, are not available to a subclass, so access methods (public or protected) must be used by the subclass. An abstract superclass is “extended” by a subclass. A given subclass may only extend one super-class, but a super-class may extend another super-class, in a hierarchy. (This avoids the complexities/difficulties of multiple inheritance in C++)
An interface is a proper subset of an abstract class, but has a different scope and use. An interface has ONLY abstract member functions and static, final, fields, aka constants. Any subclass has to provide all the variable fields and code which implements an interface. The implementing class cannot override the interface’s member signatures – the signatures are what the interface *is*. It is possible to overload an interface’s signatures, adding or subtracting variables, changing return or variable types, but the overloads do not satisfy the requirements of the interface. The implementing class(s) must contain actual member functions to satisfy all of the signatures in the interface, because there is no default, no code in the interface. As used above, a given class ‘implements’ an interface, it does not ‘extend’ it. These limitations to an interface allow a given class to implement more than one, which retains most of the utility of multiple inheritance without, as it were, opening Plethora’s bag. (grin)
For example: In Java, Prussia can extend (“be a”) one of the super-classes, Holy, Roman or Empire, but only one. Prussia can implement the other two as interfaces with methods and fields uniquely its own. If Prussia is to be Holy, be Roman and be an Empire, the strictly hierarchical relationship of those three super-classes has to be worked out separately and in detail, in advance. I can only imagine Herr von Bismark would approve.
Thanks to my beloved wife Jean, I got a Dragon Apollo 11 on the Moon kit, for Christmas! 1/72 scale, new tooling (same as their die-cast metal collectable?)
The short form on real, as-flown-in-1969, surfaces and finishes:
The actual Apollo Command module was covered with strips of mirror finish aluminized plastic micrometeoroid shield and thermal insulation, on the visible surfaces. The ablative heat shield, not visible until the CM and SM are separated, is said to have been painted a light gray color. During re-entry to Earth’s atmosphere, the mylar was mostly burned off and a light-gray painted structure under it became visible. Below that paint appears to have been a composite honeycomb material. I think it is unlikely that the actual pressure vessel that the crew lived in touched the outside surface except at the hatch edges.
In pictures of the remaining, unused, Apollo CSM (the emergency rescue vehicle for Skylab), you can see the stripe pattern of the plastic tape on the CM exterior, but in contemporary photographs, it looks like one piece of mirror polished aluminum. Like an American Airline’s jet airliner.
The fold-flat handles on the outside of the CSM, for astronaut Extra-Vehicular Activities (EVAs) were painted a glossy yellow, like the similar hand-rails on the the Hubble Space Telescope.
The docking capture and latch mechanism mounted on the outside of the tunnel, above the front hatch of the CM, is primarily titanium-looking metal, with a chromed, presumably retractable or spring loaded or damped, shaft. There are darkened metal handles in the mechanism, probably painted or anodized a dark blue dark gray or black.
The inside of the tunnel itself, behind the docking capture mechanism, is light gray with 12 blue-anodized cylinder-topped arms at the top, some black and some other colors of boxes, and wires,
The Service module exterior was painted with an aluminum paint, except for radiator areas fore and aft which were white, two “ram’s horn” antennas that were white or light gray, and 24 narrow stripes (about 25%) on panels under the RCS thrusters. The area under “United States” may or may not have been light gray, and many labels on the exterior appear to be black text on light gray background.
The main engine exhaust bell is complex, but a bluish gray for the biggest, lower, part, outside, and reddish gray for the upper part, outside, is a good start. The top of the bell joins the reddish part at a flange, with bright bare metal fasteners by the dozen. The top of the bell, the last part visible beyond (below) the Inconel heat shield, is wrapped in the mylar and-or “H-film” ( aka “Kapton”) insulation and micrometeoroid shield. The back of the CM is mostly covered by 4 stamped quadrants what looks like thin Inconel nickel-copper high temp metal. The furthest outer edge of the end of the Service Module is painted with aluminum paint just like the sides.
The Lunar Module has two very different areas of finish: The descent (lower) stage is primarily wrapped in thermal insulation / micromedeoroid protection, a multilayer collection of Kapton (“H film”) and Mylar, and other, exotic, things, with metal evaporated/ plated on them for protection. A lot of what looks ‘black’ is actually a black-finished foil or mylar.
The descent engine has a medium gray exterior and nestles in an Inconel-lined cavity in the descent stage.
The ascent (upper) stage of the Lunar Module is about half black-finished and half anodized Aluminum. Yes, the Aluminum looks like its dark, like Titanium, or has a distinct gray-beige-green tone. All true, many have remarked on the hard-to-describe colors. Grumman’s construction documents for the whole thing, facet by facet, are on line, and they specify Phosphoric acid and Sulfuric Acid anodizing of the various aluminum alloy pieces. Some Mylar or “H film” wrapping is on the the outside of the ascent module. The ascent engine has a semi-gloss white exterior, with a textile-like “wrapped” texture. This may be thermal insulation, similar to the thick batts of insulation wrapped around the F1 engines of the Saturn V first stage.
There are two dish antennae on the ascent stage, Both have white-painted dishes and are generally black otherwise. The antenna directly above the lunar egress hatch and the front windows has black foil everywhere except the inside of the dish. The signal radiator in the center of the dish is white.
The antenna off on the starboard side of the ascent stage has a semi-gloss black mechanism and flat black on the back on the dish. Black, also, on the 4 legs and the forward reflector in front of the dish.
In more detail:
The Reaction Control System (RCS) engine nozzles on the CM have an oxidized copper color in their throats, and a slightly corrugated texture. Photos of post-re-entry CMs show a ring of the same oxidized copper color outside the nozzles, but the aluminized mylar covers these rings up to the edges of the RCS engine bells.
The forward and side windows for the two outside crew stations have black anti-glare finish around the windows, and red-orange silicone seals at every layer of the windows.
Below or behind the port side windows and the crossed RCS nozzles are a pair of drain valves, white 5/8 spheres with gold-toned dots at the outside. A very similar purge valve is installed on the starboard side of the side hatch.
On both sides, below windows, RCS nozzles, etc and the edge of the ablative re-entry shield, there are translucent white dots. Under the Mylar there are black partial circles around these two translucent circles,. On the Service Module, there are matching white partial circles painted on the fairing at the top edge of the SM
A minor (very minor) mystery is what kind of plastic the reflective stuff on the CM is. The expected temperature range in the space environment was wider than NASA was comfortable using Mylar, generally, uncovered, in the thermal insulation blankets covering the LM Descent Stage. Therefore, the outer layer of those blankets is always Kapton (“H film”), which is usable over the expected temperature range. Of course, a blanket of up to 25 layers of plastic, using microthicknesses of vacuum deposited metal for insulation, is fundamentally different from a pressurized honeycomb structure wrapped with a layer of glued-on plastic tape. Maybe the thermal mass and inertia of the CM (and the slow-rolling passive thermal control regime) kept conditions on the outside of the CM suitable for Mylar, Maybe the CM plastic has the metal side “out”, unlike the majority of LM applications which are generally plastic side out (hence the gold-amber color: its not gold foil, its aluminized Kapton with the metal in and the plastic out.
Inside the main engine exhaust bell is complex. At the bottom, inside the bluish gray outside, are 16 dark metal petals with strong textures. Inside the reddish-gray part of the bell are a set of 6 petals and then a solid ring- all a glossy dark color. Above the dark, solid, ring, is a white metal ring, something like aluminum colored. Above that is an orangey brown and then at the peak of the engine is a light, metallic-finished plate with 5 stamped spokes and a central cap.
How I plan to reproduce these colors:
The glued-flat aluminized mylar on the real thing doesn’t look like any paint, even mirror polished aluminum. It looks like mylar, darker than polished aluminum. I have seen photos on-line of Apollo CMs finished in Bare Metal Foil, in the correct striped pattern. But I don’t see the stripes unless I look very closely in the 1960s photos- they’re easy to see in flash photos taken today, on the leftover CSM lifeboat for Skylab that never flew. But not in pictures of Apollo 11, or 15, or any of the other hardware that was flown.
Sooooo: Bare Metal Foil remains possible, or very thin aluminum foil, polished and clear-coated. “Chrome” spray paint would not be a bad choice. Having the kit part polished and then vacuum coated with aluminum would be very close to the real thing. Brush-painting Testor’s Chrome Silver oil-based paint or another similar non-water-based product is also a thought – the occasional brushmark could be said to represent the stripes of the Mylar…
“Chrome” spray paint or Metalizer Buffable Aluminum rattle can are the top two contenders at the moment. I’m going to do a study with each and see which I like more watch this space.
Polly-scale Reefer White (that’s as in Refrigerator White, the rail-road color) is my call for the white paint on the lower and upper ring radiators, the two ‘tabs’ containing the ram’s horn antennas, and the white areas near the RCS boxes. My own mix for Boeing Aircraft Company #707 Gray is my first choice for the Light Gray RCS boxes, unless they’re white too, have to check again before I commit myself. The Inconel heat shield could be Polly Scale Stainless Steel, maybe with a bit of yellow added to bring out the nickel ‘color’… Inconel is a copper-nickel alloy and its attraction is that it holds its strength at high temperatures, not that its intrinsically tough stuff like titanium. It actually cuts and polishes pretty readily, but the important thing is that its clearly NOT aluminum. Completely different color. Not unlike stainless steel, which is, itself, not like steel OR aluminum.