In previous post I described a horrible hospital where nurses were held solely responsible for patient’s health door-to-door, from entrance to exit. Surgeons were motivated to operate as much patients as possible. Story sounds insane, but sadly this is reality for many testers and for many teams struggling with quality.
Michael Bolton replied that nurses are responsible for patients health. True that, but not solely! He also suggested testers are analogous to pathologists and epidemiologists. I disagree with pathologists analogy. In modern Agile teams testers can be great epidemiologists and almost avoid being pathologists.
Epidemiologist analogy sounds very interesting. I will get to epidemiologist role in detail in some later part. For now I can say that epidemiologist is something rare and is in some way far more experienced than a nurse and is unlikely to be found in an average software development/hospital surgical department.
To make things more clear, let’s agree we are not speaking about whole hospital, but about orthopedic department: doctors diagnose, surgeons operate, patients are then transferred to rehabilitation department and department is paid per operation, not bed days. Nurses are solely responsible for patients’ health and there’s pressure to get patients out of the hospital ASAP.
Now let’s see how people usually try to solve problems at hand in such imaginary crazy hospitals.
Continue reading “Can testers assure quality? Part 2: nurses vs machines”
Time and time again I bump into opinions, quotes, tweets and comments saying directly or indirectly testers are responsible for quality of software products. People who think so claim software error(s) that reach end user is testers’ fault and testers are the ones who can save the user. I strongly disagree with that.
Saying testers are (solely) responsible for software quality is same as saying a nurse is responsible for patient’s health before and after a sloppy operation.
I think this situation comes from the often used job title QA (Quality Assurance) and it’s variances: QA Engineer, QA tester, Quality Engineer, Quality Tester. Key word is assurance.
I especially like job title Quality Engineer as if there is Inferior or Poor-Quality Engineer. Quality Tester is a good one too, does he test quality or is it implied that there are Inferior Testers too? If job title is simply “tester” how did we end up tying it up to quality at all?
To some this assurance means simple bug hunting. In some radical examples developer slips through unfinished work on purpose hoping corner cases won’t be noted during business acceptance and won’t be encountered in production. Development process turns into hide and seek, cat and mouse game.
Continue reading “Can testers assure quality? Part 1: if nurses were testers”
By a reference from a fellow quality engineer, I watched GTAC 2014 keynote video by Ankit Mehta on how different engineering and cultural practices help Google to move fast and NOT break things (almost). Overall Google’s test engineering goal is set to build an infrastructure and tooling to enable rapid launching of high quality innovative products that delight end users.
Continue reading “Move Fast and Don’t Break Things by Ankit Mehta, Google”
If you have a problem of bamboo agents running out of space and wondering why build expiry doesn’t help you – welcome to the club
I too have bumped into this problem several times and naively thought that this is configurable via Bamboo Admin by Build Expiration setting. Still, our jobs would fail with “fatal: write error: No space left on device” quite too soon. Agent’s home folder was full and running Build Expiration manually with “133 builds affected” result didn’t help a bit. Still full. Most, like in 99%, of space being taken by checked out source code.
Continue reading “Cleaning up Bamboo Agents”
“Did I do something good today?” – question I asked myself after a day of refactoring a long and repetitive test suite and ending up with TestSuite and TestSuiteOld. Was it a good time investment? Yes, I did spend more time than I planned working with this 2500+ lines monster, but looking at our goals next time we would change this component wouldn’t be soon. The old suite worked just fine and now we have two files, different styles and a day spent not on testing new features or working on items from automation backlog (I’m a Quality Engineer a.k.a. Software Developer in Test). Was it worth it?
Gut feeling told me – yes, it was. First of all, I (finally) learned how this component works. More important, I’ve lighted a guiding light for creating less testing debt – tests for this component are now easier to create: common code is moved to setUp and private methods, tests are on average 7-15 lines shorter and work with data providers.
Few weeks ahead (surprise!) we need to change this exact component. Today on retrospective my team members told me they were happy that I managed to write several good cases that caught issues. All thanks to refactoring, it was so easy to create those tests that I was surprised it was mentioned. All I had to think is what data to put in new data providers. For me real issue was why it was me who caught these issues, but that’s another story.
Test/check automation code should be treated same way as production code (1, 2) and should be clean. It wil give you shorter cycle time, less bugs and happier team. To stop creating technical debt “Stop Writing Crappy Code“, stop it right now and write it good this time. It will pay of rather soon.