Reddit reviews Lessons Learned in Software Testing: A Context-Driven Approach
We found 7 Reddit comments about Lessons Learned in Software Testing: A Context-Driven Approach. Here are the top ones, ranked by their Reddit score.
John Wiley Sons
This book is pretty good. You can jump to whatever area you’re struggling with/want to improve. Lessons Learned in Software Testing
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:
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.
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!
I would buy and read cam kaners book:
http://www.amazon.com/gp/aw/d/0471081124/ref=mp_s_a_1_4?qid=1449942666&sr=8-4&pi=AC_SX110_SY165_QL70&keywords=cem+kaner&dpPl=1&dpID=511C1lrN-hL&ref=plSrch
But in general you need to figure out your mission and objectives, then break them down into tasks and dates. Dont rush into automation until you have some stable qa practices and understand where automation fits in.
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 would take a close look at what your doing now before looking for a tool to through money at. You will be able to get a better lift from fixing what you have now before starting on automation.
What is our current testing process?
When does it start?
Who does what, when?
How do we execute tests?
What type of documentation is there?
What is our definition of done?
What slows down testing?
Do we have the right people testing?
Check out the book Lessons Learned in Software Testing: A Context-Driven Approach - https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124
It's a collection of short lessons, read the ones you find relevant don't worry about skipping around. I think it would be very helpful.
Most "schools" that offer QA programs or courses are usually a waste of money. This is due to the fact that there are not many regulations or standards that exist for education in this field. They can teach some extremely outdated syllabus and get away with it because their students and admins do not know any better (look at all the useless certifications out there). Testing is an extremely nuanced and complicated art, it's one of those things that is very easy to get started and do badly, and most people cannot tell the difference. This is an area where I'd like to make a difference later in my career. For now though, if you want to get into testing, I would suggest you to both learn the automation side (even though you didn't pass your java course, you are still probably technically savvy enough to learn the basics and go from there) and the theoretical testing concepts.
You get a lot of devs that do not have a testing mindset or testers without enough technical skills / coding experience. If you can do both really well then you will be looked at like a unicorn and can make a good living (depending on your country/area).
The easiest way to get into automation is learning through a tool like Postman (back end testing) or Selenium. There's tons of Udemy courses and youtube content for these.
Check out Valentin Despa's content for PM, and John Sonmez or Naveem's stuff for selenium.
For testing concepts such as analysis, risk, quality criteria, communication, test design and techniques I would suggest reading the following books:
https://www.amazon.ca/Explore-Increase-Confidence-Exploratory-Testing/dp/1937785025
https://www.amazon.ca/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124
https://www.amazon.ca/Perfect-Software-Other-Illusions-Testing/dp/0932633692
and consider taking Rapid Software Testing classes from michael bolton or james bach, they get pretty theoretical but are based upon practical work that you will be asked to perform.
These videos can also give you a pretty good sense of the testing role:
https://www.youtube.com/watch?v=ILkT_HV9DVU&t=19s
https://www.youtube.com/watch?v=3FTwaojNkXw&t=2048s