✕

Software Testing Series (Session 18): Story Based Automation Using Free Tools

Read Transcriptions

✕

Introduction

Good afternoon Ladies and Gentlemen, Welcome to Techgig webinar series, our endeavor to empower techies. We believe that sharing of knowledge is the key to enhance our skills and grow us as professionals. With this principle in mind we have initiated a series of webinars conducted by industry experts to give youa crisp insight of various domains.The topic of today’s session is Story Based Automation Using Free Tools. Our guest speaker today is Mr. Paul Gerrard, Principle- Unicom Gerrard Testing. Paul has thirty years experience as a consultant, teacher, author, webmaster, programmer, tester, conference speaker, a rowing coach and a publisher. He has conducted consulting assignments inaspects of software testing and QA, specializing in test strategy, assurance and automation. In 2010 he won the EuroStar European Testing Excellence Award.Paul would be there in India in July 2013, he is a speaker at the world conference next generation testing, soof you who would be in Bangalore at that time can surely go and meet him. So without further I introduce youto our guest speaker, over to you Paul.I am here to talk about some technology that we have been working on for about 2 to 2 and half years now and how we can use our product (( )) manager and (( )) of the functionality what we have called story platform for QA to manage requirement some stories and scenarios in an agile way and to handle whether scenarios to software product called robot framework which is an (( )) source test automation framework and in particular to drive websites using the selenium now know as web (( )) library if you like.Everything I am talking about is summarized in the business story pocketbook which is (( )) and myself wrote about a year ago now which you can download if you follow the links to the websites, you can actually get a copy of the pocket book as a (( )) or for free. So let me just walk through want I am going to talk about in the next half-an hour or so. In summary Behavior-Driven Developments is an approach to software design and development which is becoming more and more popular in the agile community certainly but it’s also beginning to emerge as an opportunity for most structured and what you might know as waterfall products and it’s not quite such an easy fact but Behavior-Driven Development is a way of taking the test driven approach for developers and making it more business user value oriented so that stories captured with stakeholders users if youcan be used because that they are in a structured format they can be used to drive test automation and thereby introduce the developers into their test driven approach in a quite a slick and elegant way.Now I am not going to talk about it in great detail about the Behavior-Driven Development. I will summarize it in the next slide and the benefits to developers are great and that gives them a much cleaner interface with businesses in terms of developing software to deliver features and functionality required by end-users using the mechanism of stories to drive that process. So for developer’s it’s great.Now it’s interesting that although the focus of Behavior-Driven Development has in the past been normally test automation site and I am going to talk about that shortly and the people who promote Behavior-Driven Development are now talking more and more about the collaboration between stake holders, analysts, testers, developers in order to define the stories themselves.So I think what you hear more and more is Behavior-Driven Development moving up the kind of lifecycle towards requirement analysis. Right now the software products that support Behavior-Driven Developments are a kind of development focused and in fact they provide connection between stories and test automation code but because the developers kind of own that process, that transformation the stories tend to be managed by the developers themselves. So the tools are developer focused the approach to date has been rather too developer focused and because they are geared towards driving development through stories every story is kind of an independent piece of work if you like. So the tools aren’t really yet designed to handle large numbers of stories to larger requirement spaces and they are also very atomic. So the stories themselves arekind of (( )) and I have heard of teams running projects with hundreds or even thousands of storiesin independent text files in a single directory, so that’s an extreme case but it’s clear that the tools are now popular enough to have momentum and to be implemented out there but they haven’t evolved as quickly as perhaps the thinking (( )). So the tools themselves don’t support the collaborative working that actually Behavior-Driven Development is reallyabout. So what I want to talk about today really is not to under mind BDD but rather to say we can support that approach and as often as not you can hear people talk about Acceptance-test Driven Development as well as Behavior-Driven Development. We tend to sort of talk about more likely about Acceptance-Driven that is it’s the acceptance criteria or the scenarios associating the stories that actually drive the development and then subscript test process.So today I want to talk about a product story platform for QA which is a subset of business story manager so (( )) platform for QA is the free service we are making available on the internet and have that connect with robot framework to implement an Acceptance driven approach.And just for your reference if you are not so familiar with Behavior-Driven Development there is a couple of links here, Wikipedia video search there, there’s a good list of links to further informationthere. Also I am going to talk briefly about requirements and test hierarchy when I look further into the tools themselves and businessstorymanager.com is the website for the (( )) products and there is something here that will explain how requirements and stories can be created and drive the process. So there is more detail on businessstorymanager.com.

Explain the Behavior Driven Development using current tools

So let me just introduce very quickly behavior driven development using current tools just to give you a sense of how these things work, I have no doubt some of you are already familiar with this but may be some of you are so let me do this very quickly.The principle is this the source of knowledge for requirements is captured in the story which is in a structured language and there are several formats but the most popular most likely format is gherkin and the story itself is in some structured text and the text itself would contain a definition for feature and there’ll be a name and then the feature will be described in terms of as I (( )) or some kind I want which is what I wantthe feature (( )) is the 3rd angle which you see why I want it.So what the structured story really indicates for the feature is who wants it, what they want and why they want it, so there is three dimensions. Now beneath that there is a whole series of scenarios which illustrate how that feature would be used and the structure of those clauses in a story if you like, it has a pattern of given one (( )). Given some situation some current state is a first clause when the user does something some event occurs and then the third aspect is (( )) clause. What is the outcome of the current situation plus some kind of stimulation to the software what is the outcome. So (( )) arepreconditions and post conditions, in many respects it’sa test case in the traditional way you might think of test cases. So scenarios are completely familiar to testers and the way that they think.Now business stories are written in business language and they relate directly to requirement. So they are not executable as pieces of software but they are understandable as examples of features in use. So because they are in business language they are still recognizable by usually some stakeholders but they need to be transformed into 4 more test cases if you are going to automate them and I am going to walk through that process now.So in the diagram you can see there is a story and we take a BDD tool and the most popular the (( )), but there are quite a few others now (( )) spectral under this have a BDD connect component. What the BDD tool does, it interprets the text of the story and creates, generates (( )) recognize as test codes. So with cucumber it uses the ruby language so it actually generates some ruby code. That’s great if you are a ruby programmer but not so great if you’re not a ruby programmer, but let’s move on anyway.So the BDD tool generates some test code which lookssome alternatable test code. However you still need the fixtures or test step definitions to connect the test code that’s generated to the system on the test. Obviously a story might say the usersuser confirms a transaction on a screen may be well that’s not enough information to identify a (( )) that must be clicked on a web page.So the test fixtures provide that kind of definition whether the key words used in the story the fixtures, keyword definitions the test step definitions provides the translation into some physical accuracy on the system under test. So now we concentrate in to the test code. We create structures, test step definitions, keyword definitions. What are the different technologies or different names these things and we can exclusively testthe system under test using the BDD tool or a library that it’s connected to the BDD tool? So this could be a selenium library or it could be allowed to drive windows, VB applications that kind of thing and these are to test almost every platform in (( )).We can know the tests which can test outcomes the developer who is taking this test learning this test knows even for the first time that the failure caused because the system and the test the feature and the test does not yet exist. So what the (( )) test becomes is the developer runs the tests, looks at the outcomes and then create code, writes code, manages and edits the code to pass the tests. So this kind of cycle of activity of test text trials (( )) this cycle allows the test developer to evolve the software itself and these tests are checked if you like, you know they are not very sophisticated test, they are not end to end tests. They are very much focused on the features and the development but the notion of test automation at a feature level at a story level allows developers to adopt the test driven approach. So the nature of this would be when the test pass the developer then you would expect to refactor the code.So as the code evolves to passthe tests usually there is a final phase of development to refactor to redesign to tag (( )) so on and so forth to make the code slightly of a higher quality but the test themselves provide a regression safety (( )) if youfor them to do this. So BDD development works this way.Now the benefit to developers is that they can use it to drive the test-driven approach to a (( )) provides essentially it allows the collaboration between business stake holders, testers and developers and analysts to derive requirements that have meaning and the transformation in to test code is something that the technical people can do.So this encourages the collaboration in an agile project but it’s kind of universal it’s emerging as an opportunity forproject types. Now the beauty of using structured storage which is recognizable by business users in business language in the domain specific language. It encourages the developers to write their test code and to write the software using the same words, names or entities and functions and features as was used in the requirements.So BDD encourages the use of domain-specific language right throughout the requirement through to code and the buzzword that you’ll hear quite a lot about increasingly I think is this concept of ubiquitous language that is the language used and requirements could be recognized even down to the code level and this code encourages better communication throughout a project between business people and technical people.The problem is that the current tools only really support the test automation side of this process. They don’t really provide a lot of support to the collaboration side between the business analyst’s, testers and developers. So what we have been promoting for a couple of years now is an approach which is (( )) than the rather limited BDD approach to say we’ll wait a minute non (( )) systems need a set of requirements that are more comprehensive the business (( )) themselves that are more comprehensive than just stories but our argument says that you may requirements and you need stories and the stories provide two major benefits on top of the requirements.Firstly they example and illustrate the requirements, so that can be used as a feedback mechanism to validate requirements and when the requirements and the stories are aligned and there is (( )) that the requirements and stories are accurate the storage can be reused to drive the behavior driven approach.So when business story manager and this story platform form for QA which is what I want to show you. We have a requirements module (( )) textual requirements, formatted in any regional way and provides a hierarchy of requirements too. Now beneath that we can create stories which identify features which are aligned with those requirements and its arguable that why the requirement comes first then the story comes in second or the story comes first and the requirements are derived. It’s kind of cyclical and iterative in many ways users will tell you a story when you ask them what they want but to capture the rules of the process that they describe in their stories you need a more formal language and a defined business rule to provide the generalizations, the stories quite often don’t give you. So requirements and stories are fundamental to what’s in the product.We also have a (( )) which manages (( )) dictionary but it basically holds registersyour terminology (( )) of your terminology and indexes the use of that language in requirements in stories and big scenarios and therefore tests. So the dictionary provides a navigable index a bitGoogle for your requirements to your knowledge base. So that’s what a dictionary does. So we have our structured stories and we have a feature to export those stories in a range of formats. Initially we are looking at generating test cases in a format that robot framework would recognize. So in a fact what we have got is we have a requirements hierarchy stories aligned with individual requirements scenarios with example features in those stories and those scenarios can be exported in a format that robot framework would recognize. Now justthe BDD process the test cases in robot framework format require definitions so we have a resource file typically which provides the translations of keywords into any fact selenium or web driver commands to drive the system of the test. The beauty of robot framework is it has a Mac driver selenium library for handling websites but there are many other libraries and that’s why we found it attractive to look at robot framework initially.Now once the test case is accessed the key word definitions are accessed you can run your tests against the system on the test and principle we have (( )) same process. We have a series of outcomes and status ofour tests to allow developers to build the product but also (( )) a platform a regression testing platform as a natural outcome of working with requirements and stories in this way.Now the output of those tests once the software is tested and passes the test we can pass the status back into SP.QA. So we can record progress against the scenario stories and requirements in SP.QA. So we can connect and we have that feedback loop between test run at a relatively low level against requirements which might be at a very high level. So we can provide that traceability between one and the other.

Explain about the Business Story Manager and Test Frameworks

The relationship between business story manager and test story very much in general is what I have shown you now is this relationship between requirements and stories into the left something I haven’t mentioned is (( )) at the business (( )) as well. So we have (( )) network and a risk management module as well, that’s beyond what I want to talk about today. We can trace a path rightbusiness goals to requirements to stories to generate its story by test cases that are generated, we have manually maintained resource files which provide the translations and for robot framework this is a natural way of the architecture working, robot framework has multiple drivers for different technologies and the logthe execution of test (( )) framework in particular or in any framework atcan be fed back into business story manager to provide to close the loop to provide that feedback between requirements and may be in a business goal itself and the tests of software that support that business goal.So that’s the vision for frameworks in the future and right now we have the interface to robot framework. So that’s enough with the theory and let me just walk you through the processes we are intending to use it and how we use the product sp.qa. I should say that the sp.qa is the actual URL it’s a very short URL. You can see some images and some explanations of how the process works on the website sp.qa. Let’s start with the requirements. So these are our safest screenshots,. So I am going to show you some screenshots of the products but these are real screenshots and we can show youthat if you are interested.On the left you have hierarchy the tree of requirements and you can see the requirements are highlighted input lucky numbers ticket. So this is a feature of a dummy application we have created for the purpose of demonstration but also for our own testing I should say. Input lucky numbers ticket is a screen allowing you to submit a ticket to a national lottery. So this feature is one of many within the whole lottery system. So you can have a hierarchy of requirements and as you look to the right the definition of this particular requirement is there in detail on the right. So that’s a requirement description.I am looking now at a feature which is described in one of the stories the reference that (( )) ticket requirement. So on the left you can see the feature identified and on the right you can see it’s rather small I’m afraid but you can see the detail of the story which has the as a lottery ticket retailer I want to enter a lottery ticket so that the ticket is registered on the system.So now we have a feature, if you go to the next slide I can look at one of the scenarios, one of the scenarios describes invalid ticket entry invalid tickets. So to the right you can see the given (( )) format of the scenario given the ticket has numbers. Numbers in angle brackets when the ticket is scanned then the ticket is accepted; accept/reject message is displayed. So the text enclosed in angle brackets is referred to place holders for data. So this scenario sometimes called a scenario outline is a template for a series of scenarios into which you can substitute data. So the data just beneath the scenario itself has three columns, you can see numbers, accept/reject message. This is the text of the data that should be substituted into the scenario. So if youthis business scenarios (( )). Unless it’s a kind of a more compact way of describing scenarios rather than having many more complex scenarios. There are usually patterns which we can rationalize and refactor our scenarios in to tabulated examples which can drive a scenario outline.So that’s the hierarchyrequirements through to scenarios in the data and I kind of skipped a step, a subtle kind of change happens in the system. In that we have this concept of locking of requirements and stories. When you lock a story the business scenario is frozen in time and you cannot change it. However the scenarios for those locked stories are copied into what we call test scenarios and the test scenarios provide allow you to put in the additional detail required in order to drive a website or an application with some description.So what you have here is a test scenario which relates to a valid ticket I think in this case a valid ticket on the feature input lottery ticket. So there is a lot of color coding going on and the color coding refers to two things namely the blue color coding identifies the place holders for data (( )) themselves, you can see there is a table towards the bottom of the screen this is just one test case here.

Mention about the Lucky Numbers Application

The orange and green highlighting is the dictionary doing its job; it identifies words that are defined in the dictionary. So I am not going to talk much more about the dictionary atbut that’s what the color coding refers to. So if youwe have got the hierarchy we have got business scenarios and we have also got test scenarios which logically provide you a set of test cases but in principle you could cut them out and hand them over to an individual saying go and run these tests, they are story level they are feature driven tests they are kind of low level but that’s possible. So that’swe are at so far.Looking at this application has half a dozen features, one is register to play games, you can create your ticket and essentially what is required is five numbers, there is a bonus number and then the number of times you want to play we can (( )). You can view your game plays, you can change your profile, set and reset your password and so on, it’s a very simple application but it has enough functionality for us to use it for our purposes to test but also to demonstrate. So this is the submit your play screen looks very simple.When you submit a valid play you get a report basically a play screen advising you that the play has been successful and that you have got your ticket into the system and so on.

How to Export test scenarios

So it’s a simple application and tutorial application we used. So (( )) explain how the examples I have show you relates to a real piece of software. Now story platform for qa has requirement stories scenarios and test scenarios is a process within the tool to export your test scenarios because show you that very quickly. In a test module in sp.qa in the test module and you can see the robot framework given and highlight to the export robot test cases concept.When you click on that you see a screenthis. Now I have just shown you one scenario to be exported. Normallythe scenarios for stories are locked are available to export. So locking allows you to go triggers this process if you like. Now you can export the stories in windows or Linux or Macintosh format, I can also use more than one mechanism to get the data out. So I can always found very convenient to use drop box to export files in to the drop box accounts. We can also zip these files and send them through emails as well and that works very quickly indeed but I want to show you how a drop box connection works. It’s just small element if you like.So when I click on export robot test cases and then we will direct it to my drop box account which was in the question do I want to authorize business story manager to put files in my drop box accounts and you accept (( )).The process business story manager story platform for qa places files in your drop box directory that you have control over and in this case I have exported four. So this is a listing that works in the drop box directory.So having done that I can now go to drop box and personally I choose to work within my drop box account to manage my tests and to run my tests and capture results too. So this is the explorer list of the 4 files in my robot box directory and you can see input ticket.txt is the first one. The four zeroes I’m not going to talk about it but these are secret numbers you can use to drive the secrets of test execution if you choose to but I have a input ticket.txt and that relates directly to the feature input ticket in story platform for qa and the other features you can see there is a valid login, show myplays register I’m looking in this website. So these are the exported files but if I show you another directory in parallel with the exported robot test cases I have a resources directory and the scripts reference files in this directory. So these resource files contain the definitions of the key words used in the test cases themselves So this isI connect the test cases directly to the system under test using in the example I am showing web driver selenium commands. So you can see that every test case file (( )) logging as an example has a corresponding resource file, so you can see towards the bottom of the list here (( )) login underscore resource.txt is the file that contains the definition of the keywords in the valid login test case file. These are the files that we would edit manually and debug to get our (( )) working.You can see yourselves on the top of this list there is a common resource that has system wide and environment wide kind of definitions if you are familiar with robot framework and you need these to give you some very basic definitions of keywords and you can also notice that the third file LKYTE_resource that is an application resource file. So if youyou provide definitions at three levels, at test case level at an application level and an environment level.So if you recall the schematic the way that we work with frameworks, these are the 3 levels of resource files that define the keywords.So let’s look at inputTicket.txt so this is the test case file that relates to the feature inputTicket. Now there is just one test scenario which generates this test case and it’s not so easy to check what’s going on in here but if you look towards the bottom you can see the heading with three (( )) test cases. Three test cases InvalidTickets dot zero zero one dot zero zero two dot zero zero three these correspond to the three rows of data in our examples and as you read across each of those test cases you can see that it uses a templates InvalidTickets. Now as you scroll up just before the test cases there are some keyword definitions and one of the keyword definition the only one that is there is invalid tickets.That is the template test case but the test cases are called towards the bottom of the page and the content of the InvalidTickets test case definition corresponds to the (( )) that test cases at the bottom of this page. Now you can also see in this file towards the top that every test case will reference the common resource file and a resource file which is unique to this test case file. So this is inputTicket.txt it references resources inputTicket_resource.txt file.And that’s how the structure is a (( )), so this file we are looking at right now is generated and usually you would not edit it, you would not change it because it doesn’t need to be checked. The editing comesthe (( )) towards the resource files which provides the definitions. So you can see in the template it refers to inputTicket_resource.Inputnumbers that is defined in the resource file. So in resource file inputTicket_resource.txt there is a keyword definition input numbers and you can see it takes 5 arguments and in fact each argument is processed the same way and you can see if you read across input text is a selenium web driver keyword command plays_playnumber3 is the identifier for a field on the screen in the system under test it’s actually you could see it, you could track it down in the HTML for the webpage we are looking at and dollar curly brackets three is the 3rd promoter. So when the code inputNumbers with the 5 parameters the third command would be we put a value into the 3rd field. So inputTicket_resource.txt the file towards bottom right iswe define our keywords and make the connection to our system under test.I could have shown you a windows environment running robot framework tests but for our development and testing we actually use Linux. Now robot framework works just as well and I could demonstrate it on windows and I think also on Macintosh as well, which you see is Linux so it’s not so easy to see I guess but to the right we have terminal window which we have used to drive the tests and what you are seeing on the right the green passes is (( ))the test so I typed my box space robot in the directorythe robot test case is executed and the test would run.So on the right is the command line window and on the left it’s a system under test and in this case the tests havepassed and at the end of the robot test you can see the output the 3 files you produced an output file which is xml it’s the raw data of the log itself as a log file which is arranged in our webpage which you can open and query and a report file as well which has a summary if you(( )).So let’s see what robot actually produces. This is the log file and you can see in this casethe tests have passed towards the left in the blue you can see links which refer to the 4 test cases that we have actually executed and you can see in each of those there are multiple test cases run within each test case file as you scroll down the report you can go down to every single keyword execution and look at the status of each and it’s a very handy way of debugging a test to use the robot test log in this way. Now that’s fine and well but how do I get the content of the output filerobot framework back into story platform for qa.There’s a rather boring process which is part of the way we run our tests is we provide a service which you can code and post the output dot xml file directly into story platform for qa.Now I can’t really show you that because there is nothing to see, it just does it it’s a single command on it, it just injects the contents of the xml but into business story manager story platform for qa and story platform for qa matches the outputthe robot framework test to the requirement stories and scenarios in our product. There is some (( )) as well so you don’t accidently overwrite someone else’s test that kind of thing. The xml is used to provide status of each and every scenario as executed by robot framework and that’s the feedback process happening.Now in story platform for qa when we can look towards the right of the robot framework (( )) a scenario test status is the last button on the ribbon clicking that will show you your list of scenarios and show you the status of each and in this case you can see that each of the scenarios has a pass against them and to the right there is a link to the detailed content of the test execution of itself.

So if I imagine I am supposed to takethe view test detail you get a dialog box which pops up and presents the detailed outputrobot framework and you can see for this scenario in particular a valid ticket is passed, if you see the series of steps (( )) in time there is a keyword based tests (( )) you can see there is a resource file login, sorry a valid login keyword defined in the application source file.

Source file login go to play input numbers input (( )) input number of (( )) submit numbers numbers are good submit play at home page and you can see each one of those steps has a pass in (( )) which is very convenient for me of course.

So that’s how the process the loop in the process is closed. So we can now report the status of testsits scenarios, stories, features and requirements as a whole. Now pretty much that’s the whole process end to end and what I have tried to show you is a walkthroughrequirementsthe top left to this picture down through the test execution of a system under test in the bottom right and back again and so what we can now do and demonstrate using free services and products how you can capture requirements, stories, scenarios, automated tests and provide that traceability back and test back to requirements. So in summary sp.qm robot framework combines support requirements of any complexity because as a requirements management module which is not so sophisticated but providesthe core features of a requirements management product and you can capture priorities you can (( )) the hierarchy of requirements it stores a change history and every requirement so you can see to change what and when.So beyond that as we have QA implements this keyword driven approach test automation. So robot framework picks up those keywords defined in scenarios in sp.qa and by adding the keyword definitions in your resource files you can connect the business oriented tests directly to software in your application test. I’ve shown you selenium, what selenium web driver kind of a library but there are many other libraries there are at least I think there are about 12 or 13 libraries to test different technologies.An acceptance driven approach is traceable, requirements of tests are back and we can automate the story acceptance and regression testing, we can work with developers and drive their behaviors by defining tests connected directly to requirements. And a whole notion of what we end up with this a set of automated end to end acceptance tests with reusable keywords. I haven’t shown you how to do thatI have shown you is story based test automation. Now each story references a single feature typically but if you have those keywords and the keyword definitions in your resource files, do you have the building blocks to create full end to end tests of your application. So by having those keywords and reusing what the developers are using in their test automation you have the building blocks to build more complex and convoluted and comprehensive end to end tests.The website for story platform for QA is sp.qa. It’s a subset of the functionality of business story manager and it’s free to use.This is the home page for SP.QA behind each of the big panels is a collection of screenshots with some explanation of how the process works. Essentially it just reproduces what I have shown you now. This is the image gallery and each of these images can be blown up and you can see the detail of how requirements are managed, processed and taken through towards the test automation.So the scope of SP.QA is what you get is the requirements module, you can create business stories and scenarios aligned with each requirements, the test scenarios are the more technically oriented tests and tester language is opposed to business language provide (( )) to the system under test and the robot framework interface which I showed you can export your test scenarios and recover the outputrobot framework test execution and import it back into SP.QAThere are some limitation this is a free service but there are limits of course we limit you to a 100 business stories so you can have as many requirements as youas many test scenarios but we have a limit to a 100 business stories. We are suggesting this is workable for a small team of 5 users and you get basically one application 1 project and (( )) stories, so it should be enough to run a very small project for free and clearly it’s a stepping stone to (( )) product.Business story manager is much broader around it comprehensive product. So sp.qa is included in business story manager we have a stakeholder risk management module which can do (( )) networks and risk management, we have an iteration/sprint task management module which can manage scrum sprints if you use scrum. There’s a dictionary and a library management, so you can upload files you can define your business rules terminology and so on in the dictionary and have it cross referenced in the product itself and there is also (( )) by success control. So you can manage people’s access to stories to scenarios tests andthe features of the system are controlled that way, there’s no limits on what you can use, it’s a (( )) service product and essentially we have some packages but essentially the price is 1 pound per user per day.

Video length - 01:17:58

671 attendees

Conducted on - 11 Apr,2013

5329 views

About Speaker
Paul GerrardPrincipal, Unicom Gerrard Testing
Unicom, Speaker at World Conference Next Generation Testing, Bangalore, 08-12 July, 2013.
In most Agile projects the test automation is most often performed by the developers. Where features can be tested through the API and developers practice BDD or TDD this can work well. But BDD/TDD approaches focus more on development activity than testing. System testers need to automate acceptance criteria through the user interface to make it meaningful to stakeholders.   In this webinar, Paul Gerrard will show how business stories can be used to drive GUI test automation using keywords and how the free version of Business Story Manager SaaS platform and the open source Robot Framework provide an end to end solution.  System and acceptance testers implement Acceptance-Driven Development approach using free tools.  Key Questions answered:  Who should attend? 

Tags
AgileSoftware TestingAutomation
This page might use cookies if your analytics vendor requires them. Accept