Nicky Tests Software

New to testing? In your first year as a software testing? Here are 4 useful testing tips for beginners. 1. Explicitly State your Assumptions Before I start testing (and ideally before the developers start coding), I like to go through the requirements/acceptance criteria/user stories, then write testing notes on my assumptions. That is, based on what I have read, what am I assuming? Not all of the expected behaviour of the application/feature will ever be explicitly stated, a lot of expected behaviour is implied - therefore it's useful to state your assumptions and then either tag the developers/ business analyst in your comments or share your thoughts with them face to face. While doing this, I also like to state how I would test the application/feature, based off my assumptions - this doesn't have to be written test cases, but more like test ideas; this is followed by the sort of behaviour I would expect for each test idea. (This isn't a promise to the develope

As a tester, I do my best to follow the principles of Context Driven Testing.  But embarrassingly enough, only up until recently, did I realise that context can change, while you are working in a team - so anything you put in place at the start of your time in a team, might not be the best thing for everyone 6 months later, or 12 months later. I'd like to share some things I've learned about testing in a changing context - but first let me describe my initial context and how it changed over the course of roughly 14-15 months. Initial Context 2 main applications - fairly straightforward, not too many possible flows in either of them 3 Backend developers 4 Frontend developers No test automation set up initially 1 Product Analyst 1 Product Owner Designer, who was not part of our team 1 Scrummaster How the Context Changed 7 applications - a few of which had various possible user flows within it. 1 of these applications had many flows in it. 3 Backend dev

I first came across the idea of Psychological Safety in 2017 when I attended Joshua Kerievsky's talk on Psychological Safety at Oredev. Psychological Safety is " ‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up".   Two years later it's a concept that still stays with me and I try to keep it in mind when I interact with people or am in group situations. I know that I can sometimes be a louder-than-usual presence in a group setting, or that I can be a bit too direct, so I do my best to keep it in check for the following two reasons: I learn a lot more by keeping my mouth shut and hearing what others think/how others feel But more importantly, I never want to act or react in a way that would discourage people from speaking their mind in the future.

Part I is here Here are some of my key learnings on the last 3 talks I was able to attend at Testbash Brighton 2019 before I had to leave early to catch my flight back home. Gareth Waterhouse and Lindsay Strydom : Building Communities at Scale 2010:   12 QAS 1 location Around 5 teams "Where we're going, we don't need a community" Currently: They currently have around 120QAs (this number fluctuates due to contractors) 4 locations - 3 in the UK, 1 in India Different tech stacks/languages Around 70 dev teams Dealing with growth: Before, they would send meeting invites for 16:30 UK time, this was roughly 22:00 in India. Then they started having 2 clocks in the room, so they could consider time differences when scheduling meetings They faced challenges in scheduling meetups for the testing community: After Testbash 2018, Lindsay felt inspired. A few days away from the office gave her time to reflect about the current lack of a

It's been an intense month in a my personal life and even more intense (exciting!) months to come. So before I get too busy, let's turn my notes (that can only be read by me), into a blog post! In early April this year, I had the honour of speaking at Testbash Essentials on the Wednesday. I also had the opportunity to attend the main Testbash Conference on the Friday and learn a lot from the speakers. Here are my notes on what I learned in the first few talks I was able to attend (I had to leave a bit early to make my flight back home). Lisi Hocke - Cross team Pair testing: Lessons of a testing traveller.  "Have you ever asked yourself, are you good enough?" Lisi didn't come from a technical background ---> she fell into testing.  She was mostly the lone tester at a company and didn't have a mentor. But now at her current company there are more testers. "I'm basically just managing my list, but not learning something." She

In the morning I attended Martin Hynie 's and Chris Blain 's workshop on Context Driven Coaching... There is no script. Here are my takeaways on what I learned in this workshop: 1. It's common for people to be promoted to managerial positions but not have the skills to coach people.  Martin and Chris have coached managers, who are in charge of coaching people. But people promoted to managerial positions aren't necessarily promoted to these positions because they have the skills to coach people. 2. If you want people to work together, you need to give them a chance to get to know each other, to build trust and to show some vulnerability To kick off the workshop, Martin and Chris had us answer four questions to our table groups (roughly six people each table), so we can (presumably) achieve this goal. 3. The person you are coaching needs to trust you and to trust that you know what you're doing. 4. When you are coaching, there is a high probability that y

For Part I go here Devoting time and effort - when I have it While I'm on my project my priority is as a tester in my scrum team. Therefore, I only devote time and effort when I have it. Some weeks I'm very busy in my team and barely give the CoP a second thought; other weeks I have more time to prepare a presentation or approach people to give presentations (or look up topics to see what people may find interesting to hear about from others). I really appreciate the flexibility. While there is an expectation that something happens regularly, it seems that definition of "regularly" has become roughly once a month. Merging the Test Automation COP and Testing COP The lead of the Test Automation COP pinged me on slack a few weeks ago to see what I thought about merging the two. I said I was all for it (after all I saw Test Automation as a part of testing; a way to approach testing - and so did he). We both posted messages in our slack channel saying we had th

For about 4-6 months, I have been leading the Testing Community of Practice at my current project. Before then there were 4 of us being co-leads (for 6 months ish) before I was approached to see if I wanted to drive it and be the lead. I said yes - and said I wanted to see if I was a good fit as a lead, if I had the energy/desire for it and if there was a need/desire for a Testing CoP in the first place. Finding out what people expected from this Community of Practice My first focus was to find out what people expected from a Community of Practice. I sent out some surveys to those already in the Testing slack channel, and had two discussion groups in our Malmö and Helsingborg offices. The hard part was I already had my opinions already on what it was and what it would involve, so when I was holding these discussions I had to watch what I say, and how I say things, in an effort to not affect people's opinions. The two main things people expected were to share information about