Merge pull request #113 from shepmaster/unicode-is-not-an-encoding

Unicode isn't an encoding

text/10_what_is_software_testing.md

@@ -93,7 +93,7 @@ public String lowerify(String s)
 
 The customer insists that there is nothing else that you need to know to start testing.  If you were tasked with testing this, though, what kinds of questions would you ask in order to develop a testing plan?  In other words, what other kinds of requirements would you try to elicit from the customer?
 
-1. What kind of character encoding will this be in---Unicode, ASCII, EBCDIC, something else?
+1. What kind of character encoding will this be in---UTF-8, ASCII, EBCDIC, something else?
 2. What's the expected maximum character length?  Something that works well for a few words may not work so well if it's fed in ten terabytes of text.
 3. What is the expected behavior if the input text is in a language other than English?  Especially, what if it's a language that doesn't have the concept of uppercase and lowercase letters?
 4. What should the program do if a Control-C or other cancel command occurs midway through?

text/27_tips_for_breaking_software.md

@@ -58,7 +58,7 @@ Maybe not that last one. However, you will have to think of ways to test for the
     10. What are valid ranges or limits for data?
     11. How will data be input?  In what formats?
 
-    If you assume that all weight input comes in as pounds, what happens when someone else assumes that it is in kilograms?  Was an assumption made that output is in ASCII, but some data is input in Unicode, thus causing data to be lost upon display?  Did a software engineer write a program that uses a command-line interface when the customer actually wanted a GUI?  Are output files written using CSV (comma-separated values) when downstream users expect them to be tab-separated?  All of these are assumptions in the development process that can lead to defects when the system is used.
+    If you assume that all weight input comes in as pounds, what happens when someone else assumes that it is in kilograms?  Was an assumption made that output is in ASCII, but some data is input in UTF-8, thus causing data to be lost upon display?  Did a software engineer write a program that uses a command-line interface when the customer actually wanted a GUI?  Are output files written using CSV (comma-separated values) when downstream users expect them to be tab-separated?  All of these are assumptions in the development process that can lead to defects when the system is used.
 
     There also may be common requirements for a given domain, of which the software developers are not aware.  After all, software developers tend to be software developers, not subject matter experts on the domain of the software they are writing.  That is not always the case, of course, but often enough there will be a disconnect between the knowledge of the person developing the system and the eventual customer.