diff --git a/docs/configuration.md b/docs/configuration.md
index 061e3d5..67e588f 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -1,4 +1,6 @@
-# Device ID Configuration
+# Configuration
+
+## Device ID Configuration
 
 There is a default dev_id.json file provided by
 meta-phosphor/common/recipes-phosphor/ipmi/phosphor-ipmi-host.bb
@@ -22,7 +24,7 @@
 runtime, simply restart the service to see the new data fetched by a call to
 get_device_id.
 
-# IPMI D-Bus Sensor Filtering
+## IPMI D-Bus Sensor Filtering
 
 Phosphor-ipmi-host provides a compile time option to control how IPMI sensors
 are populated. The default model is for the sensors to be culled from a set of
diff --git a/docs/testing.md b/docs/testing.md
index 2fa3602..9ee1dcb 100644
--- a/docs/testing.md
+++ b/docs/testing.md
@@ -31,7 +31,7 @@
 git clone https://github.com/openbmc/openbmc-build-scripts.git
 ```
 
-### Add `phosphor-host-ipmid`
+## Add `phosphor-host-ipmid`
 
 We also need to put a copy of the project you want to test against here. But
 you've probably got a copy checked out already, so we're going to make a _git
@@ -116,7 +116,7 @@
 in parallel while the tests run, and since the CI scripts are unhappy when you
 have untracked changes - which you're likely to have during active development.
 
-## Building and Running
+### Building and Running
 
 The OpenBMC CI scripts take care of the build for you, and run the test suite.
 Build and run like so:
@@ -129,7 +129,7 @@
 The first run will take a long time! But afterwards it shouldn't be so bad, as
 many parts of the Docker container are already downloaded and configured.
 
-## Reading Output
+### Reading Output
 
 Your results will appear in
 `openbmc-ci-tests/phosphor-host-ipmid/test/test-suite.log`, as well as being
@@ -137,12 +137,12 @@
 test file, for example `sample_unittest.log`. All these `*.log` files are
 human-readable and can be examined to determine why something failed
 
-# Writing Tests
+### Writing Tests
 
 Now that you've got an easy working environment for running tests, let's write
 some new ones.
 
-## Setting Up Your Environment
+### Setting Up Your Environment
 
 In `/my/dir/for/phosphor-host-ipmid`, create a new branch based on `master` (or
 your current patchset). For this tutorial, let's call it `sensorhandler-tests`.
@@ -154,7 +154,7 @@
 This creates a new branch `sensorhandler-tests` which is based on `master`, then
 checks out that branch for you to start hacking.
 
-## Write Some Tests
+### Write Some Tests
 
 For this tutorial, we'll be adding some basic unit testing of the struct
 accessors for `get_sdr::GetSdrReq`, just because they're fairly simple. The text
@@ -345,7 +345,7 @@
 check_PROGRAMS += %reldir%/sensorhandler_unittest
 ```
 
-## Run the New Tests
+### Run the New Tests
 
 Commit your test changes. Then, you'll want to checkout the
 `sensorhandler-tests` branch in your CI worktree, which will involve releasing
@@ -373,7 +373,7 @@
 (If you will need to apply the proposed changes to multiple commits, you can do
 this with interactive rebase, which won't be described here.)
 
-## Best Practices
+### Best Practices
 
 While a good unit test can ensure your code's stability, a flaky or
 poorly-written unit test can make life harder for contributors down the road.
@@ -418,13 +418,13 @@
 
 master -> fix Foo.Abc() -> fix Foo.Def() -> Fix Foo.Ghi() -> test Foo class
 
-## Sending for Review
+### Sending for Review
 
 You can send your test update and any associated bugfixes for review to Gerrit
 as you would send any other change. For the `Tested:` field in the commit
 message, you can state that you ran the new unit tests written.
 
-# Reviewing Tests
+### Reviewing Tests
 
 Tests are written primarily to be read. So when you review a test, you're the
 first customer of that test!
@@ -467,7 +467,7 @@
 - The committer doesn't have "Ok-To-Test" permission, and you don't have
   permission to grant it to them
 
-# Credits
+## Credits
 
 Thanks very much to Patrick Venture for his prior work putting together
 documentation on this topic internal to Google.