docs: Fix typos in testing/philosophy.md.

docs/testing/philosophy.md

@@ -18,7 +18,7 @@ This is possible because we have spent years systematically investing
 in testing, tooling, code structure, documentation, and development
 practices to help ensure that our contributors write code that needs
 relatively few changes before it can be merged.  The testing element
-of this is to have reliable, extensive, easily extended test suits
+of this is to have reliable, extensive, easily extended test suites
 that cover most classes of bugs.  Our testing systems have been
 designed to minimize the time spent manually testing or otherwise
 investigating whether changes are correct.
@@ -35,7 +35,7 @@ do, and for those components, the tests mean that new contributors can
 often make substantive changes to that component and have their
 changes that are more or less correct by the time they share their
 changes for code review.  More importantly, it means that maintainers
-save most the time that would otherwise be spent verifying that the
+save most of the time that would otherwise be spent verifying that the
 changes are simply correct, and instead focus on making sure that the
 codebase remains readable, well-structured, and well-tested.
 
@@ -157,11 +157,11 @@ So, to summarize our approach to integration vs. unit testing:
   HTTP response and internal state of the server following the request
   are correct.
 * Following the end-to-end principle in system design, where possible
-  we write tests that execute a complete flow (e.g. registration a new
+  we write tests that execute a complete flow (e.g. registering a new
   Zulip account) rather than testing the implementations of individual
   functions.
 * We invest in the performance of Zulip in part to give users a great
-  experience, but just as much for making our test suite fast enough
+  experience, but just as much to make our test suite fast enough
   that we can write our tests this way.
 
 ## Avoid duplicating code with security impact