How I would plan test for OrangeHRM module

It is an absolute must to create a plan for any module that you intend to test.The document could be made in word and may/may not be formal depending on the organization and the project being tested.But the key features of such a document should be to lay out the testing approach (i.e. the strategy, types of testing, test environment and test data involved).Most importantly it should also list the various assumptions that would be undertaken during the testing process as well as the risks involved and  mitigation plan for addressing the same should any of the risks happen.Having such a plan in place not only provides a clear vision and a strategy to the testers involved but also provides clarity to project stakeholders and raises their confidence in the quality of product being released.You may also find it useful to revisit the test plans post release to identify if any strategy changes could be made to avoid any of the post release production issues or to ensure a smooth delivery.For instance in one of the projects in my testing career we realized GUI testing of the HTML templates if done early before these are released to the development team could avoid a lot of  later stage issues which sometimes slip through the development phase and end up being neglected and ultimately marked as cosmetic / minor to be fixed in next release.We decided to incorporate this change in our plan and to start GUI testing even before coding actually starts.Below is the test plan for testing of  'MyInfo' Module.Refer: https://docs.google.com/document/d/1A7GbxWdkij7BAwoVJsLhr26f8Thx3STXQTXunk85CtA/edit?usp=sharing

Walkthrough of OrangeHRM SRS

An important technique prior to Test planning is SRS review and walk through to identify testable and any missing requirements.

I have always reviewed requirement documents and participated in walk through meetings with sprint stakeholders. What I would generally do is make note of missing/unclear requirements before Sprint planning meeting on Google docs or against the SRS hard copy.

Recently on softwaretestinghelp.com there was an article suggesting that it's always better to maintain a SRS analysis template.This document doesn't need to be very complicated and it's always best if done manually.

Pros of maintaining such a template:

• Helps identify testable requirements

• Uncovers missing requirement and is cost effective

• Ensures no requirement is missed during testing in other words ensuring maximum test coverage.

• This could be used to create Requirement Traceability Matrix later on.

• Makes one think on the number of test cases this module would involve in all and thus helps to calculate estimation basis the complexity of project.

Below is the template created after analysis of OrangeHRM 'Personal details' SRS.

https://docs.google.com/spreadsheets/d/1HBOjtSSwQWulk65dU3QVvUL-aJk3SKXX6mMc1LosUNE/edit?usp=sharing

Testing Process for OrangeHRM

The project which I chose for testing is a HR management software by OrangeHRM.
This project is available as part of the https://www.softwaretestinghelp.com/free-online-software-testing-qa-training-course/. Please refer the website for details on how to access and for the business requirements.
The below is my approach on how to test the project.
There are 3 versions of the software available:Open Source, Enterprise and Professional.
The various modules available in the software:

1. System Administration and User roles
2. Personnel Information Management
3. Leave/TimeOff Management
4. Attendance Management
5. Recruitment & Onboarding
6. Performance and Training
7. Travel and expense tracker
8. Disciplinary tracking etc..

As in the scope provided in the website and the software specifications made available, I am focusing on only the 'Personnel Information module' and within that only on the 'Personal Details' section.

Let's also assume Agile-Scrum methodology is being practiced for the development of this project.Agile is an iterative development approach and Scrum is a popular Agile framework with the aim of releasing high quality software faster preferably 2-4 weeks or even 1 week.
Ideally in a scrum project you will have a scrum team consisting of the product owner, scrum master and a team of QA and Dev working on this.But, since this is a practice project , so we won't have a team. Also, instead of daily EOD meets to discuss on sprint status,I will be updating my sprint status here.
Sprint Activities:

• Sprint Planning :  Module:

            (MyInfo)Personal Details section(Viewing of personal data and editing)
            Sprint start date: Today
            Sprint end date: 1 week (Saturday - 5th July)

• Sprint Backlog from testing perspective: 

            SRS Review and identifying testable scenarios
            Testplan creation - tomorrow EOD
            Test case preparation and Design(Test environment setup) - 2 days
            Testing and Bug Reporting,Test Summary Report-1 day
            Regression Testing - 1 day

Next up SRS analysis and identifying testable requirements.