As of 2020, the software development industry keeps changing more than any other industry. Programming languages keep changing. Old programming languages like Java, C++, PHP getting new language features and syntax. For example, within the last 2 years, Java had 4 major updates while it took 5 years to release Java 7 after version 6. We as software developers would like to try new technologies. That is what makes us exciting and keep moving. Especially start-up companies always try to keep up with the new technologies and try them. Because unlike corporates start-up does not huge organizational structure.
Do you really need microservices?
My personal experience is a lot of small startup companies trying to adopt microservices architecture to their project just because it is the “NEW TREND”. If you ever google the word “microservices” you would lot of diagrams like this.
According to this diagram each hexagon is small web service with their own database. This looks simple. But the reality is far different from this diagram.
This is the microservices architecture diagram of Netflix. It has around 700 microservices running.
When you start with microservices architecture. You might have a user service that is responsible for handling user registration, login, and other user account-related activities. Then you will have an order service to handle user’s orders. So user order services probably need to know about the user details. Then you need a way to get those details from the user service. To accommodate that you might add an endpoint to the user service return user details and then order service can invoke that endpoint. When you developing in your local development environment you might run these 2 services in 2 different ports. So you know how to access each other. But in the cloud, you might run these services in 2 different instances. They have to discover each in the cloud environment. There are a lot of ways to do service discovery in microservices. You might get service discovery services by default depending on the platform you are using. But service discovery is another critical aspect you need to consider when developing microservices.
Another thing your services might go offline for some reasons. Then your other services that depend on the unavailable service should know how to handle the situation. So you might use Circuit Breaker to handle these situations. And then you need to decouple services as much as you can to avoid dependency between services. So you might use some type of messaging service or event bus to handle messages between services. Then you need to manage multiple databases that are being used by your services.
So what do I suggest?
Starting a microservices project with 2 to 3 developers is not the best idea. Because those developers need to lay the groundwork before start developing the functionalities. My opinion is for startup companies up and running project is far more important than the technology it uses. Being a startup company meaning is trying new ideas and projects. The reality is most of the projects won’t be successful. So the important thing is to get an up and running project and check the user’s feedback and based on that improve the architecture and technologies. Companies that use microservices like Netflix have thousands of employees so comparing a small startup with Netflix and decide to go with the technologies they use can be problematic.
Finally, if you have a well-designed monolithic system it much easier to migrate to microservices. If you think the project cannot be designed properly with a monolithic architecture. First, you need to figure out how to do that. Because If somebody cannot design a proper monolithic system. s/he definitely cannot design a microservices system.
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.
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