Future of Software Testing!!!

Introduction

Trends in the industry suggest that software testing in the future will look very different than it does today. Businesses are leading change and transformation projects and application development is changing to support it; current trends include:

Web based applications
Service Oriented Architectures (SOA)
Software as a Service (SaaS)
Wireless technologies
Mobile technologies

Each of these trends is further complicated by a more agile approach to software development and an increasing emphasis on the 4Rs; repeatability, reliability, re-use and robustness. This paper investigates how testing will need to change to accommodate these trends and become a business led activity.


Predictions about the Future of Software Testing

This article attempts to predict how testing can become more effective and efficient so that it can keep pace with, and support the changing trends in software development. In order to drive these changes in effective and efficient application development of quality systems, more emphasis must be placed on improving the Analysis and Design phases and ensuring early engagement of testing in these areas.

To date, analysis and design have been people based activities with Business Analysts and Systems Architects producing a combination of natural language, models and diagramming techniques (such as Data Flow Diagrams, Logical Data Structures, Logical Data Models and Process Data Diagrams) and some structured language techniques (such as Use Cases and UML). This has led to business requirements and functional designs which do not meet the four key criteria which make the resultant systems “testable”; clear, assumption free, unambiguous and complete.

In the future, if we are to enable the production of quality applications, in less time and at lower cost, we will see more structured and more automated analysis and design techniques, with Static Testing (reviews, inspections and walkthroughs) becoming “robotized” and built in as part of the analysis and design requirements capture tools. This will result in clarity, the eradication of assumptions and ambiguity and a greater likelihood of completeness which will in turn enable:

Executable specifications
Auto generated code and systems configurations
Model-based test generation
Model-based bug prevention
System simulation
Fault tolerance developing into self-testing, self monitoring, self healing software
Performance optimization “designed in” and “on the fly”

So what will it mean for Testing and QA? Well the products should be more reliable, more reusable and more robust. Automatically generated test scripts with full branch and decision tree coverage at the early test execution stages; unit test and “integration in the small”, combined with the development of fault tolerance into self-testing, self monitoring, self healing software will result in defects being found and eradicated earlier in the lifecycle. As a result, fewer defects should be found at the System Testing and
“Integration in the large” stages and businesses will be able to concentrate on Acceptance Testing (User, Operational and Performance) in a fully integrated target environment and do full end to end testing of business processes and model office scenarios. In this way, businesses will be able to leverage their investment in technology to realize true business benefits and competitive advantage through creative integration and deployment of reliable, re-usable, robust components; the way in which the components are
Integrated and deployed will be the differentiator, not the components/systems themselves. In turn, this will enable business to concentrate on business propositions, and go to market services and products, supported by the ability to deal with high volumes, provide excellent customer service and quickly enable high margin/low volume services etc.

Testing Robots? What about Professional Testers?

Software testing in the era of mainframe systems was merely executing a series of steps manually and punching various key strokes as an attempt to break the application. This was followed by the event-driven client-server environment in which applications were deployed on multiple hardware platforms in conjunction with various other applications. As a result, the scope of testing has increased as failures and unexpected behaviors have become more prominent.

The recent development of web applications, where multilayered designs were architected in order to hold complex business logic, which are to be supported on numerous browser types and various platforms and different network structures, further increases the potential areas of failure. In addition, web applications say something about the integrity of business operations to a large audience of external users (i.e. customers, business partners) and can have a major impact on brand and reputation. New and emerging technologies, such as Service Oriented Architectures (SOA) are significantly changing the trends in the application testing. SOA in particular has major implications for how tests are designed and performed. Software as a Service (SaaS) also has a totally different view of software testing. We can conclude that new and more complex technology/ architecture creates greater risk. So, how will the new approaches postulated in the predictions in the previous section of this paper manifest themselves and what will it feel like to be a Test Professional
in an increasingly automated and “robot” driven software engineering environment? Testing mitigates risk and despite automation and “robot” driven testing techniques, the Testing Professional will continue to be pivotal in the Software Engineering Lifecycle. Working in multi-disciplinary teams alongside Subject Matter Experts, Business Analysts, Systems Architects and End Users they will continue to play the roles of; arbitrator, mediator, translator, negotiator between the other parties, ensuring that their ideas are not only effectively specified and designed, but that the criteria required for effective quality and testing are captured and articulated into the models and tools so that tests are accurately generated by the “robots” to verify the design and validate the requirements.

In this new world, the Professional Tester will concentrate on adding value to the business and the software development lifecycle and will operate in a new and elevated position where the combination of their structured process driven approach, creativity, destructive inquisitiveness and ability to articulate and define quality and testing criteria into the models will be critical to the success of the business implementation of technology.

Change is a given and we can be sure that it will come in larger amounts and at increasing pace. No industry, least of all software engineering, is immune from change and therefore none is immune from risk. The changes in software development will require software testing to develop in parallel. Of one thing we can be sure, the role of the Professional Tester will become more interesting and more essential in both the definition of model based testing criteria and the facilitation of Acceptance Testing (User, Operational and Performance), testing of business processes and model office scenarios alongside Subject Matter Experts and End Users and ultimately realizing business benefits.

Testing and Quality Assurance will become more important and add more value as we move into architectures and technologies that support the business in their goals of bringing products and services to the market as rapidly as possible, with minimal risk. We will see a shift towards testing the transformed business operation, the business processes, the way people interact with the systems and processes and the information it provides, and therefore mitigating the risks and increasing the benefits of business change.

Difference between Use cases, scenarios and user goals

A scenario represents a particular path through a use case or a specific instance of executing a use case.

Each use case encompasses multiple scenarios. Each scenario involves certain data combinations and branches taken through the use case execution. Some scenarios result in success; that is, the user achieves his intended goal. The most typical or default scenario typically is called the normal flow of the use case. Other scenarios or paths through the use case that also result in success are alternative flows. In addition, most use cases identify conditions under which they might fail to complete successfully. These are called exceptions. Exceptions represent another type of scenario, a failure scenario.

It's really a question of abstraction level. A use case is more abstract, more general, than a scenario. When working with use cases, it's always a struggle to determine the most appropriate level of abstraction. If the use cases are written at too low an abstraction level, you can end up with a use case explosion. This can lead to hundreds of use cases, some of which represent just minor variations on a common theme. This is a clue that you need to write the use cases at a higher level of abstraction and treat these variations as different flows within the use case, or simply as data variations that could take place during execution.

Be cautious about dividing a use case. Remember, a use case states a goal the user is trying to accomplish. Don't arbitrarily split a use case up just because it gets big or has many alternative flows. If the ultimate user goal is the same for each of the flows, it's one use case. The only time you should subdivide a use case into multiple use cases is when you realize that some of the flows might logically fit together and be qualitatively different from another subset of the flows. For instance, if you find the word "and" in the name of your use case, you might need to split it into multiple use cases because it really represents multiple goals.

Choosing Software Testing as your Career

If you are willing to choose software testing as your career then this is a must read!

Nowadays we see lot of people getting confused in choosing their career. Should I select software testing as my career? How to switch to software testing from other job experience? Which institute should I join for testing course? And many more …

Here is a common answer to all these questions whether you should choose software testing as your career or not? Let me first explain in brief about software testing. Software testing and quality control are the processes by means of which application quality is improved. Software testing is done in each phase of product life cycle i.e from requirement specifications , design, coding, to the user acceptance.

Many complex software structures require in depth analytical and technical skill to test the applications. Knowledge of programming languages is required for unit testing, scripting skill essential for Automation testing.

Now we will speak about your career in software testing. No one can guide you choosing your career more than you! Its right and you are the only person to decide your career.

Do self-assessment to figure out where you can fit well. Do study of your skills, interests, strengths, weaknesses.

Ask some questions to your self like:
What is your goal in life?
What will increase your satisfaction and skill?
What is your interest?
Which skills you have developed in your life till now?
Which training you did that can be applied to future job?

By answering these questions you will automatically come to decision.

To switch to software testing career What skills you will require? Is the most important question I think.

Some of the software testing required skills are:

1. Communication: Customer communication as well as team communication most important for this job. Written communication as well!

2. Technical skill: As I mentioned earlier for testing technical domain skill in languages is important.

Project life cycle,
Testing concepts,
Knowledge of testing types,
Programming languages familiarity,
Database concepts,
Test plan idea,
Ability to analyze requirements,
Documentation skill,
Testing tools

3. Leadership quality
4. Analytical and judging skill

Don’t worry if you don’t have some of the skills mentioned above. You can always learn the things if you have interest. Non-IT personas can also grow fast by gaining necessary skills.

So finally selecting testing as your career ask one question to yourself:

Are you looking for career in software testing or just a Job?

Skills of a Tester's Skull

Software Testing is one of the key practices in the Software Development Life Cycle that requires diversified skills. Because, developers find it difficult to find out the defects in their own code psychologically, the developers cannot test their code effectively. Hence, there arises the need for an Independent Testing Group, who approaches the code with a different perception to test them effectively.

Provided this scenario,

1) What are the unique skills required for the “Independent” Testers (which may or may not be required for a developer)?

2) What are the best practices that an “Independent” Tester need to adopt?

This article tries to find out the answers for the above questions. Biologically, the skills and talents of a human being is managed by the brain and hence the title “Skills of a Tester’s Skull”. “Tester’s Skull” does not mean exactly the Skull of a tester; it is the Tester’s Brain inside the skull.

Understanding Skills

The first and foremost activity of Software Testing is to understand the requirements/ functionalities of the software to be tested. Formal Documents like Software Requirement Specifications, Software Functional Specifications, Use Case Specifications and other Documents like Minutes of Meeting serves as the key references for planning and executing the testing tasks. The testers must have very good understanding skills to read and understand the information written in these documents. Many a times, it is possible to have many interpretations for the information presented in the documents. The testers must be able to identify the duplicate & ambiguous requirements. If the requirements are not clear or ambiguous, the testers must identify the sources of the requirements and get them clarified. The sources of the requirements in most of the project development team should be Business Analysts, Business Users or any other competent authority as identified by the Project Management team. The testers shall analyze and co-relate the information gathered within the perspective of the project.

Listening Skills

Documents are not the only source of reference for the testing activities. The information required for the testing activities may be acquired through offline meetings, seminars, conferences, etc. The minutes of the meetings, conferences, seminars may or may not be recorded in a formal document. The testers must have very good active listening skills in order to collate and co-relate all of that information and refer them for the testing activities. While the requirements or functionalities of the software are discussed over a meeting, many a times, some part of the requirements are missed out. The testers should be able to identify and get them clarified before heading towards the subsequent testing phases.

Test Planning Skills

All software requirements shall be testable. The software shall be designed in such a way that all software requirements shall be testable. The test plan shall be formulated in such a way that paves the way for validating all the software requirements. In the real time scenario, there could be many requirements that are not testable. The tester with his/her test planning skills should be able to find out a workaround to test those non-testable requirements. If there is no way to test them, that shall be communicated clearly to the appropriate authority. There could be many requirements that are very complex to test and the tester should be able to identify the best approach to test them.

Test Design Skills

Software Testing Science preaches many techniques like Equivalence Class Partitioning, Boundary Value Analysis, Orthogonal Array and many more techniques for an effective test design. The testers shall be aware of all those techniques and apply them into their software test designing practice. The tester shall be aware of various formats and templates to author and present the test cases or test procedures in a neat fashion. The tester shall aware of the best practices and the acceptable standards for designing the test cases. The tester shall be aware of the how to write test cases – non-ambiguous, simple, straight to the point.

The test case needs to contain Test Case Description, Test Steps and its corresponding expected results. The tester shall be aware of how to present the content in these three topics effectively in such a way that they can be read without any ambiguity by all the project stakeholders.

Test Execution Skills

Test Execution is nothing but executing the steps that is specified in the test design documents. During the execution, the testers shall capture the actual results and compare against the expected results specified in the test design documents. If there are any deviations between the expected and actual results, the testers shall consider that as a defect. The tester shall analyze the cause of the defect and if it is found and confirmed in the application under test, the same shall be communicated to the developers and it shall get fixed. If the cause of the defect is found with the test case, the same shall be communicated to the test designers and the test cases shall be modified/ amended accordingly. If the testers are not confident about the application functionalities and the test design documents, they may not confidently come to a conclusion about the defect in case of any discrepancies. This will lead to defects being leaked to the next phase and the testers needs to avoid this scenario. The testers shall be confident about the application functionalities and in case of any ambiguity or clarifications; they need to get them sorted out before executing the tests or at least during the test execution.

Defect Reporting Skills

Defect Reports are one of the critical deliverables from a tester. The defect reports are viewed by the development team, business analysts, project managers, technical managers and the quality assurance engineers along with the testers. Hence, the defect reports shall carry enough information about the defect. Steps to reproduce the defect, its expected result and actual result along with other information such as Severity, Priority, Assigned To (developer), Test Environment details are very critical for a defect report without which, the defect report is considered as incomplete. The tester shall be aware of the importance of the defect report and he/she shall create defect report in such a way that it is non-ambiguous. During the course of fixing the defect, the developers may come back to the testing team for more information regarding the defect and the tester shall provide the same without failing.

Test Automation Skills

Test Automation is a wonderful phenomenon by which the testing cost is drastically reduced. The manual test cases upon automation can be executed by running the automated test scripts. This means that the manual effort to run those automated test cases is not necessary and hence the total test effort is reduced drastically. The testers shall be aware of the technique for adopting test automation into the current testing process. Identifying the test automation candidates is very critical for the success of the automation project. Automation candidates shall be identified in such a way that the testing cost towards manual test execution would reduce significantly. This involves lots of thoughts from the financial perspective as well. The testers shall understand the process of do’s & don’ts of automation to make the automation project successful.

Conclusion

The testers shall understand/ learn and be confident about the application functionalities. Test planning, designing, execution and defect reporting are the basic and essential skills that a tester shall possess and develop in his day-to-day career. Professionals who are perfectionist in using these skills are called as “Testing Professionals” or “Testers” or “Testing Engineers”. Hope now, you are a tester…