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.
Continue reading “Seeing the Test Case Through the Forest”
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:
Continue reading “The Key to Lasting Testing Success are in the Test Cases”
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!
Continue reading “Failed Tests Are Better With Screenshots”
“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?
Continue reading “Making Test Plans”
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.
Some test automation require you to look at the page source to confirm tags. This article covers opening the view source to assert tags are present using Ruby. Here’s a quick way to validate text on page source using ruby. Continue reading “Checking View Source While Testing”