In automation, always look for the lowest possible level of checking.
“End-to-end to rule them all” strategy is doomed to create slow and difficult to maintain suites that don’t provide precise feedback.
5 Likes
Say yes - be willing to work on value-add tasks that weren’t on your job spec if you know they support the quality of the deliverables and there’s noone already in place to do them e.g. delivering training, conducting user research, knowledge transfer to new team members, getting requirements into TFS/Jira. This will help develop your quality mindset as well as cementing yourself into a team.
6 Likes
In order of importance:
- Champion the domain
- Master the testing framework(s)
- Work at best practices
- Continuously add more automated tests, refactor existing ones and improve on naming convention
- Practice and learn about your OOP, DB language, JS, HTML/ CSS everyday
1 Like
To remember our goal is to provide useful information about what we are exploring.
4 Likes
- Constantly learn by reading as much as you can
- Help others to improve their testing as you may learn something off them
- Learn to read code so you can understand things when you are sat with developers
- Build a strong relationship with the development team
- Don’t be afraid to speak up if you have to.
3 Likes
Here’s my checklist, in order:
- Be an awesome person to other people that you work with. Applicable testing is purely social. You will achieve nothing unless people listen to you and think that your ideas are credible. This is based mainly on your reputation, the language you use and how you conduct yourself. You need to understand the needs of others and how that affects how you’re going to be able to get your job done.
- Learn about, understand and know the nature of epistemology. Understand subjective reality and the many failures our heuristic brains create when making sense of a complex system with a brain designed to keep us alive in a jungle. From here you can learn how to learn facts despite our rudimentary primate brains - how we know anything to be true or false, despite ourselves (or “science”, as it’s known). This links into scientific thinking, the design of experiments, the role of falsificationism, critical thinking, tacit and explicit knowledge, mental modelling and much more. YOU NEED THIS TO HAVE THE SCIENTIFIC HUMILITY (and why you need that humility) TO DO GOOD TESTING.
- Understand that we form inferences based on our observations and that models sit between the two. You will know when to broaden or narrow your observations, how to branch and backtrack, when to simplify or complicate your tests, when to be exacting and when to be chaotic. This will form a solid basis of exploratory testing. Exploratory testing is the most basic building block of all testing, from where you can learn tools and “automation” and so on. YOU NEED THIS TO BE ABLE TO EXPLORE A PRODUCT EFFECTIVELY.
- Learn general systems thinking. Without this you will struggle to be able to model a system in various, useful ways, and your thinking will be stilted and overly “vertical”.
- Learn how to communicate effectively and safely. Do not over-promise anything, do not state things you do not know and be careful of how you speak. “It works” is possibly the most un-tester sentence in the known world. Be able to tell the “story” of testing (the state of the product in ways that are important in the right way to the right people, how we know the state of the product and how reliable that information is, what we don’t yet know but feel we should know because it’s important, what you need and want to help the testing be better and faster). You can have all the information in the world, but if nobody cares to listen and believe it then you are just Cassandra.
- Learn technology. If your product has an API then you should know about APIs. You should be able to see behind the UI and model the flow of a system. You should know something about programming - not how to do it, necessarily, but how objects work and what a procedural language does is a good start. The more general knowledge you have about systems design and technology the more valuable you will be and the better your internal models will be for testing.
- What’s the difference between your expert testing and someone banging on the keyboard until something interesting happens? If you know that, and you can explain it to me when I ask, then you understand test framing. Without solid test framing you are relying on instinct and luck more than is necessary. Without test framing you will struggle to give TACIT STRUCTURE to your testing, and that’s the line between a good tester and anyone at a computer. Try doing some testing, to an explicit charter, and ask yourself why you’re spending valuable time on your current action - what value are you providing right now? Who cares that you’re doing it? What could you find that anyone would care about?
Then yours is the Earth, and everything that’s in it. And what’s more, you’ll be a tester, my offspring of non-determined gender identity!
4 Likes
Do a recap of your work at the end of the project - put everything on paper and look at what you did well and what you could have done better. Each new project brings unique new challenges that provide useful new knowledge that may expose flaws in your testing process, and thus help further improve it.
Also, if possible, ask other team members for their feedback about your work. They have different perspective and will likely have different experience from which you can learn something as well.
1 Like
Be a champion for the user.
Escalate issues to the Product Manager if needed. Putting requirements into code requires interpretation. Developers may not completely understand how the user will interact with the application, dismissing your test results without understanding the impact. Your Product Manager will appreciate that you took the time to ensure things worked as intended and not just as designed.
1 Like
- Delete the notion that says the more you find bugs, the better Tester you are
- Instead focus on creating an Awesome Product/Application
1 Like
and: Deliberate?
1 Like
Try and remember when testing that people want outcomes, and they use products or services to achieve these outcomes. I find it can be quite easy to forget this when testing. There is an interesting article here related to this: https://www.theappbusiness.com/insights/the-outcome-driven-approach-to-innovation
1 Like
-
Try any peace of tech you can try.
-
Use operating systems that are not popular.
-
Try beta versions of softwares.
-
Attend conferences.
-
Believe that your work goal is to release a better software not to prove that you’re right.
1 Like
Learn Blockchain. Many of the software are getting
integrated into blockchain.
Don’t forget the basics - 1) Attention to detail
2) curiosity to explore.
1 Like
Get involved with having a Testing Community of Practice at your workplace.
They’re a great way for testers to share what they do, how they do it, and why they do it, letting experiences be shared between one another.
Got a shiny new tool others might be interested in? Share it in the CoP!
Been to a conference cough TestBash cough and want to talk about what the presentations? Share it in the CoP!
Unsure how to test X? Ask about it in the CoP!
A great video about them, and their benefits, by Emily Webber at https://www.ministryoftesting.com/dojo/lessons/communities-of-practice-the-missing-piece-of-your-agile-organisation-emilly-webber
4 Likes
For 2019 - ask the people on your delivery team who are knowledgeable about the CI (continuous integration) pipeline (and CD if the team is doing continuous delivery or deployment) to explain it to you with visuals - drawing on the whiteboard or using sticky notes or cards on a table or wall. Learn what has to happen in between developers committing a code change until that change is seen by production users. This can take a lot of courage. You will have a better understanding of your product, process and risks. And as you ask questions, you may help your teammates think of ways to shorten feedback loops!
I did this last month with one of my teammates. I work remotely and I’m new AND I’m shy, so it was hard for me to ask “Who can help me understand the CI/CD pipeline” and then set up a time with that person - though he was perfectly willing! He walked through not only the pipeline but a drawing of the entire product architecture and all the many tools used in the infrastructure for building and hosting it.
4 Likes
Every once in a while you should apply the same critical mindset you use when testing to evaluate your own test approach.
4 Likes
Stop, breath and step away. That thing can wait until you’re ready to come back with a fresh head. Give your mind regular breaks.
8 Likes
Communication is the must have core skill for a tester. Writing and speaking are great ways to learn more about this skill. Writing is involved in everything testers do, daily. From exploratory testing, to automation, to documentation, having developed writing and speaking skills paves the way for so much of the day-to-day interactions with other technologists. Get feedback. Write often. Learn about your audience. Mentor others on the skills of writing and speaking. Your career will thank you for it.
5 Likes
- Be nice to people and treat everyone with respect.
- Be an active listener.
- Ask questions when you think they are needed. Don’t overdue it with them, people can get annoyed.
- Be a storyteller. Practice to explain technical systems to people who have no idea about it.
- Be an active reader of blogs and books.
- Dive into the technical domain you are working in.
- From time to time test something completely different. Being it software or hardware.
- Share your testing experience with the community. Don’t be shy, everybody has something to share.
- Close the knowledge gap for things you need for your job.
- Focus
5 Likes