Delhi Testers Meetup- The Power of Conferring

by | Syndicated


On my recent visit to India, Santhosh Tuppad (@santhoshst) decided to travel to New Delhi with few of his colleagues so that we all can meet. On my suggestion Santhosh organized a public event instead. The Delhi Testers Meetup (or TEAM-Delhi) was born and was planned for Sunday, 27 September 2015.  
I called the meetup TEAM-Delhi because Test Engineering Alliance Meetup (TEAM) in Melbourne has been a very successful meetup since its inception and testers in Delhi exhibited similar passion and engagement when we announced the meetup in Delhi.
The meetup was at a hotel’s conference room and the hotel staff arranged the room in a formal classroom structure. But I wanted my Exploratory Testing workshop and other discussions more interactive, so we began the meetup by moving tables & chairs around. The benefit of this movement was that it started informal talks among people. I did not realize that passionate testers can turn anything into a worthwhile valuable discussion. It was a good beginning.
Testers who attended the meetup were: Santhosh, Dwarika, Alka, Siddharth, Devangna, Sahas, Atul, Nitin, Rupinder, Ramit and Kapil. After a while Smita Mishra also arrived who is organizing a Testing conference in Delhi along with Rapid Software Testing class with James Bach.


I started the Exploratory testing workshop by giving a snapshot of context-driven testing and the strong community support that Context-Driven testers get. I focussed on following topics in my workshop:

– Definition of Exploratory testing
– Changes in definition over the years and the latest from ET3.0– Skills of a good exploratory tester – Note taking, exploration, experimentation, questioning, study, modeling, observation, inference etc.


We talked about Heuristics and mnemonics (“rules of thumb”), Oracles (how to recognize problems), Session-Based Test Management (SBTM) and cheating. Some of the good exploration skills that we talked about were self management, critical thinking, developing test ideas, examining a product and telling compelling testing stories.  
An important part of the workshop was to explain ET from Rapid Software Testing namespace perspective. RST has its own namespace and I believe that any practitioner who teaches ET should keep that in mind.
Another important aspect of my workshop was the exercises. We worked on various exercises including developing testing idea for a simple program that calculates two integers, testing a basic calculator and testing an image. I explained through exercises that testers can miss bugs because of inattentional blindness. We looked at Google calendar to understand oracles.
There was a lot of discussion and everyone was contributing. When we discussed about questioning skill, Ramit mentioned 635 technique (Method 6-3-5).  We talked about effect of culture on testers (and testing) and then there was another discussion about testing conferences and their value.
Santhosh shared his views & experience on Security testing and very soon the discussion digressed to emotions, at which point Santhosh explained Plutchik’s wheel of emotions. From there the discussion moved to Persona-based testing and that led to a question whether testers can actually test like users or not. There was a mention of colorology but I do not remember the context in which it was mentioned.
The passion and energy in the room was contagious. Even those who I considered reticent, participated well in all discussions. It was a free-flow of ideas and I did not stop anyone from contributing or digressing.
I learned so much from everyone and I am sure all learned a lot too. This is what I call power of conferring.
Thanks to TestInsane for organizing the event.

Rapid Software Testing Course Notes

by | Syndicated

Here is the mind map of the RST that I attended in Sydney between 19-21 August, 2015. The public link to the file is below:https://drive.google.com/file/d/0ByGSwxM9lnaYYVRQcVc1TFJUMG8/view?usp=sharingThe mindmap was created using Mindmup. If you want t…

TESTING VS. CHECKING APPLIED – Testing Trapeze August 2015 issue

by | Syndicated

Following article was published in the August 2015 issue of Testing Trapeze. http://www.testingcircus.com/testing–trapeze-2015-august-edition/).

Testing v/s Checking – Applied


The discussion about testing versus checking has been alive in the software testing industry ever since the distinction was first made by Michael Bolton in his thought provoking talk at Agile 2009. Michael later expanded his talk in thispost. A relatively recent postby James Bach and Michael refined the distinction even further.

What prompted me to write this case study was the success I achieved in making the distinction between testing and checking clear to the stakeholders at my current organisation. These stakeholders include the Chief Information Officer (CIO), the Head of IT Infrastructure & Service Delivery, the Development team and the Release Manager among others.

Through this case study I have also demonstrated that the distinction between testing and checking is not ‘just semantics’ but can in fact have a direct impact.

Background of this case-study:


In 2014, I moved to Australia when I was hired by my current employer, a health regulation agency under Australian National Law. The management team at this organisation had observed areas in the product as well as in the process that they wanted to improve. The managers were also keen on bringing positive changes through enhancing the capabilities of the testing team.

At the time, the testing team was struggling to cope with the demands of stakeholders because of a lack of structure and organization. The team members were trying to manage different priorities defined by different stakeholders and they were often failing to manage them effectively. There was a lot of documentation which included a Test Strategy, an Automation Test Framework and a Performance Test Strategy. There were templates for test planning, test estimation, test reporting as well as other processes. The team KPIs were defined on metrics such as test execution percentage, test coverage and number of test scripts.

What I just described may appear to some of you as a properly defined process. So what was the problem there? Quoting Gerry Weinberg:

A problem is a difference between things as desired and things as perceived.


For our testing team the so-called testing process model described above, had created the perception among the stakeholders that the team was well organized and capable of responding to the high rate of change. So while the testing team perceived a lack of support from management, the stakeholders had an expectation that the testers would deliver the outcome they wanted. This expectation was a problem in itself, as it was in fact a desire. While testers were supposed to test faster, they were also expected to write test plans and test cases merely so that they could tick all the boxes of the testing process model. Another problem was that due to bugs in product the business users had the impression that the testing team had not tested the product adequately before it was released for user testing.

I felt that there was a need for change. A change in the stakeholder’s perception, expectations and desires; a change in testing team’s communication to others and a change in the overall testing process. The team needed mentoring and coaching to understand that what was being considered testing was not testing; it was checking. Almost everyone in the group was making the reification error by presuming that test cases were testing.

I arranged multiple internal coaching sessions (with supporting reading materials) and also held regular brainstorming sessions over several months to help me transform the team. However, it seemed to me that there was a greater need to change the stakeholders’ perception of testing (and checking) if they were to accept our new processes. And due to the separation of duties across various teams, I also needed the engagement of the broader management team so that they could help me implement good testing practices and mandate the change.

Convincing the Managers:


My experience is that many senior managers do not know much about testing. Some of them also may not know much about other areas such as development or architecture. But that does not mean that they do not care about these teams. They do care because they know that without these teams they will not be able to deliver the products or services that they are accountable for. Sometimes the managers’ attitude may appear to be indifferent or uncaring, but it may be simply due to a lack of communication.

I consider myself lucky because my manager is a reasonable person. He is a good listener and supports his teams. When I explained to him the challenges that the test team was facing, he agreed that there was a need to make changes. He suggested that I prepare a roadmap for achieving these improvements within the next twelve months.

I explained the distinction between testing and checking to him using some examples. I also explained why this distinction was important and why focusing on just checking presented risks. I demonstrated the risk of focusing on checking only with an example of an important batch process that our team had just finished testing. The batch affected hundreds of thousands of records and was considered critical to the business. There were bugs that had evaded checks but when a team member ran an ET session, a critical bug was found which had the potential to destroy the whole process directly affecting clients. By using the distinction between testing and checking I was able to highlight the weakness of our processes in a way that he could understand.

In order to execute my intended improvements, he asked me to arrange for a discussion with the CIO. The discussion with Mr. CIO was a brief one. After I explained the terms to him he agreed with my suggestions understanding their impact and our objective. Indeed he welcomed the change.

The next challenge was to communicate this message to everyone in the IT and the Project Management teams.

Communicating the change to the wider audience:


My testing thinking has been shaped and greatly influenced by Michael Bolton and James Bach whose work and websites have been a great source of knowledge and information for me.

In this case, I was aware of a letter that Michael and Rob Sabourin wrote to help one of our testing colleagues some time ago. While the definitions and/or ideas behind this distinction have slightly changed since they were first written, the original letter worked perfectly in my context with some slight modifications. For example, in my message to our stakeholders, I added that they were important for us as our work affected them in some way. I also added a reference to an overview session on ET and SBTM provided by Lee Hawkins which some of the email recipients had attended. I was concerned that there might be questions whether we were planning to abolish automated checking and the human checking; so I included a specific reference to those too which were not there in the original letter. You can read the original version here. 

Here is the email message that I sent to Developers, Architects, Business Analysts, Project Managers, Infrastructure team, Testers and the IT Management team:
—————
Hi there,

You must be wondering why you are receiving this message about “Testing v/s Checking”. You may think that you are not a tester and you do not need to know what testers do with their ways of delivering things. But, from Testing and I.T. Team’s perspective, you are an important stakeholder and whatever we do impacts your work in some way.

I recently explained the difference of testing and checking to both Graeme (The CIO) and Con (my boss). I am delighted to tell you that they not only understood this difference, but also asked me to share this with you. We believe that it demonstrates the value that I.T. team is able to extend to you as an important stakeholder.

Testing is not checking. Checking is a process of confirmation, validation, and verification in which we are comparing an output to a predicted and expected result. Testing is something more than that. Testing is a process of exploration, discovery, investigation, learning, and analysis with the goal of gathering information about risks, vulnerabilities, and threats to the value of the product. The current effectiveness of our automated scripts is quite excellent, yet without supplementing these checks with “brain-engaged” human testing we run the risk of serious problems in the field impacting our customers, and the consequential bad press that follow these critical events (reputational risks).

At [the workplace], much of our “testing” has been focused on checking. This has served us fairly well but there are many important reasons for broadening the focus of our current approach. While checking is very important, it is vulnerable to the “pesticide paradox”. As bacteria develop a resistance to antibiotics, software bugs are capable of avoiding detection by existing tests (checks), whether executed once or repeated over and over. In order to reduce our vulnerability to field issues and critical customer incidents, we must supplement our existing emphasis on scripted tests (both manual and automated) with an active search for new problems and new risks.

There are several strong reasons for integrating exploratory approaches into our current development and testing practices:

●     Scripted tests are perceived to be important for compliance with [regulatory] requirements. They are focused on being repeatable and defensible. Mere compliance is insufficient—we need our products to work (better).

●     Scripted checks take time and effort to design and prepare, whether they are run by machines or by humans. We should focus on reducing preparation cost wherever possible and reallocating that effort to more valuable pursuits.

●     Scripted checks take far more time and effort to execute when performed by a human than when performed by a machine. For scripted checks, machine execution is recommended over human execution, allowing more time for both human interaction with the product, and consequent observation and evaluation.

●     Exploratory tests take advantage of the human capacity for recognizing new risks and problems. Exploratory testing is highly credible and accountable when done well by trained testers. The findings of exploratory tests are rich, risk-focused, and value-centered, revealing far more knowledge about the system than simple pass/fail results.


The quality of exploratory testing is based upon the skill set and the mindset of the individual tester. A few months ago I invited Dr. Lee Hawkins to give an overview of the structures and disciplines of excellent exploratory testing and Session Based Test Management (SBTM). My team has greatly benefitted from it.

What about Checking and automation then? Are we going to stop doing that?
No. Checking and automation still have their relative importance. We will:
●     Continue with checking along with extensive testing using better ways of exploration, learning and investigation

●     Still use automation scripts to ‘check’ for regression


Practical Findings:
We have been very successful in finding serious issues with our products with a fairly small test team using exploratory test approaches. As an example, recently we found critical issues in the last CI release as well as in [Mobility] projects within just couple days of exploratory testing in a load that had taken many days previously using scripted tests (test case driven).

We have also been successful in providing the requested coverage with lesser effort without disrupting our other commitments. The typical approach would have yielded at least twice the effort (or close to it) which would have caused a delay in the project’s subsequent release. Our experience using exploratory testing has demonstrated improved flexibility and adaptability to respond to rapid changes in priorities.

I will be glad to answer any questions that you may have regarding this.

Best Regards,
Rajesh Mathur
———————————-

Impact of this communication:

After this message had been sent, I began receiving responses from managers of other divisions appreciating the efforts and success the testing team had achieved in such a short time span. They had seen the testing team transforming from a process heavy team to a dynamic context-driven team. They see our team practicing ET, pairing and SBTM along with scripted checking. They notice us writing our own automation frameworks. They also now see the testing team as their trusted advisors because we provide them the information that assists and guides their decisions. They know the information they get is the result of a cognitive process and careful inspection rather than the process driven checks received previously. The testing team has a roadmap which guides it forward. Where required, the team changes direction to align with the business objectives. Team members are self-motivated for learning and sharing their knowledge; they work collaboratively and have trust and mutual respect. They challenge each other on complex tasks and also provide coaching to others where required. Each one of our team members is responsible for their own work and exercises discretion and judgement. There are no secrets in the team and other teams observe these positive behaviours. The stakeholders are impressed that the team is finding and communicating important bugs faster.


Some managers said that they were not even aware of the difference between testing and checking. Others said that this message enlightened them. One of the responses that I received was from a manager in IT Security who had little interaction with the testing team. His response was:

Rajesh,

Very informative email as always and congrats on the success.

Testing team has played a pivotal role in the releases and will continue to do.

It is great to see comms coming out of the team as well which has definitely raised the profile of the team and makes us all realise how important the testing team is and the value it brings to the organisation.

Looking forward to reading more success stories and informative material.
———————–

It is obvious from the responses I received that it is not hard to make stakeholders aware of what good testing is if you make an effort to explain and demonstrate it to them. Some people criticize, question or complain whenever there is an effort to refine testing terminology.  There are two categories of these people; those who do not truly understand testing as a cognitive task (let’s call them blindfolded testers) and those who prefer to keep it obscure to benefit their own ends (let’s call them snake-oil sellers of the testing industry).

In my experience, the blindfolded testers represent many testers outside of the Context-Driven Testing community. For them automation is important because they believe that automation can test even though it can only assist in checking.  These people also believe that merely memorizing a glossary of terms is more important than the cognitive process which guides the exploration and investigation while testing a product. These testers like to follow the testing process models, templates and documentation that some international standard prescribes instead of performing intelligent testing which fits their context.

The snake-oil sellers are those who either sell the certificates to the first category of people or employ them in their test factories. They encourage standardization of testing because standardization is easier to sell to their gullible clients. Any discussion about cognition in testing unsettles them because they do not understand good testing. Be aware of these snake-oil sellers as they will discourage you from applying the distinction between testing and checking undermining the value of testing.

Michael said in his initial post about this subject, “I can guarantee that people won’t adopt this distinction across the board, nor will they do it overnight. But I encourage you to consider the distinction, and to make it explicit when you can.”

It may take a while to bring people onboard when you do something different, but it is not an impossible task. This case study just proves that.

References and Suggested readings:


Guest post- Adaptive Automation Framework

by | Syndicated

This blog post has been written by my colleague and software automation expert Scott Miles. As ever, both Scott and I will be glad to receive any feedback, comments or suggestion regarding major flaws in logic, about similar tools, questions about the proposed solution and about any grammatical or formatting errors that may have escaped my eyes.



-Raj

————————————–


Improving the cost-effectiveness of automation using adaptive tools


Automated checking (often incorrectly referred to as automated testing or test automation) is widely acknowledged as a useful tool within today’s software industry to augment an organisation’s testing processes. Many organisations implement some level of automated checking or are striving to do so with the same goals in mind; to improve test coverage and reduce the cost of testing. The expectation is that automation will accomplish these goals by allowing checks to run without manual effort, outside of regular business hours, be repeatable on demand, reusable across environments or configurations, run faster than comparable manual checking and more accurate than manual checking. Yet from my experience within the industry and through discussions with other industry experts, I have found that many organisations are dissatisfied with the cost-effectiveness of their automation frameworks. The return of investment an organisation achieves rarely seems to meet the claims made by the tools used and often falls short of expectations.


It is well documented that automation is not a cure-all remedy that is suited for every context. In fact there are a lot of circumstances in which the benefits of automation will not outweigh the cost. Instead of being considered as a silver bullet to fix all of your testing woes, automation needs to be considered as another weapon in your testing arsenal that may provide benefit when used in the correct situations, but may also wreak mayhem when used incorrectly.


Almost all of the negative sentiments about automation that I hear tend to stem from a single complaint; automation frameworks do not do enough for how much they cost. In this context cost may refer to financial expenses, effort or other resources. While this revelation is not surprising for anyone who has been involved in creating and maintaining an automation framework, it has led me to delve deeper into the question of why automation costs so much and more importantly what can be done about it.


Why does automation cost so much?

Whilst the main contributors to cost in automation vary between organisations, there are several factors that I have identified as being consistent across the majority of contexts. I believe these key costs to be:


  1. Initial investment to get the framework off the ground
There are many automation tools available to choose from. Some that come  with all of the bells and whistles, some that come with just the bells and others that will only provide a single feature. The price of these tools vary as widely as the features, ranging from astonishingly pricey to free (open source). Selecting cheaper/free tools may appear to decrease the cost of your initial investment, yet you will likely find that those savings will quickly dissipate due to the increased effort required when attempting to build a framework around multiple/partial tools. No matter your choices at this stage, you may be looking at a significant investment.

  1. Maintenance to keep the framework running effectively
The magnitude of this aspect is what catches most organisations unaware. When a seemingly insignificant change is made to an application it can result in days worth of effort to update the affected automation scripts. Worse is that an automation script will often break due to a code change that has no effect on functionality. A common occurrence of this is when a developer changes the name property of an object. This property is only ever used by the code and will not affect the functionality of the product, yet the automated scripts may depend on this property when locating elements in a user interface.


  1. Additional resource requirements
    The cost of purchasing automation tools aside, an organisation will still find heavy expenses in acquiring additional software development tools, hardware for hosting tools and frameworks and additional environments for running automated checks. There is also likely to be additional costs in hiring people to assist in the implementation, as well as training existing team members in the use of new tools and technologies. And when onboarding new team members you may find that the additional requirement of automation skills increases the cost and selection of potential candidates.


  1. The application needs to be modified or reverse engineered
    One more factor of cost that needs to be considered is the complexity or the unreadable nature of the software. In some instances when creating a locator for a simple element such as a button, the only options available to the tester is to find the button based on its X and Y coordinates, and sometimes even that option doesn’t exist. In these scenarios the development team gets tasked with going back through years of legacy code in order to expose handles to these objects for the automation framework to use. The scope of this task by itself can be immense even without including the inherent risk involved when modifying any legacy code. However even in the most modern systems that were built with automation in mind, the tester will still run into the odd unexpected querk. A web page may be generating an object on-the-fly when the user scrolls to a certain point on the page or an application is using a custom object type that the tool cannot interpret. These situations often require reverse engineering of the code by the tester or developer in order to find or create a solution.


These costs can usually be foreseen and mitigated by an effective testing team with a little investigation, collaboration and good communication. However while I spend hours updating automation scripts with simple changes I can’t help but wonder why these expensive tools couldn’t have anticipated the update in the first place. After all, computers have been capable of solving advanced mathematical equations since the 1930’s and with current advancements are capable of driving cars, diagnosing medical conditions and even holding conversations?


With this in mind, I put forth three challenges that are and faced by many commercial automation tools but could be minimised by utilising simple artificial intelligence and machine learning approaches that are already prevalent in other industries.


What can be done about it?

Challenge 1: I never know if my scripts are broken

One of the great advantages of automation is that scripts can be scheduled to run in a specific order and usually at any hour. However when it comes to verifying the condition of your automated scripts this can also be a weakness. It is not unusual for an error to exist within a script and it is possible that these errors will not be detected until the script has been executed by an automation tool. An error within a script may exist due to the tester not being aware that a change had occurred, that a change would affect a particular script, that the tester missed a script when making the required updates or that the tester made a simple mistake during the update.


Due to the sequential nature of automation scripts, in order to verify a particular script, several other scripts may need to be executed first. This dependency can mean that it takes a significant time for the tool to reach the point you are interested in, possibly several hours. If the tool does encounter an error in a script you may not be confident with any of the results that come after the failure. When the script error is corrected the whole sequence will need to be executed again to be assured that all errors have been resolved. There may also be a number of factors such as shared resources and environment availability that require scripts to only run out of business hours or to be scheduled to run when an environment becomes available. The result is that a script may require several run throughs to find all of the errors in the script that have been recently introduced and those runs may need to occur over several days.


But should it be left to the user to find and make these adjustments? When checking changes to an API interface an automation tool could make several validations prior to runtime simply by inspecting the changed libraries or code source. Through this inspection the tool could determine which interfaces have been modified. Taking the inspection a step further could reveal useful information about the change such as if the number of required parameters or the type of one of the parameters has changed. The tool would then be able to notify a team member as soon as the change has been committed and identify every script that will be effected. Likewise when a GUI element has been modified the tool could use the same detection methods to discover the change and identify the affected scripts.


Presenting the tester with this information as soon as the change is made would save large amounts of effort on a frequent basis greatly reducing the maintenance cost of an automation framework.


Challenge 2: My scripts keep failing

An automation script failing is a common occurrence and only occasionally is the failure due to a defect in the application being checked. It is more likely that the failure is caused by an error in the script or even an issue in the environment. A failure in an automation script is mostly due to either not finding an expected element, not being able to set a value in an element or an element having an unexpected value.


When an automation tool fails to locate an item in the application being checked the majority of automation tools will handle the situation in one of the following two ways. They either skip the remaining steps and fail the whole script, or fail the single step and continue to next which in turn will most likely fail as a result of the skipped step.


There are many reasons an automation tool may fail to locate an item, but the most common reasons are:


  1. The object has changed
    Objects changing within an application is the natural outcome of software development. A good automation tool will select the parameters it uses to locate an element carefully with the intention of finding a set of parameters that are most likely to remain unique and are least likely to be modified. However even in the perfect automation tool these parameters are likely to require updating from time to time.

    A solution to this issue has been partially addressed by the previous challenge, however we don’t always have access to libraries or code sources, particularly when checking off-the-shelf products. When a tool has not been able to detect a possible failure prior to execution there are several other approaches that can be used to minimise the impact of a missing element. One of these approaches is to have the automation tool attempt to identify the missing element based on a closest match technique. By comparing the known properties of our element to those currently present on the page it could identify the most likely object that the script was looking for. To further enhance results the tool could cache the set of objects on a page from the previous run and only include the delta set of objects in its comparison.
  2. An unexpected event interrupted the script
    It is impossible to control every condition of your environment and application. Therefore, a tester cannot predict every event that may occur during an automated script. When a script encounters a warning screen, an unexpected dialog box, or even the lack of an expected dialog box, the script will not be able to locate the expected element and fail the step. These interruptions could be environment related or even caused by the application being checked. Common occurrences of these interruptions include: new updates are available, this is not your default browser, the terms and conditions have changed and another user completed this action recently message. There are countless variations of similar messages that can occur at any time interrupting your automated script.

    When these interruptions occur an automation tool could use machine learning and artificial intelligence to identify the best action to take to continue the script. Sometimes these dialog boxes have only a single possible response such as OK, in which case the correct path is simple to identify. When more than one response is possible the tool could refer to a catalog of dialogs for common applications such as Internet Explorer or Microsoft Windows and respond with a predefined action. If the dialog is not contained in the list of known interruptions the tool could refer to existing scripts to identify if this interruption is expected elsewhere and what response is used. The last option for the tool would be a set of heuristics to determine what the best action would be based on the choices available and keywords detected in the text.
  3. An event timed out
    Many organisations help minimise the cost of software development by providing limited and/or shared environments for testing. Unfortunately this means that response times can be sporadic and requests can occasionally timeout. This may occur due to another team performing a stress or performance check on the same environment or it could just be that there is just too much activity on a particular server. What ever the cause, a failure of a web page to load or of a database query to return a result within the expected timeframe is not always reason to fail a script.

    A more advanced automation tool would be able to repeat a query, refresh a page or even repeat a login when the previous attempt timed out. Based on the configuration of the tool an action like this could be repeated multiple times in succession or with a fixed pause between to allow other tasks to complete.


Whenever the automation tool has recovered a possible failure the automated script would continue as scheduled. The final report would show all results including any recovery actions taken. The report would allow the tester to determine if the tool adapted to the failure correctly by accepting or rejecting a change. When the change is accepted the user would have a further choice of allowing the script to be updated with the change, further reducing maintenance time and cost.


Challenge 3: Creating scripts is slow and repetitive

When a page contains input fields there are a dozen checks that jump to mind in order to verify if the field is validating data correctly. By using simple heuristics I can instantly tell that a field labeled age should not accept negative values and a field labelled email should require the text to be in a specific format. Furthermore I know that pressing back should return me to the previous page and the total cost listed on every page should remain consistent until new items are added.


An automation tool could gather information from a page and make intelligent decisions on the purpose of most elements based on the type of objects, the available parameters such as name, and relative labels that are grouped by elements such as a div or pane. Similar techniques are already used by current web browsers in order to pre populate login or payment details on remembered pages. Having identified the purpose of a field, a set of checks can be generated on the fly to determine validation and consistency across pages. An automation tool could walk through entire web pages, applications or forms this way performing in-depth analysis with little to no generation or maintenance involved.


Making dreams a reality

Having read this article you may be thinking that these ideas are not possible with the technologies available today. You may be thinking the ideas are great but no company would invest into developing them. Or you may be thinking that the ideas mentioned in this article only scratch the surface of what is possible. So what are the next steps from here?

I am currently working with my esteemed mentor and friend Rajesh Mathur to produce an academic paper to promote the concept of smarter automation tools. The ideas presented in this article and the corresponding paper have been developed over long conversations and many coffees with Rajesh. The interest and support shown in the software community has also led me to begin work on a prototype tool to demonstrate some of the functionality discussed. Stay tuned to Rajesh’s blog http://www.dogmatictesting.com/ for further articles, the final academic paper and some early releases of a working prototype.

——————————–

References:
1 http://www.satisfice.com/blog/archives/category/testing-vs-checking
2 http://www.softwarequalitymethods.com/papers/star99%20model%20paper.pdf
3 http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
4 http://mathworld.wolfram.com/TuringMachine.html
5 http://spectrum.ieee.org/automaton/robotics/artificial-intelligence/how-google-self-driving-car-works
6 http://www.wired.com/2014/06/ai-healthcare/
7 http://www.cleverbot.com/