Best products from r/softwaretesting

I've been in QA for about three years - started out in Support, kept getting stuck with the "weird" tickets, got better at troubleshooting and bug hunting, and eventually started doing testing with the dev team. Working at very small startups helped speed this process up tremendously. I'm now working at a ~500 person company (huuuuuge from my perspective, I'm used to a dozen coworkers, tops!) and learned Selenium/Capybara automated tests about a year ago.

I haven't found any quality-related books that have interested me, and most of the technical resources I've found have just been whatever pops up on Google/Stack Overflow. I am also subscribed to this subreddit, and /r/qualityassurance, but they're both pretty low-traffic, and I wish more articles were shared here. If there are any blog posts that have resonated with you, I'd love to take a look as well!

The best thing I've done for myself, technically, was re-writing our automated UI test suite in POM. This ended up saving me hours of work a few months later when we added a bunch of new features, and I just had to copy-paste a few things to test for them. This is a good overview:

https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html

Because of how much grief this saved me, I continue to evangelize for it!

I can, however, recommend some management/team/soft skills/business-y books! I'm not in love with my current company, so I end up reading a lot of these to keep myself sane and motivated. Here are some of the ones I've liked the best:

• First, Break All The Rules: What the World's Greatest Managers Do Differently
  
• The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change
  
• Good Boss, Bad Boss: How to Be the Best... and Learn from the Worst
  
• Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators
  
• Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead
  
• The Accidental Creative: How to Be Brilliant at a Moment's Notice
  
• Crucial Conversations: Tools for Talking When Stakes Are High
  
• Crucial Accountability: Tools for Resolving Violated Expectations, Broken Commitments, and Bad Behavior - Kindle version on sale today for $2!
  
• Nonviolent Communication: A Language of Life, 3rd Edition: Life-Changing Tools for Healthy Relationships
  
  A lot of these are available in libraries too, and I've made a habit of checking them out there, and buying them if I really like them.
  
  I hope this helps!

I can only highly recommend the second book/link as I have not fully read the other two. https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124 is a good one as well. Outside of that, here is the advice that I would give to someone in your position.

You as a Project Manager and a QA have sole responsibility as to what your customer will see. You are the gatekeeper for software good or bad to make it to the public's hands. This is the key and the only thing you really need to keep in mind. Everything else is just fluff and suggestions.

1. Think about your product. What is it advertised to do? What does it currently do? Do those answers match?
   
2. How does it feel to you or to a customer? Is it buggy or difficult to understand? Can the process be simplified?
   
3. What criteria does software have to meet before you are willing to let your customers see it, or get their hands on it? Is there a 70% pass rate that you are looking for? 90%? And who gets to make that decision?
   
   What you decide for #1, you can start to form a set of product requirements or statements of what the product is supposed to do. For example : "I expect the login form to validate username and password, and take you to a dashboard"
   
   Keep track of these (excel or if you want to spend some money, a test case management system), and they will evolve into test cases, that you can use for your QA cycle. This will be 75% of the work. A Traceability matrix can be generated from reqs and test cases, and can be useful in checking things off.
   
   Keep in mind that while Agile is vastly popular, it's not the only SDLC you can follow. You may opt for waterfall style QA cycles instead with a sprint dedicated towards regression or exporatory testing. The ISTQB is the standardized test for QA, simply reading through their syllabus and the content that they have on their site will allow you to talk the language of other testers once you get to that level (https://www.istqb.org/).
   
   ​
   
   As for automation testing, it is never too early, but it is also never too late. If you want to think about automation testing early, start by trying to create Gherkin for your test cases and/or requirements. That will allow you to transition into using cucumber or specflow (depending on your technology stack) quickly, when you are ready for it.
   
   My advice, although may be different, is to NOT FALL INTO A SDLC PATTERN JUST BECAUSE SOMEONE TOLD YOU TO. I've seen too many shops fail in QA because they are so engrained into following the SDLC pattern that the developers are using. If you don't continue to switch things up, then you will get to a point where you're simply looking for and finding the same issues over and over again. I've been in agile heavy shops where I've told the QA team to forget what they know of agile, and go different patterns for their QA cycles, and then switch things around the next release. Keeping things fresh and continuously learning what is the trend in QA will help keep your product fresh, and your developers on their toes. Keep trying new things, and relying on what works to back up your QA work as you go. Just keep to the time schedule and the promised deadlines.
   
   ​
   
   My final advice for anyone working in a QA field is to ask questions. Ask so many questions that your developers start to label you as someone that needs to be scheduled to have a conversation with. If you don't understand anything, ask, and make sure that you understand why something is working the way something is before you let it pass in your testing. If something doesn't make sense, falter in writing too many defects and asking questions about why those defects are not defects in bug scrub or when working with your developers. May seem like I'm telling you to be annoying, which I probably am, but after a couple cycles of this, you'll naturally fall into understanding core concepts of your software, how it works, what you expect it to do in the field, and common misunderstandings from your customers about what it does and how it should work.
   
   ​
   
   I am usually fairly available, so if you have questions, feel free to pm me. And above all, best of luck with the company!

Presumably you know how to code. . . the question is, do you know how to test? Not that knowing how to test is rocket science but I'd say the first thing to embrace is that anything and everything can just break. When you write code, it's easy to focus on the "happy path".

As you might expect, there are tons of resources about testing online. . . including this subreddit and r/QualityAssurance.

Other resources I'd recommend:

• Twitter, there are a number of QA/SDET people on Twitter. . . I've stopped using it for the time being as the discussions there can get a bit pedantic/theoretical but there's quite an active testing community on Twitter.
  
  
• http://sqa.stackexchange.com/
  
  
• Blogs. . . there are many, if you want me to list my favorites, let me know.
  
  
• Forums like http://www.softwaretestingclub.com/ and http://www.stickyminds.com/
  
  
• Books, there are a ton of course, I'd recommend these two to start: http://www.amazon.com/Explore-It-Increase-Confidence-Exploratory/dp/1937785025/ and http://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124
  

I wouldn't run away, as some others are suggesting. QA/Testing is a great learning experience that can help you understand technology from a variety of different perspectives. Personally I would recommend buying a few good testing books, you can learn everything conceptually about testing from reading 2-3 books. Everything else is learning specific tools, businesses and technologies.

Here's the book I loved when I first started in a testing role (15 years ago though...) - https://www.amazon.co.uk/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124

If you are in Barcelona, DM me, happy to meet for a coffee.

​

​

​

​

​

​

​

I'm with ya on the test case counts as well as all the other practices which waste testing resources. I wish all that would end someday...so so badly.

I agree that exploratory testing is a better path to take with testing than writing up hundreds upon hundreds of steps that end up being completely unmaintainable in agile development, even with the best of intentions.

I found the book linked below on exploratory software testing to be a great resource on manual testing, since a lot of good test execution is just a mode of thought. If your employer prefers manual test cases (eww) then you could still use these techniques to write good ones.

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design https://www.amazon.com/dp/0321636414

The point is that their performance is being assessed based on a number of bugs. They want to be perceived as performing well. It's important to remember that this is only /partly/ about how testers will respond to being measured like that. The other part is about how flawed measures like this are. Like /u/tech_tuna mentioned, the most senior folks end up spending a lot of time working with other people which means they are reporting far fewer bugs. According to your method, this would mean they are not performing well.

Read this book if you want to learn more about measurement.

I am really not a fan of assessing performance via measurement, that usually means management is divorced from the work to the extent that someone has to measure it so they can make interpretations. I like it when management is there to facilitate.

Questions like this can help though:

• Is the tester providing useful information to developers
  
• Is the tester providing useful information to people that make ship decisions
  
• Is the tester finding (and persuading people to fix) problems that matter
  
• Is the tester able to adapt their approach to the problem at hand.
  
• How does the dev team feel about that person?
  
  
  Note that those are not things you count but can sort of be represented on a scale, meaning that you can make that assessment on a scale of 1 to 10 or something like that.

I liked

http://www.amazon.com/Software-Test-Engineers-Handbook-Edition/dp/1937538443

when I started. Might be a bit dated, but still a good intro into classical testing.

Agile Testing: A Practical Guide

Continuous Delivery

Clean Code

Obviously, after this you can expand more in the direction of your particular product needs. I've been doing a lot of reading around CI/CD process, and the overall trend towards "DevOps". But you might want to focus on security or performance testing, and that will have its own path.

From, one quality manager to another, you must absolutely read this book asap. It makes everything clear about what you should be doing to lead quality in your organisation. Hint: its not about HOW you test...

https://www.leadingqualitybook.com/


In terms of general management of people, would also recommend the following books.

https://www.radicalcandor.com/

https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034

https://www.amazon.com/Primed-Perform-Performing-Cultures-Motivation/dp/0062373986

Since you already have a nice amount of experience, start here: https://www.amazon.com/Experiences-Test-Automation-Studies-Software/dp/0321754069
Then figure out where selenium fits in.

Foundations of Software Testing ISTQB Certification 3rd Edition): https://www.amazon.com/Foundations-Software-Testing-ISTQB-Certification/dp/1408044056/ref=sr_1_1?ie=UTF8&qid=1537727578&sr=8-1&keywords=istqb+foundation+level

​

I read this and passed. Has a lot of sample questions, as well as a sample exam, too.

'Blazing New Trails: Tips For The Lone Tester' may be of interest too - https://www.amazon.com/dp/B07G5H7DZN