Transcripted Summary
Let's wrap up the course by discussing some lessons learned from testing on the inside.
What I've found over the years is that it's all about finding new ways to add value.
So, testers, I'm going to challenge you. Participate in code reviews regardless of your technical skill levels. You don't need to actually know a lot about programming to bring value, because the value that you bring is a unique perspective that you have from testing this product day in and day out from a customer's perspective.
So, review those tests for coverage. Yes, unit tests for coverage, and I'm not talking about code coverage because that's something that a tool can calculate automatically, but really, you want to look at the coverage from a testing perspective.
What are the variety of values that are being thrown at this program?
Are they representative of values that your customers are going to use?
Do they help to uncover issues like off-by-one errors or boundary values that just hit extreme conditions that cause your software to crash?
That is the type of coverage that you need to be assessing.
Maybe one day you'll go from communication bugs to submitting bug fixes. I've seen testers use courses like this to build up their technical skills to a point that no longer are they afraid of touching the code. They're actually in there submitting pull requests, writing new tests, fixing bugs, doing the whole works.
In other words, they've become switch-hitters. They've gone into a point where they can use the findings from exploration to improve the testing that they do on the inside.
One of the most powerful things I've ever seen at our organization is dev-tester pair programming.
Here we have those two perspectives working together, and you start to see this cross-pollination of skills, developers becoming better testers and testers becoming developers.
You want to automate tests, mock classes, use these skills that you've learned, and then promote the test pyramid because it's really about discovering your patterns and anti-patterns.
Do you have an ice cream cone where you have many UI tests but very few unit tests? This really indicates a lack of development practices for unit testing and a big automation effort without support from development.
Or maybe you have the hourglass, lots of unit tests, plenty of UI tests, but almost no integration. Here, you might have an overconfidence in unit testing and end up with Big Bang integration, and this doesn't help.
You really want to get to your pyramid where your focusing on testing at the lower levels actually helps the integration and system levels. This is going to mean simpler, faster-running tests.
You're going to make your tests double CRISP if you follow these practices — meaning clear, repeatable, independent, simple and performant AND concise, readable, isolating, self-sufficient, and purposeful.
These are all lessons that we learned along the way by putting these techniques into practice.
The last thing that I'm going to say is that there is really just value in perspective.
This is not to put anyone in a box or try to label anyone, but when you think about software from a development point of view, you're thinking about creating something. You're very optimistic. You're focusing on all the details of that particular solution, and the efficiency of your solution becomes very, very important.
From a testing perspective, it's really about the big picture and analyzing and picking things apart. You're a little less optimistic and a lot more pessimistic. You're thinking about scenarios and the user experience.
So, there's only one question left to answer, and that's when?
That is really up to you, but my recommendation is that you should start this today. Your future is really created by what you do today and not tomorrow.
So, happy testing. Thank you.
