How do you test software with incomplete or ambiguous specifications?

Get the background of the work and the user base. What's the problem we are trying to fix? Who are the users and what do they need? Align your test objectives to those goals. We are there to help ensure quality

I completely agree with Stephen, if the software has incomplete or ambiguous specification, we need to try our best to understand what it is we are actually trying to achieve, what needs are we trying to fulfill, and in searching for those answer it could be possible we are able to suggest improvements to the current specifications to be more aligned with reality.

Base activities on risk to user/patient (patient is specific to medic al device). 1. Locate any manual or documentation of the software. 2. Identify (especially if already released software any power users). 3. Identify subject area SMEs (subject matter experts), protocols of treatment (medical device), standards of practice (any regulated industry), or workflows (if necessary by observing workflows for that process/discipline. 4. Document findings (btw these actually help ID requirements), and generate test designs (general areas of test and nominal and deviant test steps). 5. Create test strategy, protocols, and perhaps even a general guide for ad hoc testing. Focus on areas of highest risk to users, patients (if med dev) and business.

Find out with the users what problem(s) the software is trying to solve. As you verify that these problems are being solved.. you are testing the software for the cloudy requirements..

'Communication is the key' in this scenarios Testing software with incomplete or ambiguous specs demands creativity, communication, and strategic thinking. We can: -Prioritize communication for defect discovery and improving specs. -Use brainstorming to uncover uncharted scenarios. Employ heuristic testing like "error guessing" and "equivalence partitioning" to find hidden issues. -Visualize interactions with use case diagrams. -Create a risk matrix to pinpoint areas of high ambiguity. -Implement a strong feedback loop with developers for real-time ambiguity resolution, ensuring evolving specifications as testing progresses.

Communicating and clarifying specifications is critical for alignment. It is an iterative process facilitated through collaboration methods like reviews, prototypes, and exploratory testing. From my experience: - I review requirements documents and note unclear areas - I meet with product managers and developers - We walk through gray areas interactively - I document decisions and get alignment Also, when exploring software, I log inconsistent behaviors from the specs. I share those cases with stakeholders. Together we clarify expected outcomes.

Clarification is key assumption is the death of quality. Check the specifications and high level design with the architect. Review and dicuss requirements with the business analyst. Walk through the code base with the developer. How I do this, verbal walk through which I video record. I make a presentation on the material and brief it back to ensure I have understood. Make sure the material isn't lost and is shared.

Never make unfounded assumptions, have a concrete base and evidence to back up the "why" you are testing something a certain way.

A lot of insight already written here so I will not re-iterate that. One thing that I would like to add is that less senior testers have a tendency to ask the Developer how the feature is supposed to work when they do not have the Requirements. Do not ask a developer how its supposed to work. As the requirement is unclear the Developer will also not have had clear directions could have assumed things that are wrong. This can lead to a development of a feature that is completely wrong but goes through development and QA with flying colors and gets released to customer Note: I love Developers and this is not an attempt to point fingers. They are suffering as much as testers when it comes to bad requirements.

Absolutely! Communication and good social skills help me a lot, since we’re working on many different projects and TCs at the time. Each product is different and so is the customer. Besides, the world of software (per se) is a constantly changing environment. So, there can’t be wrong or stupid questions when it comes to testing. Asking questions also helps me to save my time and better schedule my work to be more productive.

Risk based approach is always useful and listening to the user base. Focus testing on areas with highest risk of defects. Work with the user base to understand what they care about and consider effort in that area. You can never fully test anything so balance what you can achieve with the time, effort and funding you have.

Techniques like risk-based testing, value-based testing, or MoSCoW analysis offer structured approaches to determine what needs immediate attention. Assessing the impact of potential defects, evaluating feature value, and aligning with specified criteria aid in establishing testing priorities. This strategic approach optimizes resources, ensuring that testing efforts are concentrated where they matter most, thus delivering enhanced value and meeting stakeholders' and users' expectations effectively.

The more we have time constraints, the more we need to prioritize. What is more important? What will be used more? What is essential that never fails? In reality, nothing is ever fully tested, and nothing is ever bug free. Speaking with stakholders, having proper requirements and understanding well the product under test is essential to prioritize what should be tested. Establishing coverage metrics is also a good approach.

Useful suggestion. I did not hear about MoSCoW technique. I agree, testing should be prioritized and focused. Personally, I always struggled with spending too much time on testing. With exploratory testing, it is recommended to use test charters and time blocks so that you focus on specific area. The following techniques can be helpful - Risk analysis, risk probability x impact - Product coverage outline - Product blueprint - Which functionality is most important to the project's intended purpose? - Which functionality is most visible to the user? - Which functionality has the largest safety impact? - Which aspects of the application can be tested early in the development cycle? - What kinds of problems would cause the worst publicity?

For test automation it is very important to use good/best programming practices. For example screenplay object model, Test factory and other test patterns in order to maximize code reuse. In this way testing frameworks are more resilient. In other hand these patterns are more easier to AI to learn, leveraging the AI potential to applying it to testing.

Until this year I'd never tested a "low code' solution and couldn't find much guidance on best practice. To that end once I had completed the project I made sure to document what I did, lessons learnt etc. I then created a presentation for my peers on what my experience was and how they could learn from that. If the whole community does that we can quickly gain an understanding of anything.

Process is key. Having a concise and organized way to document what you did, how you did it, what you found and what impact it had can lead to the approach used being used in other projects. I've had this happen in projects I participate, where approached to document, report bugs, generate test results are being used in multiple projects due to their proved success. It's important to show the effect testing had, the issues it prevented and the money it saved.

Learn, listen, ask other people about their experience and be receptive to new suggestions. You never know how you may need to adapt or what skills you will need. Constant learning is crucial to become a versatile tester.

Good testers are constantly learning. Having a passion for new knowledge and technology is crucial in this profession. Some projects may require very unusual skills not necessarily related to programming but to your life experience. I suggest learning time management skills and techniques for newcomers. As for the experienced testers my go-to would be learning Postman, Cypress and the basics of SQL.

Try to write one when requirements are missing. Try to test wherever the user is involved to see the correct behavior. Break software to build one strong application for your end users.