4

I have been asked to automate the tests while developer has finished only some part of the change in the current sprint.

I have no framework, but I have been asked to concurrently automate the tests, so by the time coding part is done, automated test cases will be in pipeline for execution and thus whole process will be faster.

Is it possible? And Should it be done in this way? I have to use selenium for it.

  • Are you using Scrum or an another Agile setup? I wonder since you name Sprints. – Niels van Reijmersdal Aug 20 '15 at 14:40
  • Yes, we are using scrum – Fazaikh Aug 20 '15 at 16:40
4

Automated tests should be part of the Sprint stories definition of done.

When the story acceptance criteria are known you should be able to start defining which test-cases you want automate before the tasks is done. When coding is done, developers and tester should make sure the tests are fully implemented before starting on new stories.

If you could build a skeleton test during the coding-phase this might make it faster to implement the end-2-end tests for the story. Think about things you can prepare like Page objects, the Arrange/Act/Asserts in AAA. Even if the naming of the objects is not final, the flow of the story should be clear by now to begin writing some code.

Prevent mini-waterfalls in sprints, certainly do not start testing after the sprint is done.

  • But I dont have a framework....can i use selenium ide to record and then export it.....? – Fazaikh Aug 20 '15 at 16:12
  • To be able to record Selenium tests you need the "final" product, at the beginning of the sprint this is not yet possible. As a team find a good way for you to get started with Selenium tests, in Scrum you should not have dedicated roles try to think cross-functional as a person and as a team. So as a team get started on a end-2-end testing framework, which allows you to get started on automated tests as soon as possible. – Niels van Reijmersdal Aug 20 '15 at 18:51
3

If it is possible to do it and how you can do it, is one part (which Niels already mentioned) but the other part is what developers should do to make it happen.

Explicitly they need to have a testable design/architect i.e. the application is testable even though the full stack is not completed yet. As an example, they should follow 'decoupling practice'. It helps you (as a tester) to mock/stub those components which are not ready yet.

Want a better and faster solution? Help them to write valuable test cases and ask from the team to follow TDD.

1

Its possible, but requires very good communication between developers and QA, and often a technical understanding of how the solution is to be implemented.

For example, if you are working on a login page, and underlying authentication HTTP endpoint, you can start writing test automation for the endpoint before any work is done.

This service would likely have tests to check that a valid request is granted a session token, and that invalid requests get a HTTP 401 response, etc. the service doesn't need to exist to start writing the tests, you just need to know the outline of the functionality and a decent enough idea of how it will do this.

You could also start writing the page object model for the login page if you have a decent idea of what functionality it should provide.. e.g it may likely have the following methods (this functionality would be decided upon and formalised during sprint planning):

  • Login(string username, string password)
  • ForgotPassword(string username, string email)

The login page would likely have the following private fields:

  • private WebElement LoginTextbox
  • private WebElement PasswordTextbox
  • private WebElement ForgottenPasswordButton

You do need to stay wary of how likely various parts of this are to change, and dont waste time developing against something which will end up being completely different to what you have written tests against.

1

One thing that our team does is to write the Detailed Design for the test case in a code file as comments. This is a lot like manual testing at this point, but the start of the automated test is in place without having any actual test code (which would likely change).

Additional information: Comments are the detailed steps wrapped in tags which are extracted by Doxygen and used as the official test case documentation. Detailed steps include

specifics on where test data comes from (e.g., data driven), actions performed and on which controls actions are performed, and details of exactly what will be verified along with the expected result and where the actual result will be found. Code signatures for any expected helper methods are added at this time. With this level of detail already specified before the actual test code is added there is excellent documentation for the peer review of the proposed test case.

  • Thanks for your input! But could you please elaborate....that would be really helpful – Fazaikh Aug 22 '15 at 8:55
0

Definitely possible but it's all about resources(number of testers, good understanding of coding, time for other QA related activities etc.). Also, selenium or similar can be a good starting point as it provides robust framework.

  • Definitely not a record and playback situation and will require some planning before scripting – Akshit Lomash Aug 20 '15 at 22:26
0

Yes it is possible (as saying goes "it is a matter of simple programming", which is a joke btw) but if changes are expected could be huge waste of time. Manual testing is better fit.

Manual/explorative testing allows you to give feedback to developers much quicker, and you are also developing scenarios which might be worth automating for e2e testing (or not).

Not all tests should be automated.

Summary of comments debate: Even if best practices of TDD suggest to create (unit tests) before code, in my experience fast round of agile explorative testing can show shortcomings of UI design and hints for redesign. So unit test will have little or no change, but UI (business requirements) might change significantly, as customer realizes flaws in original UI design. Or not: then just automate (some of) manual tests. In my experience, there are always some manual test left behind which did not made it to automation. TDD is not a silver bullet - nothing is.

  • That's a controversial statement. Making changes to a program which doesn't have automated tests is clown shoes. Step one is write the tests, always. Without them, you make a one line change, then deploy, and find production is down. Who's wasting time now? – Jonathan Hartley Aug 20 '15 at 20:22
  • 1
    unit test, yes, written before or alongside code. Unit tests are written by developers themselves. e2e test, written by QA? Unlikely. Locators are changing, UI design is changing etc. You would be coding e2e tests against moving target. – Peter M. - stands for Monica Aug 20 '15 at 21:58
  • 1
    All requirements change through the development process. I don't think UI is any more susceptible to that than other kinds of development. Managing that change is an important part of dev. Meanwhile the fundamental tenet of TDD is to write the system/e2e tests first. Are all TDDers wrong? Is TDD not applicable for systems with a UI? I don't think either of those things are true. – Jonathan Hartley Aug 21 '15 at 14:16
  • Do we have a holy war with TDD? I never heard of company where all tests were automated and they did no explorative/manual testing. I never said that TDD is wrong - not sure where you get that strawman. I am just saying that before you automate something, you need to know how to do it manually. maybe some of the tests you did manually will get automated. Certainly not all - at least in my experience, there is never enough time, and certainly not concurrently with the development. – Peter M. - stands for Monica Aug 24 '15 at 11:29
  • Hey there. Sorry if I've been abrasive. Not my intent. Hugs! I have worked at companies where all tests were automated, plus written before the code. On the whole, they were the best places I've worked at. I don't agree with "before you automate something you need to know how to do it manually", because anywhere that practices TDD proves this isn't true. In such places, tests are routinely written before the code exists, and hence before any manual tests can be done. – Jonathan Hartley Aug 24 '15 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.