Performance in General
I got to thinking about performance in general. Who's responsibility is it?
1. User Research-Should get some data on what performance users expect in which context.
2. Program Managers-Should define performance with comparisons per system (Faster than, as fast as, no more than % slower than _____________ on the same machine.)
3. Developers should write the code with this in mind and explain to testers when the code is optimized and ready to be tested. This is a performance handoff.
4. Testers then test against these requirements and pre-defined goals. They try different situations, stress tests, repeat scenarios, memory intensive tasks, different OS settings and hardware, long runs, benchmark tests. These tests are some of the best automation candidates.
5. Testers look at perceived performance (Progress bars, number of steps to do something, screen feedback, cursors, ect) from a customer perspective.
So, in general, software performance has split responsibility.
Work performance does not have shared responsibility as much. If there is something getting in the way of you giving your best work performance and you say nothing and do nothing about it, that makes you responsible. It isn't the fault of your co-workers, your boss, the lack of requirements, the lack of a spec, the failed delivery of testable code. It is your fault. As a tester, it is your job to make sure that you can do the best possible testing. Obstacles will come up. Find a way around them. If you can't, directly address them.
I'm very lucky to have had some feedback last week from someone I really respect. There are people I like, and people I respect, and sometimes both, as in this case. As far as work is concerned, I'd rather work with someone I respect but don't like than someone I like and don't respect. In my personal life, I need someone I like who likes me more than I need to respect everything about them. At work, there was a situation I was just tolerating. Basically, I was waiting for it to improve or go away. I've now had a revelation thanks to a gentle reminder. I'm no victim. The only person who can make sure that my performance is something I am proud of is me. The only criteria for me to be proud of my work is to know that I did the best I possibly could given the circumstances, and that "my best" continues to improve in a tangible way as I learn. It's been a rough few months for me on the job. This is the first time ever where I know I made some mistakes and could have done better. I know I should have been brave enough to admit when some things were a total waste of my time. Knowing when to call it quits on working on something is a tough lesson to learn. When I do things that my heart just isn't in, I can't be more than mediocre, and I'm a very open person. If I disagree, it is written all over my face. I have to really believe in something, or at least accept. I'm unhappy with an "ok" performance. Unless my performance could be described as "rockstar level", I'm not satisfied.
1. User Research-Should get some data on what performance users expect in which context.
2. Program Managers-Should define performance with comparisons per system (Faster than, as fast as, no more than % slower than _____________ on the same machine.)
3. Developers should write the code with this in mind and explain to testers when the code is optimized and ready to be tested. This is a performance handoff.
4. Testers then test against these requirements and pre-defined goals. They try different situations, stress tests, repeat scenarios, memory intensive tasks, different OS settings and hardware, long runs, benchmark tests. These tests are some of the best automation candidates.
5. Testers look at perceived performance (Progress bars, number of steps to do something, screen feedback, cursors, ect) from a customer perspective.
So, in general, software performance has split responsibility.
Work performance does not have shared responsibility as much. If there is something getting in the way of you giving your best work performance and you say nothing and do nothing about it, that makes you responsible. It isn't the fault of your co-workers, your boss, the lack of requirements, the lack of a spec, the failed delivery of testable code. It is your fault. As a tester, it is your job to make sure that you can do the best possible testing. Obstacles will come up. Find a way around them. If you can't, directly address them.
I'm very lucky to have had some feedback last week from someone I really respect. There are people I like, and people I respect, and sometimes both, as in this case. As far as work is concerned, I'd rather work with someone I respect but don't like than someone I like and don't respect. In my personal life, I need someone I like who likes me more than I need to respect everything about them. At work, there was a situation I was just tolerating. Basically, I was waiting for it to improve or go away. I've now had a revelation thanks to a gentle reminder. I'm no victim. The only person who can make sure that my performance is something I am proud of is me. The only criteria for me to be proud of my work is to know that I did the best I possibly could given the circumstances, and that "my best" continues to improve in a tangible way as I learn. It's been a rough few months for me on the job. This is the first time ever where I know I made some mistakes and could have done better. I know I should have been brave enough to admit when some things were a total waste of my time. Knowing when to call it quits on working on something is a tough lesson to learn. When I do things that my heart just isn't in, I can't be more than mediocre, and I'm a very open person. If I disagree, it is written all over my face. I have to really believe in something, or at least accept. I'm unhappy with an "ok" performance. Unless my performance could be described as "rockstar level", I'm not satisfied.
Performance: I'm responsible for my performance and my manager evaluate my performance regularly so that improvement can take place.
1User Research get data on what users expect from the system.
2PM's define performance with benchmarks 1faster than 2as fast as 3no more than % slower than on the same machine.
3SD's write code and explain to Testers when code is optimized and ready to be tested. Performance handoff.
4Testers then test against these requirements and pre-defined goals. Try different situations, stress tests, repeat scenarios, memory intensive tasks, different OS
pettings and hardware, long runs, benchmark tests. Best candidates for automation.
5Testers look at perceived perfomance from customer perspective(Progress bars, number of steps to Do Something, screen feedbacks, cursors...
Communicate obstacles impeding work perfomance and solve them on the spot. Challenges build strong character. Testers must have Klingon stamina.
That's right you are not a victim. About liking and respecting at work. Respect everybody, you're not obliged to like somebody who is behaving like a jerk.
Report that immediately because it could cause problems to effective work and team performance as well as personal performance.
Be proud of the excellent work you do and you are awesome not being satisfied unless your performance is at the rockstar level. Remember though that
the rockstar counts on a host of players in his band. Statues are built for outstanding individual contributors but she/he benefited from a strong team
in the background.
Reply to this