January 2021 M T W T F S S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Archives
- January 2021
- October 2020
- September 2020
- August 2020
- April 2020
- August 2019
- November 2018
- July 2018
- February 2018
- 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
Blogroll
Pages
- 1996 Porsche 911 GT1 (993 based)
- Porsche 911 GT1 1996, 1997 “evo” and 1998 references
- Just the links, please: click through, cut-and-paste links that will work. In spite of me.
- Porsche 911 GT1 (993 GT1) bibliography, reference photos in print
- Web Page: List and description of Porsche 911 (993) GT1 photos from Pieter Melissen
- Web Page: List and example of Ultimate Car Page’s Porsche 911 (993) GT1 photos
- Tamiya 1/24 Porsche 911 GT1 model
- Porsche 911 GT1 1996, 1997 “evo” and 1998 references
- Air International (Air Enthusiast) Index
- Books I like to give away
- Five of my favorite John McPhee books:
- Links
- Modeling Projects Update
- Paint and finishing for model builders
- The Allen Ginsberg Knock Knock Joke
- 1996 Porsche 911 GT1 (993 based)
Category Archives: quality
A Software Tester’s journey from manual to political tester
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.
Posted in Computer Programming, Computers, Exhibits, How, Me, quality, Software development, Software testing, Tools, What, Why
“Testing – How does one learn QA?” – An answer I posted on the StackOverflow “Programers” forum
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?“ I wrote: 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 |
Posted in Computer Programming, Computers, quality, Recomended, Software development, Software testing, Tools
Tagged adujstment, assurance, automated, bugs, change, clean, closed, condition, control, correction(s), evaluation(s), example in manual, expectation(s), inspection(s), install, manual, modification, Quality, record, rtfm, Software, solution(s), testing, tests, validation, verification, version