Permalink
Browse files

a few small fixes reported in #52

  • Loading branch information...
1 parent 2ae6bf1 commit 1af9e12087510758e7685a73e4806878b6ce05e5 @lydiapintscher lydiapintscher committed Mar 3, 2012
Showing with 3 additions and 3 deletions.
  1. +2 −2 code/ThiagoMacieira.tex
  2. +1 −1 qualityassurance/JonathanLeto.tex
View
@@ -54,7 +54,7 @@ \section*{Phrasing the question correctly}
technique to problems may certainly help.
Phrasing the problem and the question correctly, in all its details, is also a
-way to further describe the problem statement. First, we must realize that the problem very likely does not lie where we are expecting it to be -- if it did, we would have probably solved the problem by now. Explaining all the details of the problem at hand provides the help-givers with more information to work with. In addition, even if counter-intuitively, the act of describing the problem in its entirety often leads to finding of the solution, so much so that many development groups require ``stuck'' developers to perform this task, either by discussing it with a colleague or talking to a ``naïve'' entity, like a rubber duck or Mr. Potato-Head.
+way to further describe the problem statement. First, we must realize that the problem very likely does not lie where we are expecting it to be -- if it did, we would have probably solved the problem by now. Explaining all the details of the problem at hand provides the help-givers with more information to work with. In addition, even if counter-intuitively, the act of describing the problem in its entirety often leads to finding the solution, so much so that many development groups require ``stuck'' developers to perform this task, either by discussing it with a colleague or talking to a ``naïve'' entity, like a rubber duck or Mr. Potato-Head.
In addition, one must return to the question every now and then, so as to not
lose sight of what the goal is. While executing activities to solve the problem,
@@ -121,7 +121,7 @@ \section*{Boundary conditions}
In software systems, the boundary conditions are often referred to as
``preconditions'', which are conditions that must be met before a certain action
-is allowed. Verifying that the preconditions have been met is good exercise in
+is allowed. Verifying that the preconditions have been met is a good exercise in
the searching for an answer, for a violation of the preconditions is definitely
a problem that needs solving -- even if it is not the root cause of the original
problem. Examples of preconditions can be as simple as the fact that a pointer
@@ -74,7 +74,7 @@
switching between tasks constantly.
Most information about being test-driven is very specific to a language or
-situation, but that does not need to be the case. Here is the how to approach
+situation, but that does not need to be the case. Here is how to approach
adding a new feature or fixing a bug in any language:
\begin{enumerate}
\item Write a test that fails, which you think will pass when the feature is

0 comments on commit 1af9e12

Please sign in to comment.