What are the outcomes of Negative Testing

As manual and automation engineers, we frequently consider the "Happy Path"- the path that the client will in all likelihood take when they are utilizing our application. When we compose our computerized UI tests, we need to ensure that we are mechanizing those Happy Paths, and when we compose API automation, we need to check that each endpoint restores a "200 OK" or comparable successful reaction. 

In any case, it's important to consider negative testing, in both our manual and automated tests.  

Here are a couple of reasons why:  

Our automated tests may go for inappropriate reasons  

When we initially began composition automated UI tests in Javascript, I didn't comprehend the concept of the guarantee. I recently accepted that when I made a solicitation to find a component, it wouldn't restore that component until it was really found. I was so energized when my tests began returning with the green "Passed" result until a colleague suggested I attempt to cause the test to bomb by affirming on an alternate worth. It passed once more since it was really validating against the guarantee that existed, which was continually returning "Genuine". That showed me a significant exercise never expect that your automated tests are working accurately on the grounds that they are passing. Make certain to run a few situations where your tests ought to fall flat, and ensure that they do as such. Along these lines, you can be certain that you are truly trying what you think you are trying.  

Negative testing can uncover improperly took care of blunders that could affect a client  

In API testing, any customer related mistake should bring about a 400-level reaction, as opposed to a 500-level server blunder. On the off chance that you are doing negative testing and you find that a 403 reaction is presently returning as a 500, this could imply that the code is never again dealing with that utilization case appropriately. A 500 reaction from the server could shield the client from getting the proper data they requirement for fixing their blunder, or even from a pessimistic standpoint, it could crash the application. 

Negative testing can discover security gaps  

Similarly as significant as ensuring that a client can sign in to an application is ensuring that a client can't sign in to an application when they should. On the off chance that you just run a login test with a substantial username and secret key, you are feeling the loss of this critical region! I have seen a circumstance where a client could sign in with anything as the secret key, a circumstance where a client could sign in with a clear secret phrase, and a circumstance where if both the username and secret key weren't right the client could sign in.  

It's additionally significant to check that specific client don't approach portions of an application. Having a carefully tried and utilitarian Admin page won't mean much on the off chance that for reasons unknown, any irregular client can get to it.  

Negative testing keeps your database clean  

As I referenced in my last post on info approval, having great, substantial information in your database will help keep your application solid. Information that doesn't adjust to desires can cause pages to crash or neglect to load, or cause data to be shown erroneously. The more negative testing you can do on your sources of info, the more you can guarantee that you will just have great information.  

For each information field, I am responsible for testing, I like to know precisely which characters are permitted. At that point I can run an entire host of negative tests to ensure that sections with the taboo characters are can't.  

Now and again clients take the negative way.  

It is so natural, especially with another element that is being raced to fulfill a time constraint, to neglect to test those client ways where they will hit the "Cancel" or "Delete" catch. However, clients do this constantly; simply consider times where you have contemplated making an online buy and afterward altered your perspective and expelled a thing from your truck. Envision your frustration in the event that you couldn't expel something from your truck, or if a "Cancel" catch didn't get out a structure to enable you to begin once more. Client involvement around there is similarly as critical as the Happy Path.  

Testing is tied in with searching for unforeseen practices, so we discover them before a client does. At the point when negative testing is joined with Happy Path testing, we can guarantee that our clients will have no unpleasant shocks.