Learnings from a failed project.

Recently, a project I was part was removed from the team, at first this feels like we failed. Failed to deliver what the project needed.

I have taken some time to process this, and to not feel that it was all wasted tim. There is always things that you can do better, in every project in retrospect. A couple of things that come to mind is team size expanding too much, to quickly and having an ever moving requirements expectations that differ between the developers and the product owners.

But even though we found that we were not achieving enough to continue on the project for now, there were many valuable lessons along the way. The team as a whole learned to adapt to the constant changes to the team and the deliverable expected of them, the team learned to adapt really quickly and accept the change. I bet that many of the team have personally learned a skill or two along the way

I personally developed my ability to lead a test team, it was a big challenge to develop some of the things that I did such as holding people accountable and answering awkward questions under stressful situations (saying a deadline wont be hit for some stories...etc).

So the project itself did not grow into what it needed to be, but we as a team and as individuals learnt a lot of useful experiences that can be applied to it for the next time that a project of the same calibre joins the team.

My point really here is that when you are going through a rough project, a project that is failing or really stressful. In there somewhere, you will usually learn something, that will be useful for next time to make more refined decisions and possibly enough that the next project will be a success!

Motion blur, the faster you go, the less you see

I have found myself in a position of leading a test team in a fluctuating and unstable environment. With all the turmoil that has disrupted the flow of the team, I have noticed things are being rushed, DODs not followed and as a result easily visible bugs were missed. We have now spotted this issue and now putting ourselves back on track to keep the quality high.

We know we need to keep the pace up, but remembering that going fast isn't always good, sometimes motion creates blur and it blinds you.

The Copinator!

As a tester, I spend a fair amount of time testing the CMS and also user fields. While testing these fields, I spend a lot of time copy pasting different character types into the same fields in an attempt to ensure they will all work as expected.

I noticed this was using roughly the same characters across different character sets and wanted a consistent and easy way to produce the letters required instead of searching for them every time either in documentation or on the web. So I built a desktop app!

Its nothing sophisticated, just copies a set of characters to the windows clipboard. but saves a lot of time finding these things!

This is going to make using the fields quicker to fill and test, which is a big bonus as it can be passed onto the rest of the test team and everybody will have access to all the character sets that I use.

I have also asked for feedback from other members of the team, for character sets that they use in other projects so that they can all be added. this will allow everyone to see what the other teams are using and use their character sets as an inspiration to further test their own work.

The only negatives I can think of using this is to not become complacent in using our own imagination to find the edge cases and relying solely on the app, not a good idea! The other drawback is a small amount of refactoring if the characters change that the (Testers/ Developers) use, then it will need updating and redistributing.

But overall I think this is a nice time saver!

Leadership Update..The bigger picture

It has been a busy couple of months for the project, multiple streams of work happening at once.

Sometimes taking a step back is a really nice thing to do, allow the other members of your team take stories that you could be doing while allowing you to get the bigger picture of how everything is going to fit together. This can allow you to resolve issues found before getting more people involved meaning leaner testing times and quicker story delivery.

I tried to explain my recent example of this but it got complicated and confusing :) this is a simplified version:

A was trying to talk to B through C
B required something from C that it was not passing through
B rejected C so A could not happen.

We passed A by skipping C as it was just a middle man, but could have spent a lot of time debugging A if we hadn't seen that B didn't need the required variable (even though it was in the requirements!).
B got the variable removed by the developer.
A Could be passed without the completion of B.

As the streams of work are quite close at the moment, passing on knowledge of what the each tester is doing is quite important as shown with the example above, both parts A and B were implemented at the same time by 2 sets of people meaning communication is key :)

Leadership

My team has recently come into a position where one tester was not going to be enough resource to carry the project on in a sustainable fashion.

So we ended up with having a tester from a different internal team join us and contractor as well!

This has led me to have my first proper encounter with having a leadership role within a group of testers.

It has been a great experience so far, lets not forget though that it is hidden work at the end of the day that you don't appreciate until you are in the role.

I no longer just have to worry about the flow of work coming into me, but also into the other two team members, while also getting them up to speed on the different aspects of the project and providing the work most appropriate for them as time goes on. There is also the benefit of having many eyes and more idea's floating around of how to test things effectively.

Lets see how it goes!

Sent from Mail for Windows 10

Hello!

What is my job?

My official role title is Software Test Analyst. But what does that mean, what does that cover? Other team members call me a “Tester” or “QA member”, do I just test, or assure quality or analyse tests?

I don’t think I assure 100% quality in anything, I don’t think anybody will be able to provide 100% assurance in the quality of software provided, there will always be bugs that will make it through, even if they are really small ones that do not detriment the usefulness of the system. no matter how hard you try to find them.

I work within an agile team, I sit with the developers and have a unique relationship with our client where the product owner is on their side and we work with them directly rather than working through a proxy of a product owner/ product delivery manager.

I think my job is to increase the ability to deliver a quality product for the client, and to try to provide what they want from what we produce.

So what do I mean by that? I start work on a new project when it is in its infancy and has yet to be split into stories (sometimes even at an architectural level), I help create the stories with the developers, I help refine the stories. I then create BDD’s for the automated acceptance tests to be based on. If time permits, I will help write the automated tests.

By this point, most of the logical gotcha’s in the flow of the software should be found as BDD’s are a great way to find “what ifs”.

The developers will start writing code when the BDD’s are done, but before the automated acceptances tests are done (we are not there yet for test driven development L)

While this is happening, I will get involved in decisions for things the developers will come up with and make small decisions on how the software will behave, larger ones will go back to the client for clarification.

After the story is complete, then the story is put through a code review. And then it arrives to me ready for testing. I will test it to the requirements of the story and requirements of the definition of done (includes non-functional requirements). While this is going on, the I will start reporting bugs back to the developer(s) and explain what they are while leaving a list of bugs on out story board.

Whilst I do requirements testing, exploratory testing takes place, I find that if I do it while doing the standard testing, I am more likely to find the intricacies within the software that will hold some of the harder to find bugs. After all bugs are fixed, all testing completed. Then it will get pushed to UAT.

Most of that I would class as standard work for testers within the testing life-cycle. But I don’t think our job ends there. When live issues arrive, I participate in the hunting down of the issues as well. I also tweak the software as we go along, I enjoy adding my own input into the design of the software to try to enhance it for the end users.

So my job is more than just testing and analyzing tests, it does not assure quality, but does enhance the overall quality provided by the product to the client from the code that tests the software all the way to the user experience for those who use it.

Now, only if i could sum up all that in a paragraph!