We developed a project, QA already verify the project and now we are going live. but I am still wondering about expected bugs.
How much testing technique is there to certify a product?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this communityWe developed a project, QA already verify the project and now we are going live. but I am still wondering about expected bugs.
How much testing technique is there to certify a product?
This is a difficult question, and it really depends on what you want to acheive and what you already have in place. Generating tests can be a long and labourious, and this goes severalfold for automated tests.
So the question "how many types of testing should I perform" has the answer "it depends on what you're trying to acheive and how much time/money you have to do it". The question "how many testing techniques are there to certify a product" depends on what your project counts as "certified". You cannot fully and exhaustively test the average project.
It's also hard to see what will apply to your project. For example there is Static testing (looking at the code) and Dynamic testing (checking the code at runtime). There's white box testing, black box testing and grey box testing. There is functional and non-functional testing. User acceptance, GUI, security, sanity and smoke, automated and manual, performance and load, stability, and various other types or mechanisms of testing.
It may be sensible to trust QA's decisions on this, just let them know what you want to achieve: find more bugs, fewer regression bugs missed, increase in coverage/finding more bugs in certain areas of the project, finding more critical bugs earlier, quicker repair of the testing architecture after code changes (maintainability/speed). Look at what comes back from your Beta testing, or at least what feedback you get from the users when you launch.
One more thing: testing is probably something you should be doing throughout the cycle. It's not going to be easy to suddenly ask for a system to be tested when it's ready to air, unless you intend to continue testing after the release.
Abdul, I suspect you are looking for a cookie-cutter approach to satisfy some desired level of confidence. Such a cookie-cutter doesn't exist.
Techniques are systematic approaches based on heuristics to help solve very specific types of problems within a given context.
"Certifying" a product, or "signing off" from a testing perspecive is either an implicit or explicit contract between the test team and management (or employer) that the product has met or exceeded stated criteria.
The test team will use various techniques, approaches, and methods to evaluate and provide feedback against the stated criteria, but it is analysis of the information that is provided by the testing that helps you as manager make the final decision to 'certify' the product or provide compelling evidence to the decision-makers why the product is not ready to go live.
https://www.tutorialspoint.com/software_testing_dictionary/equivalence_partitioning_testing.htm
Please go through the above link you will get to know detailed information regarding which testing you have to do before lunching application into play store.
-Boundary Value Analysis (BVA) -Equivalence Partitioning (EP) -Decision Table Testing. -Beta Testing -GamaTesting