| |
Day #1: Time to Understand QA
Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5You must understand QA before you can make an impact as a tester. You need to understand what the testing process is and how you fill your role in it. Whether you work in an Agile, a Waterfall, or an Iterative Waterfall development environment, the actions that you take as a tester are basically the same.
Understand The Testing Process
The only real difference in the development environments is when you, as a tester, become involved. You still wait for development to reach a specific point and then you test. How soon this point is reached differs depending on your environment, your team, and your release schedule.No matter your development environment, your goals should be the same; deliver the highest quality testing, accurate measuring, and succinct reporting. In its simplest form, here is what a project looks like: A company comes up with an idea that they are sure their target market wants. The product is put to paper (or electronic document form). Here they will detail what the desired behavior and end-user experience will be. The product is then developed (coded, manufactured, etc.). • Once in a stable enough state, the product is tested • Testing uncovers issues (bugs) that need to be fixed • These issues are reported • Developers fix the issues and the product is tested again • This developing, fixing, and testing continues until the product has reached a pre-defined state of completion, or is close enough and the pre-determined ship date has arrived • The product is completed • The team hold a meeting to wrap up the project (this is called a Post Mortem meeting)
As you probably guessed, testing is where you come in. Whether daily builds prompt testing from the first day of coding in an Agile environment or weekly builds in a Waterfall environment, you job is to test as quickly and effectively as possible and get results to the rest of the project team. For you to be the most effective tester possible and to claim that you understand QA, you have to be able to describe the
types of testing
that will be needed and you may be asked to execute. There are many types of tests and
testing techniques
that will need to be executed; including Functional, Automated, Boundary, Stress, Compatibility, Regression, End-User, and Ad-Hoc to name only the most common. In the beginning you will not need to know all of the detailed permutations and definitions of each test, but you should have an understanding of the basic idea behind each test type and why it is important to execute them.
This is an intro that will help you understand QA. You will find more technical definitions of test types in
the Glossary,
but below are some basic explanations that will get you started.
Brief note regarding terminology: Keep in mind that just about every company has slightly different terminology and definitions to which you will need to adapt. But if you understand QA; if you have an understanding of what the tests are, why they are run, and what they test for, all you have to do is change the name that you associate with each test and you will be off and running.
Basic Test Explanations: • Ad Hoc – This is testing that is improvised. The tests run are at the discretion of the tester, therefore the experience and skill of the tester is very apparent when this type of testing is executed. Ad Hoc testing is performed without following predefined test steps • Boundary – These tests attempt to “break” the program from within by changing or breaking the program’s own rules. Pushing the program from within to check for correct error handling. Are the error messages that it gives intelligible to the end user? This includes tests like: Selecting buttons when you shouldn’t, interrupting dialog as it’s playing, using both mouse buttons at once, what input will text fields accept (foreign characters, “too” many characters), etc. • Compatibility – This testing answers question regarding whether or not the program will work on all of the operating systems that it claims to? What sorts of errors are given when you try to run on an unsupported OS? Are you given a helpful, clear error message? • Functional – Exercise every single function in a program step by step, piece by piece. • Real-World – This is testing that is focused on the user paths that are most probable. This may also be called “Golden Path” testing • Regression – This is testing that focuses on validating pre-existing functionality. It is also the term used when testing bugs that claim to have been fixed • Stress – These tests attempt to “break” the program from the outside. Changing external factors to see how the program responds. Checking the error handling capabilities of the program. Are the error messages that it gives intelligible to the end user?
To understand QA you must have a solid knowledge of the tests that you will perform during the testing process. This is one of the first steps in preparing to be a real Quality Assurance Professional. When you can walk into your first testing job already having an idea of what tests you’ll execute and why, you will have an immediate leg up on your competition.
Your fellow newbies will not yet understand QA. They will be confused and doing all that they can just to keep up with what they are being asked to do. They won't have heard of these tests, they won't know what they are for...they will not understand QA. So that’s the beginning. That is the basic flow of the testing process: • Code is ready for you to test • You execute tests brilliantly • You validate what works and what doesn’t • Log your bugs and report your results • Code is updated and is again ready for you to test • Lather, Rinse, Repeat
Tomorrow, in Day #2, we will look at executing tests and finding bugs – just your basic QA Tester bread-and-butter.
Go To: Day 1 - Day 2 - Day 3 - Day 4 - Day 5
Leave
Time to Understand QA
and head off to
Successful Quality Assurance Home

|