Skip to main content

It was a good day


Decided to write down today the stuff I (remembered to have) had done today. And as paper doesn't store so well, thought to write it here as well. 

So here in a semi random order:

  1. Reviewed code for a change now implemented that had planned couple of days earlier. Mainly to understand how it had been done, but dropped two comments still; one on a missing log event, and another one on the naming of a method. Also asked another team member explain me a thing I didn't totally understand (it was a lazy loading feature so now I know).
  2. Coffee
  3. Did some happy path testing for the change, looked good.
  4. Discussed through the status and next steps of a cool new feature started yesterday. It seemed devs where far with the implementation already and not that much was missing.
  5. Got pretty excited of the feature
  6. Identified and discussed a possible fix with a dev for a thing I had heard yesterday about from a customer. Replied back to customer
  7. Tested one new feature a bit and noticed one missing validation on it, discussed with the dev a bit about it and he wanted to fix it.
  8. Discussed with two testers a bit on something I was introducing to them yesterday, helped out on some test script running problems
  9. Lunch. Roasted beef, pretty good.
  10. Discussed status on three other things with three other devs, and also what could be next up on the todo list. They picked one, and agreed to have a little starting mob for it (dev booked one for tomorrow)
  11. Coffee
  12. Helped out an integrator with problems they had in using one of our API functions. They sent me some php code. Asked a dev to help me out, and based on that sent them a suggestion on what to change. Got response that it worked. (The dev had worked with php 10 years ago).
  13. Sent mail to a person in the organization suggesting that we should use Flowdock more for cross team communication, and stop using other tools for the same thing (lync, skype, hangouts, jira). Much frustration there.
  14. Issue in step 6 was fixed by a dev. Low risk, so he pushed it to production.
  15. Had a short discussion about test strategy on a project
  16. The two testers pairing on a thing reported of a problem they had while testing. Realized it was a potentially nasty problem, discussed with a dev about it.
  17. Noticed me and the dev are 5 mins late with a meeting with another integrator. Went in it, discussed a little about a new service of us they are taking into use, demoed them one of our new features that might be interesting for them. They were interested
  18. Dev said that the cool feature of step 4 would be pilot ready. Exciting! Can't wait us to tell our stakeholders about it :)
  19. Coffee + water (I always forget to drink water)
  20. Helped our customer support in three problem cases
  21. Dev said he had fixed the issue on step 14. Fast! Tried it and seemed to work. Production tomorrow likely? Another dev noticed another related problem on the scenario. Fi tomorrow maybe
  22. Tested a bit more the case in number 1. Learned nothing new really.
  23. Time to leave home. Plenty of exciting stuff to do tomorrow :)

Definitely not the most focused day of my life, but definitely a good one. 


Comments

Post a Comment

Popular posts from this blog

Testers doing test automation - is that the most important thing for you to do right now?

I've been thinking quite a lot about tester's moving to do test automation.  Lately beause of these three things: 1.  European testing conference , a great testing conference I attended couple of weeks ago. It is very cool due to many things; the way the speakers get compensated, the focus on the conferring side of conferences making it very easy for people to discuss stuff, the way the talks are chosen, and because there are also a lot of developers joining. So anyway when I was talking with several of the attendees, it was a bit strange how it was easier for me to talk about the product development as a whole with the developers, where as with the testers it more naturally moved into talk of automation and tools. Also on the open space, I think the majority of the topics pitched was automation or tool related. And quite little on the process or on the customer facing side of product development.  2. In my company there are a lot of different products and...
3 comments
Read more

Testing drunk

(My first blog writing ever.) I've been thinking a long time that it's funny how many bugs I find by accident. Try to do something, make a mistake and boom - a bug is found.  Making the mistakes intentionally doesn't quite work - that's why they are called accidents I guess.. So I've thought of ways to make myself more prone to accidents, coming up with an apparent one; testing drunk. TUI (testing under the influence). So this I gotta try. More to come on that later.
3 comments
Read more

Six reasons why testers should do code reviews

I have had quite a lot of discussions about code reviews. Quite many also with testers, by which I have understood that many do not do those. I will not start arguing here on whether code reviews are good/important or not. But I will list a few things why I think testers would benefit of doing them. 1. Code is the only documentation that is up to date . If you really want to know how something really functions, you want to be able to see and read the code. 2. Knowing more about the thing done enables you to do better testing . You can spot things that you should definitely test, and things that you probably don't need to test that much. Like extra things added by coder, usage&modifications of existing functions, data types, etc. And to arguments thinking that one loses their "independence" as a tester by knowing too much, I would worry a lot less about that than about testing stuff that you have no idea on how it has been built. 3. Improve logging . I obse...
2 comments
Read more