I was knocked out! I was asked a question about API testing and I was mentally knocked out. While I have tested APIs before, I have been focused on front-end testing lately. The last time I did it in an automated fashion was as a proof of concept. At that moment, I realized I have been focusing on front-end test automation too much and I really needed to brush up on my back-end testing skills.
It is easy to let your regression suite get out of hand. We tend to throw every test case we create in the regression suite. It is a test case dump yard for everything test we create that isn’t in the smoke test. We want to make sure everything works as expected before each release. When we do this long enough, we end up with thousands of test cases.
Before you know it, your regression suite is a forest, when you only need a few trees. There has to be a better way.
Test cases are the keystone of the QA house. Test cases document functionality of the applications we test, training material for new team members, and the building blocks of our test plans. With them we can demonstrate and clarify what we are testing during our regression and production test runs. Without them the following problems arise:
When your test automation is running fine, everything is great with the universe!
Then it happens. A test cases fails and your trace isn’t entirely clear as to where it failed. Even when the trace is clear, you still have to walk through the test steps to capture a screenshot for the bug. Imagine being able to capture screenshots at the moment of failure.
Imagine no longer!
“In preparing for battle I have always found that plans are useless, but planning is indispensable.” – Dwight D. Eisenhower
This seems like one of the most obvious parts for testing in QA. After all, it’s our artifact in Agile and the testing process. Believe it or not, I still see this fundamental lost in testing teams. Why is that? Why do we need test plan anyways?
Failure is important.
Losing is important.
At some point in our lives, we were losers, whether at a board game or a soccer match, etc. That loss taught you something. It changed how you played the game.
Failure is the same way.
In the software community we say “Fail fast” for a reason. Try something, if it fails then let it fail fast. Don’t throw more resources at it.
Failure in business and in life, is better to do fast. Don’t agonize over failing, because when you do, you fail to learn the lesson.
Take your failures and your losses and learn from them. Improve and try again. Always try something new and learn.
Not ALL ideas will win at the first try. Sometimes, the concept is right but the timing or execution is wrong.
So fail at something.