Active testers should be the norm

So yesterday we had a sprint review wherein the testers conducted the demo to our product owner. I reckon it went rather smoothly. I am pleased with how my tester team mates did their presentations. The delivery team overall got good feedback from our PO (yay!), and we testers got some kudos from our PM (yay, again!).

Later in the day, our team had our sprint retrospective. Under the header of what worked well, one of our team mates wrote “DEV-TEST” (which someone corrected to DEV♥TEST) referring to how well the devs and testers were working together. It was actually one of the most upvoted items. And from the retro deck I quote: “Strong and instantaneous link-up between developers and testers. Notification and resolution of defects are faster due to great work relationships between the team”.

Under the header of what to do differently of our sprint retro, not wanting to make scrummerfall a norm in our coming sprints, I suggested to plan sprints such that there are testable features earlier in the sprint (and definitely not 3 days before the end of the sprint as what we’ve encountered for Sprints 0 and 1). This concern didn’t go unheard and the team actually brought up a couple of action items which addresses this.

Earlier today, we got word from our PO on the priorities for this sprint. The devs had to prioritize several bug fixes and that left one of the high-priority items on data encoding to us testers. It’s not exactly testing work, and it’s not exactly dev work either. But it needs to be done this week, so we went ahead and owned it. We actually completed the task in half the time we estimated. Yay for efficiency (or overestimation, but I’d say the former).

So where exactly am I going with this post. I guess I’m just glad that the testers are having such an active role in this project. We’re being heard and (I’d like to think) appreciated. And I guess this shouldn’t be an expectation only in Agile projects. This should go for any project.

Brain dump: Being a test lead

I’m grooming a team mate to become a test lead. What makes this role different from being a tester?

As a tester, your focus is on your test assignments. But as you become more senior (and not just when you become a test lead), you need to start looking at the bigger picture. Not just in terms of functions being tested e.g., you become more concerned as the system as a whole. But you also start seeing your purpose in the software engineering process i.e., you’re an integral part of it and what you want to deliver aren’t test cases or bugs but rather an application that has been fortified by your testing, an application that the target end-user will actually want to use. Software isn’t made to just make jobs for us who are in the business of delivering software. Software is for helping people do the stuff they need.

I guess I’m getting ahead of myself with that explanation and that might be too much to take in.

So a simpler answer…

  • As a test lead, you need to be able to coordinate test tasks among the test team.
  • There’s also a lot of admin work like you need to be able to note attendance or how to contact folks just in case they don’t show up.
  • You also need to watch out for risks, dependencies, assumptions, constraints (or basically anything that could go wrong), and for issues (when things went wrong), and capture lessons learned. As a tester, you already do this but it scales up when you’re the test lead.
  • You also act as a representative of the test team — if there are concerns that they hesitate to raise, you have to either encourage them to raise it or raise it yourself.
  • You need to be able to initiate creation of templates, standards, guidelines, workflows that will help the test team do their work.
  • You need to be able to review other testers’ work — be it test case drafting, test execution, bug reporting, status reporting.
  • You need to be on your toes in case something tricky or complex comes along so that you can suggest options or strategies on how to go about with it.
  • You also need to be able to take the blunt hits for your team when something doesn’t work out, because in a way you are more accountable if you’re the “lead” in general. You might think leads or project managers have it easy because most of the time it looks like they’re just doing reports or asking others to do the work. But when shit hits the fan and the team doesn’t deliver, someone’s going to look for a neck to choke and often it’s theirs.

Ok. That’s about all I can write this morning. Till my next brain dump.

Hello again, world

I haven’t been in this space for some time. Lately, I’ve been instagramming about my lovely dogs and tumblring my attempts of doing art. I am still in software testing. I still feel that the work we testers do highly contributes to making software better (or at least less sucky).

I’m around month and a week into my 2nd mobile testing engagement. We’re at the 2nd week of our 2nd Sprint. There are a lot of things that are new in this project so it’s a really great learning opportunity for myself and more so for my younger tester team mates. For one, we’re adopting an Agile Scrum methodology, and it’s probably the closest we’ve gotten to an actual agile project (we have some scrumbuts). This project is also an implementation project, so this provides them with the opportunity to see something get built from scratch. I think testers who haven’t tried working in an implementation project are missing out. This is where the fun is, and where testing can make the most impact. Plus, this one’s building a mobile app so it has a really modern feel to it.

So tomorrow’s a holiday and we still haven’t received a build for half of the user stories in scope of this sprint or for the fixes of the bugs that were already reported, and Friday is the last day of the sprint. Ah, scrummerfall! It’s a word I picked up yesterday. One of the questions in a webinar I attended touched on the topic of agilefall or scrummerfall. It happens in Agile projects wherein the testing work starts at around the 8th day and the testers are scrambling to test the features and doing overtime work to catch up, and the developers are already moving on to other things. If you’re experiencing scrummerfall, sorry but you planned it that way. The good thing is you can choose to not plan it that way (or so the speaker says). Someone needs to raise their hand and point it out so that the team is planning for a sprint that has something testable as early as day 2 or 3.

Something to raise for our retro. :p

TED Talk: Why work doesn’t happen at work

Excerpts:
That’s what happens at the office.You don’t have a workday anymore. You have work moments.It’s like the front door of the office is like a Cuisinart,and you walk in and your day is shredded to bits,because you have 15 minutes here and 30 minutes there,and then something else happens and you’re pulled off your work,and you’ve got to do something else, then you have 20 minutes, then it’s lunch.Then you have something else to do.Then you’ve got 15 minutes, and someone pulls you aside and asks you this question,and before you know it, it’s 5 p.m.,and you look back on the day,and you realize that you didn’t get anything done.I mean, we’ve all been through this.We probably went through it yesterday,or the day before, or the day before that.You look back on your day, and you’re like, I got nothing done today.I was at work.I sat at my desk. I used my expensive computer.I used the software they told me to use.I went to these meetings I was asked to go to.I did these conference calls. I did all this stuff.But I didn’t actually do anything.I just did tasks.I didn’t actually get meaningful work done.
And what you find is that, especially with creative people –designers, programmers,writers, engineers,thinkers –that people really need long stretches of uninterrupted time to get something done.You cannot ask somebody to be creative in 15 minutes and really think about a problem.You might have a quick idea,but to be in deep thought about a problem and really consider a problem carefully,you need long stretches of uninterrupted time.And even though the workday is typically eight hours,how many people here have ever had eight hours to themselves at the office?How about seven hours?Six? Five? Four?When’s the last time you had three hours to yourself at the office?Two hours? One, maybe?Very, very few people actually have long stretches of uninterrupted time at an office.And this is why people choose to do work at home,or they might go to the office,but they might go to the office really early in the day,or late at night when no one’s around,or they stick around after everyone’s left, or they go in on the weekends,or they get work done on the plane,or they get work done in the car or in the train because there are no distractions.
… Just silence, that’s it.And what you’ll find is that a tremendous amount of work actually gets done when no one talks to each other.This is when people actually get stuff done,is when no one’s bothering them, when no one’s interrupting them.And you can give someone — giving someone four hours of uninterrupted time is the best gift you can give anybody at work.It’s better than a computer.It’s better than a new monitor. It’s better than new software,or whatever people typically use.Giving them four hours of quiet time at the office is going to be incredibly valuable.

Reads: How to destroy programmer productivity

Not a programmer, but a lot of what he said somewhat applies.
Excerpts:
Whatever I can control, I should control. That means:
  • Turning off notifications on my iPhone (this has the added benefit of  increased battery life)
  • Giving myself a reward for 3 hours of continuous coding [or testing, in my case] (usually in the form  of “internet time” like checking Hacker News or twitter)
  • Working from home when I really, really, need to get something done
  • Scheduling ‘no meeting’ times on my calendar. These are times shown as busy  to everyone else. It’s my work time.
  • Not getting into programmer arguments around the office; people have strong  opinions, and the programmers who have arguments love to argue. If  there’s an actual business problem that needs to be solved, let’s grab a  conference room and come up with the advantages and disadvantages of each  approach. Let’s get some data. Let’s not just argue.
  • Position my desk in such a way that passersby aren’t distracting. [Well, i slouch so that i can’t see passersby. That’s not so healthy but that’s another topic.]
  • Taking a first pass at the problem, and *then* asking another developer to  walk me through the problem so that I can get a better understanding of what to  do. This accomplishes two things: First, it allows me to get the ‘lay of the  land’ so that I’ll at least have a basic understanding of the forces at work.  Second, it allows me to ask more intelligent questions when I ask for  help

Reads: Creating a Modern Mentoring Culture by Randy Emelo

I finished a couple of books last week, though I’m not sure if the 20-page “infoline” counts. So anyways, one is this infoline I read on “Creating a Modern Mentoring Culture” by Randy Emelo over at Books24x7. Here are just some of the stuff that I’ve highlighted for myself and for sharing:

Modern mentoring is connecting people across an organization to share critical knowledge and skills. Everyone has something to learn and something to teach, regardless of age or title, and people can be both mentees and mentors at the same time.

Key Pillars of Modern Mentoring

  • Open and Egalitarian
    • everyone has something to learn and something to teach
  • Diverse
    • different perspectives within mentoring communities and relationships help novel ideas and approaches arise in answer to organizational problems or issues people are facing
  • Safe and Judgment-Free
    • people don’t want to show perceived weaknesses by asking for a mentor
  • Independent and Autonomous
    • no need to try to control the amount of time people spend engaged in mentoring, the topics they connect around, or the people with whom they connect.
    • Too much rigid control will only create unwanted barriers to knowledge flowing from those who possess it to those who seek it.
    • Once you have created an enabling structure for modern mentoring, let your employees take the reins of their own learning.
  • Asynchronous
    • technology-enabled communication (email, online communities of interest, business social networks, mentoring and social learning software) is only on the rise and is a key enabling structure that supports modern mentoring
  • Self-Directed and Personal
    • Self-directed learning also allows individuals to learn what is applicable to them right now, gain skills that can help them with their unique work context, and make them more productive.
  • Technology-Centric
    • means to connect with others and a space to collaborate and communicate
  • Flexible
    • allowed and encouraged to shift in and out of your mentoring program and of the mentee-mentor roles themselves, as learning needs and knowledge strengths evolve

If the open nature of modern mentoring is compromised by too much organizational involvement, the quality of mentoring connections and the caliber of learning that takes place as a result of these connections will be degraded.

Creating a Modern Mentoring Culture

  • Re-Educate Leaders
    • need to help organizational stakeholders understand the expanded and broad vision of modern mentoring and its associated benefits
    • must be re-educated to understand that modern mentoring is a productive activity that won’t detract from employees’ effectiveness, but rather will help to strengthen it.
  • Get the word out
    • webinars or e-briefings, various media (podcasts, webinars, or newsletters), brief “commercials” at other training events
    • Sponsor roadshows or lunch-and-learns where mentoring participants share their experiences. Offering a venue for mentoring participants to meet and mingle can help energize your program and provides another opportunity for people to network and make learning connections.
    • Leverage employee resource groups, town hall meetings where a brief presentation could be followed by a question and answer session, Leverage your program’s evangelists.
  • Modernize Current Mentoring Programs
    • expanding your current mentoring programs and making them modern
    • Onboarding – new hires
    • High-potential development
      • brightest talent pull from an array of mentors and knowledge resources [instead of just one mentor]
      • allow high-potentials to be mentors themselves and share their knowledge with others while concurrently learning how to be a leader
    • Augment your formal training initiatives with mentoring cohorts
      • alumni of training programs mentor and advise a group of people currently going through training
      • Peers going through the same training can also connect and share stories around application of concepts learned in class to help cement the newly attained knowledge.
  • Amplify Using Technology
    • Let employees use technologies you have available to communicate and collaborate.
    • Make online employee directories or other skill profiles available to help participants see who would be a good mentoring connection.
    • Allow people to join your mentoring program at any time.
    • Acknowledge the efforts of those in the program.

On retrospectives

When things slip, a typical reaction is to add processes especially for tracking and monitoring. Just take the overhead effort for effort tracking for example. I’ve been in a lot of projects that at one point or another have gotten so delayed. A knee-jerk reaction is to have the team prepare more reports — daily status updates from everyone, summarized daily progress reports from the leads, reports for upper management, reports for client, etc, etc. This has its benefits — it provides more visibility on what’s going on in the project, and it can pacify stakeholders since it gives the impression that you’re on top of things. What it doesn’t do is get more of the actual needed work done. It doesn’t get more work coded. It doesn’t get more tests executed.

dilbert-19950217

Instead of just diving into the “more reports” bandwagon, what I’d like is for the team to look into how we’re currently doing. What’s working for us? What isn’t? What do we need to do differently? These are questions that usually get asked in a retrospective meeting. If we google “retrospective”, a definition that turns up is “looking back on or dealing with past events or situations”. Reflecting on what has happened is but a part of it. In retrospectives, you also try to identify what you need to bring forward to keep your project successful or to recover so that your project will (hopefully) be successful.

I think I can pretty much go ahead and do a little retrospective on my own. We all can do it individually. But that just won’t suffice. I can plan all I want but if the folks who will execute are not aligned with the plan, then the plan will just fail to materialize. And you can come up with all brilliant sorts of ideas and workarounds but if you can’t get the other guy to execute then it wouldn’t matter so much (but I’ll credit your brilliance, of course). Retrospectives need to be a team thing. WE need to come up with plans for improvement that WE are ALL willing to execute or follow through. In the end, there is no one else to drive the project’s success but US as a team.

Slideshare: 26 Time Management Hacks I Wish I’d Known at 20 by @egarbugli

I stumbled upon this deck again and it’s really something that I want to share to the younger ones. Time management wasn’t exactly something I learned when I was starting out. I came from projects where OT would become the norm at certain points, and we even had Saturday work. I was so time-poor. As I grew older, I came to realize how valuable my time is. How I could make up for losses for some things, but I can never get back time I have lost or wasted. And that the more efficiently I manage my time will allow me to spend it on things that matter more.

Saved myself some time by not writing my own presentation covering the same topic.

One of the points I like is #18 which had a quote from Jason Cohen (@asmartbear):

Only ever work on the thing that will have the biggest impact.

I think most especially for the younger ones, we often get sidetracked by initiatives or other non-project related tasks. We fill up our plate with a lot of things. We say “yes” to this and that. But then you have to think about it, step back and look at the big picture, and reflect whether the things that you are doing are really the things that you need to grow or achieve your goals. As an aspiring tester/technologist, are these tasks really relevant to making myself more technical and capable in my craft?

On being overwhelmed (an open letter to the new guys)

Hi, guys…

We’re three weeks in our current project. I know it’s still a period of adjustment for you. You have a lot to take in, and I’ve been asking you to do stuff that is new to you. I know things can be a bit difficult at first. You might feel overwhelmed. You might just want to curl up into a fetal position, hug your favorite stuff toy, and just wish everything away. I know, I’ve been there. And I’m here to tell you to not despair.

Sometimes it’s the fear of having to do something big that freezes us into inaction. We end up not accomplishing anything because our minds are too caught up at the scope of what we have to accomplish.

It is not because things are difficult that we do not dare, it is because we do not dare that they are difficult. ~ Seneca

When you feel like there’s too much in your plate, here’s what you can do. Take a step back, breathe in, breathe out. Don’t try to tackle everything at once. That’ll just be crazy. Find out what you need to prioritize at the moment, then focus on those. Try to break up the work into smaller bite-sized portions. Taking it one step at a time will make it less stressful and less daunting for you. Sometimes it’s just hard to get the ball to start rolling, but once kicked off, things get easier as you go along.

When you feel like you’re sinking, do not hesitate to call out for help. You must remember that you are not alone in this project. Your team mates are here, we’ve got our senior test automation engineer (Sr. TAE), and I am here (I’m not just a pretty face, you know). We also have support from our team leads and our manager. Don’t take asking for help as a sign of defeat or something that will be taken against you. That may be the case in other cultures or other teams, but I assure you that it’s not the case with me. But don’t take this as a cue that you can just ask for help anytime and every time. What I’d want is for you to learn how to help yourself first. And if you come to the point when you’re already doing your best and things are still not working out, that is when you reach out.

So there. I hope you don’t feel too overwhelmed. Know that you can rise above that feeling and that you have my support.

In the end, everything will be okay. If it’s not okay, it’s not yet the end. ~ Fernando Sabino, translated from Portuguese

Cheers,
KC

Basic QTP Training: Enhancing our script

The past couple of days of our QTP training covered a lot more ground. The most nifty stuff are on tools like the Object Repository, the Object Spy (which is an icon of a guy with a top hat reminding me of Professor Layton), the Active Screen, and the topics on parameterization. I created a short video covering the last 2 topics. So there I demonstrate two things:

  • Updating the script with the help of Active Screen — instead of having to record all over again
  • Updating the script to make use of parameters instead of the hard-coded values.