SDET Flashcards - SDLC Manual Testing
🇬🇧
In Inglés
In Inglés
Practique preguntas conocidas
Manténgase al día con sus preguntas pendientes
Completa 5 preguntas para habilitar la práctica
Exámenes
Examen: pon a prueba tus habilidades
Pon a prueba tus habilidades en el modo de examen
Aprenda nuevas preguntas
Modos dinámicos
InteligenteMezcla inteligente de todos los modos
PersonalizadoUtilice la configuración para ponderar los modos dinámicos
Modo manual [beta]
El propietario del curso no ha habilitado el modo manual
Modos específicos
Aprende con fichas
Escuchar y deletrearOrtografía: escribe lo que escuchas
Expresión oral y comprensión auditivaPractica la pronunciación
SDET Flashcards - SDLC Manual Testing - Marcador
SDET Flashcards - SDLC Manual Testing - Detalles
Niveles:
Preguntas:
45 preguntas
| 🇬🇧 | 🇬🇧 |
| Why do Software Applications have bugs? | There are various reasons why a system might have bugs, such as bad design, coding errors, miscommunication, continuous changes in requirements, rushing to meet deadlines and also the complexity of the application. |
| Can you tell the Difference between Verification and Validation? | Verification is when you are analyzing requirements, design documents, test plans and test cases to ensure we cover all scenarios and we are creating the right product and here there is no code involved. Simply reviewing documents to ensure everything is covered and NO coding is involved. Validation is when we are executing our test cases and actually writing code to verify the system |
| What is the difference between static and dynamic testing? | Static Testing (Done In Verification Stage). Static Testing is a White Box testing technique where the developers verify or test their code with the help of a checklist to find errors in it, this type of testing is done without running the developed application or program. Code Reviews, Inspections, Walkthroughs are mostly done at this stage of testing. Dynamic Testing (Done In Validation Stage). Dynamic Testing is done by executing the actual application with valid inputs to check the expected output. Integration Testing, System Testing, Regression and Acceptance Testing. |
| Can you tell different types of testing you are aware of? | Unit testing ● Integration testing ● Regression testing ● Ad-Hoc ● Smoke testing ● Performance testing ● System testing ● UAT Testing |
| In which phase should testing begin? | Testing should start at the requirements phase. We have to make sure requirements are correct in the first place. With the wrong requirement it is impossible to build bug free applications. |
| What is Ad-Hoc Testing? Exploratory testing? Random Testing? | All are the same thing, it is informal testing where you are testing without a test case and randomly testing a module conducting negative testing and positive testing but not in any order etc. |
| What is unit testing, and have you ever done unit testing? | Unit testing is a part of the white box testing and it is done by the developers before they deploy their code from the Development environment to QA environment. Since it is performed by devs, I haven’t done unit testing. |
| What is Integration testing? | Once every individual component is tested, we must make sure that when we integrate these components together they must work as expected. Example amazon.com has fresh and prime, but the entire website works together even though it has different components. |
| What is the difference between QA and UAT? What is Acceptance testing? | QA is one lower environment to UAT. QA can be a separate team that does testing and after testing has passed, the QA environment code is moved to UAT environment where again Testing is conducted to make sure no bugs have been missed. Also, UAT is mostly a business side client side that conducts it. Acceptance testing is UAT testing another name for it. |
| What is system testing? | It is testing the entire system which includes but is not limited to the Front-end, Back-end, Database, Server, Hardware, and any related Software product/application |
| What is Beta Testing? | Beta testing is conducted to gather feedback from the real-time usage of the product. It happens after the installation at the client-end or another good example is in the real-world gaming industry they release a game to a certain audience before a mass release to get feedback. |
| What is 508 Compliance testing? | All government websites are supposed to be 508 compliant meaning disable personnel should be able to use it. Features are specific fonts used on these types of website, text to speech capability and magnify capability etc. Just know what it is but you don’t tell the interviewer that you have done so. |
| What is Boundary Testing? | Boundary testing is to make sure software accepts valid data inside the valid Boundary and rejects invalid data outside the valid Boundary. A simple example would be testing the input field limitation from 0 to 100 where the lower boundary is 0 and the higher boundary is 100. We make sure we can’t go lower than 0 and higher than 100. We only test the edges and not the middle. Boundary value testing can be very beneficial since errors are frequently made during programming of the different cases near the ‘edges’ of the range of values |
| What is Negative Testing and what is Positive Testing? | Negative testing is testing the application/system with a negative scenario using incorrect/invalid data and verifies if the application responds as expected. Negative test cases are created based on the idea of testing in a destructive manner. Positive testing is testing the application/system with correct and valid data and verifies if the application responds as expected. Also can be called a “Happy Path” Testing. |
| What is non-functional testing? Have you done any performance testing? | Performance testing (Can 5000 user’s login to the application at the same time?) Security testing. Simply say NO you have not done so and that performance testing was conducted by a separate team. |
| What is Functional testing? | Simply, testing any functionality is functional testing. Manual testers do functional testing and they can be called a functional testing team. As an Automation Tester, you may be required to perform manual testing based on project needs. |
| What is a testing hierarchy? | ^Unit testing: Developers test their code to make sure the functionality they created is working. ^Component Testing: Component is a standalone functionality that can work by itself ^Integration Testing: All modules are combined. When integrated do they still work together ^System Testing: Hardware, Software, Database, servers everything ^Acceptance Testing: (User Acceptance Testing). It's testing done by a UAT team mostly business/client-side team or hired UAT team that validates what QA team tested before moving to production. |
| What is the difference between regression testing and retesting? | Regression testing is performing tests to ensure that modifications to a module or system do not have a negative effect on previous functionalities. It is performed when a new functionality is added or bug fix occurs and we want to make sure other parts of the application are still functioning correctly. While retesting is performed when a defect gets fixed and you have to retest the functionality to see if it is really fixed or not. |
| What is the difference between system testing and integration testing? | System testing is when the entire system is checked such as hardware, software, servers, databases etc., whereas for integration testing, the integration between the individual modules is tested. |
| What is a hotfix? | A hotfix is an emergency issue that needs to be fixed right away and does not need to go through a whole sprint cycle. It’s an exception where it can be developed, tested and deployed in a few hours or a day since it’s an extreme priority and clients want the critical issue fixed ASAP and deployed. |
| When is a test considered to be successful? | Tests that cover more functionalities and discover more errors in your software product are considered more successful. The whole purpose of a testing process is to discover as many bugs as possible and as early as possible. |
| When we prioritize our test cases, here is what we look for: | ^Which functionality is most visible to the user? ^Which functionality has the largest safety impact? ^Which aspects of the app are most important to the customer? ^Which aspects of the app can be tested early in the development cycle? ^Which parts of the code are most complex and thus most subject to errors? ^Which parts of the application were developed in rush or panic mode? ^Which parts of the requirements and design are unclear or poorly thought out? ^What do the developers think are the highest-risk aspects of the application? |
| What would you do if you end up with unclear requirements or requirements are not available? | In this scenario, your knowledge of application plays a big role. I would start to do some random testing to understand what is being asked and try to discover to get an idea, so I can start writing scripts. Then I will also check out our meeting notes, emails, and discussions. On top of that, look for wireframes which might give me an idea but overall my common sense and experience plays a part here and also I would think from a customer’s perspective. Also if BA is available to clarify with them as well. |
| When do you know if you have enough test cases for your project or a specific module? | If all requirements have at least one test case, then we know we have covered everything also in this case a Requirements Traceability Matrix (RTM) is very useful since it maps out Requirements to Test Cases. |
| Tell us some key challenges you face in the Testing industry? | ^ Requirements changing. ● Application not stable. ● Rush testing to meet deadline ● Unclear requirements ● Domain knowledge and business user perspective understanding. ● Lack of Regression testing or not enough. ● Lack of skilled testers. ● Lack of resources, tools and training |
| Can you do 100% manual testing and find all bugs? | No, it is impossible because there are a number of possibilities and scenarios. If we cover all functionalities and test them then we can reduce the risk of bugs and have a satisfied client. |
| What is a Test Plan? | The Test Plan document is usually prepared by the Test Lead or QA Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test. |
| Components of the Test Plan: | ●Introduction● Test items● Features to be tested● Features not to be tested ●Test techniques● Testing tasks● Features pass or fail criteria● Test environment (Entry criteria, Exit criteria)● Test deliverables● Staff and training needs● Responsibilities ● Schedule |
| What is Test Strategy? | A Test Strategy document is a high level document and normally developed by the project manager. This document defines “Software Testing Approach” to achieve testing objectives. It sets the standards for testing processes and activities. |
| Components of the Test Strategy: | ● Scope and Objectives ● Business issues ● Roles and responsibilities ● Communication and status reporting ● Industry standards to follow Test automation and tools ● Testing measurements and metrics ● Risks and mitigation ● Defect reporting and tracking |
| What is a test case and what does it include? | A test case is a document which has a set of actions that needs to be executed to verify a feature or functionality of your software application. |
| Test cases includes: | Test Scenario/Objective ● Pre-Condition ● Test Case ID ● Test Data Test Description ● Expected Result ● Actual Result ● Pass or Fail ● Comments |
| What is Test Coverage? | Test coverage measures the percentage covered area to test the feature/functionality. It determines whether our test cases are actually covering the application code and what functional area those test cases are covering. |
| Who is responsible for writing test cases and test plans? | We testers write test cases for various scenarios, while the test lead or even QA Manager is responsible for making a test plan. |
| What is the difference between Test case and Test script? | Test case mostly used for manual testing whereas test script mostly used for automation Testing. Test case is a documentation which specifies input values, expected output and the preconditions for executing the test. Test script in software testing is a program intended to test the functionality of the application. |
| What is the Requirement Traceability Matrix? | RTM is mapping requirements to test cases and test cases to defects. If there is a defect found, we can trace back to tell which specific requirement failed. RTM also tells us if we are missing test cases for any requirement. A lot of time is done in Excel. |
| What is test coverage? | What are we testing and How much are we testing! Test coverage means how many test cases that we have and what functional area those test cases are covering. Are our test cases covering the entire application or not? |
| How do you define the bug life cycle? | Bug life cycle basically comprises numerous statuses of an error during its life cycle. A few examples are open, fixed, retest, reopened, reject, and closed. |
| How do you deal with a bug which is not consistently reproducible? | The best approach is to take a screenshot of it. If you are using Snagit you can even capture video of it and note it down. Discuss the bug with the team so everyone can keep an eye on it. |
| What would you do if a developer rejects your bug and refuses to fix it? | Go back and retest it several times that it is a bug. Then check it against the requirements’, wireframes. If the developer still refuses to fix it then set up a meeting between BA and developers. If in rare situations the developer still does not want to fix, then QA manager or Project manager get them involved as a last resort. |
| What do you do when you find a bug? | First you will go back and retest it to make sure it is a bug, then you take a screenshot and create/log a bug in Jira with as many details as possible such as short description, environment found in, exact steps to reproduce, severity, priority etc. so the developer can try to recreate it. |
| Let's say you have a bug that comes in the day before the sprint is ending, do you let it go into production or move it to the next sprint? | If the bug is of a very low priority and severity we will log it and fix it at a later time since it doesn’t impact the system much and release it into production, but if it’s a show stopper we will never release it into production since it can cause other issues. |
| How many bugs do you find a day? | We don’t test every day since we have meetings and time must be allocated to create and automate test cases. When we do actual testing anywhere from 2 to 3 bugs a day at the very beginning and as we continue testing the bug rate falls to 0 to 1. |
| What is the difference between bug release and bug leakage? | Bug release is when a version of the software is released with a set of known bugs. These bugs are usually of low severity/priority. It is done when a software company can afford the existence of a bug in the released software rather than the time/cost for fixing it in that version. Bug leakage is something when the bug is discovered by the end users or customers and missed by the testing team to detect while testing the software. |
| Bug priority vs Bug severity | Priority represents the importance of fixing a bug, and reflects a business decision as to how soon that bug should be fixed: all priority 1 bugs should be fixed before priority 2 bugs, etc. Severity represents “how bad a bug is.” For example, a bug that causes the program to crash would be considered high severity, while a small spelling error might be low severity. |