BOSS - YOU ARE WRONG...

Hiya all,
Interesting thought. All of us would know that there does not exist any software product which is defect-free. Very true and accepted world-wide!!! Applying the same thought to life, it means that there cannot be a human being who cannot be always right. That means that you, the reader, ain't always right (you might just not agree with this - which means neither am i right - hypocratically speaking as I write this :))..... But this means, that your boss at your ain't always right either. But, who is going to tell him that he is not right?

Before going further, let me dedicate this post to all the "fake bosses"!!! Happy Faking!! :)

Dis-agreements with your boss is a common happenning at the workplace. It's not uncommon to find employees commenting on the lack of common sense of their bosses. I am very sure, if a survey is taken, more than 95% of people would find themselves in almost every day situations where they dont agree with their bosses. What about the other 5%? They would belong to the breed of "yes-boss"ers!!!

Some very common situations that I have seen where you would find that your boss is in the wrong and what to do then --- and a few drastically radical thoughts on how you can tell your boss that he's wrong...

1) Testing times - Let's give this guy, who's been with our organization for 2 years a promotion. --->
I have seen this situation happen so many times. Say there's a average performer in the organization who has worked with the companyfor 2 years. Though it is not worth giving him a promotion, bosses intend giving them a feel-good promotion. Sometimes, this would be highly depressing to the other deserving candidates since this guy, on the virtue of having served the company for a 2-3 year period, eats into the quota of another deserving candidate. Many managers have tried unsuccessfully to fight this situation, but this keeps coming up in 1 way or the other almost every appraisal cycle.
How to tackle:-
a. 1 way is to have a 1-on-1 with the boss to tell them that another person is deserving. But, this method usually doesn't work since the boss has an ego that does not like being told that he's in the wrong. So, you have to pacify the ego and try to push in this information.
b. Since the person is an average performer, it should be easy for you to compare him with a similar performer in a different team and tell your boss as to why this guy does not deserve a promotion.
c. Tell the boss that even if he is being given a promotion, then ask him to transfer this guy to a different team since the promotion would definitely affect team morale.
d. Put your promotion critera on paper and try to reason out with the boss.
What happenns mostly:-Well, mostly, the boss goes ahead and gives a promotion to this guy, and gives him a very little pay hike. Finally, the good performer feels that he's not rewarded and plans to move out. The rewarded performer feels that the reward ain't enough and plans to move out. It's a perfect example of a lose-lose situation, and mostly, you would be fighting a losing battle.

2) Oh!! That feed hasnt' been active in 8 months time. Don't waste time testing that feed --->
I have seen this. To cut-down on testing time, when the boss wants the code to go to market in quick time, they take a quick look at test cases and try to cut corners. Usually, people try to reduce test cases that get executed so that the product can be certified in quick time. An interesting case is in the case of feeds. Consider that there is a scenario wherein the product rates get fed into the system once a year. Looking to cut corners, the boss might make a decision to "not test" that part of the system, to reduce test timelines. This is just 1 example. What do you do?
How to tackle:-
a. Bring in the business analyst. Get the business sign-off stating that this feed will not be used and that this testing can be ignored.
b. If you feel that you would look like a "nut"case asking business to look into this, prompting business to ask you "dont you know even something as elementary", then try to take the boss through the system and convince him as to why this feature would be important for testing.
c. If you are very confident of your business knowledge, tell him taht the system would crash if it is not tested.
d. Try to locate business critical test cases and see if this case exists over here. You would have to dig into some old scripts.
e. Search the defect database to see if there have been any earlier defects in this area. If there have been, then this would become like a "potential cause of failure".
What happens mostly:-C mostly works :). The bit of telling the boss that the system would crash mostly works. What many people dont know that it is very easy for the tester to strike fear into the heart of the boss, by telling that if a feature is not tested, then that particular system would easily crash.
3) Oh... site ain't working with cookies disabled, is it? - no problems. Test it with cookies enabled and give the sign-off --- >
This has happenned so many times. As I write, I dont know how many places this is happenning at. Assume that the web-site does not work with cookies disabled, the boss instructs you to test all functionality with cookies enabled and give the sign-off. But that's just not testing, is it???!!! Well, the boss thinks that's what testing all about. The boss's business objective is to "ship code" in quick time. wait a minute... Shouldn't that read "ship QUALITY code"??? Well, some where in the test cycle, due to time constraints, QUALITY has gone out of the window :).... What do I do?
a.This is an every day situation. If the test team is really net savvy, they should have a list of other such projects where such bad testing has happenned. It should be easy for you to quote a reference.
b. Tell your boss that your fresher feels that this is a very dumb idea.
c. Have the project reviewed by the other people in the company who are tech savvy. They should tell him that this is not the solution.
d. Again, go running to business - Business users would never agree to this. If you have a very good business team, they would have the configuration and information about the end user browsers and their settings. Refer to this to make a decision.
What happens mostly:-All of the above 4 work and you would be able to stop the release. But, common sense dictates the presence of "idiots" in management. For the exclusive set of these idiots, they would want you to go ahead with testing with cookies disabled.
4) Why does the tester need to understand the software design? --->
A very commonly asked question. Not just by the development team, but even by some CEO's and CTO's... Why does a tester need to understand the software design at all? All he needs to understand business requirements to test the software. So, why would you want to waste time by having the test teams attend sessions with the design teams at all?
Well, it's a good question... My take... The tester would need to understand all the design workflows in teh system to design his test cases. A very simple example --- If a website is designed with values being passed as querystring instead of being passed as form values, then he shoould design his test cases to ensure that the system behavior is not altered when he tries to inject teh relevant querystring with his own values. This is just 1 example.
And, if you are working in an organization where the CEO/CTO question the need for understanding the design, please do not fight it--- just quit. Sometimes, quitters end up winners too!!!
5) Performance testing --- Why do we need it if the client says that he doesn't? --->
Another every-day happenning. Hey, the client feeels that we do not need performance testing at all... Why are you planning to do it? The client is always right, ain't he? If he doesn't want something, dont do it... Go ahead and deliver just what he wants!!!
My take --- BOSS, the client is not always right. When you go to a doctor, the patient does not say what he wants. The doctor does the diagnosis and treats the patient accordingly. When you go to a lawyer, the client does not issue the diktats. It is the lawyer who says what needs to be done and advises the client of all options. In this case, if you are doing a website receiving regular feed, doing regular refreshes, etc.,, then it's highly likely that you need to do at least 1 round of performance testing before go-live to predict how the system would behave today and after it goes up to a certain level (scalability tests, etc...). It is your duty to convince the client as to why he needs to do performance testing. Tell him the reasons as to why you need to do performance testing and from your organisation's project archives, pick up the list of projects which have failed due to lack of performance testing and present it to him. Work with him to understand how you can do performance testing parallelly so that timelines will not be hindered and I am sure, he woudl agree to the same. Budget problem, again escalate... But never tell the client that he can go live without performance testing, especially if you do a project review and find that there is a need for performance testing.
6) 2 days for go-live and want to fix a defect? Sure go ahead, we can complete testing and release --->
More of an every-project happenning. In 75% of the projects, there exists a situation where the business has a requirement that is born with 2-3 days before project release. This assumes the highest order of priority and very soon, the boss finds himself telling the clients that this last minute change can be accomodated. After all, the customer is king, ain't he???
But BOSS:-
But, Boss, the customer might be a king... but please read the history archives to undersatnd how many kings have lost their kingdoms due to having a very bad ministry team? Akin to the ministry team, the business will always place a lot of pressure on making last minute changes. But, as a tester, you will have to highlight the risk. A simple cosmetic fix that comes at the last minute might cause the heart of the system to break. A very simple javascript fix would cause an inability to login. Sample this - someone wanted a date-of-birth field to be added with 2 days to go live. The programmer, injected a defect wherein the date-of-birth went and over-wrode date-of-registration on the website. So, when the website wanted to generate a report to reward long time subscribers with 100 points per year, imagine their surprise when they learnt that they would go bankrupt, if they were to fulfill their promise to their customers. This is because, the report took into consideration the date-of-birth of the customers instead of their date-of registration. For someone who would earn only 100 loyalty points, the site said that they would earn 4500 loyalty points... All this happenned because of a last minute release.
So, never ever agree for a last minute change. The boss might pressurize you saying that you need to be more flexible, etc, but please remember, common sense takes priority over everything. Negotiate to make the release as a patch release sometime in the next few days, but never agree for a last minute release if it does not fix a defect.
7) Test Estimation can never be more than development estimation --->
Not many know that this is a myth. A commonly held belief of the fake tester... So many companies have this - They split requirements as 10% of project effort, design as 10%, project management as 5%, development as 30-40%, testing as 25% and UAT as 5%. More often than not, as a tester, you would find yourself into a project with very minimal estimates for testing. People, more often than not, do not think that a tester would need time to understand requirements and design. They think that on Day 1, he can start scripting for test cases, create test data and test it in quick time.
What do you do:-1 thing that comes to mind. Always ask for additional people. Try to create your own estimation mechanism and if you feel that the project estimates do not match your estimates, reason it out with your boss showing him valid data on time taken to create test cases, test data and test execution.
What do you do if the development tell you that test teams are longer than development? Some examples...
a. If the developer is using a framework, that reduces his development time. But that does not mean that a tester should refrain from testing his business requirements.
b. Like a code review, test team would need ot undergo a test plan review and a test case review. Testing is a parallel activity and it is not possible for test estimates to be containeid within overall project estimates.
c. Testing time would also include application setup, and more often than not, the 1st build that you receive would not be working. You will have to accomodate for these timelines also.

8) Original software for automation costs a million? Well, go ahead and use a pirated version just this once. Who would know about it? --->
This is something very unethical. A true tester would never ever go down this path --- It's better to be without a job, than do something "unethical". It's similar to commiting rape or a murder. If you are a rapist or a murderer, then go ahead and follow your boss!!!
9) All the valid reasons where the boss's right --->
Well, its not that the boss is always wrong. So many times, the boss is right. I have had the pleasure of working with so many bosses that I have looked up to. Sometimes, the boss might be wrong... and sometimes, you might be wrong too. The boss can be right more than once, and... after all, he's the boss coz he's been doing the right thing most of the times. So, please do keep in mind that the boss might be right. Always evaluate the complete situation before deciding on what action needs to be taken.

Always remember... there's 1 differentiating factor between the real tester and the fake tester... The true tester would know "what to expect from fake bosses" and have plans in place accordingly.

And what happens if all the above fails? A true trait of the "fake boss" is that they would believe whatever they find on google!!! They also have immense trust in whatever info they find on our blogs!! heh heh.... So, all you have to do is to give them a link to my blog and I am sure you would find a solution!!! :)

Well, the above is just some instances that I have seen happen around me. A few of my friends also experienced somme of these situations. Few takeaway points --- just because that you are the boss don't mean that you are always right. Please rely on common sense to determine the person who is correct in these situations. Time, Quality and cost are vital parameters that a test manager would need to rely on for decision making to ship software. Anyone who does not rely on these parameters, like me, is what I would call another "fake tester"!!!