Project 1 - V&V SW Analysis - I
Write a Test plan to test features of a new mobile phone (Blackbox test) that needs to be implemented based on the following requirements.(The product is still under development stage and is yet to be UA (User Acceptance ) tested .Every other thing to be included in the test plan can be hypothetical.
TEST PLAN:
if(owner long press the power button)
{
open the company logo at centre;
}
else if(customer press the power button)
{
open the apps in grid;
}
else if(owner power on the phone)
{
shows call the phone icon on first position at bottom;
}
else if(owner power on the phone)
{
shows Dictionary icon on second position at bottom;
}
else if( owner click on call the phone icon)
{
contacts appears in chronological order;
}
else if(owner click on Dictionary icon)
{
search bar appears at centre;
}
else if(owner long press power on button)
{
displays Good-Bye and gets switched off;
}
else if(owners phone font)
{
always in calibri with size of 12;
}
else if(customer requirement touch responsive)
{
reflects on touch;
}
else ( customer requirement no hard buttons)
{
touch screen sensitive;
}
if(owner long press the power button)
{
open the company logo at centre;
}
else if(customer press the power button)
{
open the apps in grid;
}
else if(owner power on the phone)
{
shows call the phone icon on first position at bottom;
}
else if(owner power on the phone)
{
shows Dictionary icon on second position at bottom;
}
else if( owner click on call the phone icon)
{
contacts appears in chronological order;
}
else if(owner click on Dictionary icon)
{
search bar appears at centre;
}
else if(owner long press power on button)
{
displays Good-Bye and gets switched off;
}
else if(owners phone font)
{
always in calibri with size of 12;
}
else if(customer requirement touch responsive)
{
reflects on touch;
}
else ( customer requirement no hard buttons)
{
touch screen sensitive;
}
Different Types of Test Cases
Test cases can measure many different aspects of code. The steps involved may also be intended to induce a Fail result as opposed to a positive expected result such as when a user inputs the wrong password on a login screen.
Some common test case examples would be the following:
Test cases can be applied to any number of features found in any given software. Some of the most popular include:
A Popular Test Case Example
Test cases come in handy in a variety of software scenarios. Everything from banking to personal software requires a test case application. For example, if the goal is to have encrypted, sensitive data, the software needs to have features that work as intended.
But functional testing is just one aspect of writing a test case. Software testing should robustly challenge every aspect of the code from performance to compatibility to security. That’s why personal encryption software needs to be tested so thoroughly — especially when it comes to.
How to Write Software Test Cases
Writing test cases varies depending on what the test case is measuring or testing. This is also a situation where sharing test assets across dev and test teams can accelerate software testing. But it all starts with knowing how to write a test case effectively and efficiently.
Test cases have a few integral parts that should always be present in fields. However, every test case can be broken down into 8 basic steps.
Step 1: Test Case ID
Test cases should all bear unique IDs to represent them. In most cases, following a convention for this naming ID helps with organization, clarity, and understanding.
Step 2: Test Description
This description should detail what unit, feature, or function is being tested or what is being verified.
Step 3: Assumptions and Pre-Conditions
This entails any conditions to be met before test case execution. One example would be requiring a valid Outlook account for a login.
Step 4: Test Data
This relates to the variables and their values in the test case. In the example of an email login, it would be the username and password for the account.
Step 5: Steps to be Executed
These should be easily repeatable steps as executed from the end user’s perspective. For instance, a test case for logging into an email server might include these steps:
- Open email server web page.
- Enter username.
- Enter password.
- Click “Enter” or “Login” button.
Step 6: Expected Result
This indicates the result expected after the test case step execution. Upon entering the right login information, the expected result would be a successful login.
Step 7: Actual Result and Post-Conditions
As compared to the expected result, we can determine the status of the test case. In the case of the email login, the user would either be successfully logged in or not. The post-condition is what happens as a result of the step execution such as being redirected to the email inbox.
Step 8: Pass/Fail
Determining the pass/fail status depends on how the expected result and the actual result compare to each other.
Same result = Pass
Different results = Fail
Accelerate Software Testing by Sharing Test Assets Across Dev & Test Teams
Standard Unit Test Case Format
Each part of a will define several core aspects including:
- Functions performed by the test
- Data used in the test
- Expected result from the test execution
- Ensuring the test was executed in isolation from other parts of the codebase
It’s important to know that the standard format of well-written tests is composed of the following parts:
- Meaningful test method name
- Controlled data or mocks to be used for testing
- Method or unit under test (the part of code we are testing)
- Applying an assertion
- Executing the unit test in isolation
Is There a Test Case Template?
As mentioned, there is a standard test case format. However, the test case template would likely vary from company to company and even from team to team. Instead, a test case template is the document with a list of test scenarios and subsequent test cases.
Quality Test Case Example
Though test cases will vary based on the type of testing and overall field of testing, building a quality test case comes down to those few reliable items above. Remember: the name of the test method must include the method or unit under test and what is the expected outcome.
It should also be noted that each unit should be tested in isolation. In this case, “isolation” means keeping tests focused as much as possible in order to execute only the piece of the application we are testing for.
This example comes from a banking-related test case:
With this method name, we know that this is a unit test that is:
- Testing the method ‘isOverDrawn()’.
- The balanced used for the controlled data was 500.
- The expected result is true.
A meaningful method name allows anyone reviewing the results to understand what the unit test was testing for. Moreover, it signals the data to be tested, the expected result, and what was tested.
If the test fails, knowing the expected result is critical in allowing for easier troubleshooting and
Test Case Data
The data used needs to be enough to execute the test. For unit testing, we want to make it as simple as possible to test the most basic unit of our application. The data could be as simple as making a string or object variable for which you can control the data. Or a mock framework can be used for the test if a dependency is not available or you need that dependency to be in a specific state.
Having just enough to test that one part if sufficient. You DO NOT need to configure every piece of the application for the test to run.
All of this affects how the unit test will behave since this is the data being used for unit test execution. As such, this part of unit testing is the most time consuming as it requires some understanding of the code you are testing to know what data to use for testing.
Keep it simple by using just the parts needed for the code being tested. Mocks are very useful in this phase as they allow you to control how methods from those objects will behave when interacting with your test.
For example, given the following data:
We avoided the “real customer class” by using a mock for the “customer class” for testing isolation. We do not want to introduce nor configure another object for this test as it adds another layer of maintainability for that object, and it is not affecting the result of the method under test.
The next variable to be created is the “initial balance”—something known due to knowledge of the code. The next line shows the Account object being created along with the mock and the Initial Balance to prepare the method we are testing for with the data we just used.
So in this example, the account object is configured with the mock customer since we do not care about the customer object’s data and we passed an initial balance that we can control for our test.
The next line defines the input as the method under test requires a number to be used. We defined the “balance” to be used in the method we are testing for. Then the method is executed with the result of the method being stored in our variable for us to use later.
Applying an Assertion
Once the test can complete successfully (as in it runs from start to finish with no exceptions or errors), then it is time to apply an assertion to the unit test. Without the assertion, the unit test is meaningless since there is nothing you are enforcing to ensure it is working as intended.
Collecting coverage of what lines were executed does tell what was executed but it does not provide enough detail to determine the following:
- If the code is behaving as expected.
- If the code meets quality targets.
- If the data returned is the expected data.
An assertion can be as basic as:
As long as the unit test contains one assertion that is checking the method under test result, this is a meaningful unit test.
By applying the standard format of unit test, a team can easily maintain, read, and/or update tests with more ease to readily see where more testing can be applied to the rest of the application.
What Are the Best Practices for Writing Quality Test Cases?
How to write effective tests and test cases can be streamlined over time. Some include using strong titles, strong descriptions, and keeping the language concise and clear.
But you’ll also want to include preconditions, assumptions, and the expected results, too. All of this information is relevant for the software tester — especially when determining whether the test case should be a “pass” or a “fail” instead.
A cheat sheet for creating test cases that work well is as follows:
- Keep things simple and transparent.
- Make test cases reusable.
- Keep test case IDs unique.
- Peer review is important.
- Test cases should have the end user or defined requirements in mind.
- Specify expected results and assumptions.
Simple, unique, specific, open to feedback, and focused on reusability: that’s the way of a great test case. For a more visual look at how to write a quality test case, check out Parasoft’s webinar on the subject.
Test Suite vs. Test Plan
The other aspect of a test case involves test suites and test plans. These differ in key ways and both are vital to accurate test case development.
Be a Smarter Software Tester With These 5 Delicious Technology Combinations
What Is a Test Suite?
A test suite comes into play for test cases as it relates to source code, the collection of dependencies, or the suite of tests to be performed on code. Test suites allow you to categorize test cases in ways that align with any analysis or planning needs.
This means that core software features might have their own test suite while another test suite is for a specific testing type such as smoke or security. Think of test suites as a bookshelf to organize your test cases on.