Some feelings about Testing Engineer and Software Engineer in Agile development?

Question

• I am Software developer, have worked for Agile development in some years. In theory, team members should support together. But the reality is different,I always struggle with Testing Engineers about the scope between us.
  • Testing Engineer usually force developers to write unit test, must have 80%-90% test coverage. I don't know why 80%-90%? Why they don't write unit test?
  • Should they provide the solution in coding to improve ability to testability or improve quality? and How?
  • They always be happy and then complains about the bugs? However, If the software have no bug, I feel they are unhappy
• Please feel free sharing your experience

Answer 1

Testing Engineer usually force developers to write unit test, must have 80%-90% test coverage. I don't know why 80%-90%?

These numbers are a rule of thumb in the industry. If you would ask "why unit tests at all?" A short answer would be that unit tests force the writer to deeply think about the goal of the production code he will write and, primarily, deeply think about architecture: If you end up with tons of mocking in a unit test, it's signal you have tons of dependencies - which means your code will be fragile to changes in many other places. Unit tests will allow to write the highly-dependable production code and, afterwards, refactor it to remove dependencies. Higher levels of checking do not provide this well because they are not close to the code, but to the abstractions/integrations.

Why they don't write unit test?

I would guess it may fall on at least of the cases:

• They read on some book that it's developer's job;
• They do not have the technical skills;
• They are 100% filled with other tasks;

The first two cases show that they would need to change their perspective - if their help makes sense in your project, you should talk with them and managers during retrospectives.

The last case would require better understanding of what they are tackling and re-organize yourselves as one single team.

I like to review frontend and backend tests, on every level, to spot missing cases. Migration scripts and boundaries cases in both front and back were specially fragile to missing test cases. Sometimes I am on either one of the last two cases - and I work with the team to change it, because I know the value I can bring to even lower levels of testing - some testers don't...

Should they provide the solution in coding to improve ability to testability or improve quality? and How?

I would not say "provide the solution", but surely they should help both developers and designers to improve testability. Code review is a good tool for this feedback. Writing testable documentation together before writing code or mockups also helps.

They always be happy and then complains about the bugs? However, If the software have no bug, I feel they are unhappy

Well, finding bugs is one of the funniest parts of testing :D

More seriously, not finding bugs (or not having observations) after an exploratory session are signs that maybe the session was not well performed. Software is complex, understanding differs from person to person - and testing is the process of learning about it through exploration and experimentation. So, when a testing session end up with nothing new discovered, it's a sign that we've learned nothing new with the session - which is frustrating.

One ceremony that I've work well to integrate better developers and testers is to use planning time to plan also testing for the following work items. It may help you to talk more about testing in a period where the focus is to understand how the work will be performed. Check out my blog post "A Testing Planning Ceremony for Scrum Teams" for details.

Answer 2

Why don't test engineers write unit tests?

There are several reasons developers are usually tasked with creating unit tests:

• Developers are intimately familiar with the code they are writing. They understand what that code is intended to do and more importantly why that specific implementation was chosen. Ideally they are writing the unit tests while or before the code is written.
• Test specialists (whether they are called testers, QAs, test engineers or something else) are broadly familiar with the application as a whole. They may not have as much experience with code as developers, nor are they necessarily aware of the underlying logic that's needed.
• While testers can write unit tests, it is usually a less effective use of their time, since the ideal time to create unit tests is before or during application development - a time when testers often aren't involved with whatever part of the system is being built.
• The proper time to run unit tests is whenever and wherever the application is compiled. Testers often don't have the authority to check in code to the main application, and they often don't have the ability to add to tests being run in whatever continuous integration system is being used.
• There are usually more developers than testers, leading to functional testing often becoming something of a bottleneck.

Should testers provide code to improve testability and quality?

Ideally testers should provide suggestions to improve testability and quality. Those suggestions may not be the best way to improve testability or quality, because as I said above, testers are less familiar with the application code and architecture than developers.

Testers can certainly work with developers to:

• Suggest tests a developer may not have considered
• Request specific information be surfaced in the application to allow for easier integration and functional automated tests (for instance, if the application architecture dynamically generates HTML Ids, a tester can request developers use a different attribute to provide a unique reference to each element on a web page)
• Use information on unit tests to effectively improve coverage by minimizing overlap (for instance, when business logic is thoroughly unit-tested, integration tests do not need to cover all possible business logic paths, but can focus on ensuring that the correct information is passed from module to module)

Should testers be unhappy if they don't find bugs?

Yes

All non-trivial software has bugs. Software is complex, and the number of paths through a piece of non-trivial software is if not actually infinite, then so large that testing every possible path is impossible. Even with something very simple, like a basic text editor, users can add text and delete text they added as often as they please. It's feasible that something can happen the 513th time text is deleted after the last time the text was saved because of an internal limit - but how many people are going to find this?

Every tester with any experience knows that if they haven't found any bugs, they've missed something. If they've missed something, they don't know how bad it is.

Testing generally focuses on these areas (more or less in this order):

• Does the software do what it should do?
• Does the software prevent itself doing what it should not do?
• Can the software be made to not do something it should do?
• Can the software be made to do something it should not do?
• Can the software handle unexpected events with grace? (for example, if you pull the network connection mid action will you get a generic error message and no partial transactions or do you get a stack dump and bad data?)
• Can the software handle catastrophic events without generating bad data?

A happy tester has gone through to the last of these types of tests, is reasonably confident they have found most of the serious problems, and reasonably confident that none of the bugs they have missed will cause customers to lose valuable data.

I'd add from my experience that testers don't complain about bugs unless they fear that bugs they have found and believe pose a serious risk to the application are not being fixed.