I have little to no experience about QA. I was moved within my company from another department nothing to do with IT.
If you could tell me one thing that you would consider necessary for me to know, what would it be?
If you could suggest programs that could help with testing and potentially make this journey easier, please comment as well.
One very helpful trait would be ability ("knack") to search available information and being able to find what you need. If you did simple search in QA (I used search string "how to start qa") you would find many answers, like:
https://sqa.stackexchange.com/search?q=how+to+start+qa
It took me about a minute. Writing this took longer.
Other good traits is to be able to communicate efficiently, and being detail oriented.
Good luck!
Another one for you: Resources to learn about testing theory - and see every page has "related questions".
The one thing I think it's necessary to know: The essence of the job is to provide decision makers with accurate, relevant, timely information about the system, to help them make better decisions.
Of course, you will also need to learn zillions of strategies and techniques for providing that information. But the key is to remember the point of what you do: Inform decision makers about the system.
This question comes up from time to time. You may find the answers given in this post of tremendous help: What are the key properties of a great QA team member?
It will be hard for anyone to suggest programs to you unless we know more of your testing environment. Although it may change in the future, we use no automation on our testing team. If I were to learn any programs it would be the basics of what the developers code in so I can better understand the constraints they have to work within.
If I could tell you 1 thing that you need to know, it would be to stay curious. There will be naysayers who will shoot down what you think is important to the quality of the product. Don't be discourage; stay curious in spite of them.
What do you need to be a great QA Analyst?
There is a lot of answers to this portion of the question. The main things I think would be:
Know your limitations and strengths. I am weak with UIs so whenever I am tasked with a piece that uses UIs, I typically will ask for assistance and get a 2nd party to verify that I did not miss anything. My strength is on the technical and code end, so I am constantly verifying code, reviewing code and checking for potential issues in code.
Asking questions is the primary duty of QA in my eyes. The who, what, when, where and hows are what we need to be able to do our job well. Often times just asking those questions will find the issues. Asking others about what they are expecting from the system and asking yourself those questions for every change in the system is how you create the testing scenarios.
If you could tell me one thing that you would consider necessary for me to know, what would it be?
Know your strengths and weaknesses, what the company expects from you and the software and what you plan to accomplish. A lot of the information you will gain from just time on the job, others you will naturally have. As for 1 silver bullet to QA, there is none. QA is designed to be multiple mindsets viewing the project from different angles in order to accomplish the goals. Without this ultimately multiple things will be missed.
If you want to be more valuable to your company, find your niche, the task that no one on your team seems to either want to do or is actually doing and master it. This can be something as simple as documentation, organizing and managing data or creating extensive tools and utilities for the team.
If you could suggest programs that could help with testing and potentially make this journey easier, please comment as well.
For tools check out this answer. It gives a rather comprehensive list of utilities and tools.
I have till date only worked with Web Applications and there is this idea/method I use which I think can be generalized:
At some point during the testing I envision myself as a little kid. Kids are impatient, greedy and want everything all at once(this is not a judgement. I have a wonderful little nephew whom I love to pieces). I try to do the same. I go where I am not supposed to. Do what I am not supposed to. Why?
Different organizations have different QA processes. Different levels of communication between the QAs-devs-higher ups. Different time boundaries(often tight). With so many activities taking place, every person involved is often bombarded by information(relevant/irrelevant). So much so that you stop looking at the Application as a purposeful tool and start seeing a collection of UI elements coupled with complex code execution in the background. This often warps your mind, in the sense that the devs and the QAs start performing their tasks with certain assumptions. Something like- "Oh a user will never click on this button." or "It is clear that doing so and so on the application doesn't make any sense. A user will never do it."
I click that button. I do the "so and so that doesn't make any sense". I work with the simple rule:
If an option is present, use it
I can't say that I have ever found critical bugs that helped save a lot of time and money and often reporting bugs found this way put the dev(who have to deal with their own brand of corporate BS) and myself at loggerheads, I feel it is my duty as a QA to do this. Any changes introduced in a system this way always make me a little proud.
The main motive of the QA person should be "How to break into the system". This statement keeps on driving me and helps in delivering the application as per requirement specifications.
What is actually breaking into the system ? - According to me this actually accessing or using the application components by not following the usual way. For Eg. An application has been developed which has a log-in id which accepts only alphabets. So my aim would be to get into this application by entering combination of alphabets and other characters into the log-in field.
The other thing which can be driving force is Patience. A Quality Analyst has to be very patient in understanding the Application flow and Usability. The better is the understanding the better the application is developed in the right direction with help of QA.
