Kalpana, I don't know if it is your responsibility or not, but if found an issue with the database (after release), surely it will be your fault :-)
The better way to look at this is 'if any other tests are covering that area?'. If not, then check with your manager/leader and clarify. Definition of the scope changes from place to place, but I have seen more undetected issues in these areas (where there is no clear ownership) than anywhere else.
If I were you, I'd get my development team together (including programmers, testers, DBA, everyone who works to deliver the software) and ask them, "How can we achieve the level of quality that the customer needs?" The entire team working together will come up with a better solution than you can on your own. The whole team can decide in which ways each team member will contribute.
This works well if he and his team control the full project but if he is working on outsourced software and the project has been chopped, sliced and scattered across the world, what would you do? A request like this to a project manager in a different country can wait weeks for reply. Especially if he is unknown.
The user will not care two figs who's responsibility it was to test something if it doesn't work. All they will know is it doesn't work. The best way to work out who should be doing what is to walk through the feature workflows and make sure all elements of those workflows have at least one person testing them. System testing is historically the area where the largest gaps in testing have occurred for my teams. I've seen different groups spend days testing identical features from different viewpoints but completely miss something like business logic built into the data access layer using stored procedures or triggers. Both teams assumed it was the other's responsibility.
A black box tester either don't interact with code part of software but it is not mean, His /Her responsibility only emphasis to the functionality aspect of the software. a black box tester is last who clear the built for release. so all aspects that he/her can cover for testing should be the of his/her responsibility.
You might want to ask yourself:
"When I find a bug using (functional) black box testing, because the underlying database is not correct, would I have found it earlier/easier/cheaper if I had checked the database first?"
But also remember to ask yourself:
"If I would check the database for correctness first, that means I will have less time for other (functional) tests."
And maybe if you give those options to someone that decides about your responsibility, that person (even if that person is yourself), can make an informed decision.
sure sarah .
It occurs normally with testers , they have less time to test any built as they needed. so if u have any bug due to problem with database, the principle of defect clustering is fully satisfied in such scenario . so always have a back up plan for such worse condition always.
If its to test the database as well, then why not do just that? If its possible, doing what you are interested helps improve your testing. Proviso though, I would speak to stakeholders (as Lisa's suggestion) they may give you a good reason for NOT testing it!
If you don't want to test it, ask yourself why not? Is it because its too much work? Is it because you believe its not worth it? Or perhaps you don't have enough time. Only you know the answer to that question. It may give you insight into what the real problem is.
You may feel its not necessary, but perhaps if you provide us some context we can help you a bit better.
In my view YES, That’s your responsibility to check the Database too to ensure your validations.
# Password encryption fields : You have to check this form back end to ensure that the password entered by user should encrypt state in the db.
# Shopping cart calculations / Order system : You cart values and the ordered items should be equal in the DB includes any extra items that are coming to free with any of items / in the time limits ..e.t.c