9

So, situation is quite tough. As a test-manager, I have a need to create an approach when the team has a situation: when requirements and specifications are not accomplished and don't satisfy the definition of ready for testing quite often. To be honest — we don't always have 100% requirements on that project.

Situation with requirements seems to be incorrigible at the moment, so I need to create an approach when testers will check product without requirements, which sounds a little bit crazy. But we need to be adaptable.

In my mind, we could try ad-hoc sessions before we have any clarity about what should we have in a requirements. Developed feature should be tested in an ad-hoc style (30 minutes), testers would collect lists of questions and problems, deliver those lists to the other members of team (developers, designers, manager).

Next step is a collecting the answers about functionality and design. And after that, exploratory session starts (90 minutes). After that it is supposed to store much more information about feature, more questions, more defects, more answers, and after that testers should create a test-design for most important test-cases. Why? To have a documentation for regression checks (it is not supposed to be automated soon in that project).

So scheme is like:

ad-hoc -> collect information -> 
exploratory -> collect information -> 
test-design (most important cases) -> 
exploratory + documented testing (final checks) -> 
moving to regression

Do you have any ideas about that? Should it work, and how can I improve that approach?

Improve this question

6 Answers 6

Reset to default
9

In situations like described I like to test for business goals instead of strict requirements. Your application has a certain function and implementation can either support it in achieving that function or hinder it. Any hindrance would be treated as a defect (to be filtered through the product owner since some implementations that to not directly support the business goals might still be wanted because real life is messy).

With an approach like this you will meet certain problems of course, first of all you need to really understand your business cases and your users to accurately determine what helps and what hinders them. Secondly, you will over report issues and waste your time as well as other peoples time since your issues need to be reviewed by someone who can make decisions on how the application should act. The third big problem is that you will miss more issues since cases that are supported but not obvious and will be missed without requirements telling the testing team about it.

So the question is if your company is willing to accept those trade offs. My recommendation would always be to tackle the process problem that results in QA not getting requirements for feature they're supposed to test but if added complexity and decreased efficiency in the testing process is accepted, using the core business cases as a guideline is usually the best approach to such situations.

Improve this answer
5

Requirements are rarely complete, not necessarily because people are sloppy but because we figure things out as we create them. So good Testers should always read requirements with a critical eye and employ other test strategies as well.

Having said that, it's important to create an environment where people actually work together and Testers have access to different stakeholders.

What helped me in similar situations in the past:

  • working closely with developers, perhaps even testing together
  • having access to business people and asking them questions
  • showing (business) people the new featurs
  • having (business) people play with the new features on the test environment
  • or at least showing some other work products like screenshots, ... so people can see it (the app, feature, ...), not only read about it
  • having previous experience with the business domain, kind of app, helped a lot

Last but not least, having time-boxed exploratory sessions is great, however, I'd not try to impose any particular duration on the Testers. Hire people who are interested and give them the freedom to establish their own work rutine.

Improve this answer
4

"Good testing involves balancing the need to mitigate risk against the risk of trying to gather too much information." - Jerry weinberg

Implement 3 amigos sessions

I would implement precisely 3 amigos sessions in this situation to develop an shared understanding as team for below:

  • Business- What problems are we trying to solve?
  • Development- How might we build a solution to solve this problem?
  • Testing - How could we possibly test this solution effectively? What could possibly go wrong which is critical for business?

Meeting Structure

I would recommend having one meeting between 3 team members only- Business Analyst , Developer and tester for each new feature story .These 3 should be only the one who actually going to work on that story. The other team members should be excluded generally so that it could be very focused meeting between 3 people closely working on the story together.

People holding these different perspectives should collaborate to define what to do, and agree on how they know when it is done correctly.  The end result of such a collaboration results in a clearer description of an increment of work often in the form of examples, leading to a shared understanding for the team.

Expected Benefits

Builds a shared understanding about the intent of an increment of work.

Identifies misunderstandings and confusion early and allows learning to happen sooner in the delivery of an increment of work.

Provides a reasonable guard rail for the number of people who should be involved in discussions about any given increment of work.

Source: 3 Amigos meeting

Improve this answer
1

when requirements and specifications are not accomplished and doesn't satisfy definition of ready for testing quite often.

If you test functionality under this scenario that is the problem.
Another way to put it - your organization has decided that actually it is ready enough for testing despite all the issues. Ready for testing and easy to test may be very different.

One solution is to revisit requirements and ready for testing until both are satisfied. It isn't easy and will likely mean several hard conversations and will need to have the backing of several levels of management.

Improve this answer
1
  • +1, "Ready for testing and easy to test may be very different."
    – Vishal Aggarwal
    Oct 2, 2021 at 10:33
0

When it comes to software testing, testers never get to have a full set of details on requirements. From usability to functionality, performance, and security, it is entirely the job of testers to understand the project requirements and foster QA operations that can help meet every smaller and broader objective with the product.

The process you have shared seems to be good for any project that does not have requirements specified clearly. Meanwhile, I’ll suggest you bring your developers, QA team, and technical staff together on discussing the objectives of the project and create a more detailed set of requirements if possible. This will help you add more definition to the process and could even avoid last-minute failures due to any error areas skipped.

Improve this answer
0

I think your approach is quite there, but my suggestion would be keep updating it as the project goes on.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.