Manual QA #FTW :(

Recently I’ve been looking to improve our app delivery QA. We’ve had to come up with a solution for our team to run the QA.

So we got the test plan from them and currently the QA was being run from a spreadsheet… on one person’s machine.

So after much chatting with our WMG Team, I lead the design and implementation of QA system we’d be more used to. This also meant rather than me diving is a developer and just writing some tests, I am utilising the resources available to me.

Our new system…

  • Keeps our workflow in Trello, which means shared work and understanding
  • Handles file uploads and pictures for visual help with Asserting something passes
  • Can push failed tickets straight into our Sprint board for resolution
  • Can write verbose test instructions so the QA can be passed to anyone in the team
  • Handles discussion on why it failed, or mistakes
  • We can copy the board for each build

Workflow

  1. In the “Master board”, we write new QA tests and maintain the Master instructions
  2. When a new build is released, we duplicate the “Master board”, we add the build number to its title to make a “Build board”
  3. We share and assign the QA tickets to the team
  4. We process them in order
  5. Any passes, we just archive the ticket, gently clearing out the board
  6. We mark any errors / fails / bugs in the “Build board” and move them to the Sprint board, “Failed QA” column
  7. Then Repeat for every QA run we need to do
testplan v0
Testplan v0
testplan v1
testplan v1
a verbose qa test 1
a verbose qa test 1
a qa test 2
a verbose qa test 2

[ReflectionException] Class LocalUsersSeeder does not exist

Just a quick techie post to help out any other laravelians’ who might hit this issue with Laravel 5.2 and database seeding.

I’ve written a seeder and it keeps failing to seed when I run this,

artisan migrate:refresh ---seed

[ReflectionException]
Class LocalUsersSeeder does not exist

Turns out the quick fix was all I had to do was re-run the

composer dump-autoload

Then it all worked! #HTH

Re: “Baking in” SCD…

Planning for Change, some evidence. Here’s a little follow up to my post, “Baking in” SCD.

I’ve been forwarded this link which is exceptional in it’s brevity and information. I suggest anyone in HE should read it’s from the, “Leadership foundation for Higher Education” and is called, “Adaptive capability in higher education institutions“.

It looks at 4 Universities and they change they went through with details from staff at all levels involved.

Some of the major points I thought were interesting.

  • Enterprise Enablers – in Plymouth Uni. 60 people who were enthusiastic about the changes from across the spectrum of the University. These people helped champion the change from all walks of the University staffing.
  • Town Hall meetings – Places to have open and frank discussions about the changes with the VC’s and people at the top.
  • Details reports on the actual state of the University – Senior staff having access to the correct information
  • A reason – The changes reported as successful had or created an urgent need
  • Removal of staff – Blindly reducing the headcount, left staff un-happy. But involving the unions, discussing reduced working hours and structural changes left staff with a better morale
  • Students suffer – There’s a massive tripartide relationship at Universities between Academics, Staff and Students. Balancing changes appeared to adversily affect the students.

We’re ignoring our stakeholders and they couldn’t be happier!

The following is a set of techniques that at WMG, Warwick University I have led and implemented on various digital projects to great success. Stakeholders are happy with it, and they’re not inadvertently altering the success chance of the projects.

You’ll recognise this. Every project you run, has a plethora of stakeholders involved. In some large organisations too, you’ll find they enjoy a rather flat structure where everyone’s opinion is valid and should be considered.

So when you invite lots of people to a meeting, you come out with a mess of features and a confusing array of project actions which possibly didn’t need chasing up. Because of this we need a framework that will allow for ideas from all people, but only qualify the ones which are “goers”.

Here’s 4 tips that I use with my teams at WMG to both keep the stakeholders happy. It makes but the project the most important success factor, not egos. It makes everyone nearly equal.

1. Have a shared Product Backlog or the “the duff idea buffer”

Headline.
This is a place where all ideas are held and are accessible to every stakeholder. This isn’t an obtuse Word Document you keep emailing round with “Track changes on” and forgetting to CC (Carbon Copy) people in, but more like a shared pinboard on Trello.com which you can export every so often to Excel.

Reasoning.
The reason for having a shared Product Backlog is more to do with human behaviour than anything else. Often in a working group of many, you’ll find most of the angst is whether or not someone’s personal idea was set down and recorded. Some / most of the suggestions will be pants, off-topic and not worth the keystrokes you took to record it, that’s natural, we all do it.

However, if it’s fairly recorded somewhere you can move on, rather than discussing its use-fullness there and then.

Often you’ll find that the person who raised it, after a couple of days, gets some perspective and realises they don’t think the idea’s any good anymore.

1. Have a Product Owner (the gatekeeper)

Headline.
This is 1 person. Not two, three or 12. Just 1. It is 1 person who was voted by the stakeholders as the “best decision maker for the project” and who always decides what’s the most important action for the project next.

Reasoning.
So sure, the stakeholders have now had their thoughts recorded into the backlog, but let’s be honest, quite a lot of that might not be immediately urgent or produce the highest business value. So a Product Owner is voted in by the stakeholders as the person best placed for making decisions on the product.

They have authority. They were voted in by their peers, and so can yay or ney actions confidently. Also, if you’re worried about someone being voted in that’s a bit power hungry, it’s good to know that this role has a lot of responsibility, so their decisions have to be good, they’re picking how the project progresses.

3. Be strict.

Yup. They’ll hate this bit, but you need to vote in someone who can stick to these rules and keep to the rhetoric of, “Great idea, put it in the Backlog”, “You don’t get to pick, it’s the Product Owner’s choice”.

This way, no stakeholders can adjust how the project goes as they agree to the rules of the Product Owner says what’s next. By staying strict it helps fight the “culture eats process for breakfast” saying and starts adjusting how you work together.

4. Keep everyone updated, frequently

Every 2 weeks, re-present to the stakeholders what’s done so far. Then chat about what they think is important next. Invite them all every time, and after a while you’ll see they more just want to leave you to your work and don’t turn up. Allowing the process to move on.

The Product Owner can then make the decisions based on feedback about what’s next.

I hope that helps!

Note…. In the title, I mean, “happier” with our process, I imagine their first child or standing on a surfboard might also be a happy event.

 

“Baking in” SCD tools to our staff’s daily appetite

Recently I started scratching the surface of SCD here at Warwick University by reading a couple of online resources. Then last week I planned to and meet some of the core team. The chats we had introduced some really interesting new discussions and concepts to me around change programmes.

SCD is a massive change programme here at Warwick University and it stands for Simplify, Collaborate and Deliver. It’s the concept that we can reduce waste on our tasks, work with each other and deliver change rather than just talking about it.

Here are some initial theories I’ve been knocking about in my head since that first chat and I wanted to ruminate and share them. Please bear in mind they are all TOTALLY un-tested and un-researched. For me this write up is more a process of going with the raw thoughts and seeing what rises up from it.

The thoughts are all based on, how do you “Bake in” SCD to peoples’ daily working lives? I’m sure this programme is going to be very successful. However, in my mind the questions which rose to the top were, how do you make change programme in any institution more than just being a whim for staff, some training imposed from above or worse… a new expensive fad which fades! How do you “bake it in” so that when ANY staff member has a work problem there’s something in the SCD toolkit to call upon as naturally as picking up their phone?

btw. “Baking in” is a term to describe that there’s no extra input needed, you’ve got access to it easily. You’ve baked in cranberries to that pie so you don’t need to add any separately. It’s just there, baked in.

Herd immunity

A well known medical term and practice for immunising a population against disease is Herd Immunity. The theory and practice is, you don’t have to immunise everyone, but at least a certain percentage of the population to prevent widespread pandemic… Obviously I don’t think the staff are herd, or that there’s a disease, but the point is that the population is resilient even if not everyone is immunised. Is there cross over in the theory here where if enough of the staff are trained in dealing with Waste and Change (SCD) that as a University we are resilient?

How would we know when we’ve hit that point or herd immunity status, what KPI’s and monitoring would you introduce to know we are “immune”.

Trickle down SCD

In the same way that “Trickle down economics” doesn’t work, how do we make sure this programme doesn’t fail from “Trickle-down change”? How do we inspire, support and sell grass-roots change?

Is there a way to create equality of access and interest in SCD so it’s “Four Legs Good, Two Legs baaaaaad”?

How can we make a culture where everyone feels the same responsibility and expectation of each other to practice and learn from it?

How can we make make sure we use people’s skill and enthusiasm across a spectrum of the Payroll Grading, the Departments and Skill sets?

Culture eats process for breakfast

It just does.

So why would most people here care about LEAN and SCD? A lot of people just want to get on with their job. Would purposefully identifying enthusiastic people lead other people change their culture?

Include it as a DPR requisite

Well if it’s that freaking important, how do we back that up and make it more than an avoidable fad?

How do we make sure it doesn’t go away, could we include a couple of questions or tick boxes in staffs’ reviews to remind them if they’ve practised SCD this year or not?

People do like to learn and would enjoy SCD, however they also have their day jobs. How do we make it a common thing for everyone to muck in with? Could we attach it to merit pay? How could we highlight and celebrate people who have purposefully called on SCD to solve a problem?

Done!

Anyway, there’s my initial and wide-ranging thoughts on a new subject. No answers yet, just questions! Also, I really enjoyed these pictures from this blog, have a look

Are you too busy to improve?

are-you-too-busy-to-improve2 are-you-too-busy-to-innovate1

Simplifying Digital Reporting Tools in WMG, Warwick Uni

As we’re speccing and delivering more digital systems at WMG, Warwick University, we’re beginning to re-evaluate how we handle reporting from each and every system. It’s becoming clear that every online application or process seems to implement a different set of reporting tools by default.

Currently we have 2 which output custom .csv’s (comma separated values), another system that you only get reports out if the developer is available and we have 3 more systems planned for release in the Summer all with reporting requirements.

Clearly we’re need to start offering a more unified interface for our users, so we can,

  • reduce the strain on developer time per. system (a premium)
  • simplify the learning requirements per. system per. staff member
  • improve product delivery time

As a potential solution I’ve been looking into clever add-ons from elastic.co, which as a dev is my favourite. However, that would be a new system for admin staff to have to learn. Also, we can’t implement it on all the systems, just a few of them.

Another potential system might be Microsoft performance point, however, no-one here knows that system. Also, we’re unsure of which technology stacks it will hook into.

However, we’ve discovered a more generic solution that would build on our staff’s Microsoft Office skills rather than learning technologies and it can access any technology stack.

It appears that Microsoft has an add-on called “Power Query” which connects directly to Azure, SQL and Mysql databases. With a read-only database account for staff and administrators, they would connect directly to the database and with some guidance access and work on real live data. If we were to organise a shared OneDrive folder with the queries and charts in, then we would reduce the team’s adoption.

This way, I won’t need request time to build custom reports on every project, unify our reporting technology to one piece of software and reduce the cost of licensing to our current Office 365 licence.

We’re at the stage where we are going to trial Power Query and I’ll report back on our findings.

State of the Unicorn (from Sep to Dec 2015)

Super proud of my husband for getting the job he wanted at the University of Warwick! Congratulations!!!

The previous state of the union post.

I wanted to do more, of these but have I? This is just a post reminding me of various bits I’ve done these past 6 months.

Digital Strategy

  • Unify our custom development endeavors
    • Leading the unification of previous dev work into a team accessible resource
  • Staff training in GIT
  • Staff training in Gitlab
  • Staff training in Gitlab CI
  • Researched, Created and maintaining standards for our dev team to work with (simple stuff docs and processes)
  • Started our “disaster docs” if someone is hit by a bus / wins the lottery
  • Identified need for QA resource
    • Got the QA resource!
  • Roadmap
    • Asked for and took Action to start a “Technology Enhanced Learning Operational Roadmap” aimed at engaging team members with future considerations
    • Actioned the Roadmap meetings and discussions
    • Lead the Roadmap meetings (ongoing)

Human Resourcing

  • Completed the Line Manager Hiring training
  • Completed the Line Manager Ethics and Diversity training
  • Sat on the interview panel for 3 WMG roles
  • Spoke my mind clearly to Head of interview panel
  • Invited to help write job specs for 2 roles
  • Invited to help create job interview tasks

Representation of WMG

  • Invited to the MyDay CollabCo User group to represent WMG & UoW

Agile & Project Management

  • Improved on the Agile workflow I introduced to work better inside the University environment
  • Project problems solver – became the goto person for digital projects going “haywire” and turning them into achieving projects
  • Had our first Agile vs. Culture issue, got knocked, learnt and then spoke with the relevant people to be less knocked next time
  • Ran “Introducing Agile” for more staff again
  • Agile coached 2 Product Owners on their projects and any fails / issues they were experiencing
  • Ran multiple, “introducing Agile courses”

Actual Production

  • Lobbied and received Continuos Integration access from Central IT
  • Setup Gitlab CI to build, test and deploy on master push
  • Changed development method to BDD (Behaviour Driven Development) with Behat
  • Created local, feature, pre-production and production flow
  • Built a Transaction and BDD testing process
  • Built re-usable modules for
    • Continuous Deployment
    • Google Analytics
    • Environment Banner to identify app servers
    • Basic User Role ACL control
    • HTML Helper templating
    • HTML / CSS workflow
    • Model Repository Modules
    • Pulling live DB to local DB for testing
    • Clearing DB automatically
  • Improved my Laravel 5 understanding

Projects

  • Maintenance on Biddr (my custom reverse bidding web app)
  • Launch and Maintenance of critical Supervisor & Project matching tool for 1000 users
  • Parachuted in to sort 3 broken projects
    • Applied Trello Story Points
    • Started the team talking again (humour and leadership)
    • Created strategy to bring the external developer more “internal”
      • Skype
      • Daily scrums
      • Internal account from IT
      • VPN access
      • Added to our Gitlab central repo
    • Applied Weekly sprints
  • PM Elective Selector
  • PM MyTime
  • PM Visits
  • Maintenance on Gradr

Next…

I’m moving towards more Project Management, so training in that and more experience.

Maybe become a line manager

Baby!

Agile Release Management Training.

Just a note of my training this afternoon.

We looked at Epics and Adventures and how they sit in the overall weekly Scrum planning, Backlog Grooming and Release planning.

We looked at Roles and Responsibilities within a FULL company setup, past and further than just the Scrum team.

I was told about a new role in an Agile software team which is solely to do with Documentation!

We looked at the challenges of change management and “Culture eats process for Breakfast” so people management is very important with change.

From this I have created our own Agile Project Initiation Document (to only approve high value projects), a Roles table for every project (who is what) and a Responsibility table (who does what)

Speed up your Behat testing workflow

So I’m really enjoying Behat and BDD so thought I’d share a cool tip which has sped up my writing test workflow using @tags.

When you need to keep re-running one of your tests you can use tags to make sure you’re only running one thing rather than a whole suite or the whole .feature file.

Basically, in the test you’re working on, add a tag @now

@now
Scenario: Student who has requested an Interview can Apply
When I follow "View"
Then so and so

Now run your test like so,

behat --tags now

It will only ever run that tagged test, so you’re not running loads of others and waiting around. Sometimes, it “feels” even faster to run,

behat --tags now -f progress

I know this may seem pretty simple, but I’m learning here and found this really useful.