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.
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.
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.
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):
The login page would likely have the following private fields:
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.
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.
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.
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.
