role definition code example

Example: role

I am responsible for maintaining our "test automation
framework" based on the POM and adding new test cases
to our automated regression suite.
I performed various types of testing, like; functional
testing, smoke testing, regression testing and back-end
testing.
I am also responsible, in my current project, to execute
Regression test when developers add new functionality to
the application or every end of the sprint.
I run the entire regression suit before each release, in 3
months. I analyze the test result. I provide a pass-fail
report. I monitor the execution to see if anything is
wrong, once it fails. If it fails because of my code I have
to fix my code. (Perhaps during that time, the application was
down, and I ran my script at the wrong time.) If there is really a
defect, I log the defect and test it again until it is fixed.
As a Cross functional team member, I help the functional
testers, teach them basic automation framework, Java
and Selenium to make them part of the team, All to
improve productivity of the team. At least they can execute test
cases and analyze the results.
As a CROSS FUNCTIONAL team member, I also try to help the
functional testing team whenever it's needed, to execute manual
test cases. And if there is any defect that I am able to
reproduce, I log the defect to JIRA.
In sprint grooming meeting I always give feedback to the user
stories to make sure it is something testable and measurable.
For example: there were a user story said after such and such
change in the application the performance should improve. I
have asked the business people what do you mean by
performance improvement? How do you measure the
improvement? After that they have come up with better user
stories (requirement in agile)
Beside that I can tell you one of my responsibilities which I really
enjoy is user story generating sessions, because it is very
interesting from a user's perspective. Because we are the ones
testing the application all the time. I am thinking from the enduse
perspective. I think I am doing good, by putting myself in
the end user's perspective. Therefore, when we attempt user story
sessions, we are making our acceptance criteria much better. So,
Business Analyst go over the user stories, they go over the
acceptance criteria, we ask questions we give feedback, improve
user stories therefore making our team more productive. Because
we have better, clear acceptance criteria. That makes us, our
requirements better, our code better, clearer and we are avoiding
some of defects in terms of the user story generation session
itself, instead of having unclear a user story, making unclear
code, making something wrong.
Also, as a part of the Agile Scrum Team, I participate in the
several walkthroughs meeting for the requirement reviews and
provide valuable feedback to the BA.
That is pretty much about %8o of my role as an automation
engineer in my current project.