Sprint Backlog for "Pay Bill - Web" (Customer Functionality)
Day 1: Sprint Backlog and Database Design (DDL)
On day one, the sprint backlog outlines the tasks for the customer to log in and pay their
electricity bills. The payment page will display key details such as the bill amount, total
payable amount, PG charges, and available payment modes (Debit/Credit). Customers
will have the option to proceed to the payment screen where they can input their card
details to complete the transaction. The database design includes tables to store
payment transactions, along with bill amounts and customer details. The backend will
handle payment requests and store transaction information.
Day 2: Mock UIs
The second day is dedicated to creating mock user interfaces for the payment page.
The screen will have a right-side section displaying the customer's name with a logout
button that ends the session. The top navigation bar will include options like Home,
Payments, Register Complaint, and Complaint Status. The payment page will feature
fields displaying the bill amount, total payable amount, PG charges, and payment
modes. Additionally, the Pay Now and Back to Home buttons will be placed at the
bottom of the screen. A separate mock UI will be designed for the credit card payment
screen, including fields for card number, cardholder name, expiry date, and CVV.
Day 3: First Integrated Screens
On day three, the UI is integrated with the backend to make the screens functional. The
payment page will display the bill details, and customers can proceed by clicking the
Pay Now button, which will lead them to the credit card details page. The backend
service will handle customer details, fetch bill information, and ensure the transaction
process is connected to the database. The Make Payment button will process the
payment, and the transaction details will be stored. Basic testing will ensure smooth
navigation between pages and that all payment fields are functional.
Day 4: Logger Implementation
On day four, logging is implemented to track the payment process. Logs will capture key
actions such as when a customer views their bill, proceeds to the payment screen, and
completes a transaction. The logs will also capture any errors during the payment
process, such as invalid card details or transaction failures. Each log entry will record
customer IDs, bill IDs, transaction statuses, and timestamps for auditing and debugging
purposes.
Day 5: JUnit Implementation
The final day focuses on implementing JUnit tests for the payment functionality. Tests
will be written to validate that the correct bill details are displayed for the customer and
that the payment process works correctly. JUnit tests will also cover edge cases like
invalid card numbers, expired cards, and failed transactions. The tests will ensure that
once a payment is successfully made, the transaction details are stored in the database
and available for the customer to download.
Sprint Backlog for "Add Bill" (Admin Functionality)
Day 1: Sprint Backlog and Database Design (DDL)
The sprint starts by outlining the tasks for the admin to add bills for customers. Admins
should be able to capture the following details: consumer ID, units used, start date, end
date, disconnection date, and bill amount. The system should auto-generate the bill ID.
On this day, the database design is prepared to store these details. The bills table will
include fields like consumer ID, bill amount, and the date fields mentioned above. We
also specify how the backend will integrate with the UI to allow admins to input this data.
Day 2: Mock UIs
On the second day, mock user interfaces are designed for the admin to add a bill for a
customer. The UI includes input fields for the details to be captured—consumer ID, units
used, start and end dates, disconnection date, and bill amount. There will be a button to
submit the information, triggering the auto-generation of a bill ID. The mock-up provides
a clear flow for the admin to efficiently add bills into the system.
Day 3: First Integrated Screens
By day three, the UI is integrated with the backend to make the "Add Bill" functionality
operational. The admin can input the required details into the form, and the backend will
auto-generate the bill ID before saving the data to the database. The form connects to
the backend services, ensuring that the bill information is properly captured and stored.
Basic testing ensures that the data flow from the form to the database works
seamlessly.
Day 4: Logger Implementation
On the fourth day, logging is added to track the addition of bills by admins. Each time a
bill is added, a log will record the consumer ID, bill ID, and timestamp of when the bill
was created. This ensures that bill additions are traceable and can be monitored for
auditing purposes. Error logging is also included for cases where invalid data is entered
or the bill fails to be added.
Day 5: JUnit Implementation
The final day focuses on implementing JUnit tests to validate the functionality of the
"Add Bill" feature. Tests ensure that all required fields are correctly captured and that
the bill ID is auto-generated. The DAO and service layers are also tested to confirm
proper interaction with the database, ensuring that bills are accurately stored. Error
cases, such as missing data or invalid inputs, are covered by test cases.
Sprint Backlog for "Search Bill" (Admin Functionality)
Day 1: Sprint Backlog and Database Design (DDL)
On the first day, tasks for searching bills are outlined. Admins should be able to search
for bills by consumer ID and see the following details: consumer ID, consumer name,
start date, end date, bill amount, and payment status. The database design is confirmed
to ensure that these fields are available for querying. The bills table will contain fields for
payment status, bill amount, and consumer details. The connection between the UI and
backend is planned so admins can search bills based on the consumer ID.
Day 2: Mock UIs
Mock interfaces for the "Search Bill" functionality are created on the second day. The
admin will have an input field to enter the consumer ID, and the results will display the
bill details, including payment status and bill amount. Buttons or filters to refine the
search results will also be considered in the design. The mock UI provides a clear
layout for displaying search results efficiently.
Day 3: First Integrated Screens
On day three, the UI for searching bills is integrated with the backend, enabling the
admin to enter a consumer ID and retrieve the related bill details from the database.
The search functionality is connected to the backend service that queries the bills table
and returns the results in the UI. Basic testing is conducted to ensure that the search
function retrieves the correct data and displays it properly in the interface.
Day 4: Logger Implementation
Day four is focused on logging for the search functionality. Each time a bill search is
performed, logs will capture the admin performing the search, the consumer ID, and the
results returned. This ensures traceability of bill searches and provides a record of
system usage. Errors, such as invalid consumer IDs or failed searches, will also be
logged to track any issues.
Day 5: JUnit Implementation
The final day focuses on implementing JUnit tests for the "Search Bill" functionality.
Tests ensure that the search feature retrieves the correct bill details based on the
consumer ID. The tests also cover edge cases, such as invalid consumer IDs, to ensure
proper error handling. Tests for the DAO and service layers ensure the correct
interaction between the frontend, backend, and database.
Sprint Backlog for "View Bill History" (Admin Functionality)
Day 1: Sprint Backlog and Database Design (DDL)
On the first day, the sprint backlog outlines the tasks for viewing a customer's bill
history. Admins should be able to view all past bills for a customer, displaying details like
consumer ID, consumer name, start date, end date, bill amount, and payment status.
The database is designed to store these fields in the bills table, and the backend is
prepared to query the bill history for a given consumer ID.
Day 2: Mock UIs
Day two is dedicated to creating mock UIs for displaying bill history. The admin interface
will feature a search function where they can enter a consumer ID and retrieve the bill
history. The results will be displayed in a table format, showing multiple bills with details
like payment status and bill amount. The UI design ensures that admins can view and
manage bill history easily.
Day 3: First Integrated Screens
By day three, the "View Bill History" screens are integrated with the backend, allowing
admins to search for and view all past bills for a customer. The backend queries the
database to retrieve the bill history, and the UI displays it in a clear and concise manner.
Testing is conducted to ensure that the bill history is displayed correctly and that all
relevant details are included.
Day 4: Logger Implementation
Logging is added on the fourth day to track the usage of the "View Bill History" feature.
Each time an admin views a customer's bill history, a log entry is made to record the
consumer ID and the admin's details. Any errors, such as invalid consumer IDs or failed
queries, will also be logged for troubleshooting purposes.
Day 5: JUnit Implementation
On the final day, JUnit tests are implemented to validate the "View Bill History"
functionality. Tests ensure that the correct bill history is retrieved and displayed for each
consumer ID. The DAO and service layers are tested to confirm the proper interaction
with the database and the accuracy of the retrieved data. Error handling for invalid IDs
or missing data is also covered in the test cases.
### **Sprint Backlog for "View Bill - Web" (Customer Functionality)**
---
**Day 1: Sprint Backlog and Database Design (DDL)**
On the first day, the tasks for the **View Bill** functionality are outlined. After logging in
using their **user ID** and **password**, customers will be able to see the home page
with options like **Pay Bill**, **Register Complaint**, and **Complaint Status** in the top
menu. The system should allow customers to select and view their electricity bills,
calculate the total amount based on the selected bills, and proceed to the payment
screen. The database will store the **customer bills**, including details such as bill ID,
due amount, and status. The backend will be responsible for fetching and displaying this
data when the customer logs in.
---
**Day 2: Mock UIs**
On day two, mock UIs are designed to outline how customers will interact with the
**View Bill** page. The home page will display a **welcome message** with the
customer's name, along with a **logout** button at the top right. The top bar will have
menu options for **Home**, **Pay Bill**, **Register Complaint**, and **Complaint
Status**, which will navigate to the respective pages. In the **Pay Bill** section, the
customer can view multiple bills with checkboxes to select them, and the total payable
amount will update dynamically based on the selections. A **Proceed to Pay** button
will be placed at the bottom, allowing customers to move to the payment page.
---
**Day 3: First Integrated Screens**
On the third day, the **View Bill** page is integrated with the backend to make the
screens functional. The system will fetch the customer's bills from the database upon
login and display them on the screen. Customers can select which bills they want to
pay, and the total amount will update based on their selections. If no bills are selected,
the total will reflect a value of zero. Upon clicking the **Proceed to Pay** button, the
customer is redirected to the **payment page**. The backend ensures that the selected
bills and the calculated total are passed to the payment system. Basic testing is done to
verify that the correct bills are displayed and selected amounts are updated properly.
---
**Day 4: Logger Implementation**
Logging is added on day four to track the customer's interactions with the **View Bill**
feature. Logs will record when a customer logs in, views their bills, selects bills to pay,
and proceeds to the payment screen. If there are any errors, such as failed data
retrieval or issues with bill selection, these will be logged as well. Each log will include
details such as the **customer ID**, **bill IDs**, and **timestamps**, providing a clear
record of customer actions.
---
**Day 5: JUnit Implementation**
On the final day, **JUnit tests** are implemented to validate the functionality of the
**View Bill** page. Tests ensure that the customer's bills are correctly fetched from the
database and displayed, and that the total amount updates dynamically based on
selected bills. Tests will also verify that the system correctly redirects to the **payment
screen** with the appropriate bill details when the **Proceed to Pay** button is clicked.
Error scenarios, such as invalid customer data or missing bills, will be covered in the
test cases.
---
### **Summary**
At the end of the sprint, the **View Bill** functionality will allow customers to log in, view
their electricity bills, and select which bills to pay. The system will calculate the total
payable amount dynamically and redirect the customer to the payment screen when
they choose to proceed. The system will include logging for tracking actions and JUnit
tests to ensure that the feature works reliably and handles errors properly.
7 View Customer Complaints - WebUS007 As a customer service
representative, I want to view customer complaints After login to the system with
username and password, service representative can view the following information in
the screen;
- At the right side , Welcome <username>, Logout button<onclicking it should be
logged out>
- Top menu bar should have following options- Home, Active Complaint,Complaint
Status and Feedback
1)Home - onclicking it redirect to the same page with total complaints under
resolved, open, assigned to specific teams displayed in form of table.
2)Active Complaints - On clicking should be redirected to Feedback Screen
3)Complaint Status - On clicking should be navigated to Complaint Status Screen
4)Feedback - On clicking should be redirected to Feedback Screen
- In Active Complaints page, representative should be able to display the number of
open complaints alongwith the complaints listed in a table.
- It should also have a search bar where the representative can filter complaints based
on customer name or date.
- Use web concepts for the necessary actions.
Sprint Backlog for Register and Login
Day 1: Sprint Backlog and DDL
On the first day, we focused on creating the Sprint Backlog for the User Registration
and Login feature.
This included defining the user stories, tasks, and acceptance criteria required for the
development
process. Additionally, we worked on the Data Definition Language (DDL) to design and
implement the
database schema. This involved creating tables for storing user credentials, profile
information, and
login activity to ensure all necessary data can be captured effectively.
Day 2: Mock UI's
On the second day, we focused on designing mock user interfaces (UIs) for the User
Registration and
the user Login feature. We developed visual layouts to illustrate how the application
would look and
operate, with an emphasis on user experience. This involved creating forms for users to
register their
accounts, as well as screens for logging in and managing their profiles. The mock UIs
were crucial in
gathering input and ensuring that the design aligns with user requirements before
moving forward with
the development phase.
Day 3: First Integrated Screens
On the third day, we started integrating the mock UIs for the User Registration and
Login. This included
developing the initial screens for user sign-up and login, while linking the front-end with
the back-end
to ensure data is captured and displayed properly. The integration is key to verifying a
smooth user
experience across the registration and login process.
Day 4: Logger Implementation
On the fourth day, we implemented a logging system for the User Registration and
Login feature. This
involved tracking key user actions, like account creation and login attempts, to assist
with debugging
and maintaining the system. Logging helps improve transparency and makes future
troubleshooting
easier.
Day 5: JUnit Implementation
On the final day of the sprint, our focus shifted to writing unit tests using JUnit to
validate the User
Registration and Login feature. Unit testing is a critical step in ensuring the robustness
and reliability
of the application. We created tests for different components, including the registration
form validation,
user authentication logic, and error handling during login attempts. These tests were
designed to
simulate various scenarios, such as successful user registration, failed login attempts
due to incorrect
credentials, and handling edge cases like duplicate registrations. By thoroughly testing
these
components, we aimed to catch potential issues early in the development cycle. This
helps ensure that
the registration and login features perform as expected under different conditions and
are less prone to
bugs or failures when deployed. Implementing unit tests also contributes to the overall
maintainability
of the code, making future updates and improvements easier to manage.
This structured approach over the five days enabled us to make substantial progress on
the User
Registration and Login feature, establishing a strong foundation for future
enhancements. By following
a systematic process, we ensured that each phase—from planning and design to
integration and
testing—was thoroughly addressed, providing a reliable base for further development.
Sprint Backlog for Register Complaint/Service
Day 1: Sprint Backlog and DDL
On the first day, we focused on creating the Sprint Backlog for the Register
Complaint/Service feature. This included defining the user stories, tasks, and
acceptance criteria necessary for the development process. Additionally, we worked
on the Data Definition Language (DDL) to design and implement the database
schema. This involved creating tables for storing complaint details, user information,
and service types to ensure that all necessary data can be captured effectively.
Day 2: Mock UI's
The second day was dedicated to designing mock user interfaces (UIs) for the
Register Complaint/Service feature. We created visual representations of how the
application would look and function, focusing on the user experience. This included
designing forms for users to submit their complaints, as well as screens for
administrators to review and manage complaints. The mock UIs were essential for
gathering feedback and ensuring that the layout meets user needs before
development begins.
Day 3: First Integrated Screens
On the third day, we began integrating the mock UIs into our application. This
involved developing the first set of screens that allow users to submit complaints and
view their statuses. We focused on connecting the front-end components with the
back-end services to ensure that data can be captured and displayed correctly. This
integration is crucial for validating that the user journey flows smoothly from one
screen to another.
Day 4: Logger Implementation
The fourth day was centered around implementing a logging mechanism for the
application. We set up logging to track user actions and system events, which is vital
for debugging and maintaining the application. This involved deciding what
information to log, such as complaint submissions and user interactions, to enhance
transparency and facilitate future troubleshooting.
Day 5: JUnit Implementation
On the final day of the sprint, we focused on writing unit tests using JUnit. This was
an essential step to ensure the reliability of the Register Complaint/Service feature.
We created tests for various components, including the complaint submission logic
and service integrations. By validating each component through unit tests, we can
catch issues early and ensure that the application behaves as expected under
different scenarios.
This structured approach over the five days allowed us to make significant progress
on the Register Complaint/Service feature, setting a solid foundation for future
development.
