Q: What is your view of software QA/testing?
A: Software QA/testing is easy, if requirements are solid, clear, complete, detailed, cohesive, attainable and testable, and if schedules are realistic, and if there is good communication.
Software QA/testing is a piece of cake, if project schedules are realistic, if adequate time is allowed for planning, design, testing, bug fixing, re-testing, changes, and documentation.
Software QA/testing is relatively easy, if testing is started early on, and if fixes or changes are re-tested, and if sufficient time is planned for both testing and bug fixing.
Software QA/testing is easy, if new features are avoided, and if one sticks to initial requirements as much as possible.
Q: How can I be a good tester?
A: We, good testers, take the customers’ point of view. We are tactful and diplomatic. We have a "test to break" attitude, a strong desire for quality, an attention to detail, and good communication skills, both oral and written.
Previous software development experience is also helpful as it provides a deeper understanding of the software development process.
Q: What is software testing?
A: Software testing is a process that identifies the correctness, completeness, and quality of software. Actually, testing cannot establish the correctness of software. It can find defects, but cannot prove there are no defects.
Q: What is a test engineer?
A: We, test engineers, are engineers who specialize in testing. We create test cases, procedures, scripts and generate data. We execute test procedures and scripts, analyze standards of measurements, and evaluate results of system/integration/regression testing.
Q: What is a QA engineer?
A: QA engineers are test engineer, but they do more than just testing. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization.
Communication skills and the ability to understand various sides of issues are important. A QA engineer is successful if people listen to him, if people use his tests, if people think that he’s useful, and if he’s happy doing his work.
I would love to see QA departments staffed with experienced software developers who coach development teams to write better code. But I’ve never seen it. Instead of coaching, QA engineers tend to be process people.
Q: How do you write test cases?
A: When I write test cases, I concentrate on one requirement at a time. Then, based on that one requirement, I come up with several real life scenarios that are likely to occur in the use of the application by end users. When I write test cases, I describe the inputs, action, or event, and their expected results, in order to determine if a feature of an application is working correctly.
To make the test case complete, I also add particulars e.g. test case identifiers, test case names, objectives, test conditions (or setups), input data requirements (or steps), and expected results.
If I have a choice, I prefer writing test cases as early as possible in the development life cycle. Why? Because, as a side benefit of writing test cases, many times I am able to find problems in the requirements or design of an application. And, because the process of developing test cases makes me completely think through the operation of the application.
You can learn to write test cases! If there is a will, there is a way! You CAN do it, if you put your mind to it! You CAN learn to write test cases, with little or no outside help. Click on a link!
Q: What is the role of the test engineer?
A: We, test engineers, speed up the work of the development staff, and reduce the risk of your company’s legal liability.
We also give your company the evidence that the software is correct and operate properly.
We, test engineers, improve problem tracking and reporting, maximize the value of the software, and the value of the devices that use it.
We, test engineers, assure the successful launch of the product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down.
We, test engineers, help the work of the software development staff, so the development team can devote its time to build up the product.
We, test engineers, promote continual improvement.
Q: What testing approaches can you tell me about?
A: Each of the followings represents a different testing approach: black box testing, white box testing, unit testing, incremental testing, integration testing, functional testing, system testing, end-to-end testing, sanity testing, regression testing, acceptance testing, load testing, performance testing, usability testing, install/uninstall testing, recovery testing, security testing, compatibility testing, exploratory testing, ad-hoc testing, user acceptance testing, comparison testing, alpha testing, beta testing, and mutation testing.
Q: What are the QA engineer’s responsibilities?
A: Let’s say, an engineer is hired for a small software company’s QA role, and there is no QA team. Should he take responsibility to set up a QA infrastructure/process, testing and quality of the entire product? No, because taking this responsibility is a classic trap that QA people get caught in. Why? Because we QA engineers cannot assure quality. And because QA departments cannot create quality.
What we CAN do is to detect lack of quality, and prevent low-quality products from going out the door. What is the solution? We need to drop the QA label, and tell the developers that they are responsible for the quality of their own work. The problem is, sometimes, as soon as the developers learn that there is a test department, they will slack off on their testing. We need to offer to help with quality assessment, only.
Q: What metrics can be used in for software development?
A: Metrics refer to statistical process control. The idea of statistical process control is a great one, but it has only a limited use in software development.
On the negative side, statistical process control works only with processes that are sufficiently well defined AND unvaried, so that they can be analyzed in terms of statistics. The problem is, most software development projects are NOT sufficiently well defined and NOT sufficiently unvaried.
On the positive side, one CAN use statistics. Statistics are excellent tools that project managers can use. Statistics can be used, for example, to determine when to stop testing, i.e. test cases completed with certain percentage passed, or when bug rate falls below a certain level. But, if these are project management tools, why should we label them quality assurance tools?