Things Every New Software Tester Should Learn

This is a guide to learning more about software testing. As you start on your journey you will have tasks you can work through. Software testers are always learning but we cannot always quantify it. We learn about the product we are testing. We learn and develop relationships with developers, managers and testers. This makes us great at what we do. We are also chameleons. We change based on the environment we are in or the product we have to test. We have to continue to educate ourselves about the tools we need to test each product.

1. Are you interested in software testing?

Let's start with a little self-reflection.
An important part of being a tester is your mindset and being aware of it.

• Why is software testing valuable to you?
• What do you believe software testing is? We'll talk about this more in the next Task but it's good to think about what you currently believe it is.

Take a moment to think about the questions above and other questions you might have. By the end of this guide the aim is to have the majority of those answered. You're going to have more questions as you go too. Questions prompt a search for answers which results in learning.
We are surrounded by tech daily. There may be things you use in your everyday life that bother you. Perhaps a software package at work that takes longer than a minute to load. The app on your phone that freezes just after an update. Or perhaps when you get locked out of your emails and discover you can't recover or reset your password. You might have started to think more about that software package by maybe looking at your task manager as it loads.
Can you be a person who strives to make software better? Can you be an advocate for the users? The business? Your work colleagues?
Do you know what it takes to get there? Do you know what you need to learn? Think about all the good and horribly bad software you have come across in your life. You are the chameleon in both. In the good situation you want the product to stay good so you keep learning to stay on top of it. In the bad situation you want to learn more so you can feel like you did everything you could before the software was released. Learning is the key. No matter the situation you will always be learning even if you aren't aware of it.
This sounds daunting, don't let it put you off. Start with the first question and think about it. By the end of this guide you will be more confident in your answers to all of these questions.
What to do next:

• Commit to print why you are here (a post-it or whatever medium you prefer)
• Where do you plan to be at the end of this?
• What skills do you have now that you think are useful for testing?
• What do you currently perceive software testing to be?

2. What is software testing?

Start by writing down what you think software testing is and what a software tester would do.
There are many aspects to software testing. It does not always involve using the product. It is not just about finding bugs. Testing can start around the requirements stage. Thinking about what the product should do, where risks could be, and how the user/customer navigates the product is all part of testing.
One discussion I recently had, about whether it is fair to assume that customers are your users, gave me perspective on terms we use to represent stakeholders. Stakeholders, to me, covers everyone who has an interest in the software product. In the end we agreed that the person who pays for your software may not be the one who actually uses it. This is a great example of how software testers should look at things from different perspectives. Below are examples gathered from discussions with other testers about what they think testing is or is not.

What Testing Is	What Testing Is Not
Verifying whether software meets the expected value to its users. Investigating the product to find any information that is of value to our stakeholders.	Simple, quick, predictable. Only verifying that the product matches the description.
Mitigating surprises - Trying to find problems before software is released to stakeholders.	Increasing quality - this is a whole team exercise. Prove that the software has worked once.
Exploring products. A valuable activity in software development but often misunderstood due to its unpredictable and creative nature.	Well understood or valued by everyone. A process that is fixed, unimaginative and best kept under strict rules.
Communicating - with stakeholders (customers, users, developers, etc.) and work together to find out if the product is improving.	A phase that a project needs to go through in order to be successful.
Infinite. All testing is sampling. For every non trivial product, there are an unimaginable number of parameters with a great number of possible values. How do you know you are testing the important ones?	Ever finished - we can make decisions about stopping criteria but there are an infinite amount of combinations that could be checked.

What to do next:

• Read this list of things of what software testers do. 
• Try asking people around you about the title of this task. Ask people you work with testers and non-testers, ask people on Slack and maybe even ask your family. Has this changed much from what you originally thought? How different were the responses you got?
• Research other industries such as pharmaceuticals, appliances etc. What is their approach to testing? How different or similar is it to the tech industry? Do any of the differences change your thoughts on how you would approach testing?

3. Testing for non-testers

When I started in software testing I had no idea what testing was. I also had no clue of where to start. One of the most useful resources I came across was the pathway Testing for non testers by Katrina Clokie. Using Katrina's pathway I was able to understand testing and the value it provided. I was also able to investigate her references further to start expanding my knowledge and list of people I should look to for advice.
This is one of the things that will not be done overnight! I recommend reading it and referring to this guide each time. Are there any things you want to practice? Are there any things you don't and if so, why? Has this changed the thoughts you wrote down?

What to do next:

• Share the link with your team
• Read an article a day from Testing for non-testers
• Create your own list of things to learn and practice. You will most likely be updating this constantly

4. Get social

This will be a slightly easier task to get started with but you will need to put in effort to keep it up. Start as simply as you like or feel comfortable with. I do recommend achieving all of the steps below when you can.
Engaging in social activities has enabled me to meet local testers who are willing to help me when I come across a tough problem. Through these social gatherings, I have made some friends in a city I am new to. It's nice to have a sympathetic ear with friends who understand what you are talking about.

What to do next:

• Go to Meetup.com and look for a local software testing meetup
• Join the testers.io or Ministry of Testing Slack
• Join Twitter, start finding testers to follow and get involved in some conversations 
• Join The Software Testing Club
• Read Andrew Morton's blog posts on attending the Bristol STC meetup and the Cardiff STC meetup
• Start looking up testing conferences such as TestBash, Agile Testing Days, EuroStar, STPCon, Global Testing Retreat, TestCon, STAREAST, Let's Test, Nordic Testing Days. They are a big part of getting social.

5. Get organised

It can be difficult to stay organised when there is so much information being thrown at you. I struggled with this a lot, I still do occasionally. Tiny Habits was recommended to me by another tester when I was getting started. I go back to it frequently and set myself new tiny habits to achieve, particularly when I feel like things are going awry. This does not take a lot of time but it will save you in the long run.
You might also want to think about writing mind maps. There are a lot of free tools out there to help you with this. I find a mind map can help me streamline a random thought process a lot easier. Ever had a million ideas running through your mind that are loosely related but you can't get them into a sensible order to make something of? Mind maps can help with this, so can the good ole reliable post-its on a wall approach.
What to do next:

• Sign up to Tiny Habits and do it for a week
• Start a mind map
• Create a personal Kanbanflow or Trello board. Start with the column headers "To Do", "In Progress" and "Done". Add a card for each thing you would like to achieve and move them across the columns as you progress with them.

6. What is a bug?

I know a bug in software when I see one, or at least I like to think I do. I thought it would be easy to explain what a bug is. When I tried to find a definition I found many that just didn't cover the scope enough. James Bach defines a bug as "Anything that threatens the value of the product. Something that bugs someone whose opinion matters". That is a nice high level definition. On Testing Computer Software you will find "most bugs cause a program to change its behavior when the programmer didn't want or expect it to, or cause the program not to change its behavior when the programmer did expect it to".
In most of the definitions I found them to only mention the code or the developer. None of these are wrong. This would threaten the value of the product and it would not then be a bug with the code.

Think about the technology you use:

• Have you encountered bugs in any of it?
• Why did you feel like they were bugs?
• Did you do anything about it (e.g. report a bug in an app through the app store)?
• Can you think of three different things that help you decide whether a bug is actually a bug or not? These are called Oracles and we will look at them in more detail in Task 13.

7. Write a user story

A user story is like a set of instructions you get with flat pack furniture. By writing a user story it will help you to understand their purpose.
It should provide:

• A description of what needs to be done.
• Acceptance criteria outlining what the story needs to accomplish.
• Any criteria which are out-of-scope for the story to be considered accomplished.
• Note any dependencies required to start the story.

Mountain Goat Software has examples of agile user stories to give you an idea of what to expect when you're out in the wild. EPICs are essentially a large user story. They are broken down into smaller digestible or deliverable pieces called user stories.
Take the user story below as an example, the overall EPIC would be "Flat Pack TV Stand". The user story is then a smaller piece of that "Left Leg and Top Shelf Construction". The dependencies are things that we need but not things we would do, for example we would need a screwdriver to be able to assemble the shelf. The acceptance criteria are things that we actually have to do.

Writing a user story will help you to think about writing requirements for users more. It will also help you to think about the approach to take for testing these user stories. As a tester you will have a unique set of skills when it comes to analysing user stories. You will be able to highlight missed details, misuse cases, abuse cases and how it can be misunderstood. Not everyone gets the chance to provide early input with user story writing. It is an excellent process, you are testing before there is ever a piece of code written!
Your tasks for today:

• Write a user story for making toast, a peanut butter sandwich or even Ikea furniture using the templates above.
• How do you know if you missed something?
• Have you made any assumptions?
• Think about the order things need to be done in. Are there any optional inputs?
• Are there any requirements or prerequisites (assume the user has bread for example)?
• Try to make toast or a sandwich from scratch following your user story exactly. 

8. Testing personas

When you are testing you shouldn't only test for you. You need to think about impatient users, users who take their time, users who have a bit of a tester in them and like to "break" things and many more. As you get familiar with an application, things like this may slip from your mind and you may go into autopilot somewhat. I find trying to get into the user persona more helps me to avoid this pitfall.
Before thinking that personas may not already exist within a project, it may also be worth looking into whether personas research and documentation already exists. You can then use it to build things from a testing perspective.

For today:

• Pick an app on your phone or a program on your computer to test
• Navigate through it using the different user personas 
• What did you learn from this?
• How did the application perform under each persona?
• Think about and research how others approach personas

9. Test a user story

There are many ways to document testing but we will not focus on those here. If you've never written testing documentation, you could look at the test case templates on Tutorialspoint.
While writing the user story, you were testing it just as well, weren't you? But the thing that has changed is that you now have an actual product at your disposal and that makes a world of difference.
You now have something to get hands on with, you can leave the theory behind and put it to practice. This is where you start using your ability to learn. The speed and precision with which you can learn new and interesting information will define your skill and value as a tester.
Concentrate on your mindset as you test the story. This is the most important part when testing a user story.

Questions to ask yourself as you test this story:

• Who is this story important to?
• What is the one problem this User Story tries to solve?
• How could this be misunderstood?
• How could accidental bugs find their way into this?
• What behaviour should it absolutely NOT show?
• When are you done?
• At what point did you feel like quitting your analysis and want to start testing?
• Does this feel reasonable?

10. White & Black Box Testing

White and Black box testing are two approaches to software testing. Think of them as two umbrellas for types of testing to fall under.
White or Glass box testing is a testing method where the tester knows the internal workings of the program.
The tester writes a strategy to test the program based on knowledge of the application's internal code. They understand what the function is doing and what inputs will produce what outputs. This type of testing typically focuses on coverage of statements, lines of code, branches of code, etc. White box testing most often applies to unit tests.
One of the biggest risks with this type of testing is the inability to find missing features. You cannot cover a line of code with a test if the line of code never existed. The tester is required to have knowledge of the language that the program was written in. With this type of testing you are also naturally biased with your thinking patterns given the time you have spent within the product. As a result, you might miss obvious or non-obvious problems due to being too close too it. Think about signing in to your emails. It's something you do every day and you follow the same pattern every day. When was the last time you noticed a change on the login page or process? You become so used to what you expect to see that you may not notice the unexpected.
Black box testing is a method where the internal workings of the program are unknown to the tester. Tests are based on the requirements and functionality. One of the advantages of this over white box testing is the possibility of identifying missing code statements. This approach does not require the tester to have any knowledge of the language that the program was written in. A risk with this type of testing is the unknown level of coverage that testing gives.

What to do next:

• Try out doing some of the Black Box Puzzles
• Try testing any mobile app you have on your phone, you would essentially be doing black box testing

11. Accessibility Testing

Do you know anyone who is colourblind or maybe uses a screen reader? I know people who are colourblind, visually impaired, deaf, dyslexic or have photosensitive epilepsy. As a result I am always thinking about these users along with the 'standard' user set for our application. Luckily there are tools that can test an application for its accessibility level. A fun and easy trick to try is navigate through an application you are testing with no mouse or trackpad. Sounds easy right? Give it a go and see what you think. There are a few more quick things to try in this 6 Simplest Web Accessibility Tests Anyone Can Do. There are various plugins you can add to your browser to view your application the way someone with colourblindness would.

What to do next:

• Pick an application and try some simple accessibility testing on it. Did it perform as you expected? Were there any issues you encountered?
• Read A Software Tester's Guide to Web Accessibility.
• An Alphabet of Accessibility Issues is a great article to give you insight into the variety of needs people have.

12. User Experience (UX) as a tester 

The user experience is pretty much what it says on the tin. It is how the user experiences your application and how they respond when they use the application. Don Norman describes it as even more than that. Testers are often tasked with understanding user experiences and helping ensure the user has a good experience by reporting back any possible issues to the rest of the team. Even before the product is out on the market, testing can help to highlight UX issues. An example would be a page takes a long time to load. A user wouldn't wait that long because the competitor product hasn't got the same issue. We should investigate the delay and try to fix it.
The Nielsen Norman Group have an article about heuristics for user interface design which can help with the user experience.
At the end of the day it is users who will give you feedback on their experience with the product. As a tester you can help to ensure that their initial experience is a good one.

What to do next:

• Start to really think about user experience.
• Can you recall a stand out positive user experience you had?
• Can you explain why you felt it was positive?
• Do the same for the negative case.

13. Regression testing

A big part of software development is getting things to work together and keeping them working together. Even if loads of time and effort go into harnessing these implementations you'll find cracks within the surface.
Regression testing is a technique that tries to find problems in software that has worked before, but is now broken because something was changed.
Many Testing concepts are introduced because of regression and the uncertainty this gives developers and managers. Automated checks, rerunning Test Cases, elaborate smoke tests, are all in place because of regression issues.
Regression testing involves re-testing features that previously worked to ensure that they are not affected by the addition of new features or refactoring of existing ones.

What to do next:

• Think about a time when one feature in one of your favourite apps didn't work anymore. This might be in a game such as Pokémon Go, Facebook, Netflix application, or any other product that does frequent updates.We've grown quite used to these frequent updates and bugfixes. Additionally, a malfunctioning feature might be fixed tomorrow. Sometimes, this backfires and users get fed up and discard the product entirely.
• Consider the strategies these companies use to tackle their regression issues and compare them with strategies used in your company. Are they very different? Does that make sense to you? Can you come up with other strategies?
• Do you have something that you can practice regression testing on? Let's think back to that app on your phone. Did it recently update? Have a look around at the new functionality that the app creators say they have added. Has it broken functionality that previously worked? If so report it to them. They might already be aware of it but if not you've helped improve someone's experience.

14. Agile testing

If you're quite new to the software scene you will not have heard of development practices such as Waterfall, Agile or DevOps. These are methods or approaches to software development. A key thing to notice in the diagram below is where testing fits into each of the approaches. DevOps is relatively new to the scene. We'll start with Agile to ease you in and you can research DevOps more later.

15. Pairing (Pair Testing)

Pair testing involves two people working together at the same machine with a single keyboard to test a piece of software. One person has the keyboard while the other suggests ideas or tests, pays attention and takes notes, listens, asks questions, grabs reference material, etc.. There should be a shared goal with this approach and the two people will constantly communicate to ensure that the goal is achieved. Communication is key with this testing approach. Both people involved should have a shared understanding of what they are doing and why they are doing it.
This is easy and fun to do. You only need you and one other person. I try to do this as much as I can in work. It is a great way to get a different perspective on your work and maybe even learn a new skill.

What to do next:

• If you're not in a software house ask someone from the meetups you attended or off Twitter or Slack, you could even try remote pairing.
• Pair with this person and reflect on your experience.
• What did you learn from it?
• What could be better next time?
• Would you do it again?
• What did you teach the other person?

16. Mob Testing

This is not something you can do by yourself but you should read up about it in the Mob Programming Guidebook. If you can, try to do it in work or get a few people together to try this out. A good chance to do this is at the end of a sprint demo session. Start with a 15-30 minute slot with the whole team. Get them to start asking questions and testing the product as a team. This is a great way to get non testers involved in testing and possibly help generate some new ideas or approaches.
If you're lucky the meetup you attend might try this. If they don't try it, ask them! Any meetup organisers I know are crying out for feedback from the community of what they would like to see. It may not be something you can do at the moment but it is definitely something you need to be aware of.

17. Exploratory testing

Exploratory testing is one of my personal favourites. You get to explore areas of the application that you most likely didn't cover with other testing methods or covered, but you felt like you could investigate more. There are some really interesting articles I will advise you to read for this. Most of them are quite recent!
James Bach has written his thoughts about What is Exploratory Testing. Simon Tomes recently wrote an excellent article where he gave three digestible diagrams to describe exploratory testing. I particularly like this article as someone who learns more from diagrams than text. I would also like to highlight the book Explore It! that I mentioned earlier. This book is definitely a go to for exploratory testing.
What to do next:

• When you are done reading them pick something you would like to explore, maybe an app on your phone as you take the train to work.
• Explore with intent for the day!
• Did you find anything unusual?
• Did you feel like you explored it enough?
• Would you approach it differently the next time? 

18. Mobile testing

I would call this a specialisation. I've put it in here so that you have resources to be aware of the specialisation. Maybe you'd like to specialize in mobile testing or your job requires knowledge of it. Check out this quick introduction to mobile application testing. There are channels on both Ministry of Testing and testers.io Slack for mobile testing where you can ask for guidance if you wish.
Think about the apps on your phone. If you go into the about section for them does it say anything about the operating systems they support? Given what you now know about mobile testing does this surprise you?
When you're finished getting to grips with mobile testing you might want to try the 30 days of mobile testing challenge. 

19. Security testing

We've all seen the big hacks over the past year or more: TalkTalk, Ashley Madison, 3pay, Tesco. Security testing is becoming more important than ever before.
As the world around us changes and we start to (sometimes unknowingly) put more information out there about ourselves.
This task is just a starter to get a flavour of security testing. Again, it is probably one of those tasks that won't be just a day.

Your mission for today is:

• Watch or read about an introduction to security testing and see if it is something you would like to explore further 
• Check out OWASP and the incredible resources they have

20. Automation

Automation is a huge topic of debate and discussion within the software testing community. When you delve into this topic be prepared to hear such things like "automation fixes everything". These perceptions are the possible cons of automation. You may also read things about "testing vs checking", please do not be put off by the language used, I know I found it overwhelming at the beginning. One of the pros of automation is that it is a way to enhance the coverage you have of your application. You are only one person and you can miss things in re-checking of features, you are human. Computers can be very good at doing some things that people often fail at. Possible tools to use for automation are varied and can depend on the type of application you are working with. One of the main things I struggle with for automation is how do you decide what to automate.
If you want to give automation a try I recommend checking out the course from Richard Bradshaw or Alan Richardson to get you started. Of course Selenium is not the only automation tool out there, but I have personally taken these two courses and can highly recommend them. Have you found any others? Did you find them useful? Share them with others looking for these resources.

21. Performance testing

Have you ever been in an online queue for either of these? Load and performance testing can help the whole team to get an estimate of possible weakness in the product before it is released to customers.
Performance testing aims to determine how responsive an application is under normal load conditions. Examples of questions that performance testing tries to answer are how long a transaction takes to complete or a page takes to load. It can help teams see if a site can handle the projected number of users. A performance test in a tool like JMeter would keep the number of users at a normal level, where normal would be based on the requirements for the system.
Load testing is done to determine how the system responds under heavy load conditions. It would measure response times and resource utilization under this heavy load. Load testing also helps to determine when the system breaks and if it is graceful when it does so. A question we may like answered when we do load testing would be how many transactions are we actually capable of dealing with when the system is under heavy load. When running a load test the level of users is kept high to get an idea of how the system will respond under the level of usage.

What to do next:

• Read this Load Test Article by Scott Stirling which gives a nice breakdown of load, background, stress and performance testing
• Investigate the JMeter User Manual

Read more...

Floating Action Button(FAB) with Animation in Material Design

Floating action buttons are used for a special type of promoted action. They are distinguished by a circled icon floating above the UI and have special motion behaviors related to morphing, launching, and the transferring anchor point.
Most of the Material Design apps use the important element as FAB which covers important functionality of their apps. 
Floating action buttons come in two sizes: the default and the mini. The size can be controlled with the fabSize attribute.
As this class descends from ImageView, you can control the icon which is displayed via setImageDrawable(Drawable).
The background color of this view defaults to the your theme's  colorAccent. If you wish to change this at runtime then you can do so via setBackgroundTintList(ColorStateList).

1. Floating Action Button
You can place a floating action button using below design support widget. The layout_gravity attribute is used to define the position of the button.

<android.support.design.widget.FloatingActionButton 
android:id="@+id/fab" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:layout_gravity="bottom|end" 
android:layout_margin="@dimen/fab_margin" 
android:src="@android:drawable/ic_dialog_email" />


2. Creating New Project

1. In Android Studio, go to File ⇒ New Project and fill all the details required to create a new project. I gave my project name as FAB and package name as com.androidxu.floatingbutton

2. Open build.gradle and add design support library dependency.

com.android.support:appcompat-v7:23.1.1 and com.android.support:design:23.1.1

dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) test
Compile 'junit:junit:4.12' 
compile 'com.android.support:appcompat-v7:23.1.1' 
compile 'com.android.support:design:23.1.1' }

3. Open dimens.xml and add below dimensions. You can see fab_margin is added as 16dp

4.Open the layout file of main activity (activity_main.xml) and do the below changes. You can see the Floating Action Button is added in the below layout. This layout contains the toolbar and floating action button needed for the activity.

<?xml version="1.0" encoding="utf-8"?>
<android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/activity_main"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.androidxu.floatingbutton.MainActivity">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Example of Floating buttons"
        android:textSize="20sp"
        android:layout_gravity="center"/>

    <android.support.design.widget.FloatingActionButton
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom|end"
        android:layout_marginRight="16dp"
        android:layout_marginBottom="180dp"
        android:src="@drawable/ic_action_settings"
        android:elevation="6dp"
        android:id="@+id/settings"
        app:pressedTranslationZ="12dp"
        android:backgroundTint="@color/fab1_color"
        android:visibility="invisible"/>

    <android.support.design.widget.FloatingActionButton
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom|end"
        android:layout_marginRight="16dp"
        android:layout_marginBottom="100dp"
        android:src="@drawable/ic_action_share"
        android:elevation="6dp"
        android:id="@+id/share"
        app:pressedTranslationZ="12dp"
        android:backgroundTint="@color/fab2_color"
        android:visibility="invisible"/>

    <android.support.design.widget.FloatingActionButton
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom|end"
        app:fabSize="normal"
        android:layout_margin="16dp"
        android:src="@drawable/ic_action_more"
        android:elevation="6dp"
        android:id="@+id/more"
        app:pressedTranslationZ="12dp"/>

2.1 Floating Action Button Click Listener

The click event listener of fab is same as a normal button click event. Add the below code to your MainActivity.java to take appropriate action when fab is clicked.

FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
        fab.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                // Click action
                Intent intent = new Intent(MainActivity.this, NewMessageActivity.class);
                startActivity(intent);
            }
        });

2.2 Adding the click Event in other two  Floating Action Button


Add the below code with combining the animation and other two action buttons in MainActivity.java.

package com.androidxu.floatingbutton;

import android.support.design.widget.FloatingActionButton;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.view.View;
import android.view.animation.Animation;
import android.view.animation.AnimationUtils;
import android.widget.Toast;

public class MainActivity extends AppCompatActivity implements View.OnClickListener {

    FloatingActionButton fab_more,fab_settings,fab_share;
    Animation open, close, rotateclock,rotateanticlock;
    boolean isopen = false;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // typecasting the buttons
        fab_more = (FloatingActionButton) findViewById(R.id.more);
        fab_settings = (FloatingActionButton) findViewById(R.id.settings);
        fab_share = (FloatingActionButton) findViewById(R.id.share);

        // loading the animation from xml file
        open = AnimationUtils.loadAnimation(getApplicationContext(),R.anim.fab_open);
        close = AnimationUtils.loadAnimation(getApplicationContext(),R.anim.fab_close);
        rotateclock = AnimationUtils.loadAnimation(getApplicationContext(),R.anim.rotate_clock);
        rotateanticlock = AnimationUtils.loadAnimation(getApplicationContext(),R.anim.rotate_anticlock);

        // setting up the onClickListener() method
        fab_more.setOnClickListener(this);
        fab_settings.setOnClickListener(this);
        fab_share.setOnClickListener(this);
    }

    @Override
    public void onClick(View view) {
        switch (view.getId())
        {
            case R.id.more:
                if(isopen){
                    // more button is already open
                    fab_settings.startAnimation(close);
                    fab_share.startAnimation(close);
                    fab_more.startAnimation(rotateanticlock);
                    fab_share.setClickable(false);
                    fab_settings.setClickable(false);
                    isopen = false;
                } else{
                    // more button is already close
                    fab_settings.startAnimation(open);
                    fab_share.startAnimation(open);
                    fab_more.startAnimation(rotateclock);
                    fab_share.setClickable(true);
                    fab_settings.setClickable(true);
                    isopen = true;
                }
                break;
            case R.id.settings:
                Toast.makeText(getApplicationContext(),"You clicked settings",Toast.LENGTH_LONG).show();
                break;
            case R.id.share:
                Toast.makeText(getApplicationContext(),"You clicked share",Toast.LENGTH_LONG).show();
                break;
        }
    }
}

2.3 Adding the animation to Floating Button

To add animation to the material design element create anim folder in res Folder .Adding the animation element by creating xml File

create  fab_close.xml

<scale
    android:duration="300"
    android:fromXScale="0.8"
    android:fromYScale="0.8"
    android:toXScale="0.0"
    android:toYScale="0.0"
    android:interpolator="@android:anim/linear_interpolator"
    android:pivotX="50%"
    android:pivotY="50%"
    />

<alpha
    android:duration="300"
    android:fromAlpha="1.0"
    android:toAlpha="0.0"
    android:interpolator="@android:anim/accelerate_interpolator"
    />

2.3.1 For Rotating  animation to the Fab add the rotate_clock.xml

<rotate
    android:duration="300"
    android:fromDegrees="0"
    android:toDegrees="45"
    android:interpolator="@android:anim/linear_interpolator"
    android:pivotX="50%"
    android:pivotY="50%"
    />

Now run the Application and Enjoy!!

Read more...

Microsoft Office 365 Product Key

Microsoft Office 365 Pro Plus Product Key:

KDVQM-HMNFJ-P9PJX-96HDF-DJYGX

4HNBK-863MH-6CR6P-GQ6WP-J42C9

366NX-BQ62X-PQT9G-GPX4H-VT7TX

KBDNM-R8CD9-RK366-WFM3X-C7GXK

6KTFN-PQH9H T8MMB-YG8K4-367TX

Serial Key for MS Office 365 Home Premium:

MH2KN-96KYR-GTRD4-KBKP4-Q9JP9

N4M7D-PD46X-TJ2HQ-RPDD7-T28P9

2MNJP-QY9KX-MKBKM-9VFJ2-CJ9KK

NK8R7-8VXCQ 3M2FM-8446R-WFD6X

MTDNG-PDDGD-MHMV4-F2MBY-RCXKK

2B8KN-FFK6J-YWMV4-J3DY2-3YF29

PBTFM-WWN3H-2GD9X-VJRMG-C9VTX

MS Office 365 for Mac Product Keys:

G9N3P-GRJK6-VM63J-F9M27-KHGXK

GYWDG-NMV9P-746HR-Y2VQW-YPXKK

DMXHM-GNMM3-MYHHK-6TVT2-XTKKK

6HDB9-BNRGY-J3F83-CF43C-D67TX

GPT9W-CWNJK-KB29G-8V93J-TQ429

X2YWD-NWJ42-3PGD6-M37DP-VFP9K

46DNX-B4Q98-PQVPW-Q8VM6-FVR29

WTFN9-KRCBV-2VBBH-BC272-27GXM

PNP4F-KY64B-JJF4P-7R7J9-7XJP9

Product Keys for Office 365 Pro:

N2P94-XV8HD-W9MHF-VQHHH-M4D6X

7TPNM-PMWKF-WVHKV-G869H-9BQ6X

433NF-H7TMK-TPMPK-W4FGW-7FP9K

MS Office 365 Home Premium Product Key:

XRNFT-HG2FV-G74BP-7PVDC-JB29K

N7PXY-WR4XP-D4FGK-K66JH-CYQ6X

DJC4N-DX7PC-GM3GK-V8KKW-XWYGX

XRNFT-HG2FV-G74BP-7PVDC-JB29K

Read more...

Qualities of an Effective Technical Lead

Becoming a Tech Lead is a tough transition for any developer, because only part of the skills and experience you had as a developer prepares you for the expectations of a new role. Instead of simply designing and writing code, a Tech Lead is suddenly responsible for an entire development team - and this means dealing with people, both technical and non-technical.

The time a developer spent focusing on writing well-designed code does not translate into the skills necessary for understanding people, resolving conflict, or suddenly having to juggle more tasks than they can possibly achieve by themselves.

Here is few tips for being an effective Technical Lead:

1. Learn to Delegate

As a developer, you get a kick from working out what the hard, technical problem is to solve. You research different ways to solve the problem, seek the most simple solution and celebrate a victory when you want that red, failing test going green.
As a Tech Lead, you cannot take on all the coding tasks, and cannot take on all the hard or interesting problems, regardless of your experience. You have many more responsibilities that need time and attention, and if you are focused solely on a single task, those other responsibilities will fail to be fulfilled. When you take on the harder problems, it also misses opportunities for other developers to grow and problem solve, which will lead to frustration and potentially people leaving your team!
Of course, there are some problems when your experience and knowledge are important, but you do not want to be a bottleneck in solving problems, so you want to find a way to delegate and still be involved. Solutions might include kicking off a design session with developers to talk about general approaches, and reviewing progress with the developer on a regular basis to see if things are on track.
As you and the developer build trust with each other, you can be less involved and fully delegate an activity to let you focus on more important tasks.

2. Find Time to Code

The role is called "Tech Lead" for a reason, and it is essential that you find some time to spend in the codebase. Being involved in the code helps you build respect with the rest of the team, but it also helps keep your knowledge up to date and current with constraints, problems and the "shape" of the current codebase.
If you do not spend time with the code, you run the risk of invoking the "Ivory Tower Architect" anti-pattern, leading technical decisions without understanding their real implications for implementation or maintenance. This anti-pattern has numerous side effects including destroying trust with developers, increasing the development time of new features, and increasing the accidental complexity of your software systems.
There are many different ways a Tech Lead can find time to code, but it is essential that you make it a priority. This often means making difficult choices about where you spend your time. Tip #1 should help increase the amount of available time you have. I know some Tech Leads who will block out time in their calendar to ensure that there is always time during the week to write or review code with the other developers. I know of other Tech Leads who review commit logs, and provide feedback to developers - similar to a loose pair-programming style.

3. Visualise Your Architecture

I have worked in several teams where developers had no idea how their task fit into a bigger picture. A small technical decision made by a developer might have a wider architectural impact, but is impossible to prevent if developers do not understand the broader picture.
An effective Tech Lead often has a visual representation of their system architecture on-hand and uses it to have discussions with developers. There will often be different views of the architecture (logical, deployment, etc) and each diagram helps developers see how their task fits into a broader system architecture.
A whole-team whiteboard session is often a useful exercise for reviewing the overall architecture, as it evolves over time to meet differing requirements and the discussion during the session is even more important than the diagram. Focus on key quality attributes that drive out your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context to help developers guide their everyday decisions.

4. Spend Time 1-on-1 with Team Members

An effective Tech Lead will not be measured with how many coding tasks they complete. They are measured by how effective their software team is. Anything that a Tech Lead can do to make each person on their team better, makes the overall team better. Sit down with members on your team to understand their backgrounds, their strengths, their interests and their goals to understand how the people in your team fit together as a group. Connect developers with opportunities for them to grow. This means allowing them to take risks so they can learn and grow, but also contribute to the team. Encourage people sharing knowledge across the team and find ways to help each team member connect with each other.

5. Learn to Speak the Language of the Business

To be an effective Tech Lead, you will need a great relationship with people outside of the development team including people like Product Managers, Marketing, Sales and CxOs. They will not understand the vocabulary you accumulated as a developer, and talking to them in terms of frameworks, technical tools and platforms will only confuse them.
An effective Tech Lead finds ways for non-technical people to understand technical concepts, and the best way to do that is to find the terms that business people use and find ways to explain tasks in those terms. Use visual models, whiteboard sessions and metaphors to help business people understand technical concepts and their implications. You might rehearse on friends or relatives who don’t work in technology to see if you can succinctly explain an idea.

Minimize the translation layer as much as possible by bringing business terms into the development team and encouraging their use as much as possible. The better the developer team uses these domain terms, the better their understanding and empathy with business stakeholders will be.

Read more...

Delivery Manager Roles & Responsibilities

A delivery manager guards the team’s time, to ensure continuous delivery is possible. Team time is precious time.  

Quite simply, a Delivery Manager is responsible for the delivery of projects and products, particularly using Agile methods. They need to work closely with the Product Manager and the rest of the team to define the vision, keep everyone on the right track and ensure common priorities feeding this into the prioritization of work ensuring that all products are built to an appropriate level of quality for the stage (alpha/beta/production).
In many ways, the role of Delivery Manager can be seen as an evolution of the traditional role of Project Manager. The Delivery Manager is primarily there to serve the needs of the team, and lead them in the right direction. To shield the team from anything they shouldn’t have to worry about and which could impact on delivery. A good example of this might be removing ‘blockers’ or obstacles to progress: negotiating with stakeholders, refocusing senior leadership, or addressing procurement issues for example.
Like troubleshooting? A good Delivery Manager should also be able to spot warning signs, to foresee and remove blockers before they become problematic - often, this means providing constructive challenges to senior management on issues.
If you’ve got good communication skills, Delivery Manager might be the kind of role for you as well. It’s important to be visible to staff and stakeholders and to regularly undertake activities to engage and build trust with people involved in area of work. Clarifying strategies and plans, and communicating a clear sense of direction and purpose for self and team, are the best things we can do to help these projects along.
Delivery Managers should actively participate in the agile delivery community; sharing and re-applying skills and knowledge, and bring in best practice across the organisation and government.
On a day-to-day basis, a Delivery Manager might lead collaborative and planning processes, prioritizing the work that needs to be done against the capacity and capability of the team. This might include facilitating daily stand-ups and other sprint ceremonies, and coaching teams on Agile tools and techniques.

People who are unhappy in their jobs are undoubtedly less productive. So it’s very important for the Delivery Manger to also ensure teams are able to, not only work effectively by having a productive working environment, but are happy at work. A Delivery Manager will strive to make working with the team, and within the organisation, an enjoyable experience.

Read more...