| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Introduce yourself | G’Morning Sir/Ma’am! Firstly, thank you for considering my application and meeting me today. My name is Jitender, I belong to a small town called Palwal in Haryana. I want to begin by sharing my educational background. In 2022, I Completed my 12th standard in commerce stream. After that, I decided to pursue a career in tech, as I am a hands-on learner, so I knew that a boot camp would be the best way for me to learn. At Masai School, I learned the fundamentals of SDET and also got an opportunity to work with the Masai QA team. I was leading a group of 5 people, apart from that, One of my favourite projects was automating the GitHub API Endpoint. I was able to use my coding skills and automation tools to do all crud operations. I'm a quick learner and I'm always eager to take on new challenges. I'm also a team player and I'm confident that I can contribute to the team with my skills. In my spare time, I enjoy listening to motivational podcasts and learning new things. | ||||||||||||||||||||||||
2 | Masai after 12th | I chose Masai School over college after my higher education because it's like a shortcut to getting a tech job. At Masai School, I can quickly learn the specific skills that will help me to work in the tech industry, so I can start my career as soon as possible as if I went to college it would take a long time to get succeed. In Masai school they teach me what's in demand in the tech world right now, It's also more affordable than college, which is easier on my finances. Plus, I have options for how I want to learn, which is convenient. Masai School helps me build a strong resume and connect with people in the tech industry. They have a good track record of helping graduates find jobs, so it aligns better with my career goals. | ||||||||||||||||||||||||
3 | strengths and weaknesses | Strengths: 1. I am a quick learner and I am always eager to take on new challenges. 2. I am a creative thinker and I am always looking for new ways to solve problems. 3. I am a team player and I am able to work effectively with others. 4. I am a hard worker and I am always willing to go the extra mile. Weaknesses: 1. I can be shy at first, but I am always able to warm up to people once I get to know them. 2. I can sometimes be too focused on the task at hand, which can lead to me neglecting my personal life. | ||||||||||||||||||||||||
4 | salary expectations | Thank you very much for asking me this question I am just starting my career in tech, and I am more focused on gaining knowledge and experience, The placements team at Masai School has given me an idea about the package you are offering, and I am aligned with that. | ||||||||||||||||||||||||
5 | next five year | In next five years, I want to see myself as a senior software engineer at a leading tech company. I want to use my skills and knowledge to create innovative and impactful products that improve people's lives. I also want to be a mentor to other software engineers and help them to achieve their own career goals. I am passionate about coding and I am always eager to learn new things. I am confident that I have the skills and drive to achieve my career goals. I am excited to see what the future holds for me in the tech industry. | ||||||||||||||||||||||||
6 | why should we hire you | Sir, I believe I’m a great fit for this role. I’m a self-motivated person and give my 100% to any task that is given to me. That is why I have been able to do good with my Projects. And surely I will do the same for any project that is given to me in the organisation. I also work well both as an individual contributor and a team member, That is why I have multiple solo and team projects. Overall, I believe I can contribute a lot to the organisation with my skill.
| ||||||||||||||||||||||||
7 | ||||||||||||||||||||||||||
8 | SDLC | The software development life cycle (SDLC) is a process that defines the steps involved in developing software. It is a framework for planning, designing, developing, testing, and deploying software The SDLC can be divided into six phases: 1. Requirements gathering: This phase involves gathering the requirements from the stakeholders. The stakeholders are the people who will use the software, as well as the people who will be responsible for maintaining it. 2. Systems analysis: This phase involves analyzing the requirements to understand what the software needs to do. This includes identifying the features and functions that the software will need, as well as the data that it will need to store and process. 3. Systems design: This phase involves designing the software architecture. This includes designing the user interface, the database, and the software modules. 4. Implementation: This phase involves building the software. This includes coding, testing, and debugging the software. 5. Testing: This phase involves testing the software to ensure that it meets the requirements. This includes unit testing, integration testing, and system testing. 6. Deployment: This phase involves deploying the software to production. This includes installing the software on the target systems and training the users on how to use it. | ||||||||||||||||||||||||
9 | ||||||||||||||||||||||||||
10 | STLC | STLC stands for Software Testing Life Cycle. It is a process that defines the steps involved in testing software. It is a framework for planning, designing, developing, testing, and deploying software The STLC can be divided into six phases: 1. Planning: This phase involves planning the testing activities. This includes identifying the test cases, the test data, and the test environment. 2. Design: This phase involves designing the tests. This includes designing the test cases, the test data, and the test environment. 3. Development: This phase involves developing the tests. This includes coding the test cases, creating the test data, and setting up the test environment. 4. Execution: This phase involves executing the tests. This includes running the test cases, analyzing the results, and reporting the findings. 5. Reporting: This phase involves reporting the findings of the testing activities. This includes identifying the defects, the severity of the defects, and the impact of the defects. 6. Mitigation: This phase involves mitigating the defects identified in the testing activities. This includes fixing the defects, retesting the defects, and verifying the fixes. | ||||||||||||||||||||||||
11 | ||||||||||||||||||||||||||
12 | Test case | A test case is like a detailed recipe for testing a computer program. It tells testers exactly what to do, what they need, and what to expect as a result to make sure the software works as it should. | ||||||||||||||||||||||||
13 | Test scenario | A test scenario is a complete story or script that tells testers how to check if a specific feature in a software application works properly. It includes various situations and steps to follow, making sure everything is tested thoroughly. | ||||||||||||||||||||||||
14 | Test plan | A test plan is like a roadmap for testing a software project. It outlines what needs to be tested, how to test it, what's required, and how long it will take, all based on the project's specifications. | ||||||||||||||||||||||||
15 | Test data | Test data is like the input values and information used to examine and verify how a software program behaves. It's like the different sets of information or scenarios used to see if the software works correctly and produces the expected results. | ||||||||||||||||||||||||
16 | test script | A test script is like a computer program that automates the process of testing a software application. It's a set of written instructions, usually in a programming or scripting language, that tells the computer how to perform specific tests and check if the software functions correctly. | ||||||||||||||||||||||||
17 | ||||||||||||||||||||||||||
18 | Manual Testing | Manual testing is a software testing activity in which test cases are executed manually by a tester without using any automated tool. It is a type of software testing that is performed by a human tester, as opposed to automated testing, which is performed by a software tool. Manual testing is a fundamental part of the software development life cycle (SDLC), and it is essential for ensuring the quality of software. Manual testing can be performed at any stage of the SDLC, but it is most commonly performed during the testing phase. Manual testing can be used to test a wide range of software, including web applications, mobile applications, and desktop applications. | ||||||||||||||||||||||||
19 | Types of manual testing | 1. Unit 2. Integration 3. System 4. Acceptance 5. Black Box 6. White Box | ||||||||||||||||||||||||
20 | ||||||||||||||||||||||||||
21 | Automation Testing | Automation testing is a software testing method that employs automated tools and scripts to assess software applications. It relies on specialized tools like Selenium or Appium to create, run, and manage test scripts written in programming languages. These scripts simulate user interactions with the software, comparing actual outcomes to expected results and generating automated test reports. Automation testing is invaluable for regression testing, ensuring that code changes don't introduce defects into previously working functionalities. It can be integrated into Continuous Integration/Continuous Deployment (CI/CD) pipelines, allowing for early issue detection. While offering benefits like faster execution and increased coverage, it necessitates initial investments in tool selection and script development, with ongoing maintenance requirements. Automation testing is particularly effective for applications undergoing frequent updates and requiring consistent, repeatable testing processes. | ||||||||||||||||||||||||
22 | ||||||||||||||||||||||||||
23 | Functional | This is about what the software does. It's the main job or tasks the software can handle, like sending emails or calculating numbers. Types of Unit Testing 1. Integration Testing 2. Regression Testing 3. System Testing 4. Smoke Testing 5. Performance Testing | ||||||||||||||||||||||||
24 | Non-Functional | This is about how well the software does its job. It's about qualities like how fast it works, how secure it is, how easy it is to use, and how reliable it is. It's not about what it does but how good it is at doing it. | ||||||||||||||||||||||||
25 | ||||||||||||||||||||||||||
26 | Severity | Definition: Severity is nothing but the impact of a defect on software. Scale: It is typically categorized into several levels, such as critical, major, medium, minor, or cosmetic, to indicate the extent to which the issue affects the functionality or usability of the software. Example: A critical severity issue might be a bug that causes the software to crash, while a minor severity issue could be a minor formatting problem that doesn't affect the core functionality but is still noticeable. | ||||||||||||||||||||||||
27 | priority | Definition: Priority defines how soon the defect needs to be fixed by the developer. Scale: Priority is often assigned using categories like high, medium, low, or even numeric values to prioritize the order of issue resolution. Example: A high-priority issue might be a critical security vulnerability that needs immediate attention, whereas a low-priority issue could be a minor cosmetic problem that can be addressed later. | ||||||||||||||||||||||||
28 | High Priority and High Severity:- An error that occurs on the basic functionality of the application and will not allow the user to use the system (E.g. user is not able to login to the application) High Priority and Low Severity:- If the company name is misspelt on the home page of the website, then the priority is high and the severity is low to fix it. Low Priority and High Severity:-Web page not found when user clicks on a link (use’s do not visit that page generally) Low Priority and Low Severity:- Any cosmetic or spelling issues which is within a paragraph or in the report | |||||||||||||||||||||||||
29 | ||||||||||||||||||||||||||
30 | what is software testing | software testing is like checking a new app or computer program to ensure it works properly and doesn't have any mistakes that could make it crash or not work the way it should. It's all about making sure the software does its job without any problems. | ||||||||||||||||||||||||
31 | ||||||||||||||||||||||||||
32 | advantages of manual testing | 1. It’s good for doing ad hoc testing 2. Here we don't need any knowledge related to automation tools 3. It’s cheaper than automation 4. It’s good for UI testing 5. in manual Programming language is not required | ||||||||||||||||||||||||
33 | dis-advantages of manual testing | 1. Manual testing is time-consuming, 2. It requires more manual power. 3. In the manual we get very less accuracy. 4. In manual testing Regression testing is difficult | ||||||||||||||||||||||||
34 | ||||||||||||||||||||||||||
35 | Levels of Testing | Unit Testing is a software testing technique that focuses on evaluating individual units or components of a software application. These units are typically the smallest testable parts of the code, such as functions, methods, or classes. Integration Testing is a software testing method that focuses on evaluating the interactions and interfaces between different software components or units when they are combined or integrated into a larger system System Testing is a testing process that evaluates the entire integrated system to ensure that it functions as intended and meets the specified requirements Acceptance Testing is a critical phase in the software testing process where the software is evaluated to determine if it meets the requirements and is ready for deployment to end-users | ||||||||||||||||||||||||
36 | Black box testing | Black box testing is a software testing method where testers examine the functionality of a software application without knowing its internal code structure. Testers focus on testing the software's input and output behaviour to ensure it functions correctly. its techniques are:- Boundary value analysis | ||||||||||||||||||||||||
37 | White box testing | White box testing is a software testing method that focuses on examining the internal structure, logic, and code of a software application. Testers have knowledge of the application's source code and use this information to design test cases | ||||||||||||||||||||||||
38 | Grey box testing | Grey box testing is the combination of both White Box and Black Box Testing. The tester who works on this type of testing needs to have access to design documents. This helps to create better test cases in this process. | ||||||||||||||||||||||||
39 | ||||||||||||||||||||||||||
40 | Alpha, Beta and Gamma | Alpha testing is done by the developers at their site before releasing the software, focusing on identifying and fixing issues. Beta testing is conducted by few clients at their own locations, aiming to gather user feedback in real-world scenarios. Gamma testing is a phase of software testing that occurs after the software has been released to a small number of end-users. This type of testing is usually conducted to gather feedback from real users who are outside the development and testing teams. | ||||||||||||||||||||||||
41 | ||||||||||||||||||||||||||
42 | Exploratory Testing | Exploratory Testing will be carried out by domain experts. They perform testing just by exploring the functionalities of the application without having the knowledge of the requirements. | ||||||||||||||||||||||||
43 | ||||||||||||||||||||||||||
44 | Verification and Validation | Verification checks whether the software is built correctly, according to the specified requirements during the development phase. Validation ensures that the software meets the customer's needs and works as expected in their real-world environment after development is complete. | ||||||||||||||||||||||||
45 | ||||||||||||||||||||||||||
46 | Positive and Negative Testing | Positive testing is a testing approach that checks whether a system behaves correctly when valid input data is provided, to ensure that it meets the specified requirements. Negative testing is a testing approach that assesses how the system will handle invalid inputs, It examines what the system should not do in these cases | ||||||||||||||||||||||||
47 | ||||||||||||||||||||||||||
48 | Defect life cycle | The defect life cycle is a structured process that a software defect goes from its discovery to its resolution and closure. 1. New: The defect is initially reported by a tester when an issue is identified. At this stage, it's considered "new" and is ready for evaluation. 2. Open: After a defect is reported, it is assigned to a responsible party, for further investigation. During this phase, it is considered "open,". 3. Assigned: The defect is assigned to a specific team member or developer responsible for fixing it. This phase is commonly for addressing the issue. 4. In Progress: The assigned developer has started working on fixing the defect. It is now "in progress" as the code is being modified to resolve the issue. 5. Fixed: The developer believes they have fixed the defect, and the modified code is ready for testing. It's marked as "fixed" and passed to the testing team for retesting 6.Retest: Testers receive the fixed defect and verify whether the issue has been resolved. If the defect is confirmed as fixed, it proceeds to the next stage. 7. Verified: The defect is marked as "verified" when the testing team confirms that the issue is resolved successfully. If the issue is not resolved, it will be sent back to the developer for further work. 8. Reopen: If the issue is not resolved, the cycle continues from the "open" or "assigned" stage. 9. Closed: Once the defect is verified as fixed and doesn't reoccur, it's marked as "closed." It signifies that the issue has been resolved, and no further action is required. | ||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||
50 | Smoke and Sanity | Smoke Testing: This is a preliminary, high-level test that checks if the critical functions of a software system are working correctly. Smoke testing helps determine if the software build is stable enough for further testing. Sanity testing verifies whether specific changes or updates made to the software, do not introduce new issues. Sanity testing ensures that basic features are still working after modifications. that is why we can say it is a part of regression testing | ||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||
52 | Regression and Retesting | Regression: Regression testing, ensuring that code changes don't introduce defects into previously working functionalities Retesting: Retesting is the process of verifying that a specific defect or issue identified in a previous test cycle has been successfully fixed | ||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||
54 | Test closure | Test closure is the formal process of documenting and summarizing the testing activities conducted throughout the software development life cycle. | ||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||
56 | Mutation testing | Mutation testing involves making small changes to the code to simulate bugs and then running the existing test suite to see if it can detect these changes or not | ||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||
58 | API | API testing is the process of checking if the connections and instructions that are allowed from different browsers or computer programs are working correctly, and making sure that they are communicating and sharing data with each other | ||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | End to End Testing | In End-to-end testing, we check the complete flow of an application from start to end, with real-world usage scenarios. It aims to verify that all integrated components of the system, like frontend and back end, are working together as expected. | ||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | Monkey, Ad hoc and | Monkey Testing, is a software testing technique where the tester applies random inputs to the software application without a specific test plan. The goal of Monkey Testing is to discover unexpected behaviour which is caused by random inputs Ad hoc testing is a type of software testing that is not based on formal test plans or predefined test cases. It is an informal and unstructured testing approach where testers explore and interact with the software without specific test scripts Monkey Testing is a software testing method where testers put input random data into an application to check if it crashes or behaves unexpectedly, it's basic aim is to discover bugs | ||||||||||||||||||||||||