My boss doesn't play by the rules...what should I do?
My boss is also a developer and he pushes hot fixes to Prod all day long. How can I keep up quality/quality processes when he his changes are never tested?
You can't.But perhaps the next time you meet with him, you can ask him if there is something he would like you to do about these fixes he pushes to Prod. Perhaps he'll want you to test them after he pushes them to Prod, for example.
Sometimes testing in production is more revealing and helpful to all. Once these pushes are done, I would go ahead and immediately test things from a user perspective: GUI and functionality. If your application is reliant on data? If so, you might want to put some quick focus on data validation testing. Put together a regression test suite where you can test the application and think of it as a smoke test. You then get a kind of check to say "okay, people won't run into any major crashes immediately. Good!" You want to try to find any immediate "gotchas" first. Then put together a more detailed functional/regression test suite. This could be done where you're being more detailed, tapping into the specific areas where you know where the code was changed. Talk to your developer boss, go over those areas to make sure you understand what tests you need to consider.
Finally, try to test your application from a system perspective. Think about the inter-dependencies your application has like storing data in a database, communication between server and client and other examples you can think of for your application testing.
And like Joe stated, talk to him. While your testing, offer ideas of what your developer can do to improve but be careful in your approach. As much as you can, try to let him think it's his idea to fix/improve.
Generally hotfixes should be reserved for only things that needs emergency patching. In these situations the lost revenue for something like the site being down is far greater than the costs of testing it. (for example, a critical security flaw in a banking application with a real life exploit in the wild.)
However, in an ideal situation, hot fixes should be the exception rather than the norm, and when they do happen, they need to be tested throughly when they are merged back to the main line. Hotfixes tends to cause merge conflicts down the line, sometimes the effects of botched hot fix merges will causes issues several sprints later. Especially when there arn't any unit test to test the code that was hotfixed. Normally code get pushed in one direction, during hotfix, it goes in the opposite direction, this has the potential of very bad merge conflicts.
If the hotfixes are becoming the norm. There's a pretty good possibility that the hot fixes are the causes of the issues and causing a chain reaction of cascading issues. If this is the case, it's good to do a root cause analysis as part of your post mortem and try to identify this and bring it to light.
Last edited by dlai; 03-18-2013 at 11:55 PM.
I think the original poster understands these things but unfortunately is in a very difficult situation because the developer doing the problem is her boss. I don't think she has the ability to change the situation.
It is why I offered the advice I did, to deal with the situation without losing her job.
It's always helpful to be diplomatic, ask what you can do to keep up on the fixes and ingratiate yourself into the process especially when its your boss, make sure they know you are there to support them. I've worked with bosses like that, who like to tweak in Prod a lot, and I got the message across when trying to set up the QA lab and want to keep things in sync, so we set up change monitors and a change tracking system. It didn't slow him down, but at least we put up monitoring to keep track of what he did so I could propogate changes back. A couple of times he realized, when writing the change tracking item that he missed something and went back to check and sure enough he had made it worse, he fixed it (as is his wont) but then he noted the changes and appreciated the fact I was keeping an eye on him without doing so.
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
Now wasting blog space at QAForums Blogs - The Lookout
That's a familiar scenario to me. I'd rather not say anything further, to avoid incriminating any past or current employers. :-)
I suggest that you ask your boss to keep you apprised of the changes he pushes through, so that you can account for them in your test cases, and so that you can test them when the opportunity next arises.
Another piece of the problem is this intangible thing called experience and credibility.
As a Junior or entry level, when you point out issues with the process. It's usually falls on deaf ears. This happens a lot when you have a lot of senior developers with Junior QA staff. You have senior developers going, "This is the way we always done it, and it works", while Junior QA staff will work long hours in the backend to make up for the short comings. I've not encountered an organization I have not had push back on any process changes (even as a Sr.)
In the absence of experience. You might want to think about doing the following...
* Establishing a metric of success. By establishing this metric early on, it'll be easier to ask your boss to try something and have some tangible evidence say after a 2 months that the suggested changes are working/ not working. I'd probably start off with things that can gathered easily by the bug tracking and ALM systems such as Escaped BugCount per story point. You can then monitor this as provide a report of how things are improving.
* Prioritize your list of changes in small chunks. Process change i hard to swallow even if everyone knows it's for the better. I've been part of a couple Watherfall to Agile shifts, and seen how doing many things at once is very difficult to swallow. I would chunk down changes down to 1 simple thing at a time, and allow time between changes for the effects to show up in the metrics before proceeding. This will allow you to prove the value, ease the burden, and have a platform for continuous improvement.
- When prioritizing, think of what is a good balance on easy to do on the other parties side.
- Think of ways of doing some of the things automatically. For example, instead of requiring devs to write a change list by hand, see if this can be automatically generated by the version control. Instead of extra meetings to discuss risks and what needs to be tested, create rules that can be run at code checkin or configuration to automatically raise a red flag when risky areas in the code or configuration files are touched.