I’ve talked about “being lucid” and using description languages before. I have a whole category here devoted to TDL (Test Description Language) and I’ve worked to present examples that are not your standard “shopping cart”. In this post, I’ll cover an example of how I helped testers go from a “bad test” to a “good test.”
Continue reading Good Tests vs Bad Tests with Description Languages
In this post, I’ll focus on an ecosystem I haven’t given much attention: that of Windows and the use .NET related technologies. I’ll be covering the use of Selenium WebDriver within a C# context.
In this post I’ll focus on using page objects in a Selenium and Cucumber JVM context. Please note that this post follows on from the previous post, using the code you built up there.
Continue reading Page Objects with Selenium and Cucumber JVM
I previously posted a tutorial on using Cucumber JVM to test Java code. However, many testers are in the position of using Cucumber JVM to test web-based applications using tools like Selenium. In this post I’ll show how to use these tool solutions together.
If you are a tester and deal with automation, you will likely at some point have to run your tests on SauceLabs or some similar remote platform. In talking with some testers, this tends to make them a little nervous and I’ve found this comes down to them thinking it’s more difficult than it really is. So here I’ll cover how to do this with two popular automation libraries in Ruby and then I’ll show how to do the same thing using my Symbiont framework.
My test micro-framework, Symbiont, has reached version 1.0. This means I have officially graduated from “show and tell” to “deliver … More Symbiont Reaches 1.0!
A way back I talked about testing focusing on its roots as a technical discipline. I’ve also talked about how companies should interview testers as testers and, most recently, a bit about being generalists with some areas of specialization. I often hear, usually from hiring managers, that what I talk about makes it very hard to hire testers in light of modern day realities. So let’s talk about that.
Previously I had talked about valuing the “modern” tester as well as a possible defocusing of test practices. What a lot of these kinds of discussions swirl around is how much, and to what extent, testers are generalists or specialists. So let’s talk about that a bit.
Continue reading Testers as Generalists with Specialist Tendencies
If you look at the JavaScript test tool ecosystem, you will find it’s generally quite large. But you will see the same tool names pop up fairly regularly. The decisions actually fall along some fairly simple and standard lines. In this post I want to show you at least some of your choices and then apply those choices to testing against a web application.
Continue reading Writing Test Solutions with JavaScript: Testing Browser Apps
In this post, I want to cover using two particular libraries as part of the JavaScript testing ecosystem. I’ll be very briefly covering Mocha and Chai. I tend to use these quite a bit and will likely do so in future posts. This post will thus serve as a brief introduction to the tools along with a working example.
Continue reading Writing Test Solutions with JavaScript: Mocha and Chai
As many of my readers my know, or have figured out, I’ve been a fan of the Ruby language for quite some time and I’ve used it to construct some of my own open source testing solutions. I’m now actively pursuing JavaScript as my potential test ecosystem of choice. In a few upcoming posts, I’ll talk about this journey with practical examples. This first post starts things off by getting you up and running with a few possible JavaScript technologies.
Continue reading Writing Test Solutions with JavaScript: Starting Out
I talked about a particular test technique and how intuition can fail us. I’ve also talked a lot about testing and abstraction. But is there an intuition for abstraction? I’m thinking there is. And I’m thinking the better testers I’ve known have shown it. But I struggle with how to make this a useful concept in terms of building up this skill in testers.
I’ve said before that testing games is hard and I’ve also shown that I created a game for interviewing test candidates. You wouldn’t be far off the mark to figure that I put a large focus on game-related thinking. This is because, in my experience, such thinking makes some of the best testers. But let’s talk about that a bit.
I recently read the book called Uncertainty: Einstein, Heisenberg, Bohr, and the Struggle for the Soul of Science, written by David Lindley. It made me think a bit about the “soul of testing.”
In the past I questioned whether our test and development practices become defocused. As most people in the industry know, there has been a lot of comment and debate about whether “TDD is dead.” So let’s talk about that, particularly since this particular practice is said to sit at the intersection of testing and development. This is probably going to be a bit of a free-range over a few topics, so bear with me as we brave the dark waters.
Continue reading Test-Driven Is Not (Necessarily) Test-First
Previously I talked about the testing craft and abstraction and here I’ll expand on those thoughts a bit more.
Most testers have heard of “bump the lamp.” It’s hard to go through a testing career and not be exposed to this concept at some point. I recently found an experience where I was able to keep this kind of thinking front and center.
The idea of a test solution architect is a role that should officially exist but doesn’t. My thoughts are still percolating on this but let’s talk about architects in general and then talk about test solution architects.
Previously I had talked about the craft of testing, focusing on the balance between the creativity of an artist and the methodology of a scientist. In both cases, however, the focus is on communication. To that end, it’s imperative we can express what we test in good English. (Or whatever the native language of your environment is.) So let’s talk about this key skill.
Continue reading The Testing Craft and Levels of Abstraction
I believe in the concept of what I call Lucid Testing. I even tried to promote my own BDD-style tool solution called — what else? — Lucid. The focus on lucid testing is making testing a design activity. As such an activity, testing makes the business domain — and how that business domain provides value — lucid (expressive and understandable) to anyone who has a vested interest. Core to these ideas is that testing is a design activity and that the primary value of testing is as a communication activity.