Regression testing isn’t everyones favourite task so as testers we have tried to put a bit of fun into it. Each time we have a theme. At 10am we play music in the office to announce to everyone that it is testing time. (Star wars -Imperial March being my current favourite).
Everyone gathers for testing kickoff, where we explain the teams and what each of them will test, and more importantly why they are testing.
Its a good way to get new starters involved, as it shares our testing mindset with them and they get a chance to learn our product.
During this time testers are on hand to support testing, not test everything. We sit with developers, UI, UX etc to aid their testing and help them learn the product.
When choosing a theme the song is really important. This is played into the office to signal that it is testing time and to encourage people to leave their desks to join us for testing kickoff. Past themes have been:
- Star wars
- Jurassic Park (to celebrate the film release)
- Fraggle Rock
- Looney Tunes
- Lego with ‘Everything is Awesome’ as the theme (this was very very successful)
- Wallace and Gromit
- Game of Thrones (to celebrate the end of the series)
- 80s cartoons (could go on for 100s of releases with that!)
How often do we run these?
We currently release the site every 2 weeks, although its becoming more regular which is great!
We are not at the stage where we have fully automated regression but how things are changing with automation is probably for another blog.
This post doesn’t have a lot to do with testing software but does show some of the testing techniques that I used in a real life situation yesterday. Its ultimately a fail post but demonstrates some of the ‘when to stop testing heuristics’ from Michael Boltons blog
For the month of July I spend a lot of my free time helping set up Standon Calling festival.
The art director is one of my close friends, and in exchange for a few tickets I help paint and sew while my toddler entertains everyone. (probably more toddler supervision by me than anything else*)
My task for Saturday was to cover some sofa cushions with material. My first thought was how can I get this material to stay put and I saw another girl was slowly sewing it onto the cushion. So, I started my hunt for needle and thread. Found it and started tacking the material on. If anyone has ever tried to sew velvet into a really thick cushion and a small needle you can probably see what is coming.
It was hard. Really hard.
I did a couple of stitches and stood back and thought to myself that if I was to sew this on it would take me all day, which wasn’t acceptable. So I used the ‘Pause then refresh’ heuristic.
Staple gun! What a great idea. So I walked back to my van to get the staple gun. Sat down and started pushing the gun as hard into these cushions as I could. Another fail! Staples need something to hook onto. There was no way they would ever stay in.
Wait! Glue gun. Awesome idea Liz! This was easier to source than the needle and stapler, only problem was there was no power in the area I was and I could’t go anywhere else (due to toddler duty) so I very disappointingly gave up.
I was stuck.
Sounds like a lot of excuses.
On reflection if I had thought about the task I was asked to do before I jumping in and started it, I could have used my time more effectively.
*Sorry for not being more helpful Standon Calling Art Crew! Next week I will get my toddler to help me out with these problems.
I watched Dean Poole
at the Design Indaba
conference playing with the word Art and it inspired me to give word play a try.
As testers its important to be able to talk to people, and to know how to ask good questions, which means I really like words!
I have taken the word TEST to work on for the morning of our Friday projects day and see what I come up with.
I have chosen a number of techniques to have a play with, but there are many more out there!
It has been trickier that I thought and in hindsite using a word with the same letter in it twice has proved challenging but here are my results!
T E S T
E H C O
S H O P
T O P S
Testers love to ask questions
Explain to me how things work
Show me what things do
Tell me why it does it
T is the most commonly used constanant and the second most common letter in English language
E is the most commonly used letter in many languages
S is the seventh most common letter in English and the third-most common consonant
T (we know this one already)
James Whittaker Tours
Up next it gets a bit trickier, so I am going to take a break and come back to it next week!
This was an interesting read this morning.
My team suffer from many distractions so we will try to monitor them using the waste snake
Well not quite, but making it more the teams responsibility….
There has been something bothering me about the way we do regression testing and I want to try something a bit scary.
We release every 2 weeks. Scrum teams test their own features on our CI environment, we then branch to test and regression test the whole site. This is split into areas, and each scrum team gets an area to look after. The scrum teams like to test other peoples work for 2 reasons:
- its nice to checkout what the other teams are doing.
- the other teams act as a safety net for teams own feature testing.
This makes me a bit uncomfortable.
Its forcing us to not be responsible for the quality of our own work. As the QA team organise regression testing this is seen as the last point of call, which sends the message that feature testing isn’t as important.
‘Regression testing is a type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes such as enhancements, patches or configuration changes, have been made to them.’
We still have a need for regression testing, but what I want to address is the ownership of quality.
As Funkadelic say Can You Get To That ?
I have been throwing around conversations with the developers to ask them how they would feel about regression testing their own work. The initial reaction is intense fear, but following some reasoning its now just fear.
My plan is that is everyone shares the testing, we will work out a better way to do it, automate some (I mean more) tests and be a lot happier. We will tackle knowledge sharing by pairing more.
I still have a lot of work still do to so I will blog my journey of making the real responsibility for quality to be everyones.
Perhaps more Kanban that Scrum, but I love this clip from Silicon Valley
Its a great show!
I read Michael Boltons blog about severity on bugs and it reminded me of a conversation I had with a couple of scrum masters recently, who were keen to start using severity on bug reports.
I have always questioned the use of severity and if it really is of any use mainly mainly because:
- Its very subjective
- There would be a tendency to never fix anything that is medium or low, as the term ‘low’ sounds unimportant. Why do unimportant work?
- Everything would be raised as high, as we all think our idea, or bug is the most important
Here is a Michael Boltons post about the way a lot of companies categorise the severity of bugs, and how this really impacts users, the company and the people in that company.
Taking Severity Seriously « Developsense Blog
Its pretty blunt, and goes to extreme cases, but has a good point
Severity is different for all sorts of people. The impact a bug can have could be seen as not important, “Oh its just a design bug in IE, who uses IE anymore anyway?” . But if it makes us look silly it can reflect on the companies reputation and the way other departments view the development team.