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

An intro to using Trello

More and more University staff here are using Trello for sharing ideas and collaborating on projects.

So I’ve made a super quick intro video which I’d like to share on using Trello for Tracking bugs.

WMG IT - Using Trello
WMG IT – Using Trello

Please remember that Trello is a cloud service and we must abode by the University’s Cloud Usage Rules, http://www2.warwick.ac.uk/services/gov/informationsecurity/faqs/purchasingissues/cloud/

Being brave enough to change a process

Today we had to change a large process that wasn’t working.

The State.

A web development being built hasn’t got automated tests written for it and requires an office member to go through and MANUALLY test every item. Basically what Behat or DalekJS should be doing…

Anyway, the tests were all written in 1 document. “When I create a module, it should appear in a student’s list”, “When I select 3 modules, it calculates the student’s points correctly”, etc…

My process to solving a process.

Sometimes improving it can feel a bit daunting, however, as you talk through it with the team, record small sticking points and pains, then the you should start to see a bigger picture.
Always remember, you probably just need an evolution not a total revolution.

Steps…

  1. Remind the team, that they own this process so they will want to find solutions to save themselves time
  2. Talk through the whole process, record EVERY sticking point
  3. Look through the sticking points for the worst offenders
  4. Think of simple ideas to fix them
  5. Repeat 4 until happy 🙂
  6. Talk it through with all the team
  7. Go!
  8. Re-look at it again soon!

Our Biggest Problems were…

  • Testing document, who has the latest copy and where?
  • TheTesting document is really fiddly for comments
  • TheTesting document doesn’t really handle versions very well
  • It’s difficult to discuss the comments inside theTesting document
  • What should the developer work on next?

Some solutions…

  • Testing document has been moved to a Shared OneDrive for all the project Team.
  • Re-named testing document “Testing Document v1” to “Testing Document”, losing the version number indicated its “alive” state
  • All Passes are still recorded in the Testing document with the word “Pass”
  • All Fails are recorded int he Testing document as “Fail”, but no comment
  • All Fails with comments are created as tickets in a Trello board with the unique test id and a description of the fail
  • All Fails are re-ordered in the list by the Product Owner to show importance
  • A Trello list was created for the Product Owner to rack up no more than 5 tickets which the need the developer to work on next

Should you allow clients into your bug tracking software?

I believe yes, you should. With the proper caveats and training, your client should be able to see what’s going on.

The client has fewer surprises, is in on the problems and #FTW’s. They feel more connected to the product and weirdly will start to feel more “onside”.

Sure it might seem scary at first, but after the initial storming, the process does begin forming!

It’s all about improving process through transparency.

Today, the institution changed

A lecturer I’m working with has started his own board in Trello and invited me to contribute to it.

It might sound like nothing, but change in an institutions is a slow beast, however I’ve been here 4 weeks and the team are excited about learning and trying an Agile way of working.

Effectively he’s created a project backlog of his own, somewhere him and his team can share their ideas, comment and look to improve their projects bit by bit.

All I did was set him up access to my par’d down support Agile board and now he’s set his own because he liked it.

Very cool.

 

Killing off your emails, aiming at project transparency

Just wanted to share, recently I read this article…

https://netguru.co/blog/cc-all-the-emails-tips-from-a

It talks a lot about transparency which I totally agree with. A more transparent team is a more efficient and better team. Proper transparency means the team’s (including the client) expectations are managed and less confused. However I totally disagree with emails as the best tool for transparency. That is a Big Bad Decision. From my experience as a project manager at Thought Den and beyond, project emails only lead to a breakdown in communication and less transparency.

emails only lead to a breakdown in communication and less transparency

Emails turn into a constant mailbox search for important project facts hidden away in a long thread. Emails go wrong, people get missed out and conversations become so indented you need a 90″ wide screen to read them. Conversations become overlapped, badly formatted and the whole studio gets into a major issue with, “which email is correct?”.

A messy email chain
A messy email chain

Every efficient studio team needs a single, open, multi-platform and simple point of project contact. For me, that’s in the form of Trello, but JIRA and Redmine are both great too.

The Trello backlog board is where changes, tweaks and additions happen. It’s searchable, accessible by all the project team and it’s one shared place for everyone to work in.

The sprint board
The sprint board

Also, if a client wants to know what’s going on presently with their project or maybe a scrum “pig” (a team member with skin in the game) has a question for them, the whole conversation should be kept in a Trello ticket in the sprint board. Here features are broken down by ticket and they maintain an easy to follow comments thread. No more missed emails by half of the team because they missed 1 important email.

Conversation
Conversation

In fact, ANY changes and clarifications go in there. Even if they’re copied and pasted from an IRC chat or written straight after a phone call. They go in there, so make a good habit of it.

That leaves an email replacement for day to day teamwork, transparency and cohesion which is best with daily Scrums on Google Hangouts, an IRC channel and some face to face time. The client may join in and “chicken” (no skin in the game) if they wish. It’ll give them more transparency on progress.

Do do transparency, but keep away from emails.

How to quickly delete a list in Trello

If like me, you occasionally need to copy Trello boards to create a new Agile Sprint the same as the last, it can be annoying clearing out all the duplicated tickets with it.

And you can’t just click on, “delete list” and permanently delete a list, because it doesn’t exist.

So the fastest way I’ve found to do it is this way…

* Select each ticket (using the keyboard arrow keys)
* Press `c` to archive each one (it archives it)
* Use the arrow key to navigate to the next one
* Repeat
* Once they’re done, Press `w`
* > archived tickets
* Select `Delete`, `Delete` from there

It’s all a lot less mouse or keyboard work

I wonder if you could write a Google Chrome plugin to sort it…?