Welcome to Innominds Blog
Enjoy our insights and engage with us!

Top 5 Ways to Develop Quality Solutions and Nip Bugs at the Root

How to ensure and develop quality solutions and nip the bugs at the root is an aft discussed problem across product and service companies. Below, is my take on the processes that needs to be followed to ensure quality.

  1. 1. Write Concise and Effective Use Case Documents with Expected Results and Edge Cases to Test

    How to prepare Effective Use-cases to Test ? 

    Every use case should contain:

    • A good name/title, which gives a clear indication of what the use case is all about
    • The goal and description should be clearly mentioned
    • The use case should contain details such as actors, preconditions, postconditions, and triggers
    • It should have the main flow or the steps
    • Any relations to other use cases. For example included or extended use cases
    • Use case should also mention the alternate or exceptions flow

    Sometimes, one may not have them and they may not be formatted correctly or a Business Analyst isn’t available to document it. This should, however, not stop the Developers from writing and getting them validated from the Product Owner. Some form of use case documentation is better than none.

  2. 2. Use Good Sample Data for Testing

    Sample data is a subset of the actual data the software may gather when in production. One of the most important factors that determine if your software product is working or not is when you use great sample data. If you have wrong sample data or data that is inaccurately designed, you will almost certainly get misleading results. Using data that contains words like Test1, Test2, etc., can cause confusion and lead to a high margin of errors and lower confidence levels in your product. Test data should be as realistic as possible, including using real-life scenarios. For example names should not be containing words like “Test.” It should be a real name like Adam or Eve, etc. Similarly, age should be within 0-100 years.

    Your test details should contain positive data, as well as, negative data, which allows for positive testing apart from negative testing. Negative testing is important because it allows us to know how the product handles unusual, extreme, exceptional or unexpected input. Test data should be able to handle white box, performance, security, and black box testing.

    Importantly, your black box test data should include:

    • No data test conditions
    • Valid data set
    • Invalid data set
    • Illegal data format
    • Boundary conditions data set, and
    • Performance, load, and stress testing data set

    Cost of Fixing Bugs

    On June 4, 1996, Arianespace’s Ariane 5 rocket reused working software from its predecessor, the Ariane 4. Unfortunately, the Ariane 5’s bigger and faster engines got battered by a bug that was not found in previous models. Thirty-six seconds into its maiden launch, rocket’s engineers hit the self destructive button following numerous computer failures. At the core, the software had tried to pack a 64-bit number into a 16-bit range. The resulting runoff conditions crashed both the primary and backup computers (both running the same software). At a cost of nearly $8 Billion to develop Ariane 5, and an additional $500 Million satellite payload when it exploded, It sure was one of the worlds most expensive software bug.

    As the adage goes, “Prevention is better than a cure,” it always makes sense to catch the bug at its root. Below is a simple representation of the software bug costs. This popular proverb certainly holds true when it comes to bugs or security issues identified during the SDLC. It is more cost effective and efficient to fix bugs in the earlier stages of the the development process rather than later ones. The cost multiplies exponentially as the software moves advances in the SDLC.

    Cost of Bug Fixing in SDLC
  3. 3. Ensure Good UI/UX Design

    Design is not just about what the product looks or feels like but is also about how it works. A lot of people can be confused by the idea that good design simply means that it looks pretty. However, beauty is just one of the aspects of good design. You should make sure that all designs are not just beautiful but functional, too.

    So, to fall under the bracket of a good design, the following parameters should be present:

    • Clear and concise visual hierarchy
    • Aesthetically pleasing elements with proper balance, alignment and contrast on the screen bringing the focus of the user to the required functionality
    • Useful functionality without overloading
    • Simple design or “less is more” concept

    Good design fills the gap between business goals and user needs. In order to fill this gap, a process must be followed. The process takes into consideration the best practices of User Experience (UX) and usability guidelines to get the desired results. It is not about being functional or usable.

    Good design is not about designing the UX or the UI, it's also about using proper naming conventions for the different menu items and designing the icons associated with these menu items.

  4. 4. Documentation

    Be meticulous about documentation. Always ensure you have the proper tools for documentation like a WIKI. Documentation helps in scripting your team's behavior in a certain way, especially if you have a distributed team.

    It is very important that there is a place where your team can find what they need without waiting for other members, who are in different time zones, to come online and answer their questions.

    Some of the various types of documentations are as follows:

    • Requirements – Use Case documents, sample hard copy scans or documents, etc.
    • Architecture/Design Documents  Overview of software including relations to an environment and construction principles to be used in the design of software components Documents Design for Testing & Bug Fixing
    • Technical Documentation  Documentation of code, test cases, algorithms, interfaces and APIs Technical services Documentation for review & Testing
    • End-user Documentation  Manuals for different users
    • Marketing Documentation  How to market the product and analysis of the market demand
  5. 5. Code Review

    Code_review_img

    Code review is the most commonly used process for validating the design and features implementation. It helps to maintain consistency between multiple developers, design and implementation styles across many team members and various projects on which, companies work.

    There are two types of code review, peer review and external review.
    Good code reviewers should look for the following:

    • Feature Completion – Code should meet the requirements
    • Potential Side Effects  Code should not cause side effects on other features
    • Readability and Maintenance – Code should be readable and not too complicated for a new joiner
    • Consistency of Code – Code should be consistent across the team and company style
    • Performance – Optimized code
    • Exception Handling – Code should be checked for bad inputs and all exceptions are handled
    • Simplicity – Code should be simple and clear
    • Reuse of Existing Code as Much as Possible  Code should not be repeated at any cost
    • Availability of Enough Test Cases  Code should have enough test cases to test all the possible execution scenarios

    Code reviews enable time off because it allows sharing of knowledge across the team so that any team member can take up the reins and continue steering the ship. It also mentors newer and better engineers. Every so often, teams have concealed information/knowledge within the code that emerges during code review. Newer members, with fresh eyes, discover gnarly, time-plagued areas of the code base that need a new perspective.

    Notice Bug Count after the code review

    Based on an analysis on an internal Innominds project, you will notice that the bug count has reduced drastically after a code review.

    Bonus - Combined Engineering: Make Developers Multi-Skilled

    One of the hottest new paradigms in product companies is the concept of Combined Engineering. It states that there is no specific roles for each member of the team. Every member will take turns doing different jobs at different times (Sprints). The member would be a Developer for one sprint and a tester writing automation test code in the next would be a DevOps Engineer.

    Developers should test the application along with the Testers as much as possible and this should happen not only just at the time of release but also at the time of feature development. Combined Engineering is a new perspective to agile execution. In a typical software product lifecycle, people with multiple rules and different skills are involved. Development of the product involves UI/Middle Tier/Backend APIs/DB Developers, Testers, Build/DevOps, and Project/Program/Product Managers among others. Each member of the team has individual goals and targets. Due to the lack of a unified vision (and the lack of collaboration across people in different roles) projects often fail to meet the desired schedule and quality. Releasing this, many product companies have proactively taken steps to tackle this problem and are gradually shifting to Combined Engineering.

    Combined Engineering requires the following:

    Developer as a multi-skilled person
    • The same Developer should be multi-skilled to write code for UI or Middle Tier/Backend or DB, UI test automation code and build script automation code, among other tasks. Ultimately, everything is code!
    • Every sprint end should have automated tests run at each level to ensure the desired functional/non-functional coverage
    • Rotation of roles for every sprint. For e.g., in one sprint he/she is a UI Developer and focuses on writing code for UI feature development and the next sprint they focus on building automation for testing the feature. In the next sprint, they work on DevOps updating the build scripts and so on and so forth
    • We, thus, move away from specialized roles like Testers, Developers or Build Engineers and everyone works under the same title - Developer

    What Combined Engineering really means is that the specific role does not go away. Someone still has to do testing (maybe through writing effective automation tests and executing them manually/automatically). However, the multiple roles are handled by the same person at different times allowing you to have multi-skilled ‘Developers.’

Conclusion

Over the years, Innominds has helped build many successful software products for its customers.  The acquired experience has translated into many insightful gains that have been put into practice and some of which have been documented above. If practiced diligently, they would help build excellent and well-tested software products.

About Innominds

Innominds is a leading Digital Transformation and Product Engineering company headquartered in San Jose, CA. It offers co-creation services to enterprises for building solutions/products utilizing digital technologies focused on Devices, Apps, and Analytics. Innominds builds better outcomes securely for its clients through reliable advanced technologies like IoT, Blockchain, Big Data, Artificial Intelligence, DevOps and Enterprise Mobility among others. From idea to commercialization, we strive to build convergent solutions that help our clients grow their business and realize their market vision.

Topics: Product Engineering

Pradeep Chakravarti Gudipati

Pradeep Chakravarti Gudipati

Senior Technical Manager - Software Engineering

Subscribe to Email Updates

Authors

Show More

Recent Posts