A day in the QA Maze

This week is a week that every dev dreads in one way or another. In my opinion going live is never a stress free task no matter how silent it is. In fact I’m pretty tense just writing this article and there’s absolutely nothing that could go wrong (I kid myself, it could totes go horribly wrong in ways I couldn’t possibly imagine but onwards and upwards?).

But it is also a really interesting time, you learn a lot about yourself at this time. In my case today I learned an appreciation for a profession I immaturely felt wasn’t as hard as development. But first let me explain how the system works.

Before I can complete a ticket it must pass a few QA stages. Upon finishing an item of work all the code goes through a Travis CI build process. This step automatically checks that the code is formatted correctly and that all the unit tests that have been written pass. Round one complete!

Provided all is good one of the other developers on the team will take a look through and see if anything pops out and that the design of the code is correct.

Once another developer as given their seal of approval the PR is merged and the QA env is updated. It’s at this stage that us devs hand over to the QA team to thoroughly test against the acceptance criteria in the ticket.

It’s this that I thought was trivial, after all the work is done right? All they have to do is tick boxes and say yes that’s fine. Easy right? No I couldn’t be more wrong.

For a dev it’s easy to know the story behind a ticket, what everyone said, when, and how that relates to other tickets. After all in order to implement it we have to delve into the specifics and down and dirty with the criteria.

A QA has none of this. They have to trawl through the history of the ticket searching for the simple answer which is usually “What the fudge am I testing here?!”

Sometimes the history can be so in-depth and convoluted that a simple changing of the default option on a select can take hours to QA. This sucks, it really really sucks and it makes me sad (even cry) that this is can be true.

So I started thinking last week “there must a way I can help my friends! What can I do different to make a difference no matter how small” - cheesy right? I hate cheese (including the dairy version) but that’s genuinely what I said :\

Today I was working with Sian who hasn’t been on the project for a while. I decided to try and impart some knowledge in each ticket by summarizing the long and sometimes confusing history into a “sup dawg, this is what’s going down”™ comment. It was inspired by the same comments QA send back to us when something is not right, it contains the following structure:

  1. Quick brief summary of whats wrong
  2. Steps to reproduce
  3. Expected Result
  4. Actual Result

This is great because it tells the reader what’s wrong, how to get it, what to look for and what it should be. That’s like gold dust (or a massive surprise lego set) right there, they’ve just saved me having to figure out all this myself.

It’s too early to say whether it makes much of a difference, I haven’t asked anyone for feedback because it’s a bit uncool really but I’ll be interested to see what happens. Heck even if I save myself some head scratching it’ll be worth it!

Anchor Diary Resourceful Routes & Controllers

Play Video

Transcript coming soon.

Anchor Diary Composer

Play Video

So I just wanted to run through how I envisage anchor working with Laravel.

So we’ve got a basic directory structure here

So taking a look at this composer.json file we’ve got the name of the application and it’s requirements. Basically what this file is it’s like an instruction booklet for composer, so it’s basically saying this application requires Laravel and anchor. Then after that it has a script section that says post install I want you to run these commands.

What we need to do first is set up our database so if we call it anchor-demo. Cool then if we go to app/config/database.php and lets just add the database name, call it anchor-demo cool. Laravel also comes with support for postgres, sqlite & sequel server which is quite cool.

Right ok, to install anchor we simply need to do composer install And that will look at the composer.json file and it will look at all its dependencies for Laravel and anchor and it will attempt to install them.

Now especially when I’m screen casting this can take a while but bare with me, in the meantime I will try and explain a little bit more about these folders.

So we’ve got in the app folder our config and this contains a load of config files. Most of them are pretty standard stock Laravel config files and each one comes with a bit of help text which says what each setting does.

So it’s quite handy like that, for example this session say that it supports native, cookie, database, apc, memcached, redis and the array which is the array is literally just an php array!

So thats our config folder the only notable one here is the view now the view has been customised slightly. What I’ve done is set a path to the theme directory so basically what that is saying is telling anchor when a view is constructed, look in here first.

So we’ve got our themes folder, and heres our theme. This is just a standard @idiot default theme, so it has your article page, functions footer, theres nothing revolutionary there.

Above it we’ve got a packages directory, this is where the assets from the anchor/core…oo looks like composer has just finished installing, lets just have a look.

Yep here we go so this is the output of composer install, so as you can see it’s installing anchor/core and it’s grabbing that from Github because it’s currently not registered with packagist, theres no versions on it yet so it’s all latest and greatest from the master branch.

And then we’re installing doctrine, symfony, a few other bits and bobs - these are all the Laravel dependencies. Generating the autoloader, and then it’s running the migration table and all the migrations and then it’s publishing the assets.

Yea so as I was saying this packages directory because the public folder is the web root usually. When I request the css file for anchor/core, admin.css for example which is stored in vendor/anchor/core/public/css/admin.css because the web root is actually in /public it can’t access that css file.

So what asset:publish does is it basically copies over the public directory and names it anchor/core and then sticks the contents under that folder.

The reason why it does that is so I have a consistent naming convention that I can use when i’m creating the views and i’m loading in my css file.

Right, so that should mean if I head over to sequel pro we’ve got all our database tables there. Er ok so if we go to terminal and we type in php artisan serve --port=8080.

Right so Laravel development server started. So if we type into our browser http://localhost:8080/admin/posts. And here we go, here’s our anchor install so we can create a new post and call that hello world and its created fine it shows up in the database. So yea this is a living breathing anchor install.

So say some time passes and we need to update anchor. It’s quite simple all we do is composer update and that will look at the composer.json file again and check what versions we have already installed and update any that need updating.

And the great thing about that is it only replaces folders inside this vendor directory so any customisation done in the app directory wont be unaffected and also means you won’t have to do any manual copying and pasting like the current anchor build.

OK so that’s basically it I’m not sure if this is the best way of doing it. It’s still very much in the beta phase as it were but we’ll see how it goes as I start building more of the application. It may turn out to be a red herring but first impressions have been pretty good.

So this is me guys, it was just a quick demo.
I hope you like it and I’ll see you later.