I am a Automation Engineer. I use QTP for Automation.
I wanted to know couple of things.
- In a scrum Project which has 2 weeks of work, how can complete automation be done in that time frame (talking only about the GUI Level)?
- Similarly, how can API Level of automated testing be accomplished, especially inside a single sprint? And what exactly is API level testing?
- How to begin with API Testing? I assume QTP is not the tool here certainly.
1
You don’t try to “complete automation”. Instead, you have stories just like everyone else. You might have stories strictly for automation, or better, automation is part of the acceptance criteria of a user story.
You are (or should be) part of a team for which automation is part of what is delivered. Your work doesn’t stand apart from your team. Together you should decide what you can deliver as a team.
A two-week sprint shouldn’t mean “we can write the code in two weeks”, but rather “we can write the code and test it in two weeks”. If you can’t do that in two weeks, either you need simpler stories, better team members, or longer sprints.
As for API testing, pick an appropriate language and start writing code that calls your API.
- By breaking up the automation tasks such that they can be completed in a single sprint.
- See 1.
- Please define API testing. If you’re referring to testing interaction of multiple code units (internal and/or external), then you’re likely looking at integration testing.
A quick google search revealed QTP as a GUI robot. Such tools are black box testing tools, testing the compiled binary of the application simulating a user pressing buttons, entering values in some fields, checking the results shown at some other fields etc. Typically, you don’t have to know in which programming language the original program was written. Creating such tests typically only makes sense after the GUI parts have reached some level of stability.
When talking of API level tests (as opposed to GUI robot tests), we are talking about white box tests of the GUI logic, not through the GUI elements itself, but through an API layer of the application which is very “close beneath the GUI”. Such an API layer is most easily created by applying the “Model-View-Presenter” pattern. This pattern allows testing in a presenter-first approach, which makes it possible to create automatic (unit) tests very early – when doing TDD, earlier than the code for the GUI logic itself. Those tests are typically written by the developers who are writing the presenter, in the same language as the tested application itself, and you typically need only something like a free xUnit testing tool, not more.
To my experience, both kind of testing approaches can test different things. But both approaches can also be used to test a lot of overlapping requirements, in case where I would clearly prefer API level tests (my former experiences with GUI robots were, lets say, a bit disappointing, too much effort for too less benefit). But your mileage will vary.
Concerning Scrum: I have never done that, but I suspect tests using a GUI robot tool are best written after each sprint, while API level tests should be part of the development during the sprint.