443 Blog One - Test Cases

 For my first blog post, I read a blog written by Steven Cross, a professional software developer. The blog is titled 'The Curious Case of the Test Case", linked here: https://stevencrossblog.wordpress.com/2017/03/15/the-curious-case-of-the-test-case/
I chose this blog because it helped introduce me to a new but important aspect of software testing in how you actually go about "structuring" it. 

In the blog, Steven talks about test cases, and how they are a very useful and important aspect of software testing. Test cases, as I understand, are documented procedures that ensure software behaves as expected under a set of pre-defined conditions. In other words, a set of steps laid out before the testing actually takes place. He talks about how these test cases provide a consistent structure that can be adhered to, and how this structure can be especially useful for new hires in their onboarding process, leading them to better understand how the software works. He also talks about exploratory testing, which is essentially the complete opposite of test cases, in that it is much more free-form, "test as you go", with very few or no pre-defined steps. He explains how this is particularly useful to discover unexpected defects that regular procedures may miss. Lastly, he advocates for a strategy that involves both types of testing, where you should aim to strike a balance between them, maintaining clear test cases while allowing room for exploratory testing. He also touches on concerns regarding maintenance cost and readability. 

As someone who is new to software testing I wanted my first blog to be from the perspective of someone who has had a good mount of first-hand experience with it, I could have chosen someone who was a "regular" software developer, but Scott in particular has a whole series of blogs tied directly to testing, and seems to have specialized in it to a certain degree in his past. Gaining insight from people who are able to provide insight from their own experiences always helps me gain a sense of what is more or less important about that topic, so I try to make it my goal to seek out these accounts. 

For what I took away from this blog, I now have a better understanding of how to approach designing tests. Schott's philosophy is to take a balanced approach that can cover all the bases, stressing that while you do need a good amount of structure, you also need to leave room to "explore", in that your tests need some degree of free flow to allow you to discover new and unexpected issues with it. A interesting idea, and something I am sure will be difficult to get right at first, however also something I will definitely think about.