Archive

Posts Tagged ‘Programming’

Building Testing Competency

September 5, 2010 2 comments
Process-data diagram of Open source software d...
Image via Wikipedia

Building a testing competency isn’t easy and doesn’t happen over a period of a month or so.. its a continuous approach and over a period of time it can be achieved. But how long the period will be nobody can say and cant set a definite target as well but yes certainly can put some plan in place and try to achieve the target.

While plan for building a testing competency there are so many things to which has to be taken care of and points listed below are more or less part of all types of plans.

  1. Scope
  2. Knowledge on Subject matter
  3. Resource
  4. Process
  5. Best Practices
  6. Proof Of Concepts
  7. Dependency
  8. Environment
  9. Tools
  10. Domain

Scope: while deciding the scope the first thing you need to look after is the which area or types of testing you need to start the competency. If you consider everything related to testing while starting then things will be very complex and building competency will be difficult if you are a single person. But if a team is working on building competency on different types of competency and at-least one person is concentrating on one type like regression competency, open source tool competency, performance competency etc then it can be achieved.

Knowledge on Subject matter : The person who is going to build and design the competency should be very strong in the subject matter of the competency. The basics of the subject matter should be very clear to him based on the process, technology, methodology, frameworks etc. If he is confused then he can never drive the team and make the basics clear for others and his client presentation can not be very effective.

Resource: This is one of the most important aspect since its the resource who is going to build with other resource. So the selection of the resource should be done properly. Not all testers can be part of this. Resource with good experience, strong understanding, ready to accept challenge and have more then basics knowledge of coding should be considered.

Process: The process should be defined and adhered to reach the target faster and effectively. Now when i say process it includes rules and regulations to be followed , documentations and its standards, checklists, reviews, audit standards etc.

Best Practices: The learning’s from previous projects or POC‘s , from previous companies and if you are part of some competency before those experiences count a lot and can be handy while building a new competency.

Proof Of Concepts : Doing POC’s is vital but starting the first POC is always a challenge. Deciding what aspects of the subject should be covered in the POC is very important.But if you have prior experience of POC or strong understanding and knowledge of the subject matter, will help you in doing this.

Dependency : The most important aspect for excelling the competency is reducing the redundancy. I have noticed the most of the competencies depending on a single resource and once the resource left the company the competency became unstable or unsuccessful. So reducing the dependency is a must.

Environment: Another aspect which is of prime importance. When I say environment I includes the hardware and software requirement. Because of the security reasons most of the companies don’t allow open source software or 3rd party softwares  to be downloaded. Since servers are costly availing those is not easy for the competency team. So companies have to be relax their rules a bit for the competency group, which needs lots of approval and it has its own challenges.

Tools: Availability of tools for the competency is very vital. Normally getting the paid tool is a challenge or installing open source tool is also a problem because of security issues. Even getting the supporting tools is also tough. I have always face challenges for tools.

Domain: Some customer values and prefer domain specific competency related to technology, like Automation testing competency for Heathcare domain . So they get the confidence that the company has done extensive study on how to handle automation related project for healthcare domain. So while doing POC’s those kind of things can be kep in mind  and case studies can be prepared based on that.

I believe these points are mandatory for building a testing competency. The points are not in chronological order. Please provide your inputs and correct me wherever i am wrong.

Enhanced by Zemanta
Advertisements

Scripting Techniques in Test Automation

From easy techniques as record and playback to more advanced techniques like keyword driven testing we have numerous options as far as test automation is concern. The test manager has to choose wisely the technique to minimize the cost for development and maintenance. The various test automation techniques are as follows.

1.      Linear

2.      Structured

3.      Shared

4.      Data Driven

5.      Keyword driven

Linear Scripting

Linear scripting approach is simple record and playback approach of test automation. It can contain some redundant functions etc which may not be required at times.

Pros And cons of Leaner Scripting.

1.      A non-structured way of programming.

2.      Very low development cost.

3.      Programming skills required is negligible.

4.      No planning required.

5.      Data is hard coded in the script.

6.      Maintenance cost is high.

7.      No sharing of scripts done so efforts are often repeated.

Structured Programming

Structured programming uses control structures in the scripts so testers can control the flow of the test script. The control structures used are ‘if- else’, ‘for’, ‘while’, ‘select-case‘ statements which help in implementing decision making in the script, making some tasks iteratively.

Pros and cons of Structured Programming

1.      A structured approach of scripting.

2.      Dev elopement cost is relatively higher then leaner programming.

3.      Intermediate programming skills are required.

4.      To some extent planning is required.

5.      Data is hard coded in the script.

6.      Maintenance cost is relatively low comparing to linear programming.

7.      Since control structures are used so scripting efforts increases to some extent.

Shared/Modular Scripting

In this technique the scripts representing a application behavior is shared with other scripts. This means the AUT common functionality is scripted as shared scripts and will be called by other scripts to complete the test cases. So the re-usability factor is very high. This makes the scripts modular in terms of common functionality. Such scripts sometimes can be used for other applications as well.

Pros and cons of Shared Programming.

1.      Scripts are more structured then the structured approach of programming.

2.      Development costs are reduced relative to structured scripting since the effort duplication is reduced.

3.      Intermediate programming skills are required.

4.      More planning is needed comparing to structured programming.

5.      Data is hard coded in scripts.

6.      Maintenance cost is lower than linear programming.

Data Driven Scripting

This technique separates data from the scripts and stores the data in external repository in the form of files. So the script just contains the programmed code not the data. This useful when the data changes over time and cycle. Script need not be changed for change in data.

Pros and Cons of Data Driven Scripting

1.      Scripts are programmed in a structured manner.

2.      Development cost is relatively high because of parametrization.

3.      High programming skills are required.

4.     More planning is needed.

5.      Data is isolated in data tables or external files.

6.      Script maintenance is low.

7.      Recommended to be used where positive and negative testing both are involved.

Keyword Driven Scripting

In this approach the control to check and execute operations are mentained with exernal data files. So the test data and the operations of the test is planned in external data files. Extra library is needed to interpret this data in addition to the conventional script. Its an extension of data driven testing.

Pros and Cons of Keyword Driven Scripting.

1.      it combines the data driven, shared and structured programming techniques.

2.      Development cost high since testing planning effort is high.

3.      High programming skills are required by tester.

4.      Initial planning cost is high.

5.      Data exists in the external files.

6.      Maintenance cost is very low.

7.      Extra framework and library is needed and hence more programming skills is required.

This is my piece of understanding about various types of test automation scripting methodology. I am open for your comments to enhance it make it more meaningful .Please provide your valuable feedback.

Related articles by Zemanta


Enhanced by Zemanta

TestCase Developement

Looking at so many projects which runs into problems because of client finding out defects in either production or client testing, though test execution plays big role but I feel test coverage plays a bigger role. I agree exhaustive testing is not possible but the target should be to test all possible path and bigger challenge is to identify all the possible path. The conventional way of writing test cases is not enough to achieve a good test coverage. You need to have a different approach matching today’s application complexity. With my experience I feel if we do just reverse of what we are doing in test case writing cycle will help.

Normally once we complete writing test cases we used to review the test cases based on the checklist which contains all the types of test cases possible for this project. I feel we should have a robust checklist which should be designed based on the domain and technology used in developing the application. While we start writing test cases instead of straightway writing the test cases if we first find out the scenarios and then match those scenarios with the checklist then probably we will have a small test case writing cycle and since the checklist is tailor made for the application we hardly miss scenarios. But this approach of test case writing has a dependency on how good is your checklist and how well it cover all the scenarios possible in the application. The following points can be considered while preparing the checklist.

Functionality – It should contain all the functionality scenarios, or the happy paths of the application which we say the positive scenarios. The positive scenarios can be found out from the SRS or Use cases. We normally don’t miss those scenarios as long as the project modules are tightly coupled. If that’s the case then we need to have knowledge on the complete flow of the application to write all the positive scenarios.

Negative Scenario – This is where we miss the scenarios and having maximum challenge .Most of the associates not able to identify all the negative scenarios possible. So the checklist should contain check points for all types of negative scenarios possible for the application. Negative scenario may be based on functionality, scenario based on data, scenarios related to DB, scenarios related to experience based on the domain, scenarios based on the technology etc.

Test data – The test data should be extensive. We should consider boundary value and equivalence partitioning where ever applicable. Normally what we do is we find out the business data and forget about the negative data and field level validation data. So the checklist should have the check points for such data as well.

Non-Functional – Non functional scenarios are basically kind of negative scenarios and basic level of security scenarios like user click the browser back button, click on the refresh button, user copy the url and paste in the address bar and access the application, user closes browser without closing the application etc. The checklist should cover those points as well.

Abnormal Scenarios – Abnormal scenarios are those like if the LAN cable is disconnected, Internet is down, DB is down and Server is down etc. These should give proper error message to user instead of misguiding the user.

Database checks – we normally forget the database checks for the actions we are doing on the application.  For every database action there should be a database check to ensure the DB entry is happening. And also the negative test should not entering data into the DB.

Experience – Experience plays a big role in preparing the checklist. With experience related to the domain and technology you can add check points which normally happens to be defect with the corresponding technology and domain.

Security – Apart from the authentication and authorization related security issues  the checklist should have check points for the security testing like SQL injection, CSS, LDAP ,XSS injections, concurrency issues etc.

All these points I guess will help you in getting a  good test coverage provided the checklist is prepared well. But don’t forget to do a monkey testing after each cycle of testing and convert the monkey testing defects into test cases.   I have implemented this approach successfully.

Reblog this post [with Zemanta]
%d bloggers like this: