Ken Simeon
Posted on
Are Testers, QAs & QEs relevant in today's software development lifecycles? Asking for a friend.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (6)
Yes. Devs should do some tests on their code, and then hand it over for QA, where it will be fully tested. QA should write a lot of test cases, have automated tests, etc and all that takes time. If a developer can do all the above, yes, but while the developer is writing tests cases, the development of the next task is stopped. Besides as developers we know our code works the right way, but the user will do something that for us make no sense but doesn't matter, and it's that odd beahviour from the user that QA must test and catch.
Isidro, thanks for the response.
I agree that its the directional role of the QA team member to evaluate/test the implementations of a developer's work as a customer. But I wonder how you thing a developer knows their code is right if they don't know or care how a customer will use it?
We can never guess user behaviour. Just because he should press that nice green button, doesn't mean he will. We can develop the features and protect the application to avoid exceptions, errors, and handle all that but we need QA to work with us, make sure that if the user's cat jump in the keyboard, and if option B is selected and he press the green button everything still works fine
oh man . . . you brought out the cat test 😂
So if I could rashly summarize what you're saying. A developer should build their software to handle all of the potential logical pathways. QA would also validate those logical pathways manually & hopefully automated as well. But then a QA should also test the illogical potentials or unpredictable interactions to make sure the logical gates function accordingly (aka the Cat on keyboard test).
Usually by writing the code to meet the exact requirements they were given, and then writing unit tests (which should absolutely be the developer's responsibility) that verify that it behaves the way they were told it should.
The thing is, it's not unusual for the description given to the developer to be under-specified, and as such not unusual that some of the behavior is left up to the implementation, which may cause issues for end users. So it's fully possible for the code to 'work correctly' as per what the developer was told, but still not do everything it's supposed to.
You are very right. The potential gaps in requirements and/or expectations definitely can lead to issues or unintended behaviors.