Software QA for a Small Organization

Quality assurance is a crucial process in software development that can never be ignored or concern as a peripheral task. But in many small-scale organizations, QA doesn’t treat as a significant function in the development process. There may be excusable causes like a limited number of human and physical resources, financial constraints, subjected to unrealistic deadlines, paucity of experienced experts, etc. What are the consequences that may be occurred if not follow an applicable quality assurance plan? Well, the reputation of your start-up or small-scale company might be ended up in a nightmare! or valuable clients will compel to drop out of your service, then find new development teams. To emerge as an unblemished software service provider you have to allocate an adequate budget for QA activities. 

What if outsourcing? Mmm…can you outsource all the QA activities? Simply you can outsource some of the testing activities! Thereafter the company missing all the resources and experience that can be gained by doing the testing themselves. Sometimes you have to hand over the testing to a third-party organization or certified firm when it needs specialized testing services like penetration testing! But before that, your firm has to finalize the functional testing as well as essential non-functional testing on your own. Usually, a company is outsourcing the processes which don’t belong to their main business activity. If you’re are a software development firm and trying to outsource QA / Testing activities, then you must be misleading. Especially if you are a small-scale one! 

It is not practical and be worth performing all of the quality assurance activities for a project, instead should select the appropriate tasks which may suitable for it. 

1. Shut the Stable Door BEFORE the Horse Escape (Defect Prevention):

It needs some expertise in various technologies and previous experience on similar projects. It is costly to remove the defects that can be found in the later stages in the SDLC than identifying them and recovering in pre-stages. Identify or guess the issues and take necessary actions to prevent those before the occurrence is an excellent practice in software quality assurance. Small firms do not maintain proper documentation due to the lack of human resources. Even though it doesn’t need to maintain heavy, ISO standard documents, it is better to maintain at least the following documents in the requirements stage to avoid the requirement mismatches later on. 

A. Requirement Clarity Index (RCI) – Express the requirements in detail, Indicate the understandable percentage.

B. Requirement Traceability Matrix – Trace the system requirements with test cases. This will ensure 100% test coverage & indicates the requirement missing.

I emphasize maintaining at least above mentioned 2 documents within the lifecycle to avoid the inconveniences (not only the defects) that may be occurred in later.

2. Double Check to Avoid Mistakes (Reviews):

QA Engineer or corresponding Developer has to REVIEW all the design documents against the client requirements. Because of the limited number of human resources, this may appear as a time-consuming task from the point of view of existing team members. It should not hold multiple hours of formal meetings for these reviews. Instead, QAE or Lead Developer may conduct an informal meeting with the stakeholders. It is better to rectify the issues at the same time if those can be resolved instantly. 

A. Review the high-level architectural design document/s, diagrams.

B. Review the data design documents (ex: ERD)

C. Review the object-oriented design diagrams (ex: Class, Sequence, State Transition)

These documents must be kept in a secured repository that is related to the project as well as pointed out in the traceability matrix document. Maintaining proper documentation is mandatory from the quality assurance perspective. Since the company is a small one, these documents might not comply with the ISO standards which can be a tolerable thing. 

3. Prevent While Batting (Code Reviews, Best Practices, TDD):

This is another compulsory task that is missed by a lot of small organizations due to the lack of time & resources. Code reviews will expose the errors that may cause faults in the later stages. A lot of them may be found in the testing stage as bugs/issues, but still could have been prevented, if done with the proper reviews.

Simple examples: 

A. Expected / Actual results mismatching in the boundary values, sometimes equivalent parts as well. These could be easily detected while doing the code reviews instead of letting them find in the functional testing.

B. Issues in the SQL statements, especially in the update queries when changing the values in the database tables.

C. Calculations issues, especially in the reports or in the formulas

D. Authorization issues after the authentication happen

E. Data validation issues

Code review meetings shall be conducted at least once a month for each project to check whether all are following the coding compliances. If found any mismatches or weaknesses in the source code they must be rectified by the developers at least before the next review meeting. Although it takes more time, it is better to encourage the developers to consider the system’s maintainability when they are doing the coding.

4. Exploratory Testing

Exploratory testing is an experienced-based testing technique which mostly used in Agile environments where test design and test execution happen simultaneously. Testers use their intuition on testing to explore the system at the testing stage instead of following pre-defined test cases. Yes, it needs experienced and responsible resources to do this since it’s more tends to follow the extraordinary scenarios and find the bugs within the system under test. This is more suitable when the requirements are being changed rapidly or the clear requirements are not available. Also, the testing time is very limited within the given sprint/iteration that forces to test quickly.

It is the responsibility of the QAE to collaboratively work with the developers when designing test cases. It may expose the issues that may be occurred in the production and allow developers to take necessary precautions. 

5. Defect Tracking and Defect Reviewing

Using a defect tracking tool is compulsory even if your team has 3,4 people. Also, everyone in the team must have the access to them. Although the main purpose of these tools is to track the issues with the necessary information, these can be used to reduce the defects in the forthcoming development iterations. Not all the issues, at least critical issues must be reviewed by the developers & testers, then take necessary steps to not to happen similar issues in the future iterations or the projects.

For an instance, if found a Manufacturer based or OS-based issue in a mobile app, better to list the issue in a checklist and make use of that checklist for future developments. Don’t let the testers detect it again!!! 

6. Finally, the Mindset of all

Company ownership should cultivate a ‘Quality Mindedness’ among all the team members from their appointment date, thereby convincing them to develop a quality product over a simply working product. Monitor the SDLC and bring forth a ‘Bug-Free’ product is not only a responsibility of the QA people but the developers as well. 

One good practice is pair programming where one developer is coding and a peer is reviewing, then exchange their roles. Trainees or junior developers should guide to inspect the source code that was written by the senior developers and make use of their good methodologies.

Well, don’t forget “Quality means doing it right when no one is looking” – Henry Ford

At Treinetic we follow a rigorous QA process to make sure all the products that we engineer are up to the best quality. Reach us today, and let’s discuss how we can help you to make a quality product by realizing your concept