SupraDigit Solutions

When I was a quality manager in my earlier job in an MNC (Multi-National Company), a lot of my team members were quite misinformed about the “Power of Verification” in a software development process. I went through a lot of reflection around my own experience working on multiple projects related to doing “software verification” exercises. I gained profound understanding of how organizations can gain immense benefit just by understanding the true power of this activity (if done correctly). For the uninitiated, let me give a brief understanding about what “Verification” means. As part of ensuring quality of any software, the whole development process can be split into 2 simple parts – Verification & Validation To put this simply, “Verification” is always done before software code is developed & “Validation” is always done post development of software code. A “Verification” activity means, doing detailed analysis and reviews for – Customer Requirements Software Architectur

It is a capital mistake to theorize before one has data. One begins to twist facts to suit theories, instead of theories to suit facts. -           A Scandal in Bohemia - from Sherlock Holmes series of Arthur Conan Doyle Yeah… I understand… The IT development, software testers (and other teams) may want to emphasize their importance as well here, but trust me… I am not comparing the Business Analysts job across teams! 😊 Below are few of the most important work attributes for a business analyst (software development): Networking Capabilities – The ability to establish connects with the customer (first), management and the development team members. o    Connect with customers to establish trust in organizations capabilities o    Connect with team members to understand best practices and common features, which can be explained to a customer, to again establish greater amount of trust. Requirements Elicitation and Negotiation  – The ability to elicit requirements with limited

"Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”— Steve Jobs Everybody loves to avoid a disaster, but there is a “proactive” effort to do activities that can prevent a disaster from happening. Most of the executives do not want to “get involved” in such “proactive” efforts, simply due to the love of fixing urgencies Or having a mindset that it’s not important.   I remember, when once I was working with the Quality Assurance team on a product. The development team simply refused to spend efforts on the most essential “unit testing” for their developed components! The intent was to release the software to the QA team as soon as possible and focus more on so-called “core development”. Over the years, looking at multitude of projects failing in-spite of highly experienced resources, reasonable time and the intent, I have uncovered that, prevention is the “Most Important” and “Ignored” part of software development. Why should we

A Test Strategy is created to guide all teams on steps to achieve software quality objectives. With software companies adopting agile practices in a big way, an effective Test Strategy becomes even more important with iterative / sprint-based application development. A test strategy being a live document, should ideally plan to integrate the business, development, testing, and management teams, define the quality objectives for the intended application and chart-out a path on how all the teams can help achieve these. The test owner and the team can build an effective test strategy with these 4 best-practices: A)   Focus on Prevention – Helps avoid major issues and rework on projects. ü Prioritize requirements and business rules. ü   Communicate changes in priorities immediately and effectively to important project stakeholders. ü Strictly review and implement common require