13

We have one product to test but we don't have the resource who have the domain knowledge of the specific field my company don't want to lose the client as it a breakthrough for the company & we don't have time to hire the new resources in short period the only way somehow we have to start testing .

So my question is there any way to test the full flash product without any domain knowledge?

Improve this question
1
  • 3
    Has the client provided a test plan for you to follow, or are they expecting you to write the test plan as well? Executing an existing test plan can be done without much domain knowledge, but creating one might not be reasonable.
    – bta
    Jan 2, 2018 at 21:34

9 Answers 9

Reset to default
16

Yes, there is a way.

Take the requirements/specifications (whatever you call it) and prove whether the software fulfills them.

Improve this answer
9
  • 2
    Just to add to it: requirements can be inferred from similar products (e.g., Lotus and Word are both word processors), bug reports, etc.
    – dzieciou
    Jan 2, 2018 at 6:35
  • 2
    @NitinRastogi No one said it's easy. It really depends on your domain. If it's application from the domain that is familiar to many people or intuitive to use it might be easier to recognize and test. If you are testing microcontrollers and have no knowledge of microcontrollers at all, then it's much harder. You cannot eat a cookie and still have the cookie, i.e., you need to learn a domain, i.e., invest some time, money, resources, etc.
    – dzieciou
    Jan 2, 2018 at 6:42
  • 3
    @NitinRastogi As you said - you don't have any domain knowledge. So why philosophize whether it matters or not?
    – Embedded
    Jan 2, 2018 at 6:50
  • 1
    @NitinRastogi It's not "what if", it's "they are". Time, money and other resources are always limited.
    – Embedded
    Jan 2, 2018 at 6:52
  • 1
    Who created the specifications? Did they have 5+ years experience in both the domain and in software? If not, the specifications are WRONG, and without understanding the domain you will not be able to find the bugs in the specifications, and hence in the final software.
    – wedstrom
    Jan 2, 2018 at 22:20
9

Use Exploratory Testing.

Exploratory Testing Tutorial.

This is a perfect situation to use exploratory testing .Explore, design & test simultaneously.

Set expectations:First, set the right expectations atleast to your company regarding your domain knowledge.

Be curious.Ask yourself a question about the product functionality based on common sense/ experience and find out the answer by designing an test and executing it.

Logical Progression: Each question/ answer should lead you to the next logical question.

Timebox Sessions :Do time box(I do 40 mins ) intense sessions and make simple notes of your observations during this process.

Tools Required : Notepad (personally physical preferred ! )

Raise questions not defects at current stage and confirm your understanding from business analyst/product owner.

Improve this answer
8
  • I’d disagree, unless you have a very, very patient client. Exploratory testing is great, as a domain expert, when you know the system and are looking for unexpected things. But it’s a horrible way to learn the system, because you’re going to almost certainly make a lot of invalid assumptions, and open a lot of invalid defects. Even if you frame them as questions, the client is going to have to be a lot more involved than I suspect they want to be in this case, where they’re trying to outsource testing.
    – Kevin McKenzie
    Jan 2, 2018 at 23:14
  • Kevin let me understand,are you saying that Exploratory testing is for domain experts only?
    – Vishal Aggarwal
    Jan 2, 2018 at 23:17
  • In this case, yes. The original poster is apparently working for an outsourcing company that’s being asked to test a product. They have no internal knowledge of the product. Could they possibly learn the product via Exploratory Testing? Yes, but in doing so, they’d have to make assumptions about how the product is supposed to work. You have to have an oracle. You can be your own oracle, and make guesses about the way the product is supposed to work, but you’re either going miss problems or find lots of invalid problems. In this case, it’s not clear to me the client will tolerate that.
    – Kevin McKenzie
    Jan 2, 2018 at 23:23
  • 3
    @KevinMcKenzie I agree it's a terrible way to learn the system, but in my experience, even users who have domain knowledge use applications like they're toddlers. So having someone who doesn't know what they're doing test it will highlight areas where users can and will make mistakes that domain knowledge would have prevented. "You submitted a foo without a bar? Of course it broke!! No one in their right mind would submit a foo without a bar!!"
    – corsiKa ♦
    Jan 3, 2018 at 16:17
  • 1
    Kevin, I have been in these similar situations, and I get surprised how often when a skilled tester with Zero domain knowledge starts systematically/methodically questioning which domain experts in the team find hard to answer.Although ,it takes great testing skills,confidence and courage to speak up.
    – Vishal Aggarwal
    Jan 4, 2018 at 11:59
5

Testing without domain knowledge requires following the requirement and test script. Just reporting anything which feels "weird" for a tester without a basic knowledge will result in reporting so many false positives that error reports are useless.

I have first hand experience with such approach (testing product by testers without basic domain knowledge) when in one of my previous projects, management wanted to save money by testing our app by bunch of interns with no knowledge and no training. They reported so many false issues (repeatedly: they were not even able/trained/expected to see that someone else already reported the same issue) that triaging reported issues become full-time job for a highly trained expert (whose time would be better spent on testing). Whole experiment was abandoned after just few days, so obvious it was that it is a wrong way to solve the problem.

So if you have to do it, and keep the client, you need to build in-house domain expertise, fast: train the testers with whatever knowledge you already have, triage the issues (so you don't report duplicates), and spread all the bits learned from reported bugs back to testers.

Improve this answer
1
  • Exploratory testing done by interns and done by experienced professional testers are totally two different things.Its sad that I need to explicitly mention this in a specialized QA group.
    – Vishal Aggarwal
    Oct 5, 2023 at 10:47
5

Is it possible to do? Maybe. Is it possible to do well? It depends.

First and foremost, you need an oracle, that is, a way to determine what the correct behavior in any given circumstance is. There have been some references to requirement specifications earlier; that would be a good place to start, but is most likely not enough, as such things usually leave out a lot of implicit requirements.

Next, you need a way to prioritize problems, and prioritize testing. Otherwise, you risk spending time on things that don’t matter.

To give an example, right now, it seems like someone has handed you a black box, and told you to test it. So the first thing you do is you drop it on the floor, and it explodes. Is that a bug? It might be, or it might not be. Maybe it’s supposed to be a bomb, so exploding is good. But maybe it’s only supposed to explode when it hits an object with a certain velocity, in which case, you need to validate that requirement. Without an oracle, you have no way of even starting to test. Or, maybe you drop it and it explodes, which it shouldn’t, but it’s only ever going to be used underwater, so you need to focus on its interactions with things underwater first.

At the very least, you need to get as much documentation as possible. Manuals, any prior test cases or test scenarios, design documents, problem databases, and so on. And that may or may not be enough. You need to build very close relationships with the developer(s), because you’re going to be annoying them, either by asking questions, or by opening invalid bugs, or both.

Honestly, though, given what you said earlier, that no only do you have no domain knowledge, you have no time, money, or ability to hire anyone, you have a very, very hard path ahead of you. And I’d make sure the client understands this. And internally, within your company, you need to discuss if it’s worth the risk of taking on something that’s unlikely to go well, and will require a great deal of investment. And if the domain knowledge you build on this project could be transferred elsewhere or not, in case the other company changes their mind.

Improve this answer
4

37 Sources for Test Ideas might help you, BUT if I were in your place I would insist on having at least some domain knowledge.

Following the ideas in the link and other answers is just that- gaining domain knowledge by learning it on the go.

I would try and have a more solid starting point, for example taking a short course or talking to people that have the right knowledge.

Improve this answer
1
  • Excellent test ideas, must read...!
    – Vishal Aggarwal
    Apr 17, 2018 at 21:21
3

Tell the client that you lack the expertise to test their product. Seriously.

If you do not tell them this, you are putting yourself and them at serious risk.

Consider, for example, what impact your question would have if it were submitted into evidence in a court of law.

Your profile says you are a conscientious person. Be conscientious now. Tell the client you lack the expertise to test their product.

Improve this answer
3

What you can't test

If you have literally (literally literally) zero domain knowledge, you cannot test the following:

  • You cannot test any product requirements, because you don't know what it is supposed to do, nor can you test any requirements derived from product requirements.

What you can test

There are many basic things you can test out:

  • You can perform automated penetration testing and app scans to detect any security weaknesses
  • You can test and validate that deployments complete successfully
  • You can test any install/uninstall procedure
  • You can test web apps for browser compatibility (by comparing results between browsers; even if you don't know whether the result is correct you can tell if it is different). Similarly, you can test desktop applications for O/S compatibility, or mobile apps for device compatibility.
  • You may be able to perform load and stress testing, if you can manage to figure out how to execute a basic flow
  • You can assess any markup for HTML5 well-formedness
  • You can assess any pages for WCAG, WAI, or 508 compliance

So there are a lot of things you can test. You just can't test whether the functional behavior is correct :)

What you can sort of test

You can perform exploratory testing in the role of a naive user, who presumably will have very limited domain knowledge as well, if your end users are expected to be laymen. Think of it as usability testing (as opposed to strict functional testing) as the effort will help you and your client understand whether the app's behaviors make sense (are usable) to typical end users.

Be prepared for a lot of thrash, though, as many behaviors may look like defects but may actually be expected, especially in edge cases, e.g. a user in a locked out state or someone attempting to do something they're not supposed to be doing.

Improve this answer
1

My opinion go with Exploratory Testing (Testing without any knowledge about the business and the functionality)by try different scenarios. when you begin by this method it will cause some problems like not a bug issues the tester will upload and also more time to understand and gain knowledge for the application. if any help file is found for the application will reduce time and "not a bug" issues.

Improve this answer
1

I see many good ideas written here already. I would add - ask around maybe you know somebody who is/was using a similar product.

Once I had to test book-keeping software and I asked my friend, a book-keeper, what is important in his work.

Another great source is Google :) Amazing what you can find there!

Improve this answer

Your Answer

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

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