SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 5 of 5
  1. #1
    Apprentice
    Join Date
    Apr 2014
    Posts
    17
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0

    Question Test gets all the blame + testers not following the test plan

    Hi everyone,

    Four months ago, I started working at a Company as their test manager/responsible. My assignment is to act as a test manager in Projects and also as Company responsible for test. The Company is kind of immature when coming to test and processes. They do not have any standards or process for development, test, etc. The developers just test their own code and the Project manager just clicks around in the application for final testing before release to the customer.

    Now, I have been working in a Project which started really good. I created a test plan for the Project and all the time, I communicated with everyone about the plan. We had several meetings about the plan and I kept asking eveyone "does this plan seem good to you? Do you have any comments?" and everyone kept replying "ooh this is soo awesome!!"

    So I started testing the first sprint and Everything Went fine. We decided I was just going to test according to the described user stories, not exploratory and nothing other than these user stories. At the end of the sprint, one of the developers wrote in our Project Communication system (for all to see) that the testing process was bad. I was chocked that 1) the developer did not take this with me first 2) that the process was not good.

    I contacted the developer directly and asked him what this was all about. He kept repeating himself, "the testing process was not good". I asked him why and he said that bugs were found even if I had performed tests. I asked him about which bugs and in which test cases the bugs where found. Then, he replied, that there were no requirements for the function which had bugs, and therefore no test cases. I replied that the tests can only be as good as the requirements, and if there are no requirements and no exploratory testing is allowed and no other testing than what's described, it's not the testing process which is wrong. No reply.

    When we had a Project meeting where I told everyone about this and that we agreed on me only testing the described user stories. It was just like "Oh, we forgot to describe this user story" bla bla bla. So they can forget about things easily but they are Quick with blaming test for it!

    Anyway. I forgot about this fallacy and continued with the Project. Then the Project manager contacted me and said they have to cut down on time. The development took too much time. So, the guy who was supposed to do the testing at first, before I entered the Project, should do the testing instead. He knew the platform very well so he will have to do the testing and I should still be there as a test manager. I agreed on that. He started working and I recognized that he did not follow the test plan - at all. I contacted him and asked him if he has misunderstood anything. No reply. After one week I contacted the Project manager with CC to him with the same text, the process is not followed, is there any problem? Then he replied that "I do not understand how to do it", which made me laugh in my head, since we have had several meetings about this. I have asked everyone 100 of times if the understand and everyone has replied "yes, ooh this is Amazing!". I have, step by step, described how to perform tests and how to work with the requirement/testing tool we have (Assembla). And if he did not understand, why haven't he contacted me and asked me how to do it!? He had just ignored my testing plan totally.

    Anyway, the project manager replied that we have to do it as fast as we can, to save time. I replied that it's ok but I will write that in my test report later. That was ok.

    Then the testing went on and now it's time for the test report. The project manager wants me to write it and I asked this guy if he wanted to do it instead, but he said I could do it. Ok, good. I e-mailed him and asked about details about the tests. How did the tests go, upcoming bugs and so on. No reply. I sent the same e-mail again a couple of days later and added that I will have to finish the test report today and he replied "oh this will be too much work for me. Maybe I will do it during the day today. Not sure!" I replied that if the tests would have been performed as I have described in the test plan, which I pointed out before, the summation of the tests will just be to export the result and easily get an overview of the tests. He replied that "oh it's not that, I just do not have time to document it". I was like wtf? He doesn't need to document anything. If he had performed the tests according to the plan, he would have to just export the result. No documentation. I tried to explain but no understanding. He only replied that they had no time for proper testing. Which I also pointed out weeks ago, that the summation will take muuuuch longer time and they have to put hours on that instead. But noone seems to listen.

    I feel totally powerless. People keep ignoring what I say. Itís like talking to a wall. I have talked to my boss about this. I have been talking to the directorates and the Company owner. They support me but just say "we are immature, we have never worked with tests before. You are the first real test person we have. People are scared and do not want to change their way of testing but we really need proper testing so please have patience with us! It might take some time to implement proper testing".

    But how do I communicate with these kinds of people who does not do what I have planned? When people say "Yes I understand" and then they do something completely different. What do I do when test gets the blame for everything?

    A long Review, but all the details are neccessary.

    Comments? Thanks!

  2. #2
    Member
    Join Date
    Nov 2011
    Posts
    120
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    Okay. First off, welcome to situation normal - all fouled up. The situation you describe is extremely common.

    Now, some advice...

    First, the people at this organization are used to doing things a certain way. They will continue to do things this way unless they can *clearly* see the benefits of changing. You've probably thrown too much at them, too soon, and scared them - particularly if the company has a blame culture (which it sounds like - and you aren't helping based on your description).

    Next, there are ways to approach this situation that will get results, but they won't be perfect and they will require a lot of patience on your part.

    Here's how I see it:

    1. The developers are used to the people testing having a much greater knowledge of the application than you do. This is why you are betting blamed for not testing some things: people who know the company and application also know the unstated requirements and know to cover them in their tests. The project manager and developers aren't used to working with someone who doesn't have that level of domain knowledge. This will change, but it will take you learning more about the application and how it works so you can catch the unstated requirements and get them stated explicitly.

    2. What you've done is effectively come in and said, "You yahoos are doing everything wrong. Now I'm going to make it all go right." Oddly enough, this isn't the way to get people on your side. The way to approach something like this is to start by figuring out how things are normally done, then introduce ways of making it *easier*, and you do that by working *with* the team rather than against them. Right now what people are seeing is "The new guy wants us to do extra and we don't have time for that." What you want to do is *show* (not tell) ways to make things simpler.

    3. You'd get a better result from the tester by offering to sit with him while he tests. You can ask him why he's doing certain things (not accusing - just "I don't understand why you're doing it this way. Is there something about the system that's not obvious to me because I'm not familiar with it?") and offer to document for him - which is when you fire up your laptop and start using your tool to document (yes, it's not as nice as doing it the "proper" way, but it still gets the results into the tool and lets you report on them). Gradually he should start seeing you as being there to help him rather than to tell him what to do.

    4. Instead of asking "Do you have any comments?" about your plans, ask for more specifics: "Is there anything I've missed?", "I'm not sure I've got the right idea with this test - how can I improve it?", "Is the outcome of this test going to change depending on which user is logged in?"

    5. Never - and I do mean *never* - rule out exploratory testing. Test plans can be wrong. During programming, it's common for the initial plans around the user stories to be unworkable and for different ways of doing things to emerge. My usual method in this case is to ask the developer, "Hey, this user story says X and you've done Y. Did something change that I missed?" Half the time I'll learn that yes, there was a necessary change to how things had to be done. The rest, I'll get "Oh, oops. Sorry, I'll fix it." Exploration allows you to find things that you would never have considered in a formal test plan, and to ditch the formal test plan and trace something odd to figure out what it's doing.

    6. Always approach others from the explicit perspective that you may be wrong. It gets better results. Developers are much happier when the tester is saying, "Hey, could you check your changes didn't accidentally get overwritten because I'm not seeing them here?" than when they get, "Your changes don't work." Similarly, "Did I misunderstand the requirements?" gets a better result than "You didn't do what the requirements say."

    7. *Never* forget that your goal is the same as everyone else's in the team. You all want the project to go as smoothly as possible and end with the best software possible. How it gets there doesn't matter, as long as it gets there.

    8. Finally, don't fall into the trap of thinking you're a gatekeeper. You aren't. Your role is to communicate the *state* of the software over a period of time. Other people make the decision of whether that state supports releasing the software or not.

  3. #3
    Apprentice
    Join Date
    Apr 2014
    Posts
    17
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    Hi and thank you for your great advices!!

    Quote Originally Posted by katepaulk View Post
    First, the people at this organization are used to doing things a certain way. They will continue to do things this way unless they can *clearly* see the benefits of changing. You've probably thrown too much at them, too soon, and scared them - particularly if the company has a blame culture (which it sounds like - and you aren't helping based on your description).
    Yep, that seems to be the situation from at least some people. It's really tragic to all the time find someone to blame..

    Quote Originally Posted by katepaulk View Post
    1. The developers are used to the people testing having a much greater knowledge of the application than you do. This is why you are betting blamed for not testing some things: people who know the company and application also know the unstated requirements and know to cover them in their tests. The project manager and developers aren't used to working with someone who doesn't have that level of domain knowledge. This will change, but it will take you learning more about the application and how it works so you can catch the unstated requirements and get them stated explicitly.
    Yep, that's true! Everyone seem to be experts on our tools. In this project it was about EpiServer development. I have worked a lot with EpiServer before, but that was about 4 versions back. The latest version we are working with is completely new to me. And since we are not allowed to work so much with internal time and the project hours are few, I do not have time to learn the tools other when I test them.. So yep, it will probably know after a while. In this case, the guy who was testing had worked with education in EpiServer and is a real expert. I could never compete with him.

    Quote Originally Posted by katepaulk View Post
    2. What you've done is effectively come in and said, "You yahoos are doing everything wrong. Now I'm going to make it all go right." Oddly enough, this isn't the way to get people on your side. The way to approach something like this is to start by figuring out how things are normally done, then introduce ways of making it *easier*, and you do that by working *with* the team rather than against them. Right now what people are seeing is "The new guy wants us to do extra and we don't have time for that." What you want to do is *show* (not tell) ways to make things simpler.
    Hm okay :/ I thought I was doing the correct thing. I was very careful and discussed my test plan real properly with the team members. I tried to adjust the test plan as good as I could and that's why I kept asking the team members if this seems like a good test plan to them. Since they kept answering "yes" I thought this was a great plan for the project. But obviously I was wrong. But when I asked for comments, I recieved none. Noone had anything to say.

    In one other project I started asking questions about how they test and so on. Then the project manager got angry with me and said "stop asking questions, just do your work! Implement test for us!". I was like uuh ok? But that ended up well.. now test in that project is real good.

    Quote Originally Posted by katepaulk View Post
    3. You'd get a better result from the tester by offering to sit with him while he tests. You can ask him why he's doing certain things (not accusing - just "I don't understand why you're doing it this way. Is there something about the system that's not obvious to me because I'm not familiar with it?") and offer to document for him - which is when you fire up your laptop and start using your tool to document (yes, it's not as nice as doing it the "proper" way, but it still gets the results into the tool and lets you report on them). Gradually he should start seeing you as being there to help him rather than to tell him what to do.
    Yep I know. Unfortunately we sit in different parts of the country and I talked to the project manager about traveling to them but she said that's not neccessary. I kept asking several times but I was not allowed. And we have to put the traveling time on a customer and not as an internal cost :/

    Quote Originally Posted by katepaulk View Post
    4. Instead of asking "Do you have any comments?" about your plans, ask for more specifics: "Is there anything I've missed?", "I'm not sure I've got the right idea with this test - how can I improve it?", "Is the outcome of this test going to change depending on which user is logged in?"
    Ah, great point, thanks!

    Quote Originally Posted by katepaulk View Post
    5. Never - and I do mean *never* - rule out exploratory testing. Test plans can be wrong. During programming, it's common for the initial plans around the user stories to be unworkable and for different ways of doing things to emerge. My usual method in this case is to ask the developer, "Hey, this user story says X and you've done Y. Did something change that I missed?" Half the time I'll learn that yes, there was a necessary change to how things had to be done. The rest, I'll get "Oh, oops. Sorry, I'll fix it." Exploration allows you to find things that you would never have considered in a formal test plan, and to ditch the formal test plan and trace something odd to figure out what it's doing.
    Yeah I know :/ I presented that first, but then I got stated directions from the project manager: No other testing than what's stated in the user story. That's often how it is general in these projects, so little time I barely have time to perform tests on all user stories in the sprint.

    Quote Originally Posted by katepaulk View Post
    6. Always approach others from the explicit perspective that you may be wrong. It gets better results. Developers are much happier when the tester is saying, "Hey, could you check your changes didn't accidentally get overwritten because I'm not seeing them here?" than when they get, "Your changes don't work." Similarly, "Did I misunderstand the requirements?" gets a better result than "You didn't do what the requirements say."
    Ah allright. But doesn't that make me appear as "weak"? (Perhaps a stupid question, but I do not want to appear as unsure or weak).

    Quote Originally Posted by katepaulk View Post
    7. *Never* forget that your goal is the same as everyone else's in the team. You all want the project to go as smoothly as possible and end with the best software possible. How it gets there doesn't matter, as long as it gets there.

    8. Finally, don't fall into the trap of thinking you're a gatekeeper. You aren't. Your role is to communicate the *state* of the software over a period of time. Other people make the decision of whether that state supports releasing the software or not.
    Thank you, I will keep that in mind!

    And thank you again. This means a lot to me, since I completely stuck and I have no idea of where to go :/

  4. #4
    Member
    Join Date
    Nov 2011
    Posts
    120
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0
    Being in a different location doesn't help. Some of the things you can try - if it's feasible - is a remote session where the two of you are talking while one has control of the host machine - and control can be transferred. There's a number of tools that will let you do this: your organization should have at least one of them available for you to work with (if nothing else to actually *demonstrate* your test planning tool and have others work with it on a sample project. One thing that often happens is that something looks simple and wonderful when demonstrated but is scary and overwhelming when you try to actually use it yourself).

    With what you're saying about the project manager, I'd suggest a meeting where you go over exactly what she expects of you and if it's not reasonable you politely explain to her the reality of the situation. Starting with "I seem to be having some communication issues with the rest of the team - could you take a few minutes to help me with them, please?" and let her set a time to work with you.

    If the project manager is saying no exploratory testing, you've got a couple of choices. One is to do exactly as stated. The other is to explore on your own time and keep track of bugs found in exploratory testing compared to bugs found in scripted testing. After you have several months of data, you should have enough to present to the management folks with, "I know you don't think there's time, but I'd like to show you something." Then you show the worst bugs you found exploring (and pick the ones that scripted tests would never have picked up), focusing on what would seriously affect the company bottom line. Bad financial data is always a good one for this kind of thing... Given a large, complex product with what sounds like very little formal regression anywhere, I think it's pretty much a given that bugs like this will happen.

    Do *not* worry about appearing "weak". There is nothing weak about starting from the assumption that the other person is doing the best they know how to do within the constraints they've been given. Think about it - if someone came up to you and told you "this is all wrong. You need to do it this way!" wouldn't you be irritated? I certainly would, even if that person had the authority to tell me what I should be doing. (Why? Because I'm not deliberately doing it "wrong" - I'm doing the best I can based on what I know.) You're working with professionals: treat them that way.

  5. #5
    Apprentice
    Join Date
    Apr 2014
    Posts
    17
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Total Downloaded
    0
    Hi! Thank you again for your superb advices!! I have nothing more to comment on what you have written. I just agree with you all the way. I will keep everything in mind. Thank you!

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 11.54%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 12:23 PM.

Copyright BetaSoft Inc.