3

I work at a small company as a web developer. There are 10 developers and 2 QA personel.

There are no product owners or project managers. There is one analyst and the CPO. The CPO is quite busy as he's the only one who takes on this role for several projects. He doesn't have time to write detailed specs and many things are verbal. The QA person is present during these meetings though.

There is lack of documentation or specs so often people only know how the product works in detail by looking at the code, through experience, or by participating in meetings. Some of the specs are obvious to someone who is technical though.

I don't see this as a problem but the QA department does.

The QA person doesn't like to test anything without detailed documentation. It takes extra effort and time for me to take time to write these documents which will inevitably change again in the future.

The QA person isn't quite as devoted to the job as I am and he's been working here and on the project with me for at least 2 years and he still doesn't commit it to memory how the product is supposed to work.

He has difficulty sticking to any testing without detailed documentation.

I could just test everything myself (I already do) but I don't like it when bugs come back to me after they have been in production. I don't feel that this QA process is overly effective. Bugs are obviously not being caught.

How can I cope with this situation?

Improve this question
2
  • 12
    "The QA person isn't quite as devoted to the job as I am". Wrong IMHO. You just focus on different things because you have different roles. You want to get things done, she wants to ensure product's QUALITY. Written specs are the very very VERY basic thing to start with. Now you can complain about each other or you can start to work together to fill the gap (because there is a huge gap to fill)
    – Adriano Repetti
    Apr 12, 2019 at 18:11
  • 6
    If the only spec is the code, then the product always works, and there is no such thing as a bug. Because the code always does what the code says it does.
    – DJClayworth
    Apr 13, 2019 at 16:34

7 Answers 7

Reset to default
14

Product specifications need to be written down.

How does anyone know if the software is doing what it's supposed to be doing if it's not specified somehow?

There is always debate and discussion about how features should work. These decisions need to be written down or they are forgotten about (or people just argue about how things are supposed to work).

Lack of specifications becomes very problematic when product behavior changes. How does QA know if a behavior change is intended or if it's a bug?

A requirements document is a contract between all stakeholders in a project:

  • Developers use it to know what code to write
  • QA uses it to write test plans
  • Sales and marketing use it to know what features are in the product and how they work
  • Documentation uses it to write user manuals
Improve this answer
1
  • 5
    If you have independent test, they generally don't look at code, heck, they often aren't programmers and shouldn't need to look at code. They test against a specification (e.g. this button should do this) and write bugs against that. You the programmer then figure out why their test failed.
    – pboss3010
    Apr 12, 2019 at 17:39
5

"I could just test everything myself (I already do) but I don't like it when bugs come back to me after they have been in production."

If bugs come back, then either you're not testing, or your testing isn't good enough.

There are two issues here; One, that you are pushing code to production without testing and QA (two different things), and two, that your QA person requires specifications before he'll test things.

There MUST be a specification for any change done to the system; and verbal changes aren't worth the paper they're written on (thanks, Yogi Berra!). You need to 1. change to a ticketing system so that every change requirement has a user requirement which the QA person can then test against. You should 2., also start writing unit tests, and have an automated regression test suite for use before any code is committed to production. Code reviews would also be nice, but sometimes not feasible for really small fast moving teams.

Just these two simple things will vastly improve your teams code quality and QA workflow. And it won't slow down your team; having a stronger requirement at the start means that everyone involved knows the requirements of the change, so you won't spend as much time rewriting code. It's always more cost-effective to put the design time in at the beginning of the project.

Improve this answer
2
  • 1
    @joe Verbal instructions are of no use to the QA department, because they weren't there. So there should be a written request. A well written request, e.g "Move the home page logo 10px to the right" is simple to put in a ticket, and then gives the QA person enough information for them to QA the change.
    – PeteCon
    Apr 12, 2019 at 23:03
  • But QA is involved and he still doesn't remember anything
    – user1261710
    Apr 13, 2019 at 5:57
4

See it from his point of view. Unless functionality is defined, he has no way to judge if it's working. When he says it's a bug, you can come back with "it's an undocumeted feature". This is not at all uncommmon for small companies who can't justify the expense of a business analyst. Someone needs to put the requirements down in writing.

The question is if that's you, or your boss, or who?

As a developer, you probably shouldn't be doing this. It should be whomever gives you the assignment.

My suggestion is to get with him, put your heads together and come up with a solution, which might be a proposal to the boss to provide this documentation, or to hire someone who has that responsibility.

Improve this answer
4

Involve the QA person earlier in the process.

When you're talking to the analyst and/or CPO about what needs to be developed, have your QA team member present as well. He can plan his tests at the same time as you plan your development, and you'll both have a better common understanding of what's required.

Improve this answer
2
  • I have tried that but he forgets everything and doesn't commit it to memory.
    – user1261710
    Apr 13, 2019 at 5:56
  • 4
    @user1261710 No one should be trying to commit anything to memory. If that's the process your team currently has then the answer by 17 of 26 is best.
    – Player One
    Apr 13, 2019 at 13:46
2

Someone has to write the specs, and QA has to check whether the product agrees with the written specs. There will be cases when the written specs are not behaviour that anyone appreciates; in this case it should be possible to change the specs.

Usually the specs are written before you write any code. Sometimes, the developer writes the specs in a change request which should be visible to QA. And sometimes there is no written spec.

If there is no written spec, or not one that is detailed enough, QA can write the specs if everyone agrees that they should do this. Then they can write the spec, compare with what the product does, and if there is disagreement, report it as a bug. When that happens, the developer can be of the opinion that the spec is wrong, and if the right people are convinced, the spec can be changed.

In the end, you need to have a written spec, and QA has to check it. How you get there is up to everyone.

Improve this answer
2

The CPO... doesn't [take the] time to write detailed specs [so] many things are verbal. The QA person is present during these meetings though.

So, to recap:

  • Nothing is sufficiently documented.
  • People only know how the product works in detail by looking at the code, through experience, or by participating in meetings.
  • You are okay with this situation, because you either don't want to write the (ever changing) specs yourself, or you wouldn't have time to do your job if you did.
  • QA is not okay with this situation, and is demanding testing specs.
  • You all look bad because bugs are getting to production.

QA should have to write their own tests from a set of requirements... because if the dev is writing the test specs, that is the same as dev testing and in that instance QA would only add value as regression testing... And there are automated tools for that. (And that is not what QA should be!)
Devs testing their own code leaves holes - that's why we have a QA position.

But QA doesn't have (written) requirements... so you have to fix that problem.

Whenever you get requirements from your CPO (chief Project officer?) you should write them out in an email and send this email to your CPO and to both of your QA people.
Come up with some naming scheme - whether by web page or by application function.

Now QA has written requirements.

QA looking at the code is a mistake.
QA is most useful as "black box" testing not "white box" testing.
Once they've read the code, QA will just make the same wrong assumptions that the dev did.

QA should use those requirements to build tests - before they even see what you have implemented - and then test from there.
If you both understood the requirements differently, that is great! That should happen.

Now you can hash out what should happen (or ask the CPO) before the code goes to production.

Improve this answer
7
  • This is a good answer but we do CC the QA person on our emails and he still can't remember or understand.
    – user1261710
    Apr 17, 2019 at 19:12
  • @user1261710 Ah! No problem. So what you want to do without sounding like a jerk about it is to refer the person back to the email you wrote/sent when there is a misunderstanding. Do this in a spirit of "did I phrase this well? How did you take it?" Most people after being referred back to answers they have been sent a few times begin to look for the answers before asking you - that's your best path to recovery. The tough part is not sounding like a jerk when you point to the obvious information (which maybe is only obvious to you).
    – J. Chris Compton
    Apr 17, 2019 at 19:18
  • @user1261710 You'll want to start documenting every conversation and every meeting for a while (maybe a month or a couple of prod releases) before you start pointing to old emails... because you want a track record of covering everything that becomes a requirement - otherwise they might say, "well I think CPO changed that later."
    – J. Chris Compton
    Apr 17, 2019 at 19:21
  • 1
    @user1261710 yes, but if the specs are scattered in a long list of emails, some of which no doubt correct other emails, it becomes impossible for the Q/A person to know what the software is supposed to do. What's so hard with you having a document that you cut & paste into that is the definitive statement of what how the product is supposed to work?
    – DaveG
    Apr 17, 2019 at 20:29
  • @user1261710 Emails are NOT a substitute for written specs. A lot of back and forth happens in emails, people change their minds, etc. It's really hard to go digging through old emails to find out the way software is supposed to be working at the present time. Stop being lazy and write a spec.
    – 17 of 26
    Apr 17, 2019 at 22:36
1

Tell this to the QAer...

There are ALWAYS requirements - even if they are not formally documented. They may take some time to discover and list, but they exist. Here's one approach to finding those "hidden" requirements.

First, look for general requirements and work to document them. Some of these requirements come from previous versions of the application, some come from generally accepted usage. For example:

  • Must run on platforms x,y,z (perhaps because those platforms have always been supported)
  • Must use abc database
  • Must be able to process n records in m seconds
  • Must be at least as fast as release n - 1
  • Must not consume more memory (or other resources) than release n - 1
  • Must not crash
  • Must not corrupt data
  • Must use standards relevant to the platform (standard Windows UI, for example)
  • Must be consistent with relevant laws, regulations or business practices
  • Must not have any misspellings
  • Must be grammatically correct
  • Must incorporate the company's usual look-and-feel
  • Must be internally consistent
  • Must work in particular locales
  • Must be complete when expected by the stakeholders (perhaps for some event, such as a Beta)

If it's a web site or application, some additional requirements might include:

  • Must not be missing any images
  • Must not have any broken links
  • Must basically work the same in all browsers which are officially supported by the company

Then, interview the project manager or developers and find out what they intend to do with this release. Document the intentions and use them as requirements.

Solicit input from anyone who is a stakeholder in the project. Share everything you find with everyone and revise it as needed.

Does the product have a Help file or a User Guide? If so, that's a good source of requirements.

Do Sales materials exist for the product? Certainly the product should do what these materials say that it does.

Sometimes, writing all of this up as assumptions can go a long way toward gaining a consensus as to the "real requirements" you can use to test against.

Once the system is at all testable, do some exploratory testing. As you find "undocumented features", add them to the list of topics to be discussed.

Find out if the product is internally consistent. (This is an area I find to be very useful) Even if I know nothing at all about a product, I assume it must be consistent within itself, and within the environment in which it must operate.

Look for external standards within which the product must operate. If it is a tax or accounting program - tax law must prevail and generally accepted accounting principles must apply.

Ideally, all of these issues have already been considered and written into the formal Requirements documentation which is handed to you. But if not, don't give up. Dig in and discover!

You could point him to my blog for more tips: https://strazzere.blogspot.com/

Improve this answer
1
  • 4
    I'd think the QAer already knows there's always requirements. But they have a requirement, too: to find out about the requirements via some mechanism besides reading the code, because getting requirements from the code means your requirements are going to resemble the implemented program, warts and all. They can apply some sanity judgement, but they still have no way to tell what features were really on spec and what were things the developer thought was a good idea late one night while strung out on sleep dep.
    – Ed Grimm
    Apr 13, 2019 at 4:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .