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

Popular posts from this blog

I don't report bugs

I don't report bugs . Bug is such a loaded word that people understand very differently, that instead of using it and explaining what I mean by it I rather just use other words. Like observations, thoughts, surprises, ideas, alternatives, or something similar. (And no I don't use fault, defect, or error either). Bug has also quite a negative connotation. "Reporting a bug" is kind of like telling someone that they've been served. And as we are actually giving away the gift of information, why wrap it in such a nasty package? And maybe more importantly it is very likely that whatever you might have to say is wrong. If not plain wrong, then at least incomplete. So I like to approach the kind of situations with the assumption that I am probably wrong. Cutting off anything that might sound arrogant makes stuff quite a lot easier. Especially after you realise later on that you have been wrong. I leave plenty of observations unreported . I don't want to waste

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.

Testers of past be the IT stars of the future?

Been noticing two a bit conflicting themes lately. 1. Testers getting (or pushed) to be more technical and write test automation code 2. Articles listing future IT core skills as widely non-technical So whereas many testers are moving to work more on test automation, the vital skills of the future may be such as: - Creativity -  Analytical (critical) thinking  -  Activ e  learning  with a growth mindset   -  Judgment and decision making -  Interpersonal communication skills - Complex Problem Solving Which sounds almost like a list of vital skills needed for an exploratory tester.  So we should perhaps remind the ones starting a testing career or moving away from it, that also these skills are something that can be quite valuable in the future as well. Maybe even the most valuable.