But we don't want to automate it



  • I have been maintaining a system that replaced a system that was a hodge-podge of conflicting requirements that was ad-hoc'd together as the users figured out how to do their jobs. The new system was not built based upon functional requirements from the legacy system. Instead, it was hodge-podged together as the users figured out what legacy requirements to keep, how they should be redically changed (back, forth, back, forth, ...), and what new requirements to graft onto the system, and the littany of special cases to come up with after the fact.

    Finally, we get new high level IT management who actually get the concepts of testing, limiting ad-hoc stuff, and reproducibility and reliability. They lay down the law: everything is to be covered by automated testing, even if it slows down releases.

    Ok, no problem, right? Wrong! Our team lead decides that he wants to keep this day-long sequence of stuff performed by 30 users a manual test, in a spreadsheet, that takes 3 of us 2 days to run through - once.

    I offer to script a lot of it. No. I ask if we can get win-runner (or similar) so that we can automate pushing the buttons and the verification that the gui and db were updated correctly. No. "We don't want to automate the testing because it would take time to maintain the tests. Let's stick with the spreadsheet.

    There were nine of us sitting there when he said it, and nine foreheads hit the conference table simultaneously.

     



  •  Translation:

     We don't want to automate the tests because I don't understand how it works and it therefore must be bad.

     

    I'd start looking for a new job.  There are some people that simply can't be taught a better way to do it.

     



  • So, management has ordered that the tests be automated, and your team lead has disobeyed? Sounds like a simple matter of having your team lead removed and replaced with somebody willing to do what they're told.

    Also, IT in charge of development? Really?



  •  @smxlong said:

    IT in charge of development? Really?

     In my current company, and the last one I worked at, IT was responsible for all application development. Not all companies write software for publication and when it's being written for internal use, or is exposed to external customers, it is not uncommon for IT to be responsible for the development.



  • Better than no testing at all.



  • @smxlong said:

    IT in charge of development? Really?

    The last 'office' job I had we in the IT department was responsible for all development. While we had a name we were part of the IT team, so that's not really that weird in actuality.



  • @snoofle said:

    Ok, no problem, right? Wrong! Our team lead decides that he wants to keep this day-long sequence of stuff performed by 30 users a manual test, in a spreadsheet, that takes 3 of us 2 days to run through - once.

    I offer to script a lot of it. No. I ask if we can get win-runner (or similar) so that we can automate pushing the buttons and the verification that the gui and db were updated correctly. No.

    That's pretty fucked up.  I let productive, competent developers, who know what our needs are, decide how they will do their jobs.  I don't know which offends me more: that the team lead denied your request, or that you had to ask in the first place.



  •  Personally, I'm a firm believer in both.  I think a good mix is 80% automated / 20% manual.

     Automated can run through a large number of permutations of inputs.  Manual is necessary to test out not just the results but the workflows, the usability, etc. I've seen people sign off on work flows on paper, only to have them blow a fuse when presented with actually having to do that workflow even just for one day.



  • @PsychoCoder said:

    SELECT * FROM Users WHERE Clue > 0

    ERROR: 0 Rows Returned.

    Now, why would an empty result set be an error? What kind of crazy DBMS are you using?



  • @Schlagwerk said:

    Better than no testing at all.

    All too true. What I wouldn't give for an a QA team person monkey.


Log in to reply