Here's how you can revolutionize software testing and quality assurance.

No rocket science here. Just - ? Automate simple tests to save time ? Test early and often ? Include testing in every code update ? Use cloud tools for bigger tests ? Prioritize user experience ? Encourage everyone to care about quality

Some good to have things for a QA checklist: 1. Automate : Let tools do the repetitive testing work. 2. Jump into Continuous Integration: Merge code changes often to catch bugs early. 3. Try Test-Driven Development (TDD): Write tests before coding to cover all bases. 4. Don't Skip Performance Testing: See how your app holds up under pressure. 5. Do Some Exploratory Testing: Get creative and dig for hidden bugs. 6. Focus on Security: Test for vulnerabilities to keep your app safe.

> Automate wherever possible to accelerate the testing process and ensure product quality & Implement a CI process to schedule and trigger tests after any changes. > Promote and integrate quality into all services while collaborating closely with the Tech team. > Stay updated with the latest tools and regularly benchmark them to adopt the most suitable ones. > Begin testing as early as possible, starting with the lower layer (API), and proceed to front-end tests once the feature is implemented. > A critical mindset and thinking outside the box can help identify and address corner cases.

- Try to automate most repetitive scenarios first - Run the automation suites more frequently - Commit the code daily - Automation testing is not replacement of Manual testing, it’s just to assist Manual testing. - Keep product mindset while creating automated test cases

Yes I agree with this point that automation makes works easy but there are multiple cases and scenarios which are not possible to automate. E.g. if a browser is active for more than one day then a tool is not going to automate after 24 hrs. Automation is possible only hand to hand that's why manual process is also important.

This is a very important practice in software development where the number of code mergers is not as important as the quality of code merges. If it enhances your work, go for it. CI eliminates task that is done almost everyday and cuts out conflict and tests can be triggered automatically without manual requests.

CI is hard to achieve but changes everything. First of all, it requires good test preparation. With a lot of them in testing repository, they can run for hours until finished. And they require resources. In order not to clog up anything, tests should be set up properly, allowing developers to run only those tests that relate to the areas they are working on. Another solution are parallel tests, but these are even more difficult to write because they cannot affect each other in any way, and this is not always possible. But at the end of the day, CI changes everything.

Automation of testing is pointless without your tests integrating with the rest of your testing ecosystem. Your Testing platform should necessarily integrate with your requirements, defect management and orchestration engine, at the very least.

We use this approach at my current organization and I find it to be very effective and productive. Especially as a tester it's a quick and easy way for me to get the latest work and test immediately.

Continuous Integration (CI) is crucial in modern software development. It ensures that code changes are tested early and consistently. By automating builds and tests with CI pipelines, teams can quickly detect and resolve issues, maintaining high software quality and speeding up development cycles. Embracing CI not only boosts efficiency but also promotes a culture of continuous improvement and collaboration among developers.

é uma metodologia que pode ser muito bem utilizada pelo time, vai depender muito da maturidade, QAs podem contribuir com devs para aplicar as melhores técnicas. Acredito muito que vai depender da maturidade do time, mais é uma metodologia que pode contribuir muito durante o processo de desenvolvimento.

Test Driven Developmetn is an great tool for the beginner who are writing a production ready code for the first as it comprises test for which will happen at various occurance as per requiremetns. TDD provides a structure how an code work and let us know where the logic is going wrong.

It's a game-changer in software development. With TDD, you start by writing tests before diving into coding. These tests ensure that your code aligns perfectly with the desired functionality right from the beginning. It's not just about passing tests; TDD encourages you to write simple, effective code that's easier to maintain and extend. By embracing TDD, developers can build software with confidence and efficiency, knowing each piece of code is rigorously tested and meets requirements head-on.

As we all know, involving testing aince the project conception it's ideal to try to reduce quality risks, not only for the product but also for the project itself, so I definitely support this approach.

It is not easy to anticipate all scenarios before delivering functionality. It requires developers, a good risk assessment system and testers experienced in the product. In my opinion, TDD cannot be the only testing system in a company but it helps to get rid of those potentially most serious bugs at an early stage.

Separate Performance testing from Functional testing. Performance of an application is determined by running various tests such as Stress, load, failover, scalability after an Application is thoroughly tested and major bugs are filtered out and fixed. Then performing this testing adds more value adding to better understanding of the application ability to handle many users, or in the case of failure of a server.

Performance tests are very important, but it is also important to be aware that they are much different from the tests that are ran on a daily basis. Typically, such tests require completely different tools because they test different things and provide different information. The first step in writing such tests should be to gather realistic and achievable requirements, but probably to find out what these are, you need to do performance tests first to see where you are. Tests of this type are often overlooked, which in my opinion is a mistake.

Performance glues all the UI,QA, unit tests, SQL, etc. work that's been put into the product. Individually, teams ensure and test their components work 100% but it's Performance that symphonies all, as one flawless piece of work. I've seen the most robust apps/services be brought down by a small, simple 3rd party component that didn't mix well with the infrastructure. Only Performance Testing will root out these annoying incompatibilities.

Indeed, incorporating performance testing in early phase of software development and running it frequently provides valuable insights into system behavior. It's crucial to make performance testing activity highly visible to the entire team, rather than leaving it to a dedicated performance testing team or individual that most organization do. Non-functional defects often need immediate attention and input from various experts to identify and resolve their causes. Testers should focus not only on writing performance test scripts (this is not the hardest part) but also on the critical and challenging task of analyzing and clearly articulating the problems.

I agree with that, specially in projects where safety is involved, it's always better to make a proper analysis of the system to mitigate as much as possible all the risks that can affect the environment or life. But also, we have to consider the fault injection testing which could help also to identify potential unexpected behavior of the system.

Ways to Kick-start: 1) Ensure the QA team has a comprehensive understanding of the product and its domain. 2) Assign specific modules to team members for focused testing. 3)Identify complex scenarios and conduct thorough exploratory testing on them. By following these steps, the QA team can efficiently identify and address potential issues, ensuring a high-quality product.

Exploratory testing is indeed a valuable approach for uncovering issues that automated tests might miss. To further enhance this methodology, it's beneficial to begin with the core functionalities of the application, employing various testing types such as boundary testing, usability testing, and stress testing at appropriate times. This ensures that the most critical parts of the software are thoroughly examined early on, allowing significant issues to be identified and addressed promptly. Additionally, maintaining detailed documentation of findings during exploratory sessions can provide valuable insights for future testing cycles and development improvements

Exploratory testing is often mistaken as a separate testing phase, where testers dedicate a day or a few hours to it for each feature. However, it should be a continuous activity that starts with requirement discovery and continues until the end of the development cycle. It requires a holistic view of the system, combining information from various sources and using automation to gain deeper insights. Exploratory testing leverages all the knowledge a tester has gained throughout the development process. The outcome can be bugs or feedback for improvements, but it should never be seen as ad-hoc testing. Lastly, I don’t think we need to create a sub-task to perform exploratory testing ?? it should be a continuous activity.

In my opinion this is a test approach that have to be always combined and considered among with other test techniques to perform a good testing, obviously depending on the resources availability like budget, time, etc.

Testes exploratórios é um abordagem muito importante para um testador, é um complemento dos testes de caixa preta. Ele percorre caminhos que os testes de caixa preta e automa??o n?o percorrem. Podemos utilizar diversas abordagens para nos guiar, como heurísticas de teste, baseados em sess?o, baseados em hipóteses, histórico de falhas etc.. é uma abordagem que n?o pode estar fora da maleta de ferramentas do QA.

La seguridad debe ser parte del dise?o del software. La práctica de crear un software y al finalizar agregarle "seguridad" como si se tratara de un plugin, es una práctica que tiende al fracaso, tanto en seguridad como en calidad del software. Sanea tus entradas aunque sean del procesos del propio software o lecturas de la base de datos! Sanea tus salidas para mitigar fallos de componentes de terceros y de la infraestructura! La seguridad no es una característica: es un proceso.

Identifying the right testing mix and fitting it within your test budget is the most crucial factor in revolutionizing software testing and quality assurance. There is often a tug of war between manual testing and test automation: testers may be reluctant to give up manual testing completely, while ambitious managers push for more automation to ensure consistent test outcomes within a limited budget and resources. Moreover, project teams have to manage constraints related to time and resources. Implementing a large number of automated test cases and using numerous automation tools does not necessarily guarantee the detection of defects. Therefore, a proper mix of manual testing, which leverages experience, and automated testing is crucial.

Consider end to end reliability tools (like Watermelon), which treat the problem of reliability across the SDLC, not just in one area. For true application reliability (ability to ensure high% of successful transactions and high % of highly performant transactions), it is necessary to introduce velocity in functional testing, API testing, non functional testing (like chaos engineering and performance testing), service virtualization, SLO management in ops, capacity management, synthetic transaction monitoring etc. The feedback from ops to dev is a critical aspect to ensuring reliability.

Testing is one of the key methods to verify the quality of deliverables. However, to reduce subjectivity and bias in determining what constitutes quality, it is essential to have metrics in place to evaluate what is being tested. Whether using manual or automated techniques, testing teams must keep this in mind to ensure a more objective assessment of software quality.

Oftentimes we take for granted negative tests and later uncover that some of the tests have a great impact on our SUT. We shouldn't assume folks would use our application the way we thought it to be but fail due to human curiosity. If our application involves human lives, it's crucial to avoid this mindset and never become comfortable giving it a pass without catching a single defect. I remember once my supervisor told us that "the greatest sin as QA is to assume." because failing to confirm could be a disaster later on.

It is important to work on metrics to identify points of improvements in terms of time, costs and technical debt. Without data it is difficult to understand where we should focus on if we want to be more efficient. When implementing testing/deployment automation solutions, we should take into consideration how to measure performance and costs associated, to be able to identify patterns and plan the fixes/improvements accordingly based on their relevance. Examples are: Test run time, success/failure ratio, flaky test %, deployment cost per run (e.g. in the Cloud), etc. And last but not least, share metrics improvements over the time and celebrate the achievements!