- having no session handling
- imposes a specific testing framework
- has an exclusionary “API” that tries to be self contained with the philosophy that it is “all you will never need”
- using static controllers
- requiring you to handling requests asynchronously
- being yet another clone of Rails
- using Scala for templates
- written in Java but goes out of it’s way to avoid the existing java ecosystem
It’s the end of the year, and I haven’t written much on my blog in 2013, but it’s been a fairly busy year.
I started the year working at Ancestry and then went back to freelancing. I hired 3 interns, and started working on building a cloud test environment with them. I got a client, DIIO, and ended up working full time for them. I even got to go to the company party in Mexico. It was a blast, thanks DIIO!
But Kelsey made me come home from Mexico and she’s talking about moving. I’m not sure what the new year holds, but I’ve got a couple of interesting ideas and some more projects.
1.) What if logging were just events that a logging service merely subscribed to. You could add logging “instrumentation” and measure performance, coverage, and lots of other things — if it were baked in (or an aspect!)
2) More playing with clouds and PaaS AWS, Rackspace, Linode, Cloud Foundry, Juju, Docker
3) I’m going to set up my own private “fog” using Open Stack — for building test environments of course.
4) I’m going to be writing PHPUNIT SELENIUM documentation.
5) I’m going to write more and be purposeful.
6) I’m going to find an assistant who can proofread, handle invoices & budgets, do some basic research, handle vendor contacts, marketing & social media, oh yeah, and learn to test.
I’ve been following Eric Davis for a long time — ever since I started hacking on Redmine in 2009. As it’s maintainer, he was extremely helpful to a newbie like me. Recently I’ve started reading his blog and newsletter about freelancing. A recent post of his, “Write Every Day” struck a nerve. And a comment from Nathan Barry that he linked to hurt even worse “slow, consistent progress is the only way to make big things happen.”
It’s something I’ve been intending to do — and procrastinating for years. I’m not going to set a goal of 1000 words a day. And I’m not going to publish a blog post every day. But I am going to write every day for a half hour or so. I’m also going to take the time, as Eric suggests, to edit every day. That will hopefully allow me to make progress on a book about testing tools & automation in the cloud. If I know I’m going to go back and edit, I won’t be as worried about writing garbage — or something that’s wrong, stupid, or cheesy. It may even improve the quality of blog posts (no guarantees on today’s content.)
Besides writing a book, my goal will be to publish a monthly newsletter. With at least 1 article about something technical, 1 commentary about a process or business objective, some personal news (including potentially a hurrah for a client), and a few interesting links. I think of Mike Gunderloy’s blog A Fresh Cup or A Smattering of Selenium by Adam Goucher.
Will anyone read (or subscribe to) my newsletter? I wouldn’t count on it, not at first. But it might help me become a better writer, and even more importantly, it might help me be more focused.
It’s fall, and winter seems to be coming quick this year. I promised to have a big BBQ at the end of summer, but it didn’t happen. Instead, the Saturday after Labor Day there was that crazy storm that rolled up suddenly with strong winds, heavy rain, and nonstop thunder. We’ve had a few good days since but this fall has been dominated by cold and rainy weather.
Well, it looks like this Saturday is likely to be clear and cool, and it might be our last one before winter. So I’ve got to get something done. Living in Seattle has taught me one thing — take advantage of the good weather when you can.
In that wind storm, our back yard fence blew down. Not all the way, but it’ i’s sagging pretty good. About the only things holding it up are our neighbor’s sprinkler heads and apple tree (and maybe a few clinging weeds on our side.)
Our landlord won’t take care of it. But there’s “shoud” and “can” — he should do it, but we can. So, tomorrow morning I’m going to go on a bike ride with my kids, head down to Lowes, and fix the fence. But I’m also going to barbecue.
That big neighborhood BBQ I talked so much about is going to happen. I’ve got to use the last of the charcoal anyway. There will be ribs, spicy sausage, and kabobs. I’m going to ask Kelsey to make rolls. If we can find it, we’ll have corn on the cob. Things will be cooking all day.
And there will be plenty of work to do. I could really use a portable table saw (that can cut 4x4s), a post hole digger, and a portable cement mixer. I’ve got a couple screw guns, but we could use another.
If the neighbors are ok with it, we’ll reuse as much of the old wood as possible. Maybe cut a few inches off the bottom to prevent rot. That means work unscrewing and trimming boards. If we get enough people working on it, it shouldn’t take too long.
Bring the whole family. Or just come with the kids and give your wife a couple hours off. Stay for as long as you like. There’ll be plenty of work to do, and plenty of food. You don’t have to work, and you don’t even have to eat if you don’t want to.
But while tall fences make good neighbors, I’m betting good food makes even better ones.
If you use python a lot, you probably use virtualenv. And you probably want to use virtualenvwrapper. You can on windows now:
powershell pip install virtualenv virtualenvwrapper-powershell Set-ExecutionPolicy unrestricted mkdir ~/.virtualenvs import-module virtualenvwrapper mkvirtualenv myenv
I was reading a comment on the QA & Test Management Solutions group on LinkedIn this morning. There was a question with a pain we’ve all felt as testers.
Are you suffering something similar?
Software specifications with “maybe can do….” or “It coud be located there or maybe there” are not specific at all. If a SQA manager accept that kind of non-specific speficications, He must be going to work to a casino (That is the place for multiple possibilities and unespecific results)
Here is my response, which got rather wordy, so I posted it here.
I would ask for examples. BDD encourages “specification by example” and while not everyone is a fan of the syntax, it can help to be specific (and somewhat rigid)
As a… [user role]
I want to… [do this thing]
So that I can… [accomplish this goal]
If they can’t describe the user and the goal, then maybe the task isn’t important.
Then, you can describe specific scenarios:
Given… [these pre-conditions]
When… [some action is performed]
[with this specific data]
Then… [some result]
And press a little further (though you don’t want them dictating implementation details) to help describe what they expect the result to achieve
Verified by… [these post-conditions]
You can build your test assertions based on the post-conditions.
It should… [have this state]
Have them describe several scenarios until you think you’ve got it or they’re sure they have all the bases covered. Suggest alternate scenarios as you see them and see if they’re valid or important (at the risk of making more work for you). Then give them a time-frame to implement and negotiate features versus time.
It works rather well if everyone is willing to work together and goes into it with an honest and non-antagonistic approach.
You don’t have to use the exact verbiage. Given/When/Then is called “gherkin” syntax (gherkin is a type of cucumber — http://cukes.info.) I think If/Then/Else is just as suitable (and business types won’t even know it’s programming.)
The important thing is the feedback loop of communication and iteration, and examples are a great way to encourage concrete thinking and clarify misconceptions.
These some examples of tools that can help you accomplish the goal of performing test automation in the cloud.
You need defect tracking, test management, build automation, documentation, source control, and automation tools. You need a test environment and a variety of clients to test on. And you need it all to work together.
What are some of the obstacles to test automation in the cloud?
1) Fear of putting proprietary code (and data!) on a public cloud
2) Too many tools and vendors to keep track of and coordinate
3) Creating a seamless integration that works together
But what are some of the advantages of running your test automation in the cloud?
1) Quicker provisioning of hardware resources and ability to scale on demand
2) Ease of administration of uniform architecture provided by virtualization
3) Simplified workflow for distributed teams
I’m working on a short book about steps you can take to leverage the cloud and cloud services to help make test automation easier, faster, and more meaningful for development teams.
I’d love to have feedback from people on their experiences, questions, and advice.