This topic could touch on many areas. I rate myself as an excellent tester, but I’m no expert in the field (I’m not “book smart”). I used to have great domain knowledge, but lately I’ve struggled after moving project and finding myself not understanding a word of what people are talking about (not fun when people look to you for answers).
This post is on security testing. I am not an expert.
I recently attended a work cyber security conference. There we had people who have years, even decades, of experience in various aspects of security. They live and breathe it. Pen testers are doing incredibly clever and technical things to get into systems that I just wouldn’t have a clue on. I am years away from their level and even with the best will in the world, I may never reach that.
But that is fine. I don’t have to be an expert.
What I have wanted to stress to people through my posts, activities and talks is that even if we’re not experts, we can find security issues. Whether this is through threat modelling, asking the right questions in planning or adding some injection test data into our usual set of inputs, if we can find these problems earlier, we can fix them earlier and ultimately build better and more secure software.
The other side of me wanting to reject the expert label is that it makes it seem like the level I’ve reached is somehow further to achieve for the average tester. That isn’t the case. I’ve just been fortunate enough to get a small amount of training, maybe a few hours a month, for a couple of years (and much of that wasn’t relevant to testing).
So I want to end by saying, please don’t view me as an expert. I’ve just dabbled a little more than most folk. Join me on this journey into becoming security newbie – it is great fun!
I’ve been working on my TestBash UK 2023 talk and one of the slides touches upon how I identify as a tester and the tag line on this site.
I find bugs.
This may be an interesting topic to explore because not only have I barely entered any bugs so far this year (largely because I’ve barely done any actual testing) but also I’ve seen a number of people trying to talk around how testing is more than finding bugs.
And it is.
In the previous few years I’ve been entering plenty bugs but also helping prevent many more by contributing to planning and refinement. As part of shift left we are helping to identify and resolve bugs before a line of code is written. Sure, there may be no stats or metrics for this but the work is important and I’m proud of my efforts there. Nowadays I focus the majority of my time here.
However we still need to test an implemented user story or feature. Exploratory testing and alike helps us identify the issues that we didn’t, or couldn’t, think of during planning. Those unknown unknowns. We also need to account for the minor niggles, extreme edge cases and also just good old fashioned mistakes.
I still love the puzzle solving and challenge of trying to find a bug or getting reproduction. That hunger for finding bugs is still strong within me and I’m simply spreading my net. I’m learning how to catch new types of bugs through my security testing and by asking questions & challenging requirements.
Finding bugs is part of who I am. Its in my soul and now it is in my skin!
For the past couple of months I’ve spent half my time, which is in itself reduced following complications, as a “QA Champion”. A title I dislike. In particular I dislike how QA tends to be associated with the testing best described as “checking” and “QA monkeys” running “test scripts”.
The organisation that I joined as “QA Champion” (I’ve died a little more inside when writing that) has had quality issues, especially since a re-org tried to move us into a LeSS structure with dev teams taking on quality and testing. This was first done by getting rid of testers (well not quite) and trying to shift the QA left to do QA earlier. Everyone needs to be doing some QA, not just the QA teams that still sort of exist. We plan to solve this by automating all the QA.
Ignoring the “automation solves everything” part and the fact that we are working on an old tech stack that lacks testability, I have real issues with our approach.
Let’s have a quick prequel first.
My understanding is that our old methods were that testing was thrown over the fence to teams who ran lots and lots of test cases then produced reports and would be the authority on whether we can release. In other words QA as the gatekeepers of quality. To me this is the dark side and rightfully needs defeating.
So why the ranting, rambling blog post? Surely I should be happy that we’re abandoning this? Well no. I’ve found that the QA Champion is sod all to do with championing quality and we’re the new gatekeepers of quality.
What have I become?
A New Hope
As bleak as it may seem, a shift in the balance may be happening. I’m hoping that I’ve awakened something within the QA Champion group so that we can become a force for good.
I’ve started something of a rebellion. Through a tech talk I shared what I think continuous testing, shift left and quality engineering, all that goodness, could look like for us. With passionate discussion (or constant whining), I’ve got discussions going where I think that there is a strong alliance to bring around change.
My goal is built on two pillars right now.
First is with the teams that I immediately work with, we are looking to use practices to help us test continuously and build quality into our day-to-day. This hasn’t been a hard sell because:
There’s a strong desire to improve quality where possible.
I’ve said that I’ll have their backs in rejecting the initiatives coming from above (i.e. the ways of the dark side).
Many of us have worked together. Some of them taught me what I’m now passing back.
Secondly I am continuing to raise the discussion on what I believe to be the right practice and challenging things like “let’s get teams producing reports detailing all their testing for an epic”. I hope to change the language and expectations from management so that they aren’t looking for the same sort of gatekeeping as before. If they want us to be potentially shippable, instead of going through the arduous and prolonged hardening and release processes seemingly non-stop, lets focus our energies on employing quality engineering.
A Force Awakened
So far I’ve had mixed feelings about my progress. There are moments of hope and feeling like there’s positivity and receptiveness to this, followed by a request for dev teams to run hundreds of manual test cases each in a hardening phase for an internal release.
However I’ve now shared our new approach in the latest sprint review. We’ve had lively and positive discussions about how we can actually get to this stage. Things may actually start coming together.
I will wrap up this post by saying that if the next month or so goes well, I hope to get my job title changed from Senior Test Engineer and get the QA Champion program re-branded.
Hopefully this tale will end with the rise of the Senior Quality Engineer.
During my time as a developer I generally produced a good quality of work. My knowledge of design patterns may not have been very good but I tested my stuff to ensure that it did what I expected it to and that is why there was generally a low bug count for my work… But there was a bug count.
Given that I am very confident in my testing skills (more than my dev skills!), how was it that I missed things in my dev testing? In this blog post I hope to explore that topic.
I believe there are four reasons why we may miss things in our dev testing and push code changes with bugs:
Blind Spots: Being human we will have cognitive biases or a tendency to miss certain edge cases. There are things that at first I would miss frequently and therefore got more attention in time. Mine was writing incomplete log messages where.
Laziness: Most developers want to be writing code so we can be tempted to get our code pushed as quickly as possible in order to move on to the next thing. Certain aspects of testing may be areas where we get slack or cut corners. I mostly got slack around install/upgrade. Yawn. (See also I get bored)
Iterative: My approach to development is very iterative. Sometimes I’ll use TDD and sometimes unit tests come a little later but I’ll always manually test my code as I’m working on it. In theory this is great but I’m not going to re-test everything on each iteration. Occasionally this meant that I missed finding out that I broke something.
Scope: I don’t believe dev testing should include things like system, load, soak or other more involving tests. If there’s a high time investment to test various scenarios, rather than having two people repeat the same testing, we will often cover the highest risk tests in dev testing and leave the rest for the test phase. There is some testing that is best done by the person testing a completed user story / feature. Consequently it is quite reasonable that developers can exclude certain testing from their dev testing.
(oh hey, BsLIS, or BLISS – lets say I meant that)
So there are some understandable reasons for us to end up blissfully pushing bugs. How do we solve it?
To some extent, I don’t think we need to do anything special.
This is the reason why we (should) have dedicated test phases of a user story’s life. Ideally by working within teams where testing is completed by the development team (possibly by a dedicated tester) then you can build up the relationships, understand each other and catch these things immediately.
As a tester I like to try and get to know my colleagues and how they work. I like to understand what mistakes they may make, as well as thinking about what mistakes I may make. If we can understand and appreciate how these bugs can slip through dev testing, we can catch them easier.
Obviously if you know your flaws then it is good to work on them. If testing exposes your blind spots, try to force yourself to be more aware of them. Using techniques like TDD allows us to ensure, at least at a unit test level, that our iterative changes aren’t breaking our previous work. Also lean on your colleagues and your testers. If bugs are raised against your software, ask yourself why you missed it. Mistakes happen. It’s fine – especially if we’ve caught it before shipping.
My one final note is that it is OK to knowingly not manually dev test an area of code, so long as we clearly communicate not only what we’ve tested and but also what we’ve knowingly not tested. Writing automated tests also lets you flex your scope on manual dev testing.
Dev testing doesn’t need to be perfect. Instead communicate, be clear and work together. The team can be way more than the sum of its parts.
The importance of developing secure software is (hopefully) understood but what about our working practices?
Many, if not most of us will be familiar with navigating IT restrictions. Firewalls, limits on what you can install or automatically deleting anything that isn’t digitally signed from an approved source. All these impediments to us working.
Perhaps, like myself, you’ve disabled some security measures in the past as a quick measure to get a short test running. Or you run things as admin rather than setting up nuances permissions. Perhaps you’ve used your personal device to read a file.
Let me introduce CD Projekt Red. On the back of a rather stormy launch to Cyberpunk 2077 they were hacked. From what I gather, all their source code was stolen, personal employee data stolen and machines were encrypted with ransomware.
But this can’t happen to you right? Well maybe it could.
A couple of years ago I was working from home using a mixture of my own computers and CCTV cameras and also work kit on loan. One of my personal devices was compromised and at the time I panicked a little, re-imaged it and moved on… until I realised that the shared drives had been encrypted as well. By being slack on securing my personal devices, I’d potentially exposed a work machine (thankfully the shared files were installers for stuff like Wireshark). Potentially a more motivated attacker could have jumped machines, leveraged my VPN and got into my work network. In other words it could have been much worse.
One of the popular terms that I’ve learnt since becoming a Cyber Champion is “Zero Trust” and building a “Zero Trust Architecture”. This is about building solutions on the assumption that your outer layers of security should be compromised so you should secure all communications within your system. I could ramble on more about this but I want to stress that this applies not just to what we build, but to how we work.
If an attacker managed to get into one of my work machines they could steal our source code. This would have IP impacts but also would allow an attacker to understand our solutions and find any vulnerabilities. Simply encrypting all of our machines to stop them from working could be huge. Imagine if you have all engineers locked from doing work, or pushing changes to the repo. How much money does it cost to have developers sit in the kitchen having a coffee for a week whilst you try and restore things?
These types of attacks are very common in some sectors such as Government organisations, from “city hall” to police to health, but as software developers we’re viable targets as well.
So hopefully I’ve scared you a little. It is quite possible that you could expose your company and cause them massive damage.
However there are good things that we can be doing to protect ourselves.
My work uses security solutions that, as engineers, we usually deride for blocking us from working and sometimes look to work around. But they are important. If you can understand why they are there (see above), it is important to find how you can work alongside them, as opposed to against them.
Firewalls are an important start. All too often when we’re having communication issues with devices or services on our VMs we’ll ask “have you tried turning the firewall off?”. If you do this, only do it for a minute to prove whether firewall rules are an issue or not, then enable it again. It is important that machines on your network are only able to use the protocols and ports that you need them to use.
As tempting as it can be to download a tool to help with a job, for example I downloaded a tool to help me access the memory of an application to help with work, we need to consider the security implications. Could it be doing something malicious? Could an attacker use it to perform a malicious act? This could be a vulnerability in the application, or simply it would be a wonderful little tool for an attacker to use. Look at using software that has been approved by your organisation and uninstalling anything non-essential once it has served its purpose.
The other big area that so many of us fall down is on passwords. It is well known that a lot of people use things like Admin/Admin1234 or TestUser/Test1234 for their passwords in test environments. Similarly when there is a default login like admin/password, many people out there don’t change them.
I still remember being on a remote support session and without thinking I just entered the default credentials for an application and successfully logged in. Afterwards I was politely informed to always ask the customer to enter the credentials and it was also fed back to the customer to change their password.
p.s. don’t have default credentials in your application or at least force them to be changed after the first login.
It is important that we make sure that every account we create, especially admins, have a good & strong password that is unique. Don’t go replacing Admin1234 with My!W0rkN@m3 for everything on the network. Yes it is more secure but if someone got/guessed that password, they may have untold access to your work’s network.
So how do I remember them all? I do use wikis for some shared resources but it is better when we use a shared password manager that in itself has access permissions. I also have my own system for creating passwords, which for obvious reasons I won’t share, but that means I don’t need to remember what my passwords are, only what logic I used to come up with it.
The best solution however is to use domain accounts. This allows us to restrict access to machines and also use good, secure passwords. Obviously being part of a big corporation we don’t have permission to be adding short lived VMs to the company domain and making ourselves admins when we want, so what we’ve done is set up our own domain server that has no trust relationship with the main network.
There is another thing that we need to consider and that is access permissions. I doubt I’m alone in running most of my services as the Local Service admin account, using “Run as Administrator” or “sudo” commands when I want stuff to be working. A common example is when your service needs to write to Program Files. As a standard user it will fail but run as admin and it will work, right? This can be dangerous as there’s things like “Remote OS Command Injection” where an attacker could leverage a vulnerability to execute a command as an admin such as formatting a disk, or disabling security.
To prevent this it is best to have dedicated accounts for things that need to run with elevated privileges. For example, let’s say that you’ve downloaded a NTP service to keep your machines in sync. Rather than running as admin, the installer may help set up an account that is dedicated just to just what it needs to manage NTP – or you could set up your own account with a bit of Googling.
This is an area where mobile does seem better than desktops. For example if I downloaded an app that wanted to access my calls, I get a specific prompt asking for this permission. On Windows or Linux I’ll probably get an error when it tries and fails. After re-running as admin, it now works and exposes the application to way more than calls.
And finally – if any of this seems like too much effort to maintain then there is an alternate approach (depending on your setup). Create an isolated network for your testing where there’s no internet access and you need to physically connect to it.
It may seem like a pain but honestly, it is important that we consider the security implications of how we work just as much as the security of our products. After all, you don’t want to be the one that brings your company to a grinding halt.
Disclaimer: I have no idea on what caused the CD Projekt Red hack. It may have been something that I’ve discussed, it may not. I did not intend to speculate or criticise. I picked them as the example because I loved Cyberpunk 2077 (completed it 6 or 7 times). Please don’t sue me guys!
I am writing this from a dark place. That isn’t my solution to rising energy prices, but instead from the loss of my wife. I mention this as I think it is relevant to the changes that my career has taken and what I want to talk about today.
Change can be hard. It is even harder when it isn’t something that you’d planned for or really wanted.
The first company that I joined was using practices most accurately described as waterfall. After many years of development hell, the product was finally released and a shift to more agile working was on the cards, but it was too late and we went bust. It was interesting seeing the impact of how we worked and the challenges in the introduction of “agile” within our teams.
When I started at this company I was fresh out of Uni and whilst a shy, timid, geek, I did live rather carefree and lacked purpose beyond my work. My days would involve working, watching trash TV and playing games or going out drinking and this was the case until right at the end when I met a wonderful person, Hannah.
After this I started a new role in a new sector, testing surveillance systems. The company had been stuck in a bit of development hell but were finally nearing release. As that completed, the company moved to use (some form of) agile working. I think lean, or scrum of scrums (I get confused over terms at times). This was an interesting period and people responded well. Over the next year or two the company really seemed to improve its ways of working. I was seeing some of the advantages of agile working and whilst I was still technically in a separate test team, I got to work closely with the developers and really liked that.
That said, I wasn’t enjoying work. Testing practices were far too dependant on writing lots of documents, executing what is written in the documents then writing more documents on what was done. My frustrating for this and over time my interest in C# (from hobby game dev) led to me moving to development.
During this period of my life I found that it seemed to all come together. I was happy with my partner, evolving into a better person, enjoying my hobby game dev and happy at work. Whilst there were ups and downs, it always felt like I was moving forward in life. I ended up getting married and life was pretty darn good. During this time my work had also evolved with using a Kanban workflow and teams with embedded testers. That worked really well and I did really life being in the team, even on those days when the project sucked.
Strangely I started feeling down. Missing a “purpose”. I’d been encouraged to push more to learn and develop my skills as a software dev, but I didn’t care about it. At retrospectives I cared more about testing practices. In fact half the time it was testing that was the better part of my job, as opposed to code reviews or writing documentation.
I made some bold decisions by moving back to test and also sought mental health support. 2019 was the year when I took control. This was followed by the year of chaos with the pandemic, a takeover at work, change of teams and with that a move to scrum (with myself taking on the scrum master role as well as QA). It was hard and whilst I hated how changes just happened with no clear plan, once I managed to adapt it was a great time. I began to feel more at home with my teams, my wife and also my career. The Ministry of Testing became a big part of my life over the next few years – in particular the fact that I could downloads LOADS of great talks and watch them whenever. It felt like everything was closer, together and much better… even when the world had us all apart. Life was at its best.
Then the past 3 months happened. Hannah died during the xmas period. We don’t know why. My life was turned upside down and on top of that this month I’ve moved to a new (to me) project in a sort of different organisation. The project that I’m joining has been in development hell for years. There’s major issues (in my view) with the testing practices. I now find myself sitting at home, by myself, watching trash TV and playing games knowing that the next day I’m working in a scenario that I thought I’d avoided twice already.
Change is hard and it can be daunting. However, like it or not, we must go on. (I think)
Whilst I can never fix the loss of Hannah, I’m trying to refocus on my work and testing. I am looking to use whatever little energy I have to try and guide this new organisation. Rather than trying to adapt to the changes, can I make a difference and be a positive force for change?
Providing I don’t get myself in trouble for writing about this, over the next year I hope to share how this goes. If I am able to say that I’ve managed to make something of the changes going on, well that’s something.
P.s. apologies if this is a bit too Dear Diary. It is good to say these things.
When I first started testing within the games industry we would perform general “destructive testing”. This basically meant there was no specific work so we went off to find bugs (or slack off). I liked to pick on a particular area and would explore that and the behaviours, looking for any little nuances.
Over the years I’ve tried using this destructive testing within my day-to-day testing of user stories, going beyond the remit of what my assigned test cases would say and trying to break the feature. I especially liked doing this when I was picking up something new or unfamiliar – my time to shine – and also to my shame, in a bit of a grumpy mood. The buzz of finding a bug, something that has previously slipped through the net, always cheered me up. Even if I didn’t find a bug, it was often enjoyable and could also be informative.
The one downside of saying that you will do this is that it has a very negative name. I am going to break all of your toys. I didn’t like using ad hoc though. That felt like telling my team “I’m going to go do stuff”.
In more recent times as I’ve learnt more about testing, and perhaps matured (that is debatable), I’ve started using the term “exploratory testing” instead. However I am aware that I’m not really doing it correctly as I was never writing charters, just bulleted lists as a reminder of areas to cover.
I still struggle with them a little. Part of my problem is that I often have an idea of the sort of thing I’m looking for but I often feel like I’m shoehorning thato into the Explore … With … To Discover … format and can end up being “Explore feature with what I always use to discover any regressions”. Very meaningless.
Explore changing AD config with existing <redacted> users to discover if they have a seamless experience.
Explore alarm ownership combined with features like protection, procedure and escalation to discover if <redacted> users are handled the same as <redacted> users. [~90mins]
Explore video lockout with <redacted> to discover if it now works.
These are some of my charters for a large user story. Terms internal to the team have been redacted.
Interestingly when having a read of the Exploratory testing APIs section of Mark Winteringham’s “Testing Web APIs” book I learnt about an alternative template that might suit me better. Going forwards I am going to try writing my charters using “Look at … To test for …”.
The definite positive that I’ve found from my time using more structured/formal exploratory testing is when I’ve had a report to produce. Whilst I usually just have a rolling comment in a test task on Jira (or whatever tool I’m using) to keep my notes, occasionally using Google Docs/Sheets, for some larger testing I used a tool that I had built myself. Whilst obviously I can’t share the reports publicly, my team responded very positively to them. Typically I’d only expect people to look at my final comment on the story. To my surprise after attaching my first exploratory report as a PDF, we were reading them as a team and chatting about some of the findings. No doubt having pictures helped, as opposed to a wall of test that might have seen been in my “test task rolling comment” approach.
Here’s an example report that my tool can create, based on my tool:
I have just started using Xray Exploratory App and it seems pretty promising. I haven’t used it for any functional testing but when I took part in a Capture the Flag style tournament, it was a great way to keep notes on things I learnt about the system and commands that works.
I am starting to feel like I can genuinely call myself an exploratory tester.
In late September I attended my first in person testing conference, TestBash UK.
Early arrival at TestBash UK
I’ve previously been to online events, in person agile and development conferences and an alternative style event – TestBashX Edinburgh, but this was especially exciting.
I was attending as a speaker.
Life Goals
Now before I talk more on my actual experience as a speaker, I want to go back a few years. Throughout my life, my career decisions have been to put myself in a position where I can make a difference beyond the team. To do something people may care about. Whether it was the industry when working in games, becoming an “expert” in the growing ONVIF field or my ideas around “Behaviour-driven Lean Testing”, it all boiled down to one thing.
I wanted to do *something*. To be *someone*. The idea that I could meet a stranger and for them to know of my work was a big dream.
(I know, groan)
When I created my Threat Agents game I wasn’t sure of its value initially but people were very excited by it. Jump forwards less than a year and I am attending TestBash UK as a speaker.
Anxiety
As the event drew closer, I started getting nervous. I didn’t know anyone there. I have social anxiety and whilst speaking didn’t scare me (too much), turning up at a conference did. That first moment of walking up to the bar to have a drink with people, I was trembling.
However what struck me and made it such a wonderful event was how welcoming and friendly everyone was. If I spent longer than 2 minutes looking like a deer in headlights, someone would come over and introduce themselves. When looking for a seat, I’d be invited over.
I got to meet so many lovely people. There were folk from throughout the UK and beyond, each with different levels of experience, from someone new to testing to a veteran over decades. I spoke to many people with a mix of skill sets and different passions within testing.
Pride
My talk was (not unsurprisingly) on threat modelling, in particular my journey getting into threat modelling and how I’ve brought it to my team.
I’d been practising it over and over, walking around my living room whilst speaking to an empty sofa. How would it feel doing this in front of people? Especially because I’m a very anxious, shy and nervous person (at first).
There was only way to go about it – go for it. Embrace it.
Belly’s gonna get ya! – Speaking at TestBash UK
After (hopefully no longer than) 30 minutes my talk was complete. The crowd had laughed at my jokes, applauded my video and gave a positive response. I was beaming afterwards! The following day I ran my workshop and people warmed to it really well. My favourite moment of the entire conference was just listening in on one of the groups and hearing a perfect example of a threat modelling discussion.
Threat modeling in action during the workshop
It was the proudest few days of my life, other than my wedding of course.
And the exciting part is that I’m not done there…
Takeaway Express
If anyone is reading this and hasn’t attended a conference before then I’d thoroughly recommend it. Not only do you get to attend great talks (and often also workshops etc) but networking is a huge part of what makes an event so great. I’d always thought that “networking” with people would be like my initial experience and impression of LinkedIn – trying to promote yourself on the jobs market – but it is so much more. It is a great mixture of socialising and learning with maybe a dash of schmoozing along the way.
And finally in other news
Just make sure you leave your weekend free afterwards because you might be pretty knackered! For example maybe not go to the zoo spread over a steep hill with your niece and nephew!
I started as a manual QA tester for a games company back in 2008 as part of a massive team, very disconnected from developers. Since then I’ve worked in smaller test teams, within feature teams (i.e. server software) and within a scrum team. This includes a chunk of time where I was the developer, with a tester in our small team.
This time next year I am expecting that my team will join a larger organisation within my company, where I would be the only dedicated tester within a scrum team. It does raise the question of what my role will be. Unsurprisingly this is often on my mind.
It also got me thinking more about what might be the future for someone who most enjoys manual exploratory testing. What roles might there be?
No doubt that for several years to come there will still be jobs out there for manual testers, either in dedicated teams or working more closely with the developers. I hope that we see more of the latter and fewer companies still having dedicated test teams. However it is clear that most people recruiting right now are most interested in automated testing. An idea that I am not fond of and have previously written about (twice in fact).
I recall listening to an AMA session where testing guru Alan Page suggests that developers will be responsible for writing automated tests, probably with the use of record and playback tooling. From my experience working as both a developer and test engineer, I definitely agree that having developers writing the automated tests is the way forward (although convincing some of my colleagues to use click and record seems ambitious).
Developers are obviously skilled in coding and as part of good engineering practice, should be thinking about edge cases and writing testing. It can help force them into thinking about writing code for testability as well. I’ve heard the argument that developers might miss edge cases that a tester writing automated tests would get, which I don’t buy. There may be developers who are more reluctant to be writing these tests or say they test, but I’m not accepting that. Not trusting your teams to do a good job isn’t a reason to hire automated test engineers. If you have a weakness, you need to develop it. Perhaps be coached somehow?
Over the past couple of years I’ve heard of more and more people who’ve become test specialists/coaches who work across multiple teams in a coaching capacity. This is intended to ensure that developers are capable of doing their own testing.
I do like this as a concept and can definitely see this being the way forward. I think it works well with methodologies like scrum and ensures that the whole team is responsible for quality.
Techniques like ATDD / BDD mean that those with a business viewpoint can get involved with testing and quality by defining the tests using gherkin. As tooling continues to improve here, it will get easier to collaborate to define behaviour and tests together. This sounds like a great time to get your test specialists involved and shifts that bug “know how” left.
This does however sound like it is suited for people who like changing company every year or two. That isn’t me. My other concern with this is that I really enjoy exploratory testing. It is why I switched back to test from dev. If I was to become a coach then would I be doing the job I love?
It possibly also leans into one weakness in having scrum teams being solely responsible for their own testing. Teams can easily wind up being in their own bubble, working on their features. Quite often what a tester brings is not just the “knack” of finding a bug but a wider product knowledge.
If I was able to pitch my perfect role, one that best leverages my skillset as a test engineer and brings most value to my company it would be to see test specialists that are more akin to POs/BAs/Scrum Masters in an organisation than someone who comes in to help teams solve their problems, then possibly move on.
Developers should write their own tests and functionally test what they are developing. However having a test/quality focused role that works with a handful of teams seems like a really intriguing prospect to me.
A typical work day could be joining a couple of stand ups then attending a refinement session, where I use knowledge of the products and knack for edge cases to help teams spot the gotchas early. I then might meet up to pair with a developer who is a bit unsure on how to test a complex problem or pick up testing of a story for a team who are short handed at the moment. I later have a look at a sprint review that I couldn’t make and see that a team have just got their feature across the line. I know its been a challenge for them so lets get the build installed and do some exploratory testing. Finally I might put together some training material on a new extension that I’ve found for our E2E automated testing framework.
This sounds awesome as a job to me. Being an almost free-spirit who helps the teams. Sadly it is most likely a fantasy although who knows? Perhaps there may be a role out there?
The future is rather uncertain and, if I’m being honest, a little unsettling. Will my role continue? Will I be able to find a new manual testing role should I want/need to? Will I be forced into automated testing, or (more preferably) a return to development? Will I move to coaching?
Curiously I am also thinking that with my interest and training in cyber security, I may end up being a pen tester. From my experience so far, this seems very much like classic testing – trying to find bugs in the system. To move forward in my career, will I find myself working in the same ways as all those years ago? …
As I reflect upon my career and what the future might hold, it made sense to consider my strengths but I realised that I should also think about my weaknesses.
In terms of hard skills, I know that the fact that the nature of the software that I’ve worked on means that I don’t have any skill or experience in tools like Cypress.io, Selenium and Postman (although I am learning Postman!). However I don’t believe that my lack of these sort of skills really matters. From my experience & training down the years, I have confidence that I *could* do them.
Soft skills are perhaps more interesting to explore. Common examples of good soft skills for testers are:
Inquisitive
Thorough / Attention to detail
Communication
Creative
Analytical / logical thinking
Eagerness to learn
Straight away I know my biggest weaknesses.
I can be sloppy
I am not always a great communicator, which I’ll pick up in a separate leadership post one day
Those who’ve worked with me may be surprised by the first one. My end of year reviews tend to be very positive about the quality of my work but I know in myself that I am definitely prone to errors.
For example when reading a story I often am guilty of not being thorough in reading it. Just as I would struggle with any wall of text. I lack the focus to read it thoroughly, find myself skipping words and misunderstanding the meaning of a sentence.
Similarly I know that when I am doing a lot of “checking” style testing, I am very prone to mistakes. I will see what I’m wanting to see and move on ASAP. This means that if there’s a glaring error on the page, I may be completely oblivious. This happened to us when a library uptick to address issues with combo boxes meant that a date control was no longer displayed. I went through all the screens and verified that the visual oddity couldn’t be seen.
When mistakes like this happens I know that my mind tends to be in a particular state. I’m bored.
Sometimes when tasked with boring work I will try and perform exploratory testing to see what bugs I can find. And I usually find something. However other days when I have a bunch of things to check, I won’t be in the mood to go off piste and bug hunt (or time doesn’t allow me to) and I trudge through the work and miss things.
I want to solve my boredom. I want to find ways to not only ensure my work is as higher standard as possible but also provide greater job satisfaction. In the event that someone is actually reading this, I’d be very open to ideas!
Do I try and gamify some of these tests somehow? Do I try a new technique to help spot bugs? Like try and blitz the story whilst recording it then watch it back with a more attentive eye.
Or do I simply commit to test the f**k out of these boring tasks? I do love my bug count after all…
