If you wanted to hand a book over to a new tester, to help them get to grips with the world of testing, what topics would you expect or like to see in it?
• How to walk in to your new work station and set it all up or who to ask
• What tools is best - personal I know but always handy for reference
• Tips & Hints told by a range of testers from all walks of life
• Personal section - how not to get too down on yourself or how to communicate in XXX language when you only know YYY language.
I would completely focus on examples of testing.
I had taken an example from Cem Kaner’s book and put it on the web: https://medium.com/@revelutions/how-cem-kaner-tests-software-17e3d6fc6157
However, it’s not easy. Very few testers can create examples like this.
I would then create topics similar to RST.
Of course, the problem is that this may not marketable. The test market is a mix of traditional ISTQB type and newer agile/devops/automation.
- what tools are best
- Tips or stories from real testers - only reading books, blogs, articles wont help
- Basic outline of what to expect in terms of QA process, testing.
In no particular order:
- Testers thought process - think like a tester
- General test terms and their explanations
- Test types and their applications
- Domain Familiarisation - why you should get to grips with your new company / environment, know the business as well as testing
- Useful resources about testing, both on and off line
- How to remain current in testing and grow within it
Learn the application you’ll be testing.
As a new tester, I found the amount of information available to me was as overwhelming. It would be great to offer an approach or curriculum to follow. Suggesting a time management blueprint could be very useful when learning the application, test tools, test strategies, algorythms, teamwork & collaboration, agile/kanban etc. Even today, I know what I know and there are many things I want to learn. However, I don’t know where (or on which subject) my time investment will provide the biggest return.
Tester’s Attitude - how to face bugs and deal with the fact they’re open/closed prioritzed/de-prioritized in a professional way
How programs are made - programming a website, what is under the hood, pointers to HTML/CSS/JS websites, pointers to network concepts (TCP, HTTP, REST, SOAP, OSI stack)
Terminology and History - what is a manual scripted test case, what’s an automated test case, why we automate some and not others, what’s not a testcase, what’s a test plan, a test cycle, what’s in a bug report, what’s a bug/defect, why Waterfall appeared, why Agile appeared
Test Coverage - simple techniques (pairwise, boundary testing), how to represent it (what should be in a test plan, mind maps), how to prioritize it (pareto rule and other ideas)
Edit: after reading the others, adding up more topics:
How a tester think - how to be organized in an exploratory session, note-taking ideas, representing paths you took in a graph/bullet-points/use-case-format, ideas on how to report the findings (and understand that bugs are not the only output)
Tooling - environment management (docker, ansible, VMs, remote desktop), Selenium, some BDD framework, some TDD framework (JUnit), Jenkins/CI
In general, would be nice to pair up each section with a story about a tester using those concepts, taken from real world testers (there was a book like that, with a lot of Tester’s being interviewed, one each chapter, can’t remember the name tough)
I disagree that promoting context-driven testing not being marketable. So long as there are new testers coming into the field, there will be a need to learn how to test and how to get those who work with you to understand (or attempt to understand) what it is you do. Not to mention the benefit of learning how to think as a tester.
How to collaborate effectively
How to influence team mates
The art of listening
I actually give new testers “The tester’s pocketbook” by Paul Gerrard. Its a great primer.
Mostly longer versions of this:
How to ask questions. (Or how to ask the right questions) (https://www.slideshare.net/EuroSTARConference/kn-johnson-the-art-of-asking-questions)
How to give (constructive) feedback
How to receive feedback
Interviews with testers from different fields and industries - for example one-two page interviews where the tester describes his lessons, challenges, everyday tasks.
I was referring to the job market. I think there are 100 hiring managers who understand ISTQB for every 1 that understands CDT. This varies depending on the geography. This group might be skewed towards CDT.
The other big question is translating CDT into marketable skills - that you can put on your resume and which will stand out.
In terms of marketable skills, what I’ve found is the recruiters who skim LinkedIn are not knowledgable about testing in general. What gets a person into the door is their ability to demonstrate that their knowledge fits the needs of the organization. For every job I’ve had, at no point during an interview was I asked “Do you know what a test pyramid is?” Or “How do you write a test case?”. They either didn’t know about the ISTQB or did not take the certification seriously. The questions were moreso around how you work with other people, what knowledge you can share with the team, how you solve problems, etc.
In fact, it wasn’t my resume that got me the job. It was the ability to convince the decision maker that I was the best fit for the job through what I said and how I carried myself that got me in the door. Of course, that became easier as I built up connections over time. For someone starting out it’s much harder.
How to write test documents such as SRS, test plan, test case, traceability matrix and so on…
Pro tips you don’t think of.
What to focus on in the first place.
Because in big companies they need to reduce the number of candidates. So first you meet a person who will need to know who you are before what you can do. Then on the 2nd interview, if you remain after the 1st selection, you start to meet the techn guys.
Some companies I’ve had interviews for do the opposite. Right on the tech guys then other people.
For a new tester I would expect to see a book that covered the topics of:
- Introduction to sprint time-economics for Agile development
- Web platform testing tools and techniques for beginners (chrome dev tools, extensions, Bugzilla, etc)
- Anatomy of a bug report
- Basic command line utilities and commands
- Introduction to git and GitHub workflows
- Introduction to mobile app testing and risk mitigation
- Common testing scenarios and how to spot them
- I would like to see a section on problem solution architecture. When this happens - best practices are for this outcome from the tester which should have this effect.
• The tester position of objective skeptic (role of testing and hypothesis of product the product is of good quality)
• Framework for successful testing - short process flow
• Testers and specification and code reviews
• Attributes and data needed in a suitable bug tracking tool
• What happens when your bug tracking tool or data contents are insufficient
• Connection between bug tracking tool and measurement from test results and predictions
• Biases and organization stresses that can impede successful (suitable or appropriate) testing
• The variety of approaches to testing (not just requirements, not just exploratory, not just automated)
• Risk, scope of testing and regression (and automation)
• Connection between size of the product or system and testing
- The Role of a Tester
- Influencing Skills
- Communication Skills
- Stakeholder awareness
- Effective bug writing
- Business Awareness
- Testing as a Service
- Did I mention Communication & Influencing?
- Risk & Mitigation
- Test Design
All common principles rather than a bias to manual/automation etc.
Andy write a book and I volunteer to be one of your testing markets :)
You know its not such a bad idea