How can you create a culture of quality in SDLC testing?

Any thing that performs the job required and expected by the customer, is supposed to be the quality goal. And the metrics MUST be translated accordingly. Here are my two cents on this topic. There is a general misconception that each quality product has to have any high-end latest tech. This is making even the simplest of the products complicated for nothing. I believe that simple , to the point, and de-cluttered products provide a better sense of quality than anything that has any un-necessary AI or ML involved. If it suits the customer it is should be considered up to the mark. We can suggest enhancements but never impose them.

In my experience, defining quality and implementing measures in the beginning is of utmost importance. Then, we can assess the quality of the work after the first iteration and decide on any necessary adjustments in the approach or processes before proceeding to the second iteration. This process can be repeated after each milestone to ensure that the overall software or product is delivered at the highest possible quality.

Few things to get started 1. Senior management to exhibit behaviors' that quality is non-negotiable. Often in tight deadlines, it is seen that within the SDLC, testing cycle time is reduced. This sets a wrong precedence, eventually leading to a norm. 2. Instead of metrics which are typically like test execution rates, defects found etc. tie the metrics with OKRs. 3. Single source of truth for the SDLC data to draw relevant insights is crucial. Leverage power of AI to give you those early warnings and predictive insights.

- Expectations should be set upfront with the product managers and stakeholder. Also both QA and dev should not be afraid to ask any numbers of questions no matter how foolish they sound. The better the understanding the better the development of product and fewer the issues found in the end which means faster delivery of product. - Goals and metrics around it can be set and segregated into different segments like UI, UX, Logic, performance and everyone in the team should have a clear understanding of the same on what is the level of quality we want to achieved in the stipulated time.

Thin line between Developer and tester fades away over time as team matures. Develop the sense of pride in software delivery. Ensure a working and good quality software is not a function of QA team but by the Dev team itself. There is no QA team sitting at periphery waiting to test and report bugs. Rather testing is integral part of build process that can be achieved via automated testing. Everytime you build your application, you run testing. So seamless and integrated CI pipeline ensures continuous testing automatically.

I can assert that creating a culture of quality in SDLC testing goes beyond methodologies and tools. It starts with a mindset change. Firstly, the blame game between QA and Developers must cease. It's a collective responsibility to ensure quality, not just the burden of the QA team. Secondly, setting shared goals for both Developers and Testers can be a game-changer. Aiming to contain defects at early stages of the development cycle not only improves quality but also reduces the cost of fixes down the line. Lastly, the integration of testers into Agile Sprints shouldn't be an afterthought and should be a standard practice. Testers provide immediate feedback and can help catch bugs early, thus streamlining the entire development process.

While it's easy to theoretically expect everyone to own testing, it seldom happens. Two key reasons: 1. Pressure to deliver the primary work - The product owner is focused on the product roadmap and features clarity, and the developer focuses on working code. Only a tester has testing as the primary responsibility 2. The human brain can not easily adapt to 2 different mindsets at the same time. Development vs. Testing are tasks requiring 2 opposite focus. Solution - Have everyone own their kind of testing: Product Owner - User Acceptance Testing Developer - Unit Testing Tester - Feature Testing

One of the key elements of quality culture is early considerations for testability of a system. It applies to custom developed software as well as the systems that are assembled from readily available components. Testability, which is often one of the principles of Enterprise Architecture, means that systems must be designed so that they can be tested effectively and efficiently. Systems designed with testability in mind promote culture of quality across all phases of SDLC.

What's important is to build a culture of Testing. Testing is no longer a prerogative of Testers, but everyone should involve themselves in Testing activities. As the classic V model states, for every Development activity there is a parallel Testing activity. Testers should be involved as early as possible in the requirement process. One of the important elements of Testing should be not just to test the existing product, but to also suggest any improvements in product design, product usage & bringing about an overall product thinking mindset.

a) Brainstorming and joint agreement between business users, business analysts, development lead and test lead during the requirements analysis phase. b) Developing a UI prototype and running it through users to eliminate usability issues. c) Test driven development and review of test cases jointly by test lead and business analyst. Further verification of the broad scenarios by business users is an important step and sign off to ensure the development will be on right track. d) Automated regression suite to ensure existing functionality is intact. e) Defect prevention meeting to identify root cause of issues and steps taken to resolve them . The meeting should include all the stakeholders. f) Comprehensive documentation at various stages

Understanding, verifying, and validating requirements are critical activities in the software development process. They help create a solid foundation for a successful project by ensuring that the project team and stakeholders have a common understanding of what needs to be built and that the resulting software will meet those needs effectively.

Option to follow TDD Test Driven Design model or BDD - Behaviour Driven Design model to ensure tests are part of continuous Build and test scenarios are automated.

Test driven approach is success only when the testers are involved from the very beginning when the requirements are gathered. This sets strict boundary of use cases and the developers ensure that they are inline with the scenarios. Following TDD certainly helps in early testing and helps reducing bugs in the code significantly. TDD is a continuous process and one needs to adapt to it

Based on my years of experience in QA, I have noticed that automated test scripts often miss Business Scenario Alignment. Automation efforts should align closely with critical business scenarios and user workflows. When you plan automation coverage make sure that automated tests cover end-to-end business processes, mimicking real-world user interactions. Automate test scenarios that simulate various user journeys. Validate how the application behaves under various data inputs and conditions relevant to business operations. Validate integration points to guarantee a cohesive user experience. Prioritize automation for test cases that cover critical paths. Ensure that automated tests remain relevant as the business evolves over time.

Automating testing is a game changer. Before automation, so many hours were spent on regression testing for each release! To thrive in an Agile, rapid-delivery world, automating regression testing, smoke testing, load testing, and other repetitive task test procedures is CRITICAL!

Being an quality assurance automation engineer I know that test automation makes a significant change in quality assurance. For example if it takes to do cover the entire manual testing in a week , with automation it will take about 1 or 2 days. Not only it saves time it also saves money for the companies. But this fact is not very well understood by the clients/ companies as they try cost cutting by eliminating test automation. For the test automation to be effective the automation framework needs to be written with lot of thought put into it. Otherwise test automation will not be effective or efficient as expected.

Implementing test automation is essential for efficiency. Automated tests execute quickly and consistently, providing rapid feedback to development teams. This streamlines repetitive testing tasks, allowing testers to focus on more complex scenarios. Automation enhances test coverage, accelerates release cycles, and ensures software reliability. Regularly update automated test suites to align with evolving codebases, maximizing the benefits of this approach in creating a culture of quality within the SDLC.

Automated testing is pivotal for a culture of quality in SDLC. It involves using tools and scripts to perform tests, significantly reducing manual effort. A robust test automation strategy enhances efficiency, accelerates release cycles, and ensures thorough regression testing. By automating repetitive tasks, teams can focus on complex scenarios, leading to improved overall software quality and faster time-to-market. Embracing automation is a key driver for achieving reliability and consistency in testing processes.

No one is perfect and neither is the situation. Mistakes are bound to happen. Its a good idea to plan for failures instead of playing the blame game. The objective should be not to repeat the same mistakes again. I have seen instances where defect prevention meeting is not taken in the true spirit data is pre-filled and the meeting is over in less than 5 minutes. There were others where teams would end up fighting in the meeting. The objective and spirit of the meeting is to understand and question why the issue and collaboratively brainstorm on the permanent solution. Expect resistance during initial meetings but idea is to not stop there. What has truly worked is letting the people answer the WHYs in the meeting and draw conclusions.

Need to have continuous feedback loop in build process to not miss out expectations. By bringing Automation developer and end users as part of same team helps to get early feedback

Sometimes, test cycles do not go as planned. This can be due to oversights in planning, mistakes, shifting scope, or unforeseen issues that arise during the project. It is crucial to document these issues and deviations in a formal log. Whenever possible, take corrective measures promptly when they are appropriate. Additionally, conduct formal lessons learned sessions at the conclusion of the project and share feedback constructively. For instances where things went exceptionally well, make sure to express appreciation.

Learning from mistakes is essential in SDLC testing. Each defect is a lesson that can refine your testing processes. Treat failures as opportunities for improvement, not setbacks. Likewise, user and stakeholder feedback are not just metrics; they're tools for refining quality. Create a loop between feedback and improvement to make quality everyone's responsibility. By embracing failures and feedback, you build a culture where quality is embedded in every stage of the SDLC.

Stop the blame game and resolve the defects ASAP. There is no perfect system. Don't feel bad if you missed a bug. Just take responsibility and take it as a lesson for improvement.

This seems obvious, no? No. We often get so caught up in the cycle (develop, test, release...)...that we don't feel like dedicating time to celebrate is worthwhile (I know I've been there!). But it's SO important to balance out the failures and critiques that are inherent in SDLC activity with true celebrations of the WINS! Having a pat on the back from a leader who has been critical throughout the process might just salvage the relationship with that person - and prove that the criticisms really were just to advance great progress in the work. Don't feel like celebrations are a waste of time that should be spent working (or "fixing broken things")...recognize that even with broken pieces, what your team has done is amazing!

We should not forget to give credit to our teammates. We should always be thankful to people that helped us in our testing. We should also be proud of ourselves even if it is just a small milestone

? Invest in training and development: Equip your team with the necessary skills and knowledge to excel in testing practices. ? Align testing tools with your needs: Choose tools that support your specific testing methodologies and workflows. ? Lead by example: Management needs to champion the importance of quality and actively participate in quality initiatives. Unleash your testing rockstars! Invest in training (think killer amps!), choose tools that fit their style (metal riffs or acoustic jams?), and lead by example - be their quality cheerleader! With the right skills, tools, and management rocking quality alongside them, your team will compose bug-free symphonies that leave users cheering. Invest, align, lead, and rock the SDLC!

a) Often times, quality is treated as a subjective metric. Each quality metric must be inherently objective e.g. "a webpage must load fast" against "the average webpage load time must be under 1 second on all handheld devices". b) The leadership must directly be involved in verifying the quality aspects of the products and services from time to time. If there's an opportunity to test/experience the quality, a role-play is recommended e.g. A senior manager calling up his own helpdesk (posing as a customer) and experiencing average wait-time herself/himself.

It's also important to test at different levels of development phases. For example Interface level testing for external interfaces, software interface test to ensure software architecture is good and structural or unit test at code level to ensure that implementation is as expected.

I would consider to add CI/CD. Implementing CI/CD pipelines is a pivotal step in software development. By encouraging frequent code integration and automated testing, it enables early detection of defects, ensuring issues are caught in the initial stages of development.

In My experience, One should never limit the testing to any particular stage ex: Testing. In fact testing should happen at every Software development Level. 1. Requirement Gathering: We should understand the requirement thoroughly as per customer needs (Understand the requirement and verify the understanding against requirement documents with required stake holders Clients, PO's & with TBA's) 2. Design Level: Verify the design against the requirement if its meeting the requirement expectation or not. This helps in finding the bugs in very initial stage. 3. Development Level: Test the software code by doing simple Unit Tests. 4. Testing Phase: Perform all types of testing to find the remaining defects:).

Create a collaborative and open environment where developers, testers, and other stakeholders work together seamlessly. Encourage cross-functional teams and open lines of communication. It's also important to invest in ongoing training and skill development to keep up with industry best practices and emerging technologies. Emphasis should be given on the importance of comprehensive documentation. Ensure that knowledge is shared among team members and that there's a central repository for documentation and best practices.