Apply the same rigor to your mental and physical health that you do to your professional life.
There are so many career paths you can take. Don’t listen to people who say you have to code or coach, or anything else
Listen actively to others and yourself
Don’t beat yourself up too much, no one’s perfect
Use your words, but think before you speak
Be a continuous learner.
There are lots of meetups, events, blogs, forums (The Club
!), videos (The Dojo / YouTube) for us to keep learning and also giving back to help build the awesome testing community.
This is a collaboration between myself and @gemma.hill1987 on Twitter!
Keep learning skills you’re interested in and not what people tell you is important - but do it sustainably. Listen to yourself. Quite often it’s more valuable to have nights relaxing rather than continually pushing yourself to learn new skills.
Look for how to bring the best out of those you are working with, rather than focusing on whatever you don’t like. Help those around you to discover what they can contribute.
That’s why I recommend my team do sessions of 1 and a half hours. Try not to allow yourself to be distracted in that time, then, when the session is up, have a coffee or something, catch up on emails and slack etc.
Quick Cynefin tip:
Your go-to response might not be the most appropriate for the situation. What does the information tell you?
A)
We know this situation. We know how to handle it
Sense -> Categorise -> Respond
B)
We can ask someone who knows about this (or we can do some analysis and find out)
Sense -> Analyse -> Respond
C)
We’re in unfamiliar territory. There’s no way to know until we’ve tried some stuff.
Probe -> Sense -> Respond
D)
Stuff is on fire and we have to put it out
Act -> Sense -> Respond
-
Try to enjoy what you do. I love what I do and therefore never think its work, but I am a wee bit weird…lol
-
Sometimes there can be some pressure (not intentional) to do a lot of extra curricular activities but please Remember it’s OK if the best source of medicine is to stay at home and re-charge.

-
Take every “mistake” that happens as a good opportunity to learn. We arent machines, mistakes will happen, Lord knows I have made a good few, but as long as there is some good learning from it, what does it matter?!

- Think about your (learning) goals
- Why do you like to achieve this
- What do you need to achieve this goal
- Who can help you and how?
- Find someone to help you reflect on your goals and achievements
- Failing is totally ok - just reflect and try again
Testing is one of the most unbounded roles in Tech. You can explore in any direction that appeals to you and is useful in your role and your skills will be relevant. For me over the last 13 years its included:
Product Knowledge
Domain Knowledge
Data Setup
Environment Management
Test Techniques
Testing Types
Testing Levels
Test Strategy
Build Management
Version Control
E2E System Knowledge
Development Methodologies
Analysis
Estimation
Coaching
Mentoring
Training
Collaboration
Tools
Programming Languages
Automation
Devops
Metrics
Release Management
People Management
Troubleshooting
And so many more that will be specific to your role. Dive into the areas you enjoy.
And two lessons I have learned the hard way.
- Find the answers to the questions you have that have remained unanswered.
- Beware of overfamiliarity in your testing and knowledge it can lead to discounting genuine issues.
Recognise that Testing is so much more than just executing test scripts and finding defects. Learn that Testing starts at day 0 of a project. The whole purpose is for you learn the system which will enable you to then improve the testing and the feedback on the system
Pair/mob with developers whenever you have the opportunity.
Facilitation skills - for example, being able to bring the team together to brainstorm testing ideas.
Test automation is a software development project in and of itself. It takes a considerable amount of time and skill to do it successfully. If you treat it as a side task that people only contribute to whenever they have time, IT WILL FAIL!
So many good folks have already hit so many of the things I’d use as my one point!
So I’ll fall back to something I don’t think we testers do well: Learn the business.
What’s you organization’s mission? How does the organization contribute value? How does it earn revenue, and how does it keep customers happy? It doesn’t matter if your org writes apps, behind the scenes biz-to-biz, or creates security frameworks. Understand what the mission is and how your software delivery team impacts that.
Talk to your customer support team! They’ll be intimately aware of the mission critical areas of the application from your customers’ perspective and can help define your testing priorities in areas you’re unfamiliar with.
My 2 cents:
- understand what your application is doing, and why it is doing it - use (or create!) process flow diagrams, user flow diagrams, architecture diagrams etc to really master your domain
- test in the middle! The APIs between the frontend and backend are doing a LOT of stuff, often surfaced by the UI but not always. Learn about and use the APIs, and test them of course! But really using them will find issues, too
- everything everyone’s already said about relationships with other folks on the team - devs, BAs, PMs, support, DevOps, etc. You can learn so much from all of these other roles, and do your job better too!
- dig in to those commits/PRs, static code analysis info, logs, support tickets. Shadow your users if you can
- attend conferences and meetups. Even when you’re socially anxious (like me) it’s invaluable to your career to network! A great way to attend for free is to speak! Another amazing boost to your career
If you need help with that, join Speak Easy! - connect with the testing community! Here, on Twitter, Slack, etc. This is an amazing group of people that you can learn from, and help, too!
- don’t get overwhelmed! Don’t be afraid to specialize in a particular area. There are SO MANY facets to testing, that it can feel terrifying sometimes with so many things to learn. Focus on one area. Bored of that area? Look for something else! There’s way too much variety to be a bored tester!
- share your knowledge with others - it’s great to absorb all of this information, and you may feel like you don’t have anything to contribute since there are so many people already contributing. That’s not true! Everyone’s experiences are unique and we all have stuff to learn. Even after 11 years in testing, I learn something new from newer folks every day!
Gain an understanding of accessibility as it relates to testing. More countries are bringing in stronger laws to ensure websites are accessible and most refer to the Web Content Accessibility Guidelines WCAG 2.1 (Europe) or Section 508 of the Rehabilitation Act (US) in terms of compliance.
But there’s more to accessibility than just compliance. I believe the four pillars of accessibility are Compliance, Readability, Inclusive Language and Usability. Your sight is not accessible to everyone if it discriminates or excludes someone because of their gender, ethnicity or sexuality. If it is difficult to understand the content or use it also restricts people. Lets not just think about the perfect made up user who has the latest phone, a high IQ, is totally familiar with everything we do and binary. Lets think of everyone.
Below is my attempt at a simple way of showing those categories.
Be open to change. We learn and improve by constantly inspecting and adapting.
-
Be your authentic self
-
Don’t let the naysayers dictate to you what your abilities are
-
Never let anyone say ‘You don’t need to know’ or ‘It’s too technical for you’
-
Let your curiosity drive you to learn everything
-
But most importantly be generous and kind - two qualities that will take you further than learning any technical tool or language
Refactor something, on code and on people:
- Use some static analysis tool or your bug history to find areas of the product that can be improved - ask people what is the root of the problem and create task forces to tackle the issue;
- Discuss practices that are bottlenecks and create experimentS (plural!) to find out how to mitigate the problem - make people go out of their comfort zone with the clear goal of improving, in a safe manner, due the fact experiment are meant to fail more that succeed.
