begin at the beginning
Start With The Basics
As a QA Manager, I found that the most successful and gratifying experience for myself and the team was created by following a proven process.
The first step was always training, working with new team members to enhance their natural talents while providing basic instruction in QA analysis and testing techniques.
For those new to the role, an understanding of core concepts and methodologies is crucial for success as they begin their careers as professional QA testers.
The Novice Tester
Aspiring software testers most likely posses a set of innate talents such as analytical skills, attention to detail, and effective communication abilities.
When effective training is added to those existing traits, the novice software tester is given the keys to a fulfilling career.
We are all computer users these days, so even someone without software development experience has a feel for navigating computer applications in their daily lives.
Beyond that user experience, new testers also require working knowledge of the software development process, and that’s where basic training for software testers comes into play.
Following are some topics for a beginner:
Software Development & The Testers Role
Regardless of the development style (i.e. waterfall, agile, other), the tester should be able to understand the development lifecycle process and effectively communicate with all concerned, including developers, users, analysts, and managers.
The testers role is to plan and execute tests that support the delivery of software per the users needs and the organizations quality standards - goals that are accomplished and supported by their knowledge of the development process and the ability to work productively with all team members.
Test Planning
A roadmap is needed to thoroughly test the application. The test plan may be in the form of a document with all relevant project-specific details, or simply a set of testing guidelines that apply to all projects. A tester should have awareness of some essentials regarding test planning:
- testing types utilized: developer unit tests, functional manual tests, regression tests, automated tests, user acceptance tests
- testing goals (critical functionality vs. non-critical, delivery timelines)
- understanding and agreement of all participants of testing goals
- methodology for reporting and correcting issues and software bugs
- appropriate status reporting to the team
- contingencies for unplanned occurrences
Test Execution & Coordination
The Test Plan should contain all the details around running tests. Even so, some coordination is usually required during execution. For example:
- is the tester running a stand-alone test assuming the application is in the proper state? Or is coordination with other team members needed to execute?
- if using a ticket-based system, is the ticket in the proper status (i.e. Ready for QA), and assigned to the tester?
- are any needed supporting systems and/or interfaces (ex: APIs) active and available for the test?
- is the process for recording pass/fail conditions clear (should be in the test plan)?
- is there a stated timeline for test execution (if an agile project with a time-boxed sprint, this should be obvious)?
Reporting Bugs
When all is said and done regarding testing, there is still one potential weak link: bug reporting.
The bug report has to be timely (fitting into the current release cycle), complete (including all appropriate links, narrative, screenshots, etc.), and easily reproducible.
Incomplete bug reports can seriously impede progress by generating unnecessary crosstalk between developers and testers to clarify the issue.
While the tester is not responsible for identifying the source code that generated the error condition, they are tasked with providing as much information as possible to allow the developer to easily recreate the condition.
There may be a tendency for novice testers to immediately report a bug as soon as they see it, prior to a more comprehensive analysis. As an example, a bug found in a web-based application would lead to further questions:
- is the hardware/operating system used in the test a supported configuration (this should be stated in the test plan)?
- if this a supported system, is it a supported browser/version (again, should be in the plan)?
- was the bug discovered via the planned script for a critical function, or was it found via unscripted exploratory testing (could effect bug level severity/priority)
- are there other considerations (other than source code, such as interfaced systems, internet connectivity, etc.) that may have manifested to the user as a bug?
While not a complete list, those are some initial considerations that should be addressed prior to a new testers first attempt at reporting bugs for the application. More project and application-specific details would be added as needed of course.
At the end of the day, the objective is to ship software that meets or exceeds user expectations. Basic training in core QA test techniques is crucial in making that goal a reality.