Monday, September 29, 2014
At the start of a sprint, we leave Sprint Planning with the requirements. The next interaction with developers is when we review their Developer Design Overview document that spells out the development approach and helps QA scope their testing effort. This developer had chosen to put an error message into a file usually reserved for configuration. QA saw the DDO and raised concerns immediately. Why was a message being added to this file when they were usually reserved for the language DB? With this one question, before QA saw the code, we changed the trajectory of development. The fix was in before we got our first build, and the story closed with the Sprint instead of carrying over with the do-over.
An even earlier example came when we looked to implement secure communications between two servers. While I couldn't code my own implementation, I was able to provide recommendations at design-time by staying educated and confirming my understanding with developers who had dealt with crypto. By starting early, we were on surer footing when troubleshooting and confirming the implementation was sound.
As the examples above illustrate, QA often saves time for developers by defending standards and consistent implementation early in the cycle, but that is not the only savings that comes from shifting left. Often, test environment issues can also be aided by an early understanding of requirements. In one case, as story had carried over from a previous sprint which meant we were already behind. The roadblock was a production issue pulling the developer away from the story. Instead of sitting on our laurels, QA worked with the configuration manager to make sure our test environments were ship shape before the code was completed. When the developer's changes passed build verification, we were off and running almost instantly. Not only did our preparation help us get to the work of testing faster, but it also helped us close more stories as environments were made ready before they could become an obstacle. Not only was I able to test early, but it lead to me testing more and in greater depth.
Most modern test engineers have their own war stories from early testing. For every story where requirements changed and early notes became meaningless, there are ten stories where early questions lead to greater clarity, fewer bugs, and more time for digging in. I consider projects that foster this early access for QA to be among the most fruitful and least volatile.
Saturday, September 27, 2014
Here are a few pictures from back in 2016 showing a picture frame which was the first thing I made using my brand new jig: a miter sled I built from scratch for my Jet table saw.
The frame is Indian Rosewood. It has a very strong grain and is slightly oily. It was easy to book match, and each corner has a key from some yard cypress. The contrast between the two woods wasn't enough to make them stand out, but it gave the frame lots of strength. The finish is paste wax and nothing else. Very lustrous.
The glue up was really awkward due to the thickness of the piece. I bought strap clamps for next time. I'm not a fan of the simple geometry either. I need to take the time to make a few more shaping passes before cutting the miters. The frame itself kind of consumes the photo placed therein because there is such a deep well between the inside edge and the glass. It is very chunky as a result.
The hardware and glass was bought or salvaged from cheaper frames. I didn't measure right for the glass and had to shave a mm off one side to make it work. Gulp.