What Do You Wanna Know???
SQA are a series of activities, procedures and policies that aim at achieving a desired level of quality in the production of a given softwate deliverable. Although many times SQA is associated with Software Testing, this is only one of the activities that are linked to it, and in fact many if not most of the activities fall under the responsibility of the programmers or developers generating the code of the software being created.
Software Testing is an activity that aims at validating that the software has all the required functionality it was supposed to include and also that it meets all the additional non-functional requirements that it needs to meet in order to function properly. There are number of different types of Testing that can be done as well as different approaches or tools that can be used for this purpose.
Not every project needs testers, but every project needs testing. In many projects testers are aimed at validating the functionality and compliance of the system, while at other projects the programmers are the ones who take this responsibility and they test the system using any means that stand at their disposal. Even on projects where there is no apparent testing responsibility, there will always be testing done by the initial users of the system who will then report any issues or problems with the system in order for the developers to fix them and release another version of the product.
A bug is basically when a product behaves in a way that it was not intended or desired. Software can have bugs for countless reasons, but some of the most commons are: mistakes of developers, integration issues, problems derived from working on different platforms or versions of the same platform, etc
Sure, you can introduce any new process to any existing company, but you will need to know how to deal with resistance to change. This means that you will need to have someone in the company who will help you push this changes, either by convincing the people who need to do this work or by power of authority. New processes also need to take into consideration all the existing constraints of the organization and have answers or workarounds for any changes that will need to be done on these points
Validation checks if the specification is what the user wanted (in other words if we are doing the right thing), Verification checks if the feature was written based on the specifications (or if we are doing the thing right)
A walk-through is the process when someone takes you over a subjects and explains step by step what you are seeing. In the case of software development is when a programmer takes you over the code and explains how the functions work and what they do at every step. This is a good method of static testing.
An inspection is a review, basically when you want to go over a product carefully. It is usually a static testing activity
Software does not have quality in the same manner than a shirt does not have quality, but you can grade the level of quality of a software product by indicating how well it complies with the requirements (both stated and unstated) that the users of the same product expect it to have. Basically if it has the required functionality and if it behaves in ways that they expect it to behave (or better).
All of these are certifications that a company may get in order to show it's customers, partners and other groups of stakeholders that they are working based on specific standards. These standards in themselves do not ensure higher quality of products, but at least in principle they ensure that visibility into the processes will be achieved.
SLC or ADLC (Application Development Lifecycle) are the models of the process that companies can follow to create their products. Examples of SLCs or ADLCs are the Waterfall Process, SCRUM methodology and more.
Documentation can play a number of roles in QA. To name a few: you use documentation to know what needs to be tested, how the product under test should behave, what tests you want to run, what issues have been detected, and more.
This is a hard question to answer since there are many things that will make you a better tester and some of them will be relevant in some occasions while others may be more useful in other jobs. Many people have tried to answer this question in blog posts and articles, for example this one that I can recommend - qablog.practitest
Requirements are important as they will explain to us how the application should work, and this in time will tell us what to test and what to expect from our testing. You need to take into account that not all requirements are documented and they may also not be in one place. It is OK and even recommended to talk to your stakeholders to understand what are the formal and informal requirements of your system.
Different people will call different names to the same type of documents. The standard definition of a test plan is an explanation (a plan) of the activities you want to perform as part of your testing. Some people call this document an MTP (Master Test Plan) and it will include different sections based on the different aspects and considerations for your tests.
A test case is a series of steps that describe a feature or set of features to be tested.
Everything can be tested, the question is what is the objective of your testing. If the system is very buggy then try to test in order to define what are the major things to be fixed that will allow you to continue testing further. Point at the roadblocks that need to be lifted so that you can work on more deeper testing operations.