In this post I want to switch around some of what we already did regarding HTML and CSS, by using “variants” of these. Specifically, I’ll look at Slim (to replace our HTML/ERB) and Sass (to replace our CSS).
Building Simple Web Apps with Ruby, Part 4
Following on from the other posts in this series, here I want to focus more on the static and dynamic content aspects. This will actually be fairly tame stuff for the most part but it’s a way to make sure we can do some of the basics with Sinatra — just in time to change them all around a bit.
Building Simple Web Apps with Ruby, Part 3
Here I want to focus more on the particulars of constructing a Sinatra web application. Up to now you basically have something that can serve up static or dynamic web pages. It’s time to get an application structure in place. This in turn will let us deploy our web application.
Building Simple Web Apps with Ruby, Part 2
This post continues on from the first one. That first post was a setup to getting the tools you needed. Here we’re going to put Sinatra through its paces and make sure we understand how it works so we can get on to creating an application.
Building Simple Web Apps with Ruby, Part 1
As a tester I’m often in a position where I want to write web applications for a variety of purposes. Most recently I wanted to make a simple test application that could be used to prove out my Symbiont test framework. Then I realized I wanted to deploy this application so that it would be available for a variety of purposes. I started looking into the simplest solutions I could find. This series of posts will cover what I learned.
When Business Needs Become Specs That Become Code
There is a distinction I want to make in this post regarding what you change in a test specification and how a test specification itself my change, in terms of the role it provides. That leads into a nice segue about how team roles also change. Here by “test specification” I mean the traditional “feature file” of BDD tools like Cucumber, Lettuce, Spinach, SpecFlow, and so on.
Continue reading When Business Needs Become Specs That Become Code
Test Specifications and Fluid Test Writing
I have been introducing Cucumber to testers who have little exposure to such tools. I was looking at whether The Cucumber Book would be worth having around the office. And while it may or may not be, one thing I notice is that it (like most resources on Cucumber I find) don’t really address some of the heuristics regarding how you can start thinking about writing test specifications.
Spec Workshops, Collaboration, and Test Writing
I’ve found myself in a position lately of having to explain a lot of concepts that are “obvious” to me. I found myself getting frustrated but then I considered my own words regarding the “obvious” nature of Quality Assurance and I realized that maybe I wasn’t establishing the context of what I was talking about. So I took step back and I started to look at whether many of the testers I work with and meet these days are aware of, much less practice, the idea of requirements being tests; of acceptance test specifications that drive development; of specification workshops. As it turned out, no, most testers were not practicing these concepts and many were not even aware of them as a shift in the dynamic of how testing can be done.
Continue reading Spec Workshops, Collaboration, and Test Writing
Resilient Teams and Systems of Values
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