Based on the contributed article (Solutions to problems with Exploratory Testing) by Ulf Eriksson, co-founder of ReQtest.
The article explains the benefits of exploratory testing versus pre-defined testing (conventional testing) - exploratory testing is more effective in discovering user-oriented issues that were not properly defined under System Specification Requirements (SRS) due to too much details not able to be cramped into documents.
Just to give you an example, programmers usually have a hard time unearthing issues related to work flow and screen movements because the programmers know how, when and where to click on the screens as compared to end-users who will just click whenever they see buttons and they don't care about the flow.
This resulted in software issues not related to the requirements but the usability of the system.
Exploratory testing will only work with agile development methodology such as SCRUM - this is because, in order for it to work effectively, it requires a good combination of methods (SCRUM) and tools.
In retrospect, if you are using the tool without performing agile development, it will work less effective and hence it will be less exploratory, instead, it may end up pre-defined.
The tools which ReqTest contributes towards exploratory testing consist of:
Considering ReqTest as a software collaboration platform which a typical scenario requires the following components:
Hence, ReqTest fits to be utilized to serve the needs of issues tracker & ticketing and to support agile software development.
The author suggested that exploratory testing tends to be met with rejection and lower acceptance by users due to its nature of subjectivity - a test exercise may end up yielding zero effect.
Other resistance from end-users may include:
In many ways, exploratory testing can be compared to the conventional user-based testing known as User-Acceptance-Test (UAT) which is also effective in discovering usability issues.
Nevertheless, the UAT is usually more resource hungry and requires a lot of efforts and coordination because test scripts are to be developed based on the System Requirement Specifications (SRS) which may not go at lengths to describe every details - hence, loopholes may persist thereafter.
A pretty classic way to engage in exploratory testing is to make use of the concept of personas where programmers step into the shoes of fictional personalities (who may be using the system) and test out the system.
Eriksson explains that a good testing tool makes it easier to work in test session, I totally agreed.
Document based testing usually incurs more hard-works for the development team and is less effective because it is harder to make good use of the test results which are not digitized or not compiled.
Using ReQtest, you can define test ideas into checklists; when issues/bugs are found, issue reports are created against the checklist; the issues are thus linked to the checklist and this caters for traceability.
"One area where exploratory testing is an extremely good practice is when it comes to quickly test hot fixes for bugs or very late integrated functionality," Eriksson wrote in the article.
Use ReqTest to leave no stone unturned.
The article explains the benefits of exploratory testing versus pre-defined testing (conventional testing) - exploratory testing is more effective in discovering user-oriented issues that were not properly defined under System Specification Requirements (SRS) due to too much details not able to be cramped into documents.
Just to give you an example, programmers usually have a hard time unearthing issues related to work flow and screen movements because the programmers know how, when and where to click on the screens as compared to end-users who will just click whenever they see buttons and they don't care about the flow.
This resulted in software issues not related to the requirements but the usability of the system.
Exploratory testing will only work with agile development methodology such as SCRUM - this is because, in order for it to work effectively, it requires a good combination of methods (SCRUM) and tools.
In retrospect, if you are using the tool without performing agile development, it will work less effective and hence it will be less exploratory, instead, it may end up pre-defined.
The tools which ReqTest contributes towards exploratory testing consist of:
- Test management - to create test cases and checklists
- Bug tracking - issues tracker
- Requirement management - to create and manage requirements
Considering ReqTest as a software collaboration platform which a typical scenario requires the following components:
- Issues tracker and ticketing
- SVN - for source code management and sync
- Wiki - for indexing of contents, publishing of best practices, personal notes; Wiki can be used in place of forum
- Forum - for discussion on multiple topics
- Shared storage - i.e Online storage
- Project management tools - create project, assign team, assign tasks and etc; forum can be used as alternative
- Social network & Instant Messaging - for discussions, hangouts and meetings
Hence, ReqTest fits to be utilized to serve the needs of issues tracker & ticketing and to support agile software development.
The author suggested that exploratory testing tends to be met with rejection and lower acceptance by users due to its nature of subjectivity - a test exercise may end up yielding zero effect.
Other resistance from end-users may include:
- The organization has little confidence in exploratory testing
- Test reports are not read
- No time for debriefing
- Too high requirements and expectations on exploratory testing
- Similar tests tend to be boring
- Lack of interest and no appreciation from the organization.
In many ways, exploratory testing can be compared to the conventional user-based testing known as User-Acceptance-Test (UAT) which is also effective in discovering usability issues.
Nevertheless, the UAT is usually more resource hungry and requires a lot of efforts and coordination because test scripts are to be developed based on the System Requirement Specifications (SRS) which may not go at lengths to describe every details - hence, loopholes may persist thereafter.
A pretty classic way to engage in exploratory testing is to make use of the concept of personas where programmers step into the shoes of fictional personalities (who may be using the system) and test out the system.
Eriksson explains that a good testing tool makes it easier to work in test session, I totally agreed.
Document based testing usually incurs more hard-works for the development team and is less effective because it is harder to make good use of the test results which are not digitized or not compiled.
Using ReQtest, you can define test ideas into checklists; when issues/bugs are found, issue reports are created against the checklist; the issues are thus linked to the checklist and this caters for traceability.
"One area where exploratory testing is an extremely good practice is when it comes to quickly test hot fixes for bugs or very late integrated functionality," Eriksson wrote in the article.
Use ReqTest to leave no stone unturned.
Comments