Qa

  • Uploaded by: Sharif
  • 0
  • 0
  • April 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Qa as PDF for free.

More details

  • Words: 1,011
  • Pages: 4
Source: http://homepages.gold.ac.uk/nikolaev/210-24.doc 1. Software Quality Important points: - The requirements of the software are infect the foundation from which quality is measured ; -The standard development criteria or requrements that guide the manner in which the software is engineered or developed ; - whether the software meets these standards or not Now the factors means the real issues behind the scene -correctness - does it do what I want? - reliability - does it do it accurately? - efficiency - will it run efficiently on my hardware? - integrity - is it secure? - usability - is it designed for the user? MORE>>>>>> 1. Software Quality factors Product revision: - maintainability - can I fix it? Means kamran that with the help of qa does it helps in easy maintaining of the product or not. - flexibility - can I change it? Means kamran that if I need to change the product or alter, add or update ( like Microsoft windows 98 to win 2000 or win xp) can it be done or at what leve it can be done) - testability - can I test it? Easy to understand Product transition: The word transition means * let say if you are leaving from home to University. Now the time between “when u leave home and before srriving Uni.* “ is the transition period”. In other words, when the product start changing to the time just before it reaches it final stage. It has 3 items important: - portability - will I be able to use it on another machine? Easy to understand, like usb pen drive. - reusability - will I be able to reuse some of the software? - interoperability - will I be able to interface it with another system? Like Bluetooth mobile devices can it work in all mobile or nokia only.

http://www.testingcenter.com/c100mr00.html

What Is Regression Testing? Regression Testing The idea behind regression testing is simple. We know that changes to an existing system often cause other things to break. To detect when this happens, we keep a set of tests (the Regression Test Set, or the RTS for short) containing tests of important things that used to work okay. We run the RTS after each set of changes to make sure that these things still work. That's it. The problem is to do regression testing correctly, so that it solves more problems than it creates. Benefits of Regression Testing There are lots of benefits to doing regression testing. (1) It increases our chances of detecting bugs caused by changes to an application (2) It can also detect undesirable side effects caused by changing the operating environment. For example, hardware changes, or upgrades to system software such as the operating system or the database management system The Big Questions After A Change To The System: 1. Did the change work? 2. Did it break anything else? 3. Is the RTS still okay? 1-The first question is almost always easy. We simply test whatever the change is supposed to do, 2- "Did It Break Anything Else ". (a) what's broken, and (b) how would we know that? Answer: run the Regression Test Set (RTS). 3-"Is the RTS still okay?", is often overlooked, but it's one of the things that can get you in trouble.

Summary: • • • •

Regression testing means rerunning tests of things that used to work to make sure that a change didn't break something else The set of tests used is called the Regression Test Set, or RTS for short It's enormously helpful when you change an application, change the environment, and during integration of pieces. Regression testing is a simple concept, but it needs to be done just right to work in the real world.

Difference between White box n Black box? Blackbox testing: Testing is based on behaviour of the application . what it does/ produces etc. Also in black box testing testers does not require code language White box testing Testing is based on internal structure of the application. So in white box testing testers requires code language More example read this: if u feel easy or leave it as this much is enough to get the basic of this. http://www.webappsec.org/lists/websecurity/archive/2008-05/msg00025.html

*Black box testing is the act of verifying that a software Specification, without reference to the internal workings (functioning) of the code to verify the spec. *Black Box testing is also very strong at identifying errors of omission and unintended/surprising emergent behaviours 4. White Box testing is the act of verifying the internal workings of a piece of software with reference to structure and/or down to the algorithmic(functioning) level. There are many different types of testing that fall under "White Box" testing. (e.g "structural verification") White Box testing is primarily focused on verifying that the design structure follows an expected or ideal structure, and that the implemented algorithms perform the units of work that they are planned too. White Box testing is very strong at identifying errors of commission.

OTHER TESTINGS 1. "Vuln test" aka vulnerability (WEAKNESS) testing == subset of Black Box testing. Most commonly means to locate the artifacts of exploitable conditions & behaviors in software. False positive prone without human analysis, due to the fact the artifacts are often behavioral inference, and may not in fact indicate a security defect at all. http://www.aptest.com/glossary.html Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria. Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. Automated Testing: • •

Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing. The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.

if we have ticket or bug how we fix it write down Step

Related Documents

Qa
November 2019 66
Qa
November 2019 54
Qa
December 2019 54
Qa
June 2020 27
Qa
April 2020 37
Qa
April 2020 43

More Documents from "Sharif"

2
April 2020 38
Kamran Sharif111[1]
April 2020 30
Qa
April 2020 43
3
April 2020 27
Sharif Resume
May 2020 16