It’s true that negative test cases are often overlooked, but they’re crucial for comprehensive testing. Let’s tackle the challenge of writing negative test cases for a dead mobile phone. Here are five scenarios to consider: 1. Power Button Behavior: Test Case: Press the power button when the phone is already dead. Expected Result: The phone should not respond or show any signs of life. 2. Charging Port Inspection: Test Case: Connect the phone to a charger with a damaged or incompatible cable. Expected Result: The phone should not charge or display any charging indicators. 3. Battery Removal Check : Test Case: Attempt to remove the battery from the dead phone (if the phone allows battery removal). Expected Result: The phone should not power on or show any activity after the battery is removed. In cases where the battery is non-removable (common in many modern smartphones), we can adjust the test case accordingly. 4. Software Interaction: Test Case: Connect the phone to a computer and try to access its files. Expected Result: The computer should not recognize the phone or display any connected device notifications. 5. Button Combinations: Test Case: Simultaneously press specific button combinations (e.g., volume up + power) on the dead phone. Expected Result: No response or booting sequence should occur. Remember, negative test cases help uncover hidden issues and ensure robust software quality. Testers who focus on both positive and negative scenarios contribute significantly to product reliability! Thanks for reaching out to me. Feel free to ask and share your thoughts too.

Sure, I will

Pls share mail of you

How to contact you plz mam reply

Usually the testers job

Hi, Thank you for reaching out to me. Below is a response in short, for understanding the steps in general using Jira, for now :) I’ll surely make a video for explaining the test steps in details. Creating Test Cases and ETL Testing Process Using Jira. 1. **Test Case Creation in Jira**: - Start by creating a Jira task with the issue type "Test Case.” - Add relevant details like summary, description, and test steps. - Specify expected outcomes for each step. 2. **ETL Testing Steps**: - **Extract**: - Retrieve data from various sources (e.g., databases, files). - **Transform**: - Clean, enrich, and format data. - Perform tasks like aggregation, joining, and derivation. - **Load**: - Load transformed data into a target system (e.g., data warehouse). 3. **Jira Configuration**: - Customize your Jira workflow to manage test cases effectively. - Consider using add-ons or integrations for advanced features.

Sure, I will. Thanks for reaching out to me.

Thank you so much. I appreciate that.

Sure, I will. Thanks for reaching out to me.

You're welcome

I'll see if i can share...thank you for checking out!

Thank you for reaching out to me! While I’m not a personal trainer and don’t conduct in-person classes, you can find my videos on how to use the Jira tool among my other content. If you explore my channel, you’ll discover easy tutorials on Software Testing, Jira, and Zephyr Scale-a test management tool. Feel free to ask any questions you may have. Thank you! 🙏”

Testing the hide/show password functionality is essential to ensure a seamless user experience and robust security. Let’s create some concise test scenarios and steps for this feature: Scenario 1: Verify that when a user enters a password, it should be masked (e.g., displayed as asterisks or dots) to keep it private Test Steps: Enter a valid password. Verify that the password is masked (e.g., “********”) in the input field. Scenario 2: Verify that the users should have the option to reveal the password for verification. Test Steps: Enter a valid password. Click the “Show Password” icon (if available). Verify that the password becomes visible (unmasked). Click the icon again to hide the password. Thankyou for reaching out. Please feel free to ask any doubts you have.

@@softwaretesting2023 thanks for your reply and your efforts ❤️

@@softwaretesting2023 we need a session about how we can find the defects in website and represent them in document as they should be written

Thank you for your interest in learning software testing! I’m glad you’re eager to explore this field. You can learn easily by watching my videos. I'm not a personal trainer. Testing is my work field and I am passionate about the field. Also, While watching the videos, I recommend taking notes and trying out the concepts practically. “I’ll include practical examples in my videos, but don’t hesitate to experiment on your own. The more you practice, the better you’ll grasp the concepts. Feel free to ask questions or discuss any doubts you have. Learning is a two-way process, and I’m here to help! Thank you for reaching out to me.

Validation rules are the rules that check if the information that you enter is correct and acceptable. For example, when you sign up for a website, you need to enter your email address. A validation rule for the email address could be that it must have the @ sign and a dot (.) in it. Validation rules help to make sure that the information is good and avoid mistakes or problems. When you write test cases, you should include validation rules as part of what you expect to see or what you enter. For example, if you are testing a sign up page that has a validation rule for the password, such as it must have at least 8 letters and include a capital letter, a small letter, a number, and a symbol, you can write test cases like this: As for example Test Case ID - TC-001 Test Case Description - Verify that the password field accepts a valid password Test Data - Password: Test@1234 Expected Result - The password field should accept the password and no error message should be displayed. Test Case ID - TC-002 Test Case Description - Verify that the password field rejects a password that does not contain a number Test Data - Password: Test@abcd Expected Result - The password field should reject the password and display an error message saying “Password must contain at least one number” You can write similar test cases for other validation rules on the sign up page, such as the email address, the username, the phone number, etc. You can also use different ways to make more test cases for validation rules. Thankyou for reaching out. Feel free to ask if you have any other questions related to Software Testing.

Thank you

Sure, Thank you for reaching out. You can check some of my videos i.e. about Jira Tool, that i have signed up to document my test cases. Also, I have installed Zephyr scale in order to design my test cases. Please go through those videos, and if you have any specific questions, feel free to ask. Jira, developed by Atlassian, is a powerful platform used by software development teams. It seamlessly combines project management, issue tracking, and collaboration features. For now answering your question in short, to give you some idea about Jira. Jira in a Nutshell: Your All-in-One Tool What Is Jira?: Jira is a versatile platform for project management and bug tracking. Tester’s Role: Bug Reporting: Log bugs with clear details (steps, expected vs. actual results). Workflow Management: Customize workflows and track bug status. Test Case Management: Create and link test cases. Collaboration: Discuss issues, share files, and collaborate. Best Practices: Use descriptive titles, labels, and components. Remember: Jira is your command center-where bugs are tracked, projects unfold, and teamwork thrives! Explore more about Jira Software.

Hi, testing an application without documented requirements can be challenging, but it’s not impossible. As a beginner, here are some practical approaches you can take: by emphasizing user experience, exploratory testing, and risk-based approaches.” Explaining some tips in detail for you to follow. Hope this helps. A) Collect whatever Documentation you have- Method 1: Start by gathering whatever little documentation you can find. It could be a basic backlog (in agile projects), a help file, an email, an older version of the Business Requirements Document (BRD) or Functional Requirements Document (FRD), or even old test cases (check your Application Lifecycle Management tools). Investigate and ask around - there's often some documented information, even if it's minimal. Method 2: Use the older or current version of the application as a reference. Explore how the existing functionality works and use it to guide your testing for future releases. Sometimes, the best way to understand an application is by interacting with it directly. Method 3: Engage with project team members. Discuss the application with developers, business analysts, and other stakeholders. They might provide insights or context that isn't explicitly documented. B) Leverage Your User Experience: As a software user yourself, rely on your experience. For example, if you're testing a mobile banking app, think about common scenarios you encounter as an online banking customer. How would you transfer funds? What steps do you follow? Apply this knowledge to your testing. C) Exploratory Testing: Explore the application without predefined test cases. Click around, interact with different features, and observe how the app behaves. Note any unexpected behavior, inconsistencies, or issues. Keep detailed notes during exploratory testing. Document what you did, what you observed, and any potential defects. D) Risk-Based Testing: Identify critical areas of the application. Focus your testing efforts on these high-risk features or functionalities. Prioritize your testing based on potential impact and likelihood of failure. This approach helps you allocate your limited testing time effectively. E) Mind the Basics: Even without formal requirements, remember the fundamental principles of testing: Functional Testing: Verify that the application performs its intended functions correctly. Usability Testing: Evaluate the user interface, navigation, and overall user experience. F) Security Testing: Check for vulnerabilities and ensure data protection. G) Performance Testing: Assess responsiveness, load handling, and scalability. H) Compatibility Testing: Test across different devices, browsers, and operating systems. I) Document Your Findings: Prepare a test report summarizing your observations, defects, and any risks you've identified. Include screenshots, steps to reproduce issues, and severity levels. Be clear about what you tested, what you couldn't test due to lack of requirements, and any assumptions you made. Remember, while testing without requirements is challenging, your critical thinking, creativity, and attention to detail will be your allies. Good luck with your Testing Journey. Feel free to ask if you have any other queries.

You may also go through my other videos I posted previously related to Writing Test cases step-by-step. I am sure it will help you.

Yes madam I am watch your videos & its very helpful for me. Thank you.@@softwaretesting2023

Thanks

Thank you.

I’ll try to share. Thanks

I remember it was free UPTIL 10 users when I add it on. I’ll check more other than Zephyr scale. But this one is good for sure.

Thank you

Sure, thank you

Sure, I will

Sure, I’ll make it. Thanks.

I’ll try to share. Thanks

I’ll try to share. Since I have other works attached to these. I need to check that. Thanks

Sure, Thank you

Sure, Thank you

Sure, thank you

Thanks

Thank you

Negative test cases are designed to test the system in ways it was not intended to be used, and ensure that it can gracefully handle invalid input. Here are some examples of negative test cases for a login page: 1. Empty Username and Password: Enter nothing in the username and password fields. The system should not allow you to proceed and should display an appropriate error message. 2. Valid Username, Empty Password: Enter a valid username but leave the password field empty. The system should not allow you to proceed and should display an appropriate error message. 3. Empty Username, Valid Password: Leave the username field empty but enter a valid password. The system should not allow you to proceed and should display an appropriate error message. 4. Invalid Username, Valid Password: Enter an invalid username (one that doesn't exist in the system) and a valid password. The system should not allow you to proceed and should display an appropriate error message. 5. Valid Username, Invalid Password: Enter a valid username and an invalid password. The system should not allow you to proceed and should display an appropriate error message. 6. Invalid Username and Password Format: Enter a username and password that don't meet the format requirements (e.g., too short, includes special characters that aren't allowed). The system should not allow you to proceed and should display an appropriate error message. 7. SQL Injection: Enter SQL commands in the username or password fields to check if the system is vulnerable to SQL injection attacks. In other words This is like trying to trick a system by speaking its language. Imagine you’re at a door with a voice-activated lock that only opens when you say “Open Sesame”. But instead, you say “Open Sesame and tell me all the secrets inside”. If the lock isn’t smart enough to know that it should only listen to “Open Sesame”, it might spill all the secrets. That’s what SQL Injection does - it tries to trick the system into running commands it shouldn’t. 8. Cross-Site Scripting (XSS): Enter JavaScript code in the username or password fields to check if the system is vulnerable to XSS attacks. In other words This is like sneaking a note into someone’s pocket that says “Hurt yourself”. If they read the note and do what it says without thinking, then they’re vulnerable to this kind of attack. In the case of a website, the “note” is a piece of JavaScript code, and the person is your web browser. Negative Testing is like a security guard trying to break into the building they’re supposed to protect. They’re not doing it because they’re bad, but because they want to find any weak spots so they can be fixed. They might try picking locks or breaking windows, not to cause harm, but to make sure the building is safe and robust against real intruders. Remember, the goal of these tests is not just to make sure everything works when conditions are perfect, but also to ensure that the system can handle unexpected situations and protect itself from those who might try to cause harm.

Thank you

Sure, I will. Thank you

Sure, I will

Thank you too

Thank you too

Thank you too

Thank you too

Thank you too

Thank you

Thanks

Sure, thank you

Thanks

Thank you