Test Design of 'OrangeHRM' module Part1

As per CemKaner

Writing a test case is complex art

After reading his article on ‘What a good test case is’
http://www.kaner.com/pdfs/GoodTest.pdf

A test case is a question which we ask of a program and when executed should return some information.

And what would that information be? Well it actually depends on the type of question we ask and the information we are seeking out of that program.

It could be :

• Seek defects - We look for defects in all interesting parts of product, looking for failures in the product that could expose defects.

• Maximize bug count - Focus could be on testing high risk areas and finding as many defects as we can instead of trying to achieve coverage.

• Block premature product release- Focus only on finding showstopper bugs.

• Help managers make ship/no ship decision-managers may want to know the coverage of testing.

• Assess conformance to specifications - Any claim made in the specifications is checked.

• Verify correctness of the product- It's impossible to test the product exhaustively, you can prove that the product is not correct by trying to achieve coverage while designing test cases but there will always be some cases which you didn't test and the product might fail in those conditions.To verify the product is correct best you can do is estimation of the probability of errors.

So a good testcase depends on how well it provides the information we are looking for.

And how do you design it?

People tend to create tests based on testing styles.Within black box testing there are 11 test styles:

• Function testing

• Domain testing

• Specification based testing

• Risk based testing

• Stress testing

• Regression testing

• User testing

• Scenario testing

• State model testing

• High volume automated tests

You could choose a combination of styles to write test cases.

So, for a scenario where aim is to find defects that the rest of the development group finds worth reporting, then one test case will be better than the other if

• More credible and real representative of the events more likely to be encountered by customer

• More useful for troubleshooting and thus easier to replicate

• More likely to help the tester, developer develop some insight into the problem

• Appropriately complex- Complexity in a test case is less desirable when a new feature has been launched as the build isn't yet stable.Running a complex case is more likely to fail in the first run thus preventing you from running the other cases within the suite of tests thereby preventing you from receiving any information about the product which you could have obtained otherwise.Thus its advisable to run simpler test cases at the beginning and then move onto complex ones as the build becomes more and more stable.

Lets put this knowledge to use while designing test case for OrangeHRM.

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.