DZone

If you are an operations or infrastructure type engineer, testing may mean traditional “QA”, UAT, or the newer test automation. An alternate way to think about tests is that you are asking a question about the software or infrastructure. The question is open-ended — there is no definitive answer. What will happen when the instance runs out of disk space? It will trigger an alert. Will it? For example, why did the bedroom alarm clock not ring on the day of your important meeting? If the alert is triggered, will the people who are paged know how to respond? If we have a separate operations team, will they understand the application to troubleshoot the alert? What are the different situations for when the instance can run out of space? Let’s call these type of questions tests.

There is another type of question for which we know the outcome. I verify that the new instance of WordPress is working by logging into the application using the username, ‘admin’, and the password, ‘password’. I could use different types of usernames and passwords. I could maybe try different lengths of strings and different characters. When you know the outcome of the question, we can call these checks.

Source: DZone