Assumptions in Software Testing

Software testing and Assumptions are quiet interlinked. Entire Software Development cycle is based on use of Assumptions,

Let us start with requirement phase. While documenting requirements the Business Analysts may make assumptions viz. information about few conditions and/ or associated behavior is missing, interpreted differently, hence perceptions are given more importance than facts, complex system behavior need simplicity in understanding etc.

These assumptions become input for designers/architects, developers and they implement without questioning them or asking for evidences. While designing the application Designers too add their assumptions on which applications are built like requirement will certainly not change, hence we may not factor changes in the design, data source will be XML file, as previous projects used XML.

The developers also continue to take the same path as others did. They make assumptions on input parameters for a function, interfaces

What is ‘assumption’& inference?

A thing that is accepted as true or as certain to happen without proof. An assumption is something we take for granted or pre-suppose whereas inference means a conclusion reached on the basis of evidence and reasoning

We interpret based on our beliefs. Our beliefs are based on assumptions. Assumptions can be justified or unjustified, depending on reasons that you provide. Inference is exactly opposite to assumptions and we live with both of them. We naturally & regularly use our beliefs as assumptions to make inferences from the situation. Both things can be justified, unjustified, accurate or inaccurate. It depends on person to person & their point of view.

When it is everyday life or work we take things for granted as a human we cannot question everything, every time.Human makes hundreds of assumptions consciously & sub-consciously. Most of them are justifiable, however many aren't.

Testing is fact based activity for that we require assumptions. One has to make certain assumptions to see if it’s true to build your testing results

A tester should learn to make accurate assumptions about the proposition & practice making justifiable inferences. A Skilled Tester should be able to justify his/her assumptions when challenged.

Awareness of assumptions is required to lead good work. Various general assumptions which are made during the testing are:

• Programme Manager will be responsible for giving a timely sign-off on the deliverables,test data covering all the testing scenarios, procuring any tools’ licenses required for the successful facilitating testing activities.
• Functionalities are delivered as per schedule for testing.
• It is assumed that all the Signed off Functional Specification documents requisite test environments/applications with product parameters setup done and interfaces will be provided on start of Testing execution i.e. The complete build is expected to be available on day one of testing
• Planning estimates includes testcase designs/Testwares for CRs & modification of Regression packs as per the scope. Estimates include cost of one review and one rework based on the review comments of the same by BA & TO.
• Code is fully Unit tested and closure report to be shared by development team before handing over code to testing team.
• Any impact to testing budget due to delay in Build, Environment, Defect fix, Interface availability will be handled through Change Request process. Changes if any to the requirement / functional specifications documents during SIT will follow the change request process needing separate budget and estimate.
• Application and environment should be stable. There should be no downtime or error in functionality. Environments, connectivity, User access (Testers), IP opening, Firewall opening to be taken care by the Infrastructure team.
• Sample Test data is available OR Information on how to generate the same is shared.
• SLA for defect fixing is considered to be Sev1 = 4 Hrs, Sev2 = 8 Hrs, Sev3 = 2 Days

Always challenge, question and justify your assumptions. While finalizing the testing assumption one should be sure about the basis, criteria and testing grounds on which these assumptions are finalized. Wrong assumption can impact the testing and ultimate objective of testing is sacrificed. Below is the list of 9 factors I understand that makes assumptions more dangerous.

1. Create confusion – The tester may assume a ground while start the tetsting which may not be acceptable to development team being the specified condition on which testing assumption made ever exist e.g. if a tester assumes that she is working on a build which is latest but latest build is not yet deployed by development team then she might be raising a bug which won’t be acceptable  by development team. This might create confusion in test and development team.
2. Time consuming – Tester should make assumptions after thorough validation of the events, mere assumption on inputs received from support leads to time loss both at testing and development. Secondly, the assumption made need to be discussed with the developers to ensure they are in sync. Say I received data from other team which I presume is valid data. After few tests I found few bugs which I reported to development team. Programmer claim after some investigation that the data used for test is not valid resulting to loss of time of testers and developers.
3. It stops tester’s ability to think other possibility – As tester, he/she need to evaluate all the possible events by which an application fail or do not meet the desired conditions. By making assumption, tester is restricting the testing as the particular event is already been considered or presumed anticipated behavior of the application. 
4. Limit the scope of testing – A tester need to anticipate all the possible user behavior while using the application under different conditions. If a tester assumes that a user will not behave differently, then tester is limiting the scope of testing. Tester will not consider other possible scenarios just because of assumptions he makes. Tester creates tests based on some mental models based on their assumptions. This might reduce other possible scenarios. 
5. Fail to notice new bugs – Suppose a tester knows that he has already tested this functionality then she might overlook that function. She might misses new bugs. 
6. Reporting False Alarm – Tester is supposed to discuss the assumption with developers while testing an application. Suppose tester is testing based on requirement but if she fails to verify her assumptions with stakeholders then she might raise false alarms. Though the actual feature works appropriately but her assumption declares it as bug. 
7. Lose stakeholder’s trust – Tester’s responsibility is to test the applicatons irrespective of the application is under change or run. If testers raise false alarms then chances are high that stakeholder loses trust in tester.Suppose Tester think that application under scope of testing is already tested and he declares (assume) that function works. If anything goes wrong in production then management may question the testing ability of a tester. 
8. Lose credibility – When someone loses trust in you, it means that you also lose credibility. Stakeholders stop assigning bigger responsibilities, they start taking testers for granted. 
9. It costs – The Business user or the sponsor exactly aware of the requirement on the basis of which application is designed. If the tester make wrong assumptions which contradicts with the business users/requirements then ultimate objective of testing is at stake. If assumption made is related to cost or revenue then tester may lead to cost impact for the organisation.