Modern testing for modern stacks

We have gotten into the habit of thinking deeper about one topic on a weekly basis. We pick topics based on anything interesting we read - so the topics can range from 'how to express the value of testing' to 'Dieter Rams' design principles' to 'effective remote work habits'. Employees are guided to spend no more than one hour researching the topic online. The emphasis is on coming up with their own ideas and interpretations. We then meet as a group to exchange ideas. I love this habit and consider it one of the more unique benefits you will enjoy at Qxf2.

Start with a goal. The backlog will follow.

11-April-2017

A nice reminder that understanding the problem will lead to varied solutions.Refer to this link

Our thoughts

Arun

Early stage startups tend to over utilize code as a solution. At startups, you can prevent many bugs by questioning if a certain problem/goal can only be achieved using code. Try to think of creative ways to achieve the same goal with different tools. Your engineering team may not like it at first, but they will appreciate your thinking over the long run. For example, think about emailing your customers hand-written thank you notes instead of a generic email. This about sending paper reports with cartoons in them instead of a web dashboard, etc. AirBnB has a famous example of the founders actually going to the house of renters and taking photographs.
Adopt a similar attitude towards your tests - think about the simplest ways to verify that a goal would be reached. Start there and then expand on your tests from there.

Avinash

Many of the start-up companies when they look at testing they think automation as the solution to solve their testing problem. Rather than looking at what sort of testing is required to reach their needs and what problem they are facing they ultimately end up hiring based on the wrong strategy. Also, many times goals are not escalated well to the team due to which the business and development team don't closely collaborate to achieve goals. Business wants something which may be tough to achieve with the resource available and developers may want to build what they fell feasible. Ultimately if the goals are not set and approached properly we may end up building bad solutions

Annapoorani

Before we start our work, we have to consider what we want to achieve and then we have to commit it.For example before writing the test we have to think what are all the specific functionalities needed, is it relevant for the test, how much time needed to write it.Once we are set with all the constraints then we can plan the steps and we can work on them to achieve our goal. So overall if we are going to develop new features then we have to ask these three questions to ourselves, what problem are we solving? how do we know it's a real problem? and how will we know if we have solved it?

Shiva

This is a good article urging to start with a goal. Start-ups concentrating on adding features sometimes forget the ultimate goal. I found what was said about thinking in a customer's perspective to be interesting. It is nice to think as a customer to attain a perspective. Perspective is needed while developing a product as it gives you an idea when you are in a position to choose between A and B. Another contradicting theory about trying to be in customer's perspective is that: "A lot of times people don't know what they want until you show it to them"-Steve Jobs. The only logical conclusion on those theories is that it one should be aware that both theories exist while making decisions.

Smitha

It's a good article which insists to start with a goal. I do believe that when you start planning, you should start with a goal and break down your plan into simple steps, ensure that it doesn't get complicated or complex. Many start-ups start with a goal but as they progress further, they don't check on the goal and sometimes the goal seems to be lost or changed. I agree to Arun's comments that we should take simple steps to verify the goal.

paper cut