Top products from r/QualityAssurance

There is no magic button but in the end, you need to understand code to make the transition. It doesn't really matter what flavor of code but you need to become comfortable in code because the nature of QA Automation (and subsequently, development in general) is that the technology stack is ever changing and you need to have the self-confidence to take on these new technologies, frameworks and languages.


Note: You don't just need to learn how to write test code. You need to learn how to write test code, work with source control tools, work with a CICD process, work with frameworks, setup a proper dev machine and so on.


But don't be intimidated - you don't need to be an expert coder. In fact, generally speaking it is sort of understood that QA Automation Engineers are likely to be "worse" coders than the regular dev team. In fact, you will probably still have to do plenty of manual testing in your day to day life as an Automation Engineer.


So anyhow here is what I would recommend:

1. Pick a language, say C#.
   
   
   
2. Get a high quality coding book and actually take the time to work through it. If you are into c# I recommend: https://www.amazon.com/C-6-0-NET-4-6-Framework/dp/1484213335
   
   
   Step 2 could be a video tutorial, a bootcamp, whatever but I like books.
   
   
   
3. At this point, if you actually took the time to read your book and follow the exercises you should have a reasonable understanding of your language of choice.
   
   
   

   
   

   
   
   Now it is time to flex your new code muscles and create something!
   
   
   

4. Create a github account. You will be storing your projects there. Using github will get you used to source control and it is HIGHLY LIKELY you will use it in a professional context at some point. Having a github as a portfolio is something that can and will set you apart from other job candidates.
   
   
   
5. Time to create a project and start practicing skills! Go here and choose a public API you want to test: https://github.com/toddmotto/public-apis
   
   
   
6. There are basically 2 core level 1 skills for test automation and you are going to use your API and its website to cover them both in your project:
   

• API Automation
  
• Front End Automation
  
  
  

7. So Armed with your target API and a github account, go ahead and create a new project in your language of choice and get it synced up with your github. *Note: since this github will be your portfolio, make sure your commits have high quality messages and so on. Get in the practice of writing good commits.
   
   
   
8. Now, since we know you know how to test, come up with all of the test cases you can for the API.
   
   
   
9. Automate API Tests:
   

• Add a test framework to your project like nUnit.
  
• Code up a rest client so you can call the API.
  
• Figure out how to serialize the JSON response from the API.
  
• Write validations for the serialized response (HTTP Status Codes, Expected response payload)
  
  

10. Automate front end tests:
    

• Add selenium to your project
  
• Navigate to the website of your public api
  
• Create some UI test cases and code them up.
  
  
  Congrats, you now have a project that demonstrates your ability to write front end and API integration tests using industry standard tooling.
  
  
  Of course, your very first practice project is probably going to be quite crap because you don't know best practices or patterns, but I maintain you will be better saved by actually creating SOMETHING than by learning about best practices but never writing code. Doing is the best way to learn and in tech, there is a personal power in the confidence of being able to approach a task knowing you have done it before. So if you need to, delete your first project and start over. Or even better, keep refactoring until the project is impressive. It isn't going anywhere!
  
  
  Projects like this are great because anytime you learn a new technique, it gives you a great place to try it out. And if you do it right, you will not only have a portfolio, you will have your own personal automation code library that you can pull from when you encounter a similar situation in the wild.
  
  
  For the first decade of my career in test I was of the mindset that I could never be smart enough to be a coder. The way I was able to get past this was by forcing myself to apply myself, get a base level of knowledge and then apply it practically as described above. In the end, making the jump from manual to automated QA is less about QA and pretty much all about learning to become a software dev. So get on it!

I concur with learning a programming language, however I disagree with learning python, not that isn't a bad idea to learn it, but for automation I would suggest ruby actually....as a lot of the automated testing uses ruby (or ruby on the backend)...it's a pretty easy language to learn.

Automation is HOT right now, literally I get people adding me on linkedin JUST because I put "automation" or "selenium" on there. It's crazy at how in demand it is.

It's actually really not that bad to learn either, my programming is Rusty (I also graduated with a CS degree like 7 years ago) so you probably still have the "ability" to pick it back up easily.

I'd also suggest this book on agile testing : https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
It's a pretty well-known and referenced book.

As for Automation i'd suggest trying it out on an External Site and using Capybara with Selenium AND Poltergeist drivers. Capybara is a DSL and helps sort of...shorten the commands needed per driver (Such as click_button in all Drivers as opposed to using Seleniums driver specific button clicking method).

Poltergeist is a headless driver that uses Phantomjs, so it's perfect for Continuous Integration (Recruiters love that word). So it's worth learning to say you know how to write automated tests for a CI environment.

If you have any questions on automation let me know, I do it everyday as a QA where I work.

Your story sounds so similar to mine. I worked as a psychologist for a few years, then I had to change the path (for reasons that did not depend on me) and by chance I got a job as a tester in a company, based solely on what they called my "analytical skills". Needless to say, I felt completely lost in the beginning, having no IT background.

I am a manual tester and have started to play around on codecademy to learn some basics. At first I was very afraid that my skills will not live up to the demands of the developers, but I noticed that it was actually a bit of an advantage that I did not think like them - I was just curious about the applications and I tried to find out who the users might be, how they would use the application, what they would try to do with it. I also was lucky in developing a good working relationship with the developers and I did ask questions to try and find out as much as I could use to guide my testing. I think it is critical to ask: ask the devs, ask yourself what a user would do, ask what the expectations of the end users could be, think about the context etc etc. Scenarios are a great mind tool and testing tool.

I agree that I sometimes feel lost with this ad-hoc testing, and I felt like I needed some sort of structure to my thinking. I stumbled upon a great book that you would maybe enjoy too at this point: http://www.amazon.com/Exploratory-Software-Testing-Tricks-Techniques/dp/0321636414. Since then I've started talking about tours in testing, and I've developed mine also.

I still feel inadequate from time to time. As a matter of fact, I came to reddit today to try and find out where a less technical tester could start in learning automation :))

OK, got it. Perhaps the low level details aren't exactly what you need. BTW, I've tried reading some of these books e.g. this one: http://www.amazon.com/TCP-Illustrated-Vol-Addison-Wesley-Professional/dp/0201633469/ref=pd_sim_b_2 and they are not for the faint of heart.

What's worked better for me are online articles like the one above. While I'd love to grok TCP/IP at a deep level, I really don't need to know that much about it. Although I could see how it would be extremely useful if I worked at a networking company.

tl;dr good luck! I find Charles to be a bit easier to use than Fiddler.

Cool :)

I would start with CD book https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

Having read it you would understand how modern software development look like and you should understand why test automation is crucial these days.

I had once created a post about learning test automation - you can check it here
http://www.awesome-testing.com/2016/08/how-to-start-learning-test-automation.html

Here are two paths I proposed:

Path 1 - GUI Automation with Selenium

1. Learn basics of programming language first - preferably with Java for Testers book.
   
2. Learn basics of Selenium - preferably with Guru99 Selenium course.
   
3. Start writing real tests on existing website, for example http://the-internet.herokuapp.com/
   
4. Make sure you understand how Maven/Gradle, TestNG/Junit work.
   
   Path 2 - REST API Automation with Rest-Assured
   
   
5. Learn basics of programming language first - preferably with Java for Testers book
   
6. Learn HTTP protocol with HTTP: The definitive guide
   
7. Learn about REST API - Microsoft has recently published it's API Guide with useful links
   
8. Learn Rest-Assured with Baeldung, Test Detective or some different guide (there is plenty of them)
   
9. Write tests against real API. Check my post which you can use as a reference.
   
10. Make sure you understand how Maven/Gradle, TestNG/Junit work.
    
    There are a couple of testing books which are worth reading too. Perhaps this one is the best https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
    
    Just start small with basic checks. You may even use my github project https://github.com/slawekradzyminski/AwesomeTesting
    
    Hope I hadn't overwhelmed you :D
    

Thanks for the compliment! and compliments right back at you Sir, for your hard work doing all that on evenings after work. I never had enough energy to get past Hello World doing that. Instead I straight up quit manual QA, moved back home, and am doing oddjobs for cash while I study 40 hours a week.

I spent 5 years in manual QA at Blizzard and Microsoft going absolutely nowhere making shit money and getting pissed on by everybody else there as the lowest man on the totem pole- getting a paycheck that was 30%-40% of what everyone else in the Corporation was making despite me grinding away the same 50 hours a week same as devs, producers, artists, and marketing people. Even when I finally made Test Lead, I was in shock to realize I was still lower paid and less respected than the secretaries and parking lot security guy.

I realized the only way I was ever going to make a liveable paycheck to accomplish my dreams of home ownership and having children was to get out of that toxic lifestyle, and get job as a Dev or TestDev.

It's not easy but it's doable yourself. I'm particularly fond of Jon Sonmez inspirational videos, Brian Duggan uni lectures and RB Whitaker's textbook for Year One of C# programming. It's a wonderful regimen.

For reporting the bugs, use one bug report card per bug, not one Trello card per type of bug. So if you find 3 broken links in the same page/floater plus one crash when clicking OK, write 4 bug reports.

Try to gauge the size of each bug, and try to allocate your own time accordingly. If you think it's a nasty bug, spend more time being specific about it. If it's a typo or a minor issue, spend less time. Just make it reproducible.

Follow this general template for creating bug reports, especially in a tool like Trello where you really just get a freeform text field plus a few extras. Each bug report should contain:
Summary (card title): Brief sentence saying what the problem actually is.
Steps to Reproduce:

• 1. Note each step you took
     
• 2. To make the bug happen
     
• 3. Just like this.
     
• 4. Include what ACTUALLY happened
     
• 5. And include what you EXPECTED to happen.
     
     Try reproducing it several times and note your success rate. e.g. Reproduced 3/5 attempts.
     
     That's a really basic start (not complete at all!) to at least get you to a basic level you can build on piece by piece.
     
     If you're going to do this for more projects, a good book to invest in is Rex Black's Managing The Test Process. It basically gets you set up as an independent QA consultant able to approach any project, whether at a big company or a little company with zero QA.
     
     There are many routes into and through QA, but good bug reporting and basic bug management is a core skill you'll use all career long.
     
     Best of luck!
     
     Edit: minor formatting

This question has been popping up pretty much everyday. I really wish someone who has successfully made the transition (not me, I went from a CompSci degree to automation) would write up a solid FAQ or guide of sorts.

However, pretty much everyone will tell you to learn to program/script, software testing methodologies/principles, CI and similar shit like that.

A book I've been looking at lately might be of help, someone here recommended it to me.

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

Just looking at it, I would question the value of this. There are plenty of free resources for you to use. GTAC and other videos, software test podcasts (Test Talks), etc.. There are also countless books like how Google tests software that will help point you in the right direction in terms of what you need to learn.

Hell, pick up an ISTQB foundation book. I like this one: https://www.amazon.com/gp/aw/d/1780172990/ref=mp_s_a_1_1?ie=UTF8&qid=1479508511&sr=8-1&pi=AC_SX236_SY340_QL65&keywords=software+testing+istqb

Good luck!

A good start would be to read some books. Go on Amazon and search for "testing web applications".
I would recommend Testing Computer Software by Cem Kaner as a starting point, and once you have some experience, read "lessons learned in software testing".

I havent read this one, but seems like it could be helpful:
https://www.amazon.com/Testing-Applications-Web-Planning-Internet-Based/dp/047139470X/ref=sr_1_9?ie=UTF8&qid=1496264155&sr=8-9&keywords=testing+web+applications

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.

Here's a cool little cheat sheet for common tests to run for any application, though mostly focused on web apps:

Test Heuristics Cheat Sheet

I'd also recommend reading this book. It's kind of outdated, but still has some great tips, especially around non-web apps:

Testing Computer Software

Record and playback is only good for learning and it shouldn't be utilized as a primary method of creating your scripts. https://www.amazon.com/Software-Testing-ISTQB-BCS-Certified-Foundation/dp/1780172990 read this. It will help you greatly.

This book is pretty good. You can jump to whatever area you’re struggling with/want to improve. Lessons Learned in Software Testing

I did it a few months ago, there is an official BCS book on Amazon as well as practice papers on the BCS website. The questions in the papers were almost replicas of the actual exam. I'd recommend both the book (as new edition was just released) and the practice exam questions that are scattered around the net.
Link: http://www.amazon.co.uk/gp/aw/d/1780172990/ref=mp_s_a_1_1?qid=1453044467&sr=8-1&pi=SY200_QL40&keywords=iseb+foundation&dpPl=1&dpID=51O6SWm2OYL&ref=plSrch
Edit: link

Try selenium...

Selenium IDE 3 can be used as a first try, and can be automated with Firefox and Chrome, but with extension you can execute the recorded scripts on many browsers

Than C#, Java, Python - and many other popular languages - can be used with web drivers to automate any browser Edge, IE, Chrome, Firefox etc., combining with programming possibility in your favourite programming language .

http://www.seleniuimhq.org

User guide with examples: https://www.amazon.com/dp/B07L88LCDN

That is how long the classroom course is. It may take you longer to self study but that depends on you so I couldn't estimate. I would say it is worthwhile though. This is the course book.

I really like The Design of Everyday Things.

I would start with just reading random blogs and articles that you can find. This is pretty good but might be a bit advanced abstract if you have no hands-on experience: http://www.satisfice.com/articles/cdt-automation.pdf

Also note that different roles mean different things when they say "test automation". Often you cannot really tell whether people mean unit testing, api/integration testing or GUI automation when reading an article.

In case you are looking to implement some for of automation in your team/company, this might be a must read:
http://www.amazon.com/Experiences-Test-Automation-Studies-Software/dp/0321754069/

How Google Tests Software -- https://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027

Agile Testing: A Practical Guide for Testers and Agile Teams -- https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468/ref=sr_1_1?s=books&ie=UTF8&qid=1493586342&sr=1-1&keywords=agile+testing

A Practitioner's Guide to Software Test Design -- https://www.amazon.com/gp/product/158053791X/ref=oh_aui_detailpage_o07_s00?ie=UTF8&psc=1

Perhaps you can try working part-time in remote crowdsourcing test platforms. You'll get exposed to different types of products and learn quickly how to approach testing strategically.

https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468 -- I read this while I was still a working student in QA, to understand how QA works in dev teams.

Read up more about: BDD, Gherkin, blackbox testing