- Test case 1: Verify that the search bar is visible and functional.
- Test case 2: Check that searching for a valid location displays relevant results on the map.
- Test case 3: Verify that searching for an invalid or non-existent location shows appropriate error messages.
- Test case 4: Test auto-complete suggestions while typing in the search bar.
- Test case 5: Validate the accuracy of search results for popular locations.
Directions and Navigation - Test case 6: Verify that users can get driving directions between two valid locations.
- Test case 7: Check that alternate routes are provided when available.
- Test case 8: Test the accuracy of estimated travel time and distance for different routes.
- Test case 9: Verify that walking and public transport directions are available and accurate.
- Test case 10: Test turn-by-turn navigation for driving directions.
Map Display and Interactivity - Test case 11: Verify that the map loads correctly and is centered at the user's location (if permission granted).
- Test case 12: Check that map zoom in/out functionality works as expected.
- Test case 13: Test panning and dragging the map to verify smooth movement.
- Test case 14: Validate the display of various map layers (e.g., satellite view, terrain view, traffic overlay).
- Test case 15: Verify that map markers and info windows are displayed correctly.
- Test case 16: Check if the geolocation feature accurately determines the user's current location (requires GPS).
- Test case 17: Verify that the application gracefully handles cases when geolocation is disabled or unavailable.
- Test case 18: Test the accuracy of geolocation for various real-world locations.
Traffic and Real-Time Data - Test case 22: Verify that real-time traffic data is displayed accurately on the map.
- Test case 23: Check that traffic conditions affect estimated travel time for navigation.
- Test case 24: Test the display of live incident data (e.g., accidents, road closures).
- Test case 19: Verify that users can save a location as a favorite or add it to a custom map.
- Test case 20: Check that saved places are accessible and editable from the user's account.
- Test case 21: Test the ability to share custom maps with others.
Integration with External Apps - Test case 25: Verify that clicking on a location link from another application opens Google Maps with the correct location.
- Test case 26: Check that Google Maps can be used as an external map application for third-party apps.
Accessibility and Localization - Test case 27: Verify that Google Maps is accessible for users with disabilities (screen readers, keyboard navigation).
- Test case 28: Test Google Maps' functionality in different languages and regions.
Performance and Scalability - Test case 29: Verify that Google Maps loads and operates efficiently even with slow internet connections.
- Test case 30: Test the performance of Google Maps with a large number of markers and data points.
Okay, we have created a test strategy. Now let’s move to test planning, and designing test cases.
Now it s a good time to think about the features we have in app. Summarize our functional and non-functional features. Think about use cases. Depending on it we will think about our testing approach, test methodologies.
- What kind of functionality our app has? It is used for planning functional testing.
- Will our app support several devices, OS version? If yes we need to plan Compatibility testing.
- Which languages are supported? Localization.
Let’s summarize types of testing in the scope. Of course we need to keep in mind the timelines. During 40 minutes we can plan everything, lets keep things high level.
In a web application: we have API and Web App, so in simple words we have backend and frontend. And communication happens let’s imagine via some API (let’s say REST API).
Let’s create separate plans for API, Web App and mobile testing, we also include performance testing (stress, load, scalability), localization testing, compatibility testing.
Do you want to me start high level first, then going into details, OR we can take one functionality and designing test cases for it?
QUESTIONS:
- Do we consume data through API? REST, GraphQL, microservice? Do we use API gateway to access APIs? Database - SQL, NoSQL?
- How the authentication is implemented?
- Do we use CDN?
- Third parties are used?
FEATURES:
- Authentication and authorization.
- Features: Search, …
- Test Database, to check if our data transformation are working correctly.
Test cases:
Web/Mobile UI High Level Features QUESTIONS:
- Do we cache data on mobile and web client sides?
FEATURES:
Test cases:
- how it will work if some ones call, OR internet switches of, OR when we change network.
Performance High Level Features To plan performance testing. We need to ask lots of questions.
- How many users does the product have? How many daily active users will we have? How many users would be concurrently using the service on average and at peak times? How many actions will each user do daily (READs and WRITEs)?
- What kind of regions are supported?
- What is the expected average latency for users to get the messages?
- Do we put limits for uses? Rate limiting, data size limit?
- What kind of availability do we expect? How many nines?
- Do we have any autoscaling?
Security High Level testing - Vulnerabilities
- Input validation: Ensure that all user input is properly validated and sanitized to prevent injection attacks. SQL injections testing. Code injection. Stack overflow. Wrong files extensions.
- Authentication and authorization: Implement secure authentication and access control mechanisms to prevent unauthorized access to sensitive data and functionality. Default/weak passwords.
- Session management: cookies, bypassing sessions
- Data encryption: Ensure that sensitive data is properly encrypted both in transit and at rest.
- Error handling and logging: stack traces
- We can use automatic checker to check the code: avoiding the use of hard-coded credentials and using secure libraries.
- more then 255 characters;
- !@#!##%;
- <body>;
- 12345;
- characters in the Unicode;
- spaces before and after the name.
- Integers: -1, 0, 1, 2, middle, max, max+1
- Security testing
- Test with valid inputs.
- Duplicate Check: Check for duplicate resources by attempting to create resources with identical data.
- Test with boundary values: It's important to test CRUD operations with boundary values. For example, if there is a limit on the number of characters that can be used for a field, it's essential to test with inputs that are at the limit or exceed it.
- Test with invalid inputs: Testing with invalid inputs is crucial for CRUD testing. For example, if a user tries to create or update a record with invalid data, the system should respond appropriately.
- Parameter Validation: Test the functionalities with different parameter scenarios, such as missing, empty, or null values, long strings, special symbols, and non-existing or non-required fields.
- Test with error handling in mind: Testing should be designed to ensure that the system handles errors correctly during CRUD operations. For example, if a record cannot be created due to an error, the system should provide an appropriate error message.
- Test with data integrity in mind: Data integrity is critical for CRUD operations, and testing should be designed to ensure that the system maintains data consistency during CRUD operations.
- Test with authorization in mind: Authorization is essential for CRUD operations, and testing should be designed to ensure that only authorized users can perform CRUD operations.
- Test with different user roles: CRUD operations should be tested with different user roles. For example, a user with administrative privileges should have access to all CRUD operations, while a regular user should have limited access.
- Response Validation: Validate the response status code, message, and data schema of the API responses.
- Method Validation: Test the API functionalities with different HTTP methods, such as GET, POST, PUT, PATCH, and DELETE.
