punkmiktestshttps://punkmiktests.wordpress.com
Software Testing ThoughtsMon, 17 Jul 2017 12:19:29 +0000enhourly1http://wordpress.com/https://s2.wp.com/i/buttonw-com.pngpunkmiktestshttps://punkmiktests.wordpress.com
Yes, developers should verify their bug fixes, but …https://punkmiktests.wordpress.com/2017/07/12/yes-developers-should-verify-their-bugs-fixes-but/
https://punkmiktests.wordpress.com/2017/07/12/yes-developers-should-verify-their-bugs-fixes-but/#commentsWed, 12 Jul 2017 18:28:19 +0000http://punkmiktests.wordpress.com/?p=863Continue reading Yes, developers should verify their bug fixes, but …]]>First of all, thank you to everyone who has spoken to me about this on twitter, on the blog, in person and even in the aisle of Tesco!

The main consensus is that “Yes developers should verify their bug fixes.”. And now come the many “buts” (is that even a word?).

Yes developers should verify their bug fixes, but…

… still use the 4 eyes principle or two heads are better than one. It does not have to be a tester necessarily who helps with the bug verification, it could be another developer, a product owner/manager, scrum master or designer. -Basically, most have stated that another pair of eyes makes the team feel comfortable that the bugs were fixed correctly.

should this be a discussion about quality? I expect devs to replicate the bug and test it’s fixed as part of fixing it , regardless of if there’s another step in the process or not. –I would like to add here that I find the pointer towards quality interesting and want to explore that more. And I think both point 1 and 2 also point towards the fact that you should be owning your work and make sure it is getting the attention it needs.

clear bug reports help build trust. – I totally agree. If you can rely on your team members to communicate issues effectively and clearly this builds trust and you know that if you follow the steps indicated you can then verify if the bug is now fixed.

if we fall back to “aren’t the AC enough?” then why test at all? Aren’t the AC enough for a Dev to verify all their work? –I think this went in a slightly different direction. I still feel that testers’ time is well spent exploring stories and testing implementation of features. In the process they may find bugs and report these (hopefully clearly). And the steps and expected results in those bugs should be enough for anyone to verify the bug is fixed.

is verifying a fix, not more than that? Is it not also retesting a full feature and doing a regression of the system’s area? Hence it should be a tester doing the verification. -Well, I think they are different tasks and exercises. At least in my current context. If the fixes to bugs are so large that the whole feature or area needs regression testing than maybe there are other process issues to think about.

there should be testing expertise available if needed. -Yes!

in certain context the risk is too high to not involve testers in bug verification. -This was generally the consensus from people working in financial industries. I totally agree and think this makes sense. These are often large legacy systems and you never know what you may find as a result of a bug fix. I mostly deal with newish code (less than 2 years old)

So this is my second post on this subject. I think a lot of my thinking comes down to team sizes and speed of working. I am trying to work out if we have enough testers across the projects and how we may have to change the way we work if more projects drop on us in the near future. One of these changes may involve the way we think about testing and what a tester’s role is on the team. Will their role still involve verifying all bug fixes? I think i’d like to push for No and see what happens. More on this if I get somewhere, or not.

So far this has been great in getting an idea of how people may react and how it may affect the projects we are working on. Thank you all!

]]>https://punkmiktests.wordpress.com/2017/07/12/yes-developers-should-verify-their-bugs-fixes-but/feed/2punkmiktestsShould developers verify their own bug fixes?https://punkmiktests.wordpress.com/2017/07/06/should-developers-verify-their-own-bug-fixes/
https://punkmiktests.wordpress.com/2017/07/06/should-developers-verify-their-own-bug-fixes/#commentsThu, 06 Jul 2017 19:29:51 +0000http://punkmiktests.wordpress.com/?p=818Continue reading Should developers verify their own bug fixes?]]>This is my attempt at starting to document this discussion I am having in my life about if developers should check their own bug fixes?

In my previous job, we worked very differently to how the teams I work in now work. Not only because my previous teams worked in Continuous deployment and delivery compared to a more rigid 2 weekly release cycle, it is also partially due to the fact that I now work on projects rather than a product the company owns and develops and maintains through and through. The projects can be anything from 6 weeks to 2 years long with the long term projects being a newer thing.

In the old job we were 2 testers across around 2 product teams and our time had to be used in the most useful and productive way. One task traditionally executed by testers is to verify bugs are fixed. I had forgotten about this because I hardly checked bug fixes in the last 2 years. Why did I not verify bug fixes for 2 years? Well, one argument is that in general a bug report has a well defined steps to reproduce and an actual and expected result. Hence anyone should be able to check if the bug is fixed. Why not the developer? It hardly takes testing expertise to check a bug is no longer happening. With verifying bug fixes off of my plate, I could use my time doing exploratory testing of new features and user journeys through the application. I would of course still log bugs and discuss them with developers, but there was less of the bug fix ping pong going on.

Now with me changing my job, I saw an opportunity because a big time sink of the few testers I now work with is doing bug verification. I tried to argue that maybe they should not be testing the bug fixes but it should be the developers’ responsibility to test their own fixes. I heard some interesting pros and cons for this internally and through twitter as well. So here we go:

Pros:

Frees up testers’ time to do actual exploratory testing. Bug fixes could be classed as “checking” and the bug reports should be clear enough for anyone to check the fix.

Trust – no-one wants todo bad work and a bit of trust goes a long way for good team dynamics.

If developers do more testing, they may find ways of making it easier/faster by writing scripts or little tools, that the test team may not have the skills for doing on the fly.

It may lead to more pairing to avoid bugs in the first place.

Cons:

Lack of trust – historically bugs were not fixed properly and there may not be trust that the developer completely fixed the bug.

Would you check your own homework? Devs testing their own code is frowned upon, does this also apply to bug fixes?

Is it really fixed if no-one else has seen the fix?

What about knock on bugs that appear as a result of the fix?

What are your pros and cons for verifying bug fixes? Do you check bug fixes? Does it take away from your time testing the application?

I do think there is an element of “it depends” here as well. And this applies to the severity of the bug and the further risk of something else being wrong after the bug fix. But I would hope that someone checking a bug fix would notice if something else was wrong but maybe I have worked in very trusting environments the last 2 years and I need to re-adjust my thinking.

]]>https://punkmiktests.wordpress.com/2017/07/06/should-developers-verify-their-own-bug-fixes/feed/7punkmiktestsJoining a CD Team the experience reporthttps://punkmiktests.wordpress.com/2017/04/28/joining-a-cd-team-the-experience-report/
https://punkmiktests.wordpress.com/2017/04/28/joining-a-cd-team-the-experience-report/#commentsFri, 28 Apr 2017 11:22:49 +0000http://punkmiktests.wordpress.com/?p=770Continue reading Joining a CD Team the experience report]]>Today is my last day at Songkick. It has been amazing. Unfortunately I am in no position to move closer to the office, which means commuting! Commuting has taken its toll on me and I decided to call it a day and cried a lot.

When asked during recent interviews what my dream job would be, I did honestly say, my current role at Songkick. It obviously had its challenges but I don’t think a role has pushed me and enlightened me as much. Thanks for giving me the opportunity to experience it.

I cam from a scrum team. We had bi-weekly releases and a comprehensive suite of selenium tests that ran through the browser. By comprehensive I mean, we had 64 hours of selenium tests that when run in parallel took 4 hours. So if one test failed because it found a bug, is flakey, you name it, you lose another 4 hours.

This meant there was a 3-5 day code freeze before the release date as well. We also used a typical scrum board with columns including a testing column. Some were even so granular that there was a “Ready for test” and “In test” column.

Any bugs that were raised during the sprint ended up in the to do column and needed to be fixed and regression tested before the sprint could be closed off.

Typical problems I had at this job were:

Testers become the “bottleneck”

Convincing team to help test rather than start new work

Defining acceptance criteria

Everything had an acceptance test

No unit tests

When joining CD teams it is worth understanding what the CD stands for. At songkick we have both products working in Continuous Delivery and Continuous Deployment.

At the very basic level both have an automated test and release pipeline but the Continuous Delivery approach still has a manual step to deploy to production, whereas Continuous Deployment would deploy the code straight to production.

This environment came with many learnings for me.

Ready for test:

Being used to the “Ready for test” column it was quite a shock to join Songkick and its continuous delivery and deployment approaches. Don’t get me wrong I joined because of these approaches as well. In conference talks this often appears to be a mystical world of software development where you test your code on production and developers have relatively good dev environment set ups that they can test well themselves.

But when do I test? Also where do I test?

There was something like a complete loss of control. In certain work environments (not Songkick at all) when a bug is found in production, the test team gets blamed. “Why wasn’t this tested?” is a common phrase. If you have worked in such an environment and then go to continuous delivery you can initially feel panicky because things move so fast and you may not be, or are very unlikely to be doing the testing.

What helped was understanding what is actually going on when new features are being developed. A thing that helped was that testing is happening everywhere all the time.

So discovering that everywhere testing is happening and can happen is invaluable. So you (not you personally but the team) can and probably is testing all the time everywhere. This starts with Kick off conversations. Here you get the chance to test the idea, the problem and the ideas around implementation. It is also a good place to state how you would test the feature.

A great tip from Amy was that in previous roles she learned that telling people what you will do for testing the new feature meant it would already get done by the person developing it and hence there will be less bugs.

So overall these kick off conversations become the most valuable part of testing for a tester at Songkick. They help inform what is just enough testing for this particular release.

Forget about “Ready for test” columns. Everything is continuously being tested and not necessarily by you. Think about how you can integrate your tester mind-set to be heard.

Ultimate shift left:

Get in on the planning discussions, requirements, stories, kick offs, whatever you call them, just invite yourself to the meeting and ask questions such as:

What is the problem?

Who is having the problem?

Why are we fixing it now?

How will we test it?

What is the risk of shipping bugs?

Do we need to consider non functional testing such as performance or security?

Team and trust:

Build good relationships in your team, because you will be on holiday for a week and there will have been 50 small releases to catch up on that were not tested by a tester.

For me this was about letting go and trusting your team members. Remember no one wants to write bad code and ship broken features.

Like I mention above I felt lost in the beginning, where do I fit in? Who is testing all of this?

A lot of that was about letting go of control issues. Discuss things you care about in a team setting, such as quality features and processes so you all feel comfortable. We did a great session on what quality and quality features means to us and how we define “just enough” testing. This can vary across products and teams but is so valuable to talk about.

Mindset change:

Testing becomes more of a proactive role, where you do the testing early on by pairing with developers, or going through unit tests, or liaise with the business to make sure you have the right acceptance tests in place.

Some of this mindset change may be to embrace more of a coaching mindset and sharing experiences and testing knowledge with team members.

At least at Songkick you are an expert in your field and can leverage this to help the team get better at testing in general.

Forget a “release date”. Communication is key:

If something is ready to go it will be released. Establish good communication with teams affected by changes. Release log emails, cross functional team updates in slack or regular catch ups.

This was an awesome change for me, to see how much the team is communicating with other departments to let them know about changes.

Test in production

Get to know your production data really well, as a lot of testing will be done in the live environment. This has great advantages as the code is being tested where it is being used with real data but it can be daunting, as you could be affecting real reporting. Liaise with the relevant departments to help sort this and avoid any confusion.

I was always worried I would notify people about fake events. Liaising with the relevant teams and setting up data in a way to not disturb real fans was fun and scary at the same time and we actually found a bug that we could then fix asap.

Joining Songkick was one of the best things I did and I am super sad to be leaving today, but I am also excited about sharing what I learned and bringing this to a whole new role on the near future.

Have you had any experiences joining CD teams? Any learnings to share?

]]>https://punkmiktests.wordpress.com/2017/04/28/joining-a-cd-team-the-experience-report/feed/4punkmiktestsscrum-task-board-template-powerpointg1361999261125710696.jpgExperimenting with a Zero Bug policyhttps://punkmiktests.wordpress.com/2017/04/27/experimenting-with-a-zero-bug-policy/
https://punkmiktests.wordpress.com/2017/04/27/experimenting-with-a-zero-bug-policy/#respondThu, 27 Apr 2017 12:46:43 +0000http://punkmiktests.wordpress.com/?p=766]]>It has been a while and there are some news on the horizon.

During my research for the talk I decided that I will explore this a bit further and apply it to testing and maybe even evolve my talk in the future.

To help myself with that I decided to do a small series based on interesting articles, books, podcasts, talks or videos I have seen while researching my talk and since.

I have also had some great and insightful feedback full of suggestions of side topics and other materials to explore.

Hopefully you will join me in this research and find it useful for yourself.

Note: If you are interested in what each talk of Testbash Manchester was about there is a great summary of the day here.

Let’s get into the series.

Introduction: Why I chose this topic

When I started testing I think I was good, because I loved pointing out problems and faults, not only in the systems I was testing but also in my everyday life. I was almost naturally wired to look for the negatives (which actually we all are, some more or some less.)

I lived a life all about problems, finding and ranting about the negatives in every situation.

Nevertheless in my opinion, I did ok in my career with this approach even though I did fulfill the stereotype of the moaning tester, one with a martyr complex that hated people (not great when you are meant to be a team player).

This may have been a side effect of the waterfall projects I was involved in, or just my personality at the time.

But everything changed when I joined (supposedly) agile teams and realised I needed to communicate in more ways than just with a negative connotation. I therefore decided to try and turn my frown upside down.

In this series I want to explore my uses of positive psychology techniques in my own personal journey but also link it back to testing and software teams in later posts.

Intro: What is Positive Psychology

Positive Psychology is the scientific study of human flourishing rather than the decline, and has looks for and suggests approaches to increase human functioning. Instead of asking what is wrong and dwelling on this, positive psychology looks at how we can be the best we are able to be.

“It has also been defined as the study of the strengths and virtues that enable individuals, communities and organisations to thrive. Positive Psychology is grounded in the belief that people want to lead meaningful and fulfilling lives, to cultivate what is best within them, and to enhance their experiences of love, work, and play (Positive Psychology Center, 2016).”

However this does not mean that positive psychology is not interested in how and why things may go wrong or the importance of understanding this, but it is intended to complement more traditional psychological approaches. The idea is to place an importance on using scientific methods to determine how things do go right and how we can apply this more widely.

The positive psychology movement in a way, is credited to have been started by Martin Seligman, American Psychological Association President, who in 1998, “…suggested that psychology turn toward understanding and building human strengths to complement the traditional emphasis on healing damage. Psychology had neglected the positive side of life, having spent much of the last half century primarily concerned with psychopathology. As a result, psychologists and psychiatrists can now measure with considerable precision, and effectively treat, a number of major mental illnesses. However, this progress came at a cost. Relieving life’s miseries made building the states that make life worth living less of a priority (Seligman, 2002).”

Positive psychology, in a nutshell, seeks to emphasise the origins and the effects of psychological wellness, such as positive emotions, positive experiences, positive environments, and human strengths and virtues (Lyubomirsky, 2007).

This was a short intro to Positive psychology. Let me know if this does not make sense or what else you would like to know.

I am making the series up on the fly, but I think next I will look at how other people have evolved the field and based their research on these initials proposals of positive psychology.

Myself and Emma recently organised an intro into accessibility testing with the awesome people at Test Partners.

They are really up for doing talks or tutorials with companies and are super friendly and knowledgeable. Do reach out to them if you have any questions on how to get started.

Why is accessibility important?

Up to 20% of the UK population has a disability but moreover research shows that 57% of the UK population benefit from accessibility features:

20 million people over 50 in the UK – diminishing eye sight

6 million + people with dyslexia in the UK

1.5 million people with arthritis in the hand or wrist – use keyboard shortcuts over a mouse

Anyone can have a temporary accessibility need – like breaking an arm or hand

I have been aware of accessibility testing and really enjoyed the talk by Michael Larsen on the subject at the end of last year but did not look into it anymore.

This is a shame really because the internet is meant to be for everyone and therefore be inclusive but many websites are not.

Do we as testers do enough or even know enough about accessibility testing to point these things out? Are we knowledgeable enough to have these conversations on why we are excluding certain members of the population on using your website or services?

Have you ever had these conversations?

One place I worked at, I had just hired a new tester who came from an external testing services provider. He knew quite a bit about accessibility and started to raise bugs against our website for the images missing alt text for example.

On the one hand the things he was raising were just good practice to have really. But why did we not raise this before?

I never knew what to look for. I was more focused on functionality for able bodied users, maybe because I could easily be that sort of user.

The positive effect the other tester had, was that the designers and front end developers became more interested in how to make the website more accessible and started to reform from within. They started to design good patterns in accordance with the Web Content Accessibility Guidelines (WCAG) 2.0. I think this is the hard thing when it comes to accessibility, you can raise bugs and therefore awareness against accessibility features missing or keyboard navigation not working but if the designers and front end developers and maybe more importantly, the product team are not considering accessibility from the start then it is really hard to add it back in.

Why do we not learn about these things when we start our testing career? Was I just blind to it?The ISTQB certainly did not tell me about it.

If you are on the dojo there is a great resource to get you started. Maybe there will be a 30 day testing challenge for accessibility testing soon as well. I would love that.

One thing that Steve and Paul from the Test Partners showed us was this tool. You can add the bookmarklets to your browser bookmarks toolbar and then click on them to get visual feedback on how your website is built.

This helps with understanding the semantics of your page. How it is built and structured. For example headings are usually large and lists usually have bullet points. However, the semantic structure also need to be conveyed programmatically by means of tags in the source code. And these bookmarklets highlight where something has been tagged as a list or image for example.

This is a good starting point I feel, to understand what flaws your page may have for screen readers. Screen readers use the tags in your source code to tell the user what the item on the page is and does.

I would love to pair with some users of accessibility related tools at some point. On a similar note this podcast on a blind architect was incredible to find out how blind people actually use screen readers. TL;DR at a way faster setting than you think.

Have you ever paired with a blind user? Or someone who cannot use a mouse? Or maybe someone who uses a magnifyer?

]]>https://punkmiktests.wordpress.com/2016/10/23/thoughts-accessibility-testing-for-the-web/feed/3punkmiktestsscreen-shot-2016-10-23-at-21-58-16Songkick from a Tester’s point of viewhttps://punkmiktests.wordpress.com/2016/07/11/songkick-from-a-testers-point-of-view/
https://punkmiktests.wordpress.com/2016/07/11/songkick-from-a-testers-point-of-view/#respondMon, 11 Jul 2016 13:43:37 +0000http://punkmiktests.wordpress.com/?p=633Continue reading Songkick from a Tester’s point of view]]>This is a link to a post I did for the Songkick dev blog.

I often get asked what a day looks like as a tester at Songkick. In the post I described the common tasks that occur across the product teams.

Have a read and let me know if you have any questions. I’m always happy to chat.

At the beginning of the year, I attended TestBash in Brighton and there was a talk that just stuck with me with practical application.

This was the talk by Katrina Clokie on Pair Testing. She even outlined how she trailed it in her job.

I recently got a buddy at work and we were talking about sharing knowledge. I really wanted to try pair testing, so we did a version of it.

Step 1 – finding the right task

The team did some work on a tool that I wasn’t too familiar with and as part of our development process we created a testing mind map.

During coding the developer will use this mind map to test his code and depending on risk and sadly often time, the tester will also do some testing using the mind map.

In my pair testing example, the developer had done some testing and so had I, noting down some questions before involving my buddy. I then walked him through what we had tested so far and how the application was working.

Step 2 – What happened

Just due to different experience and knowledge he asked some other valuable questions which aided my testing to go a bit deeper and got us thinking of other testing types such as performance and database behaviour.

For me this was an invaluable experience, as I learned to think about other testing types and techniques and scenarios and I think for my buddy it was also a great experience as he got to see bits of the company’s product catalogue he wouldn’t necessarily get to see on a day to day basis.

I want to try and make this a more regular thing, and also try it before I test something and let the other tester drive.

The other side of this is, that we have a weekly test team meeting and I will try to show features or functionality that the other members may not necessarily see but may have to pick up, when I go on holiday. During this session we can also ask valuable questions of the new feature or product. Which is easier than listening to a monologue when handing something over. I think!

As testers I feel we generally want to know about the company’s products and about all the things they can do for customers and ourselves, so that is also why I envision this knowledge share to be good.

Do you do regular pair testing sessions? How do you structure them? Do you do knowledge sharing sessions with other team members?

]]>https://punkmiktests.wordpress.com/2016/07/01/thoughts-pair-testing-sort-of/feed/6punkmiktestsThoughts: Encouraging change when you are the only testerhttps://punkmiktests.wordpress.com/2016/05/15/thoughts-encouraging-change-when-you-are-the-only-tester/
https://punkmiktests.wordpress.com/2016/05/15/thoughts-encouraging-change-when-you-are-the-only-tester/#commentsSun, 15 May 2016 17:17:25 +0000http://punkmiktests.wordpress.com/?p=579Continue reading Thoughts: Encouraging change when you are the only tester]]>Sometimes things come from small conversation snippets.

Some of you may know that I did a testinginthepub episode not too long ago. In there I talk a lot about what is awesome in my job now, like being valued as a team member, being invited to kick off meetings (these help us talk about what we are building and why) teams ask me for mind mapping the testing areas.

However this was not always the case. It is important to remember that anyone can encourage change. I was not here before the changes so I will base my advice on what I did in my previous role as the first and only tester.

I did a talk on this last year at Tiny Testbash as well. The recording is available through the dojo subscription.

Encouraging change when you are the only tester.

In my previous job, I was introduced into a company which had a successful product that was starting to make them money but they had no testing department. When I questioned how they test their product I got the following answers:

“We don’t have any testers. Our product owners and stakeholders do the manual testing and we have a vast suite of front end automation tests.”

Nevertheless they decided to hire me, and subsequently a team of tester. How this came about and some learning along the way is what I would like to share below.

The problem:

So I mentioned that the company had a successful product, they had people testing it and a vast suite of automation tests. So what was the problem? The company was 6 years old at this point, had moved to their version of agile software development and the need for a fast feedback loop from the product owners and stakeholders was becoming apparent.

However these individuals generally already had a full time job and could not attend stand-ups, reviews, planning meetings, let alone test the product. More often than not the stakeholders were shown a feature at the review, and then they would find out that it may not have been what they asked for.

So the problems they were having were:

Slow or no feedback from stakeholders

No dedicated feature testing of new or existing features

Front end automation tests that back to back would take over 60 hours, and run in parallel would run for 4 hours. (these were also fragile)

No trust in the selenium tests – the tests are being fixed rather than the code.

No unit tests

Some business logic tests but they relied on experts being available to check them

No stakeholder involvement in meetings

No-one is thinking like the user

How did I approach this list?

Slow or no feedback from stakeholders:

Well this wasn’t so easy, but I tried to do a couple of things.

First of all it became clear very quickly that the business side of the company and the development side of the company actually did not know what each other did. To be able to be a representative of the user I had to understand who our users are and what they do.

Engage with the whole company:

So my first point of call was to spend time with the business, but not the managers, the actual people who use the systems from an admin POV and understand the user pains.

This would help manifold. I could understand where their frustrations may come from, and in turn the users’ frustrations and also see how the system is actually being used. In some places it wasn’t being used like the development team thought but there were workarounds in place to go around bugs. Now we didn’t even know those bugs existed.

This in turn led me to propose we talk and communicate with each other more. We set up specific projects for the internal bugs to be raised and had a dedicated team working on those, improving and maintaining the current systems rather than purely focusing on getting new features out. Which had 2 spokespeople from the business who ran teams of account managers or accountants so both sides of the system were represented. These then owned a backlog and could priorities their bug fixes and discuss them as well as progress in weekly meetings.

The important thing here was to engage with everyone across the business. Try to find out what everyone’s job role is, what do they love about their job, what isn’t going too well and why.

I did get pushbacks though when I asked the teams to forward issues to their managers which would then be logged in the dedicated project. I heard things such as “it has always been like that. I tried to tell someone before.”

We as a development team even offered to automate some data inputs but people are always wary when it comes to change.

Changes:

Once we started with the engagement I tried to create regular sessions on what testing is, what development is etc.

So we learned from the business but now we needed to see if they are willing to understand what we do. We set up fun little coding dojos over lunchtimes, where we used a language called Processing and tried to illustrate how the numbers and letters create systems ( or code).

Furthermore we set up a brown bag lunch on agile testing. When I first joined I was asked if I would be writing the unit tests. This got me thinking and I tried to collaborate instead. I am no coder or automation tester but I can pair on writing those tests and give feedback.

This way I tried to illustrate what I do and I decided to make my commitments public to the team. This came about because I was constantly being asked if I would write the automation tests, such as unit and selenium tests for the devs, which wasn’t the case. I stumbled upon the Tester’s commitments from James Bach around that time and wrote my own version, covering how I provide a service, etc.

Alongside this I made suggestions what the business/stakeholders could focus on for their UAT, held a brown bag lunch about how a manual tester fits into an agile team working on bi-weekly sprints, and did some pairing with developers to understand how they work.

Consequences of change:

As much as this driving of change and engagement with the business had a positive effect – we were now on the road to better unit test coverage, understanding of testing, it also ended up backfiring a little bit, where I was starting to be seen as a quality gatekeeper, with there being a reliance on manual regression testing before a release, so testing became a bottleneck, especially as the team of developers grew and more streams of work were happening. More streams of work also meant context switching a lot from regression testing bug fixes, to new features, to new architecture.

Note to self: Do not let anyone call you QA, gatekeeper, etc when you first start somewhere and if that is not your role.

The effect of this was the thinking that we need a tester per product team to embed into each agile team, as well as dedicated product owners. A stakeholder or business person with a full time job was not going to cut it anymore if we wanted to get back up to speed and be focused.

So we wanted to work towards integrated a tester into each team, to be able to test small iterations of work frequently, and aim for full time product owners so we can reduce the feedback loop and having to spend time chasing stakeholders.

Hiring and building a team:

I was mainly involved with the hiring of the testers.

We have discussed the problem briefly and why hiring was a solution. We were trying to find tester who can integrate into the various teams and be the testing professional. As the product teams were quite different it was important to keep this in mind and not just hire 3 of the same type of tester.

For the hiring process I had a good idea of what I wanted, a good fit, an experienced self starter and not an automation tester but someone who would be a front end tester, with complimentary skills to myself. As I was keen for the devs to own the automation tests.

For the actual process we did phone interviews, and face to face interviews which included a live action testing problem. Just to see how someone would test and tackle a tasks and if they ask questions or not. How proactive are they? There are some very succinct and good resources on the ins and outs of hiring testers, I am mainly thinking of the ones by Rob Lambert if you want to have a further read and get some more ideas.

Once we had a team (I counted 2 testers as a team, but we grew to 4 in total within my first year), I wanted the team to be engaged and constantly learning about testing.

Time boxed Sprints give you the great advantage to try new techniques and experiment with testing techniques and I didn’t want anyone to feel boxed in, while having some consistency. Also each tester was working on a different product which would need different testing activities and tools anyway based on their context.

This meant we had bi-weekly knowledge sharing sessions, new features, testing techniques you name it.

I also set up monthly one to ones and tried to share a blog a week or whenever I saw a good one with the team. Furthermore we added testing related books to the library which had the nice side effect that developers would see the titles of the books and have a chat with you, so you could sell them more on the subject.

There was an especially a good session with jerry weinberg’s Perfect software- where a dev walked past and challenged me that perfect software doesn’t exist. Of course the full title is “perfect software and other illusions about software testing”.

Also being an organiser of the brighton tester meet up, I encouraged the team to attend events or even speak at them. One thing I learned from this was that not everyone wants to engage as much as I maybe do. At least not on the surface. And this is OK. Just keep doing your thing and don’t get downhearted. It can seem frustrating, like you are not getting through but I would just persevere.

We did manage to have developers attend the tester meet up and even speak about testing as well.

So what does my story tell you?

The main thing I did was to communicate.

Find like minded people in your organisation and start sharing ideas, product knowledge, skills and experience and collaborate with them.

Start creating a library of resources and learning. This could be a physical library of books, or a wiki page with suggested reading/watching or regular events that you host inside and/or outside of the company.

Pair

Seek out people in different roles within your organisation and learn about their work. Try to understand what works for them and what does not.

But don’t forget people in the same role as you. Start pairing with other people in the same role in an effort to learn more about what they do, but also to help to build relationships.

Start socialising your improvement ideas with anyone who will listen. In my experience, planting the seed of an idea can make discussions about change easier later down the line. Get feedback on the ideas. Talk to people about how the future could be different. Listen to others.

I was passionate about what I do and tried to be positive in the light of change and when driving it.

Start gathering interesting trends about the work you’re doing – and then socialise these with the rest of the business.

Here is my blog post about sharing at Songkick, I promised Helena I would post a month ago. Oops!

First a bit of a back story.

I joined Songkick over 6 months ago now! This seems crazy! Where does the time go?!

Time has flown by. I also cannot believe that it has been a month since Testbash Brighton. If you missed out the videos are online now here.

Anyways back to the back story:

If I think back to 6 or 7 months ago and how little I knew and how much I know now (and how much I know I don’t know) about the company and the tech, the domain, the people, job roles and responsibilities, that is an incredible amount of information to have to learn in a short time.

Luckily Songkick does a couple of awesome things that really helped with this. Here are a few ways in no particular order:

On-boarding:

This is new and still being trailed, so it is important to give feedback but the idea and general execution was good.

So what is on-boarding at Songkick? Regardless of the job role you joined as, during the first few weeks you will be invited to presentations (mostly remote ones for me), from different people of the business. These cover many different topics, some are about the domain, certain departments or processes.

This may feel like information overload, but the most important thing to remember from on-boarding sessions, I think, is the topic and who to associate with it, so you can ask more detailed questions later and know who has the information.

These sessions were quite intense, but for me they became handy very quickly, as I knew who to contact to help me figure out who uses a certain system and who we would need to help test a scenario, or even find out what a scenario may be.

Understanding how your users (internally and externally) use the systems your team builds is such valuable information for testers.

Testing specific meetings:

Being the first, second tester in the company for a long time, this was unstructured, which has its benefits and downfalls.

Luckily the approach has been taken that if you have been asked to explain something, you write it up. So there was lots of relevant documentation on how to test certain things. These were super useful, as I did not have to rely on someone to be around, but could figure things out.

We also did mind maps of areas to have in depth sessions on, so I could learn about the other details of the system that may not be obvious. I found it interesting to make a learning plan using mind maps. It has been a nice experience though and I like the informal format of those sessions.

What was important too, was to learn about the history of certain features, to be able to look for backwards compatibility if needed.

As a downfall for an unstructured approach, you could say that, we may have missed stuff in my on-boarding process initially, but then I am not worried to ask if I come across something to be given the information instead. Sometimes that is a more rewarding experience, and also the information is more likely to stick if you had to seek it out yourself.

Dev Talk:

Every Wednesday lunchtime there is a slot reserved for the technology team to do a talk. This is accessible remotely, so anyone interested can dial in.

The topics for this can be anything, new tools, discoveries, experiments, oddities of screen sizes in Android, key takeaways from conferences, etc. Our next one is actually a Docker workshop!

These are relatively informal and more often than not inspire a nice discussion. I like these because they are generally technical and it is a good intro for me to learn some terms and then research them further.

Outcomes of experiments are always fun as well, because they are generally trying to solve a deeper tech problem which is outlined first and then a possible solution is presented. This always gets me thinking about testing the new solution and also if we are missing anything in the current one.

Show and Tell:

Show and Tell is a special thing. This for us in the UK happens on a Friday afternoon, involves the whole company, and generally some alcoholic drink. I don’t drink so I don’t care about the alcohol but it seems to be a nice tradition.

Show and Tell is open to anyone in the business but whatever you show cannot exceed 5 minutes. The format is very informal and usually is more of a demo than a presentation. The sort of stuff we see are:

Developers showing improvements to a tool, process, feature.

Business development may show some interesting campaign they won or lost.

Support may show case a nice, angry or funny support case.

Any internal tools that improved productivity.

UI and UX guys may show a new concept or something they learned from research.

What I love about this, is that someone is always showing something. And you get to see what people are passionate about and that they care about their job. It also gives you an insight into problems teams have with tools or products and may give ideas on how to solve them. The other things that is great is that this is that the whole company gets involved to show something.

Breakfast Code Club:

I have not been able to go to many of these yet but they are quite fun. The idea is that something to do with code can be shown off. This does not have to be work related. It can be a side project.

For example:

A game

Trying to solve poker algorithm

A pun generator (my fave!)

Solving ciphers.

Sometimes the stuff showcased is work related and this time can be used for a code review as well.

The other selling point is that it is a nice way to mingle with colleagues you may not naturally work with and also there are pastries!

P.S:

The film Breakfast Club was released 31 years ago … yep we are getting old!