One of the worst things that can ever happen to a quality function or test team is a credibility gap. When perceptions of quality take a hit — whether internal or external — you are on a bad path. Here I don’t want to talk about how you get out of that situation. What I want to do is talk about how you can avoid getting into it in the first place. But I want to talk about it at the level that it really matters. This means talking about morals and values. But this is tricky because such discussions are fraught with peril and subjectivity. Yet we need to tackle these head on.
Combining Activities in a Lifecycle Prism
For those of you who work in agile environments, maybe nothing I say here will be new. Even for those who don’t work in agile environments, you may have found yourself thinking along these lines but not necessarily sure of how to articulate it. That’s a challenge I’ve found myself in where I had to explain to people that the process gates you typically see in a “waterfall process” can be accommodated in an “agile process.” So let’s talk about that.
Build Your Own Language, Part 6
Here I’m going to try my hand at creating the start of an interpreter. This obviously follows on from the previous posts in this series.
Build Your Own Language, Part 5
If you’ve followed this series up to this point, you now have a lexing and parsing engine that, while not doing much, is passing its tests. What we don’t have is a way to really say that our language works because there’s no runtime. That’s what I’ll start to address in this post.
Build Your Own Language, Part 4
We left off with a parser test we wanted to execute (in parser_spec.rb) and a grammar file to generate a parser (in grammar.y). The actions specified in the grammar file, and thus what will be tested in the spec file, are nodes. So getting those nodes in place will be the focus of this post.
The Higher Calling: Testers Building a Base For Knowledge
One thing I can claim to know: as any company continues to grow its quality practices (not just its test practices), its challenges will grow. One of those challenges will be making sure that the company can operate in a so-called “agile” fashion while still building a solid base of actionable knowledge related to quality and testing. So let’s talk about that.
Continue reading The Higher Calling: Testers Building a Base For Knowledge
Enhancing Testing Skills By Playing Games
I started playing a game type that I rarely play: a Massively Multiplayer Online (MMO) game. Specifically, Star Wars: The Old Republic. As I was playing it, I realized that it was actually an interesting game for a tester. I found myself utilizing a lot of the skills that I would as a tester when looking at a business application. (This actually led to me doing some contract testing on the game itself!)
Build Your Own Language, Part 3
Following on from the second post in this series, a lexer has now been created that can tokenize some input for a hypothetical language. Given what was accomplished, theoretically I can use my language to create the most minimal sort of class definition. I’d really love to know if I’m completely on the wrong track here. So I’d like to get started on the parser at this point rather than fleshing out the language more.
Build Your Own Language, Part 2
Following on from the first post in this series, I did a development spike that proved to myself I had some clue as to what I was doing. So now I want to get into actually building a language from soup to nuts: meaning I want an interpreted language that executes via a runtime. Granted, this will be a very simple language (and not very unique). It will also be a very simple runtime. Let’s see what happens, shall we?
Build Your Own Language, Part 1
In previous posts I talked about how one of my goals was to come up with an alternative to Gherkin. This is not in the “just to see if I can” category but rather because I believe it could be useful to roll your own Gherkin-like language. This post, however, will be in the “just to see if I can” category. Here I want to take what I learned about lexing and parsing and apply that to creating a simple programming language. Fair warning: I have no idea how this is going to turn out.
Testers Are More Than Their Skills
As a tester, you don’t just gather and manage test data. You don’t just create test cases. As part of quality assurance, you don’t just check requirements. You don’t just do reviews. In short: you are not just a bundle of skills. Rather, you are a personality and a mindset that happens to have a bundle of skills. So let’s talk about that.
Testing That is Effective, Efficient, and Elegant
There is notion in quality assurance and testing between verification and validation. Verification asks “Are we building the product right?” Validation asks “Are we building the right product?” Some people use this very distinction to draw a line between the activities of quality assurance and the activities of testing.
Continue reading Testing That is Effective, Efficient, and Elegant
A Tester Learns Rex and Racc, Part 3
This post continues on directly from the second post in this series. Assuming you’ve been following along, you’ve broken your input into a stream of tokens. Now you need some way to recognize higher-level patterns. This is where Racc comes in: Racc lets you describe what you want to do with those tokens. That’s what I’ll be covering here: how the parser works with the lexer.
A Tester Learns Rex and Racc, Part 2
In my previous post on this subject I started off on the learning process for building a lexer with the Rex (Rexical) tool. Here I want to update the logic I provided in that post to show how to make it more testable. I then want to expand on the example of using Rex with something a bit more substantive.
A Tester Learns Rex and Racc, Part 1
As a tester, I like to know how things work. So when I started investigating the basis for the tool Cucumber, I came across the concept of Gherkin. That was written with the help of a system call Ragel. What I was curious about was whether I could build one of these languages on my own, perhaps for a customized testing tool. This caused me to stumble upon Rex and Racc, which are two Ruby-based tools that help you build your own languages. The documentation on these tools, however, is on the bad side of awful. This post is purely to document and share what I learned.
Seeing and Thinking Differently
In talking about test teams as inventors, I mentioned that Albert Szent-Gyorgyi said “Discovery consists of looking at the same thing as everyone else does and thinking something different.” I wanted to go back to that thought because it’s not the act of “thinking something different” but rather the act of “thinking differently” that really matters to me. This is even more so the case in an industry where testing and development continue to move closer together and, in fact, often merge.
Effective Tests, Not Positive and Negative Tests
My opinion is that the “positive” and “negative” distinctions for tests are a faulty conceptual distinction. To me, only “old school” testers talk about “positive testing” and “negative testing.” Pretty bluntly stated, huh? I feel strongly about this because the way the terms are promoted, they take focus away from how a tester should be thinking about testing. That’s my belief anyway. I’ll try to defend that.
Continue reading Effective Tests, Not Positive and Negative Tests
Testers Write Tools — Like Test Libraries!
I keep looking for ways to get junior testers up to speed on writing test frameworks and test libraries. It’s a very good skill to have and it’s one that’s in demand. Beyond that, I think it paves the way for helping testing to evolve into what it must become: a group of practitioners that are test solution developers. As such, I’ve been using my Symbiont library for this purpose.
There Is No “Test Phase”
When people talk about the “testing phase” of a project, you already have a problem because that implies testing is an activity that is relegated to a certain phase as opposed to a structural element of the entire project itself.
Specifying Application Workflow Activities
Lately I’ve been writing a lot of specifications and by that I mean test specifications. And by that I mean the specifications you tend to write in tools like Cucumber, SpecFlow, Lettuce and so on. What’s been interesting is deciding at what level of intent to write at.